From Newsgroup: comp.lang.forth

Owing to the recent discussion in other threads about conversion words
in Forth from

1. decimal string to a double double precision floating point number,
2. double double fp number to an output string,

it is helpful to have some reference tools to check against, for both cases.

I have written two short Fortran 90 programs to provide reference outputs:

dp2_to_ddr.f90 -- read two dp numbers and output the double double ddr_to_dp2.f90 -- read double double input and output the two dp numbers

The programs are used with David Bailey's Fortran package
ddfun-04.tar.gz, which may be found at his home page:

https://www.davidhbailey.com/dhbsoftware/

The package contents have also been placed at the following link:

https://ccreweb.org/software/ddfun/

in the directory ddfun-v04/

My two programs may be found in the directory ddr_to_dp2/

Build instructions for the ddfun-v04 package under gfortran are given in

readme-ddfun.txt

The readme-ddfun.txt file is extremely helpful to read for knowing what
is in the ddfun package and how to use it!

Build instructions for my two f90 programs are in the comments of the
source files.

Sample executions are shown below.

--
Krishna Myneni

=== begin output for ddr_to_dp2 ===
$ ./ddr_to_dp2
Enter a double double (DDR) number: 0.5772156649015328606065120900824024310422
The input DDR number is:
5.7721566490153286060651209008241e-1
The two double precision (DP) numbers are:
0.57721566490153287 -4.9429151524306364E-018
The two DP hex values are:
3FE2788CFC6FB619 BC56CB90701FBFA0
=== end output ===

=== begin output for dp2_to_ddr ===
$ ./dp2_to_ddr
Enter a pair of double precision (DP) numbers: 0.57721566490153287,-4.9429151524306364E-018
The two DP numbers are:
0.57721566490153287 -4.9429151524306364E-018
The two DP hex values are:
3FE2788CFC6FB619 BC56CB90701FBFA0
The double double (DDR) value of the pair is: 5.7721566490153286060651209008241e-1
=== end output ===



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16/09/2026 9:24 pm, Krishna Myneni wrote:

...
=== begin output for ddr_to_dp2 ===
$ ./ddr_to_dp2
-aEnter a double double (DDR) number: 0.5772156649015328606065120900824024310422
-aThe input DDR number is:
5.7721566490153286060651209008241e-1
-aThe two double precision (DP) numbers are:
-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
=== end output ===

=== begin output for dp2_to_ddr ===
$ ./dp2_to_ddr
-aEnter a pair of double precision (DP) numbers: 0.57721566490153287,-4.9429151524306364E-018
-aThe two DP numbers are:
-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
-aThe double double (DDR) value of the pair is: 5.7721566490153286060651209008241e-1
=== end output ===

Gforth:

dd# 0.5772156649015328606065120900824024310422 ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1 ok

0.57721566490153287e -4.9429151524306364E-018 ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1 ok


Win32Forth:

dd# 0.5772156649015328606065120900824024310422 ok
cr ddfs.
5.7721566490153286060651209008241E-1 ok

0.57721566490153287e -4.9429151524306364E-018 ok
cr ddfs.
5.7721566490153297162881455259806E-1 ok


Both work for DD I/O but Win32Forth has trouble entering a DD as two
discrete floats. Applying more digits fixes it:

0.5772156649015328655e -4.9429151524306364E-018 ok
cr ddfs.
5.7721566490153286060651209008241E-1 ok

OTOH it may simply be too unreliable a method. There's no room for
error in the major of the two floats!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 9/16/26 09:15, dxf wrote:

On 16/09/2026 9:24 pm, Krishna Myneni wrote:

...
=== begin output for ddr_to_dp2 ===
$ ./ddr_to_dp2
-aEnter a double double (DDR) number:
0.5772156649015328606065120900824024310422
-aThe input DDR number is:
5.7721566490153286060651209008241e-1
-aThe two double precision (DP) numbers are:
-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
=== end output ===

=== begin output for dp2_to_ddr ===
$ ./dp2_to_ddr
-aEnter a pair of double precision (DP) numbers:
0.57721566490153287,-4.9429151524306364E-018
-aThe two DP numbers are:
-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
-aThe double double (DDR) value of the pair is:
5.7721566490153286060651209008241e-1
=== end output ===

Gforth:

dd# 0.5772156649015328606065120900824024310422 ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1 ok

0.57721566490153287e -4.9429151524306364E-018 ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1 ok

Win32Forth:

dd# 0.5772156649015328606065120900824024310422 ok
cr ddfs.
5.7721566490153286060651209008241E-1 ok

0.57721566490153287e -4.9429151524306364E-018 ok
cr ddfs.
5.7721566490153297162881455259806E-1 ok

Both work for DD I/O but Win32Forth has trouble entering a DD as two
discrete floats. Applying more digits fixes it:

0.5772156649015328655e -4.9429151524306364E-018 ok
cr ddfs.
5.7721566490153286060651209008241E-1 ok

OTOH it may simply be too unreliable a method. There's no room for
error in the major of the two floats!

The behavior of DD# in Gforth is encouraging. How (and why) does DD#
differ from >DD apart from the fact that it parses the string?

I suspect the Win32Forth decimal string to double precision float is not working correctly (17 significant digits in the input string significand should reproduce the same hexadecimal value of the dp float, per IEEE requirements). Does Win32Forth pass the fpio-test.4th tests?

--
Krishna

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <118dua6$3afcb$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

Owing to the recent discussion in other threads about conversion words
in Forth from

1. decimal string to a double double precision floating point number,
2. double double fp number to an output string,

it is helpful to have some reference tools to check against, for both cases.

I can't believe this thread goes as long as it does, given that
Forth can handle floating point in hex.

<SNIP>

Groetjes Albert


--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17/09/2026 12:43 am, Krishna Myneni wrote:

On 9/16/26 09:15, dxf wrote:

On 16/09/2026 9:24 pm, Krishna Myneni wrote:

...
=== begin output for ddr_to_dp2 ===
$ ./ddr_to_dp2
-a-aEnter a double double (DDR) number:
0.5772156649015328606065120900824024310422
-a-aThe input DDR number is:
5.7721566490153286060651209008241e-1
-a-aThe two double precision (DP) numbers are:
-a-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-a-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
=== end output ===

=== begin output for dp2_to_ddr ===
$ ./dp2_to_ddr
-a-aEnter a pair of double precision (DP) numbers:
0.57721566490153287,-4.9429151524306364E-018
-a-aThe two DP numbers are:
-a-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-a-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
-a-aThe double double (DDR) value of the pair is:
5.7721566490153286060651209008241e-1
=== end output ===

Gforth:

dd# 0.5772156649015328606065120900824024310422-a ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

0.57721566490153287e -4.9429151524306364E-018-a ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1-a ok


Win32Forth:

dd# 0.5772156649015328606065120900824024310422-a ok
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

0.57721566490153287e -4.9429151524306364E-018-a ok
cr ddfs.
5.7721566490153297162881455259806E-1-a ok


Both work for DD I/O but Win32Forth has trouble entering a DD as two
discrete floats.-a Applying more digits fixes it:

0.5772156649015328655e -4.9429151524306364E-018-a ok
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

OTOH it may simply be too unreliable a method.-a There's no room for
error in the major of the two floats!

The behavior of DD# in Gforth is encouraging. How (and why) does DD# differ from >DD apart from the fact that it parses the string?

It's using my >DD per the latest Pastebin upload.

I suspect the Win32Forth decimal string to double precision float is not working correctly (17 significant digits in the input string significand should reproduce the same hexadecimal value of the dp float, per IEEE requirements). Does Win32Forth pass the fpio-test.4th tests?

Given the result above it would likely fail. A working >DD is necessary in
any case. AFAICS discrete floats were useful in defining simple DD constants (0dd 10dd etc.) in the lead up to defining >DD. Beyond that I see only risk. In future I'll be using DD# to define DDPI.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 9/16/26 23:05, dxf wrote:

On 17/09/2026 12:43 am, Krishna Myneni wrote:

On 9/16/26 09:15, dxf wrote:

On 16/09/2026 9:24 pm, Krishna Myneni wrote:

...
=== begin output for ddr_to_dp2 ===
$ ./ddr_to_dp2
-a-aEnter a double double (DDR) number:
0.5772156649015328606065120900824024310422
-a-aThe input DDR number is:
5.7721566490153286060651209008241e-1
-a-aThe two double precision (DP) numbers are:
-a-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-a-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
=== end output ===

=== begin output for dp2_to_ddr ===
$ ./dp2_to_ddr
-a-aEnter a pair of double precision (DP) numbers:
0.57721566490153287,-4.9429151524306364E-018
-a-aThe two DP numbers are:
-a-a 0.57721566490153287-a-a-a-a-a-a -4.9429151524306364E-018
-a-aThe two DP hex values are:
3FE2788CFC6FB619-a BC56CB90701FBFA0
-a-aThe double double (DDR) value of the pair is:
5.7721566490153286060651209008241e-1
=== end output ===

Gforth:

dd# 0.5772156649015328606065120900824024310422-a ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

0.57721566490153287e -4.9429151524306364E-018-a ok f:2
cr ddfs.
5.7721566490153286060651209008241E-1-a ok


Win32Forth:

dd# 0.5772156649015328606065120900824024310422-a ok
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

0.57721566490153287e -4.9429151524306364E-018-a ok
cr ddfs.
5.7721566490153297162881455259806E-1-a ok


Both work for DD I/O but Win32Forth has trouble entering a DD as two
discrete floats.-a Applying more digits fixes it:

0.5772156649015328655e -4.9429151524306364E-018-a ok
cr ddfs.
5.7721566490153286060651209008241E-1-a ok

OTOH it may simply be too unreliable a method.-a There's no room for
error in the major of the two floats!

The behavior of DD# in Gforth is encouraging. How (and why) does DD# differ from >DD apart from the fact that it parses the string?

It's using my >DD per the latest Pastebin upload.

I suspect the Win32Forth decimal string to double precision float is not working correctly (17 significant digits in the input string significand should reproduce the same hexadecimal value of the dp float, per IEEE requirements). Does Win32Forth pass the fpio-test.4th tests?

Given the result above it would likely fail. A working >DD is necessary in any case. AFAICS discrete floats were useful in defining simple DD constants (0dd 10dd etc.) in the lead up to defining >DD. Beyond that I see only risk. In future I'll be using DD# to define DDPI.

The binary patterns (or hex values) of the two double precision floats
which make up a double double precision number need to be known for a
given input string representing a double double number. Then the
conversion error, whether one uses >DD or DD#, error in ulp can be
determined. This is why I wrote the reference tools using the Fortran
ddfun code. Of course it assumes the the ddfun routine ddread is doing
the conversion to small ulp error.

Anyway, I can use the reference tools, ddr_to_dp2 and dp2_to_ddr, to
make some initial test cases.

--
Krishna



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 9/16/26 6:24 AM, Krishna Myneni wrote:

Owing to the recent discussion in other threads about conversion words
in Forth from

1. decimal string to a double double precision floating point number,
2. double double fp number to an output string,

it is helpful to have some reference tools to check against, for both
cases.

I have written two short Fortran 90 programs to provide reference outputs:

dp2_to_ddr.f90 -- read two dp numbers and output the double double ddr_to_dp2.f90 -- read double double input and output the two dp numbers

The programs are used with David Bailey's Fortran package
ddfun-04.tar.gz, which may be found at his home page:

https://www.davidhbailey.com/dhbsoftware/

The package contents have also been placed at the following link:

https://ccreweb.org/software/ddfun/

I've revised and renamed the two programs:

dp2_to_ddr.f90 --> dp2_to_dd.f90
ddr_to_dp2.f90 --> dd_to_dp2.f90

The renaming change better aligns with the terminology used in the ddfun package.

The revisions use direct access to the two double precision values of a
double double variable, instead of computing them. There's no change in behavior (as far as I can tell) for the two programs.

The link for the two revised programs is

https://ccreweb.org/software/ddfun/dd_to_dp2/

--
KM

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 9/18/26 6:15 AM, Krishna Myneni wrote:

On 9/16/26 6:24 AM, Krishna Myneni wrote:

Owing to the recent discussion in other threads about conversion words
in Forth from

1. decimal string to a double double precision floating point number,
2. double double fp number to an output string,

it is helpful to have some reference tools to check against, for both
cases.

I have written two short Fortran 90 programs to provide reference
outputs:

dp2_to_ddr.f90 -- read two dp numbers and output the double double
ddr_to_dp2.f90 -- read double double input and output the two dp numbers

The programs are used with David Bailey's Fortran package
ddfun-04.tar.gz, which may be found at his home page:

https://www.davidhbailey.com/dhbsoftware/

The package contents have also been placed at the following link:

https://ccreweb.org/software/ddfun/

I've revised and renamed the two programs:

dp2_to_ddr.f90 --> dp2_to_dd.f90
ddr_to_dp2.f90 --> dd_to_dp2.f90

The renaming change better aligns with the terminology used in the ddfun package.

The revisions use direct access to the two double precision values of a double double variable, instead of computing them. There's no change in behavior (as far as I can tell) for the two programs.

The link for the two revised programs is

https://ccreweb.org/software/ddfun/dd_to_dp2/

For those who use Windows and don't have gfortran available, I've spent
some time porting the ddfun-v04 code to compile under the Silverfrost
Fortran 95 compiler for Windows. I used the trial/evaluation version,
aka the personal edition, of their FTN95 compiler, which I had been
playing with for a couple of days. I had to rewrite some code in a few subroutines in ddfuna.f90 for dd numbers to be properly output (through
the ddwrite interface) due to FTN95 compiler optimizations. Maybe the optimizations can be turned off, but I didn't know how. I also had to
account for the compiler-dependent KIND parameter in declaring a REAL.

In addition to being able to build the executable for ddfuntest.f90,
which demos the use of double double arithmetic *and* the computation a
large number of double double special functions, and measures their
error, one can use it to make Win32 exe files for the double double
tools, dp2_to_dd.f90 and dd_to_dp2.exe.

The port may be found at the same link,

https://ccreweb.org/software/ddfun

in the ddfun-v04/ftn95 subdirectory. Please see the file,

readme-build-ftn95.txt

within this folder for notes on changes to the original package code,
and the build instructions for ddfuntest.exe. The dd_to_dp2 executables
may be built in the same way.

--
Krishna Myneni








--- Synchronet 3.22a-Linux NewsLink 1.2