Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135242 > unrolled thread

kForth-Win32 fix for decimal string to double float conversion

Back to article view | Back to comp.lang.forth

Contents

  kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-20 09:48 -0500
    Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-21 11:40 +0200
      Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-21 06:20 -0500
        Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-25 16:08 +0200
          Re: kForth-Win32 fix for decimal string to double float conversion peter <peter.noreply@tin.it> - 2026-07-25 17:07 +0200
            Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-25 13:22 -0500
              Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-25 13:30 -0500
          Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-25 13:17 -0500
            Re: kForth-Win32 fix for decimal string to double float conversion dxf <dxforth@gmail.com> - 2026-07-26 13:15 +1000
              Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-26 07:18 -0500
                Re: kForth-Win32 fix for decimal string to double float conversion dxf <dxforth@gmail.com> - 2026-07-31 14:54 +1000
                  Re: kForth-Win32 fix for decimal string to double float conversion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-07-31 08:35 +0000
                    Re: kForth-Win32 fix for decimal string to double float conversion albert@spenarnc.xs4all.nl - 2026-07-31 12:05 +0200
                    Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-31 07:54 -0500
                      Re: kForth-Win32 fix for decimal string to double float conversion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-07-31 16:55 +0000
                        Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-31 14:40 -0500
                          Re: kForth-Win32 fix for decimal string to double float conversion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-01 08:23 +0000
                            Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-01 06:42 -0500
      Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-21 11:30 -0500
        Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-21 14:47 -0500
    Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-25 23:42 +0200
      Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-25 18:47 -0500
        Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-26 13:11 +0200
    Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-26 13:22 +0200
      Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-26 07:23 -0500
        Re: kForth-Win32 fix for decimal string to double float conversion albert@SPENARNC.XS4ALL.NL - 2026-07-26 20:13 +0200
          Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-07-27 12:20 -0500
    Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-11 07:24 -0500
    Re: kForth-Win32 fix for decimal string to double float conversion Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-24 18:55 -0500

Page 2 of 2 — ← Prev page 1 [2]

#135270

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> The Problem:
> -----------
> This is a quality of implementation issue in the decimal string to
> floating point conversion implemented in the C library function,
> strtod(), for the Digital Mars C/C++ compiler. The conversion is not
> simple, and has been studied extensively by a number of people. Of
> particular note is the following paper,

[I think the Forth method would be to have hex floating point numbers
that are exactly related to the internal representation instead of
importing other languages problems. ]

I have try at https://github.com/mynenik/kForth-Win32/tree/master/forth-src

> --
> Krishna Myneni
>
>
>
>
>
>

--
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [next] | [standalone]

#135271

On 7/25/26 16:42, albert@SPENARNC.XS4ALL.NL wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>> The Problem:
>> -----------
>> This is a quality of implementation issue in the decimal string to
>> floating point conversion implemented in the C library function,
>> strtod(), for the Digital Mars C/C++ compiler. The conversion is not
>> simple, and has been studied extensively by a number of people. Of
>> particular note is the following paper,
> 
> [I think the Forth method would be to have hex floating point numbers
> that are exactly related to the internal representation instead of
> importing other languages problems. ]
> 
Yes, if one wanted floating point numbers which are exactly represented 
in IEEE double precision, the best way is to enter the 64-bit binary 
values in hex form. However, this is not practical for most scientific 
computing.

With regard to range reduction, consider that the number 5x10^9 is 
exactly represented in binary form for double precision. However, 
without accurate range reduction into the range -pi to +pi, there is 
significant error in computing the sine of this value using the x87 FSIN 
instruction.

Range reduction of 5E9 using a double precision representation of 2PI 
with a scale factor of 795774715 to bring the angle argument into the 
range of -pi to +pi gives a huge loss of accuracy. Range reduction must 
be performed with a higher number of significant digits for 2PI than 
provided by double precision floating point arithmetic.



> I have try at https://github.com/mynenik/kForth-Win32/tree/master/forth-src
> 

See if the internal binary values (shown in hex as two dwords) 
correspond to the conversions for the decimal strings on your system.

--
KM

[toc] | [prev] | [next] | [standalone]

#135273

-- 
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [next] | [standalone]

#135274

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> I recently fixed a problem with kForth-Win32's conversion of decimal
> strings to IEEE double precision floats e.g., with rounding mode set to
> round nearest (with ties to eve), the string
>
> "1.000 000 000 000 000 111 022 302 462 515 654 042 363 166 809 082 031
> 251 e0" (spaces added for clarity)
>
> converted to the IEEE 64-bit binary pattern (shown in hex, high-dword
> low- dword)
>
> 3ff00000 00000000
>
> representing the exact number 1.000 ...
>
> instead of converting to the nearest representable IEEE 754 double
> precision number,
>
> 3ff00000 00000001
>
> which has the value
>
> 1.000 000 000 000 000 222 044 604 925 031 308 084 726 333 618 164 062 500
>
> Thus, the following Forth code should behave as follows:
>
> 17 set-precision
>  ok
> 1.000000000000000111022302462515654042363166809082031251e0 fs.
> 1.0000000000000002e+00  ok
>
> instead of printing 1.000000000000000e+00

Trying a test of fpio-test.

[ It use REGRESS instead of t{ . The main difference is that it kills,
instead of reports. REGRESS is not for testing, but to safeguard. ]

Note that I must convert a 8087 stack item to IEEE by storing
and fetching it with F! and F@.

WANT REGRESS -fp-
REGRESS FINIT S:
REGRESS -1.00000001335143196001808973960578441619873046875E-10 S:
REGRESS  HEX FDUP FS.            S:
REGRESS  PAD F! PAD F@ FDUP FS.            S:
REGRESS  PAD @ S: BDDB7CDFE0000000
"
hex_t{  r4 L@  ->  aedbe6ff }t
hex_t{  r8 2L@ ->  bddb7cdf e0000000 }t
" TYPE

The outcome of the test:

$-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
-fp-   FINIT S: \ PASSED
-fp-   -1.00000001335143196001808973960578441619873046875E-10 S: \ PASSED
-6.DF37F8000000000000_-9 -fp-    HEX FDUP FS.            S: \ PASSED
-6.DF37F8000000000000_-9 -fp-    PAD F! PAD F@ FDUP FS.            S: \ PASSED
-fp-    PAD @ S: BDDB7CDFE0000000 \ PASSED

My first impression is that trimming the number to IEEE generates the correct
result.

> --
> Krishna Myneni
>
>
>
>
>
>

--
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [next] | [standalone]

#135276

On 7/26/26 06:22, albert@SPENARNC.XS4ALL.NL wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>> I recently fixed a problem with kForth-Win32's conversion of decimal
>> strings to IEEE double precision floats e.g., with rounding mode set to
>> round nearest (with ties to eve), the string
>>
>> "1.000 000 000 000 000 111 022 302 462 515 654 042 363 166 809 082 031
>> 251 e0" (spaces added for clarity)
>>
>> converted to the IEEE 64-bit binary pattern (shown in hex, high-dword
>> low- dword)
>>
>> 3ff00000 00000000
>>
>> representing the exact number 1.000 ...
>>
>> instead of converting to the nearest representable IEEE 754 double
>> precision number,
>>
>> 3ff00000 00000001
>>
>> which has the value
>>
>> 1.000 000 000 000 000 222 044 604 925 031 308 084 726 333 618 164 062 500
>>
>> Thus, the following Forth code should behave as follows:
>>
>> 17 set-precision
>>   ok
>> 1.000000000000000111022302462515654042363166809082031251e0 fs.
>> 1.0000000000000002e+00  ok
>>
>> instead of printing 1.000000000000000e+00
> 
> Trying a test of fpio-test.
> 
> [ It use REGRESS instead of t{ . The main difference is that it kills,
> instead of reports. REGRESS is not for testing, but to safeguard. ]
> 
> Note that I must convert a 8087 stack item to IEEE by storing
> and fetching it with F! and F@.
> 
> WANT REGRESS -fp-
> REGRESS FINIT S:
> REGRESS -1.00000001335143196001808973960578441619873046875E-10 S:
> REGRESS  HEX FDUP FS.            S:
> REGRESS  PAD F! PAD F@ FDUP FS.            S:
> REGRESS  PAD @ S: BDDB7CDFE0000000
> "
> hex_t{  r4 L@  ->  aedbe6ff }t
> hex_t{  r8 2L@ ->  bddb7cdf e0000000 }t
> " TYPE
> 
> The outcome of the test:
> 
> $-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
> -fp-   FINIT S: \ PASSED
> -fp-   -1.00000001335143196001808973960578441619873046875E-10 S: \ PASSED
> -6.DF37F8000000000000_-9 -fp-    HEX FDUP FS.            S: \ PASSED
> -6.DF37F8000000000000_-9 -fp-    PAD F! PAD F@ FDUP FS.            S: \ PASSED
> -fp-    PAD @ S: BDDB7CDFE0000000 \ PASSED
> 

That's encouraging. Try these two tests from the rounding section

dec_t{  1.000000000000000111022302462515654042363166809082031250e+00 !r 
-> }t
hex_t{  r8 2L@ -> 3ff00000 00000000 }t

dec_t{  1.000000000000000111022302462515654042363166809082031251e+00 !r 
-> }t
hex_t{  r8 2L@ -> 3ff00000 00000001 }t


> My first impression is that trimming the number to IEEE generates the correct
> result.

Notice that the two decimal inputs are different by 1 in the last 
decimal place. But the round to nearest changes the converted bit 
pattern by 1 bit.

--
KM

[toc] | [prev] | [next] | [standalone]

#135277

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> On 7/26/26 06:22, albert@SPENARNC.XS4ALL.NL wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>> I recently fixed a problem with kForth-Win32's conversion of decimal
>>> strings to IEEE double precision floats e.g., with rounding mode set to
>>> round nearest (with ties to eve), the string
>>>
>>> "1.000 000 000 000 000 111 022 302 462 515 654 042 363 166 809 082 031
>>> 251 e0" (spaces added for clarity)
>>>
>>> converted to the IEEE 64-bit binary pattern (shown in hex, high-dword
>>> low- dword)
>>>
>>> 3ff00000 00000000
>>>
>>> representing the exact number 1.000 ...
>>>
>>> instead of converting to the nearest representable IEEE 754 double
>>> precision number,
>>>
>>> 3ff00000 00000001
>>>
>>> which has the value
>>>
>>> 1.000 000 000 000 000 222 044 604 925 031 308 084 726 333 618 164 062 500
>>>
>>> Thus, the following Forth code should behave as follows:
>>>
>>> 17 set-precision
>>>   ok
>>> 1.000000000000000111022302462515654042363166809082031251e0 fs.
>>> 1.0000000000000002e+00  ok
>>>
>>> instead of printing 1.000000000000000e+00
>>
>> Trying a test of fpio-test.
>>
>> [ It use REGRESS instead of t{ . The main difference is that it kills,
>> instead of reports. REGRESS is not for testing, but to safeguard. ]
>>
>> Note that I must convert a 8087 stack item to IEEE by storing
>> and fetching it with F! and F@.
>>
>> WANT REGRESS -fp-
>> REGRESS FINIT S:
>> REGRESS -1.00000001335143196001808973960578441619873046875E-10 S:
>> REGRESS  HEX FDUP FS.            S:
>> REGRESS  PAD F! PAD F@ FDUP FS.            S:
>> REGRESS  PAD @ S: BDDB7CDFE0000000
>> "
>> hex_t{  r4 L@  ->  aedbe6ff }t
>> hex_t{  r8 2L@ ->  bddb7cdf e0000000 }t
>> " TYPE
>>
>> The outcome of the test:
>>
>> $-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
>> -fp-   FINIT S: \ PASSED
>> -fp-   -1.00000001335143196001808973960578441619873046875E-10 S: \ PASSED
>> -6.DF37F8000000000000_-9 -fp-    HEX FDUP FS.            S: \ PASSED
>> -6.DF37F8000000000000_-9 -fp-    PAD F! PAD F@ FDUP FS.            S: \ PASSED
>> -fp-    PAD @ S: BDDB7CDFE0000000 \ PASSED
>>
>
> That's encouraging. Try these two tests from the rounding section
>
> dec_t{  1.000000000000000111022302462515654042363166809082031250e+00 !r
> -> }t
> hex_t{  r8 2L@ -> 3ff00000 00000000 }t
>
> dec_t{  1.000000000000000111022302462515654042363166809082031251e+00 !r
> -> }t
> hex_t{  r8 2L@ -> 3ff00000 00000001 }t
>
> Notice that the two decimal inputs are different by 1 in the last
> decimal place. But the round to nearest changes the converted bit
> pattern by 1 bit.

Okay, now I got:
S[ 3FF0000000000000 3FF0000000000001 ]   3FF0000000000001 ?
ciforth ERROR # 41 : REGRESSION TEST FAILS, RETURN VALUE ERROR

>
>> My first impression is that trimming the number to IEEE generates the correct
>> result.
>
This impression is wrong.
Apparently I do not understand the fine points of this matter.


My input method has the advantage of simplicity for
lengthy input and doesn't stray too far from the wanted result.

One step goes like
 ( digit parsed backward) FI+  BASE @ FI/

FI+ and FI/ are the FIADD and FIDIV 8087 instructions.

>
> --
> KM
>

--
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [next] | [standalone]

#135279

On 7/26/26 13:13, albert@SPENARNC.XS4ALL.NL wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
>> That's encouraging. Try these two tests from the rounding section
>>
>> dec_t{  1.000000000000000111022302462515654042363166809082031250e+00 !r
>> -> }t
>> hex_t{  r8 2L@ -> 3ff00000 00000000 }t
>>
>> dec_t{  1.000000000000000111022302462515654042363166809082031251e+00 !r
>> -> }t
>> hex_t{  r8 2L@ -> 3ff00000 00000001 }t
>>
>> Notice that the two decimal inputs are different by 1 in the last
>> decimal place. But the round to nearest changes the converted bit
>> pattern by 1 bit.
> 
> Okay, now I got:
> S[ 3FF0000000000000 3FF0000000000001 ]   3FF0000000000001 ?
> ciforth ERROR # 41 : REGRESSION TEST FAILS, RETURN VALUE ERROR
> 
>>
>>> My first impression is that trimming the number to IEEE generates the correct
>>> result.
>>
> This impression is wrong.
> Apparently I do not understand the fine points of this matter.

The explanation of why the second test value has the lsb of the 52 bit 
fractional part of the converted number set is the following. We can 
ignore the implied 1 for the msb. That bit just adds the 1.0e0 to the 
number.

Input 1)

1.000000000000000111022302462515654042363166809082031250e+00

the converted IEEE double precision number

3ff0000000000000

has the fractional part, all 52 of the least significant bits, set to 
zero. The exponent is also zero. This means that the nearest number 
rounding for the number is

1.000 ... ... ...


Input 2)

1.000000000000000111022302462515654042363166809082031251e+00

the converted IEEE double precision number is

3ff0000000000001

The lsb of the 52 bit fraction is now 1. The fractional part is now

2^-52

which, added to the implied msb of 1, is the next representable IEEE 
double precision floating point number:

55 set-precision
2.0e0 -52e0 F** 1.0e0 F+ FS.
1.000000000000000222044604925031308084726333618164062500e+00  ok

The input for the second case is nearer to the representable number 
above, rather than it is to the representable number below this one, 
which is 1.000 ... ... ...

In contrast, input 1) is closer to 1 than to the number above.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135337

On 7/20/26 09:48, Krishna Myneni wrote:
...

> "Correctly Rounded Binary-Decimal and Decimal-Binary Conversions," David 
> M. Gay, Numerical Analysis Manuscript 90-10, AT&T Bell Laboratories, 30 
> November 1990.
> 
> and the corresponding code, dtoa.c, link below, which provides a high- 
> quality strtod() replacement function for decimal string to binary 
> floating point conversions, as well as the inverse function, dtoa().
> 
> https://netlib.org/fp/dtoa.c
> 
> The kForth system test code, fpio-test.4th, may be used to identify 
> problems with decimal string conversion to IEEE double floats in other 
> Forth systems. The test file may be found at the link below.
> 
> https://github.com/mynenik/kForth-Win32/blob/master/forth-src/system- 
> test/fpio-test.4th
> 
...
I recently found a paper by Vern Paxson, a student of William Kahan, "A 
Program for Testing IEEE Decimal-Binary Conversion," 22 May 1991. This 
nicely written paper was apparently written for a CS class. It contains 
tables for "difficult" Decimal -> Binary conversions and for Binary -> 
Decimal conversions, with difficult meaning the required extra 
arithmetic precision over the starting precision (53 bits) in order to 
convert to the nearest double precision floating point which can be 
represented.


For example, Table 1. indicates that converting the double-precision 
floating point number, 4891559871276714924261E+222 requires an 
arithmetic precision of 53 + 86 = 139 bits.

The paper may be found at

https://www.icir.org/vern/papers/testbase-report.pdf

I am in the process of updating fpio-test.4th to include the conversion 
"stress tests" from Tables 1 through 4 of the paper. The Forth big 
number arithmetic code (FSL #47) may be used to check that the binary 
values of the significand and exponent (power of 2) are correct for 
decimal to binary conversions.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#135413

On 7/20/26 9:48 AM, Krishna Myneni wrote:
> I recently fixed a problem with kForth-Win32's conversion of decimal 
> strings to IEEE double precision floats e.g., with rounding mode set to 
> round nearest (with ties to eve), the string
> 
> "1.000 000 000 000 000 111 022 302 462 515 654 042 363 166 809 082 031 
> 251 e0" (spaces added for clarity)
> 
> converted to the IEEE 64-bit binary pattern (shown in hex, high-dword 
> low- dword)
> 
> 3ff00000 00000000
> 
> representing the exact number 1.000 ...
> 
> instead of converting to the nearest representable IEEE 754 double 
> precision number,
> 
> 3ff00000 00000001
> 
> which has the value
> 
> 1.000 000 000 000 000 222 044 604 925 031 308 084 726 333 618 164 062 500
> 
...
> There are several approaches to doing the conversion correctly (see the 
> paper mentioned above, and the references therein). The replacement 
> strtod() function in dtoa.c uses its built-in big integer arithmetic to 
> do the conversions, and this library is apparently used in languages 
> like python and Java.
> 
> kForth-Win32, as of version 2.5.5, uses the strtod() function from 
> dtoa.c. ...
Previously, I used the high quality strtod() function in dtoa.c to do 
decimal string to binary floating point conversions.

Now, kForth-Win32 uses the high-quality dtoa() function in dtoa.c to do 
double-precision binary to decimal string conversions.

https://netlib.org/fp/dtoa.c

The dtoa() function in this code is ideally suited for implementing 
Forth's REPRESENT so I managed to solve two problems: implement a high 
quality REPRESENT and redefine FS. using REPRESENT. The new FS. output 
in kForth-Win32 is the same as in the linux versions (kForth-32 and 
kForth-64). Floating point i/o is now consistent between the different 
kForth variants.

The kForth-Win32 commit has not yet been pushed out, but will be soon. 
Now I can add REPRESENT tests to my system test code, fpio-test.4th.

--
Krishna Myneni

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web