Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135350 > unrolled thread
| Started by | dxf <dxforth@gmail.com> |
|---|---|
| First post | 2026-08-16 09:42 +1000 |
| Last post | 2026-08-26 14:29 +0000 |
| Articles | 20 on this page of 103 — 8 participants |
Back to article view | Back to comp.lang.forth
Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-16 09:42 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-17 15:11 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-18 03:47 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-17 21:18 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-18 12:15 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-18 09:01 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-18 20:04 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-19 02:30 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-18 09:16 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-23 06:06 -0500
Re: Getting the exponent of an x87 float antispam@fricas.org (Waldek Hebisch) - 2026-08-18 17:55 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-19 13:48 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-19 17:14 +1000
Re: Getting the exponent of an x87 float peter <peter.noreply@tin.it> - 2026-08-19 09:58 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-19 19:14 +1000
Re: Getting the exponent of an x87 float peter <peter.noreply@tin.it> - 2026-08-19 15:36 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-20 12:36 +1000
Floating point (was: Getting the exponent of an x87 float) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-19 08:38 +0000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-19 18:44 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-20 12:35 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-20 03:40 -0500
Re: Getting the exponent of an x87 float albert@spenarnc.xs4all.nl - 2026-08-22 18:43 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-23 18:47 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-23 14:34 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-24 11:42 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-23 22:11 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-24 14:37 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-24 06:42 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-26 01:56 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-25 16:24 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-26 13:24 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-25 23:26 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-26 18:57 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-27 09:24 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-28 11:14 +1000
Re: Getting the exponent of an x87 float Stephen Pelc <stephen@vfxforth.com> - 2026-08-28 10:23 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-28 21:28 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 09:04 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 09:10 -0500
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-28 14:17 +0000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 09:41 -0500
Re: Getting the exponent of an x87 float albert@spenarnc.xs4all.nl - 2026-08-28 19:40 +0200
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 14:00 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 14:25 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 14:40 -0500
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-08-29 12:17 +0200
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-29 10:35 +0000
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-08-29 15:02 +0200
Re: Getting the exponent of an x87 float albert@spenarnc.xs4all.nl - 2026-08-29 15:51 +0200
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-29 14:45 +0000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-29 14:50 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-29 15:01 -0500
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-08-29 23:26 +0200
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-29 17:16 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-03 10:56 +1000
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-09-03 11:52 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-03 21:00 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-03 06:49 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-03 22:56 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-03 09:02 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-04 11:31 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-04 13:50 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-05 12:22 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-05 08:59 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-06 02:49 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-05 18:20 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-06 12:40 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-06 18:57 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-06 07:36 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-06 07:42 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-07 11:00 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-06 21:16 -0500
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-09-07 08:45 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-07 21:11 +1000
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-09-07 21:30 +0200
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-07 19:09 -0500
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-09-08 14:06 +0200
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-08 12:14 -0500
Re: Getting the exponent of an x87 float marcel hendrix <mhx@iae.nl> - 2026-09-09 02:15 +0200
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-08 14:41 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-08 19:31 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-08 05:30 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-08 05:44 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-08 23:10 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-09 01:03 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-08 20:49 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-09 13:31 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-09 20:02 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-09-10 12:46 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-07 17:21 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-07 22:13 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-05 21:27 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-05 21:55 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-29 07:38 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-30 11:12 +1000
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-29 13:18 -0500
Re: Getting the exponent of an x87 float Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 07:25 -0500
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-28 23:43 +1000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-28 23:56 +1000
Re: Getting the exponent of an x87 float albert@spenarnc.xs4all.nl - 2026-08-27 12:38 +0200
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-26 10:55 +0000
Re: Getting the exponent of an x87 float dxf <dxforth@gmail.com> - 2026-08-26 22:55 +1000
Re: Getting the exponent of an x87 float anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-26 14:29 +0000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-08 19:31 +1000 |
| Message-ID | <6a9fd5fd$1@news.ausics.net> |
| In reply to | #135598 |
On 8/09/2026 2:41 pm, dxf wrote:
> On 8/09/2026 5:30 am, marcel hendrix wrote:
>> ...
>> Still one other bug may be hiding ...
>>
>> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok
>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok
>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok
>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok
>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok
> ...
Here's a potential fix using <ddout> from JVN's package as an example.
It's a patch on top of the peelDigit patch. Short of a peelDigit that
works and knows when to stop, I'm afraid it's patches...
CREATE dig$ 32 ALLOT
\ N.B. for separate stack only; 0.0E handled externally by DDFS.
: <ddout> ( f: |x+xx| -- |x+xx'|) ( sgn power -- )
2>R
32 0 DO peelDigit shiftBy10 LOOP
\ create digit string correcting for peelDigit
32 0 DO
DUP 0< IF 10 + SWAP 1- SWAP THEN
[CHAR] 0 + dig$ 32 I - 1- + C!
LOOP
\ test and correct any underflow (first digit '0')
dig$ 32 OVER C@ [CHAR] 0 = IF R> 1- >R 1 /STRING THEN
( a u)
R> ( p) S>D SWAP OVER DABS \ convert exponent
<# #S 2DROP SIGN \ append digits of exponent
BL HOLD
[char] d HOLD
[char] d HOLD
BL HOLD \ append dd
( a u) 1- OVER 1+ SWAP HOLDS
[char] . HOLD C@ HOLD
R> ( s) IF [char] - ELSE [char] + THEN HOLD
0 0 #> TYPE SPACE
;
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-08 05:30 -0500 |
| Message-ID | <117oo4l$3248$1@dont-email.me> |
| In reply to | #135598 |
On 9/7/26 11:41 PM, dxf wrote: > On 8/09/2026 5:30 am, marcel hendrix wrote: >> ... >> Still one other bug may be hiding ... >> >> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok >> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok >> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok >> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok >> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok > > The values themselves are correct but not necessarily shown in strict sci > notation for that particular case (strings beginning with '9'). That's what > you're saying? > >... There seem to be other problems as well: s" 99999999999999999999999999999999dd-31" >dd ddfs. +0.9999999999999999635896294965249 dd 16 ok s" 99999999999999999999999999999999dd0" >dd ddfs. +0.9999999999999999635896294965248 dd 47 ok In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. A proper REPRESENT-DD may be a more involved problem. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-08 05:44 -0500 |
| Message-ID | <117oouc$3248$2@dont-email.me> |
| In reply to | #135603 |
On 9/8/26 5:30 AM, Krishna Myneni wrote: > On 9/7/26 11:41 PM, dxf wrote: >> On 8/09/2026 5:30 am, marcel hendrix wrote: >>> ... >>> Still one other bug may be hiding ... >>> >>> FORTH> s" 9.999999999999999999999D" >dd dd+e. >>> 0.99999999999999999999990000000e+001 ok >>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. >>> 0.99999999999999999999999990000e+001 ok >>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. >>> 0.99999999999999999999999999901e+001 ok >>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. >>> 1.00000000000000000000000000000e+001 ok >>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. >>> 0.99999999999999999999990000001e+001 ok >> >> The values themselves are correct but not necessarily shown in strict sci >> notation for that particular case (strings beginning with '9'). >> That's what >> you're saying? >> >> ... > There seem to be other problems as well: > > s" 99999999999999999999999999999999dd-31" >dd ddfs. > +0.9999999999999999635896294965249 dd 16 ok > > s" 99999999999999999999999999999999dd0" >dd ddfs. > +0.9999999999999999635896294965248 dd 47 ok > > > In addition to loss of significant digits in the conversion from a > decimal digit string to a binary double-double number, the power is also > incorrect for these two examples. > > A proper REPRESENT-DD may be a more involved problem. > > -- > Krishna > I think what we want is the function ddeformat() from Bailey's ddfun-v04 package. This is a lengthy function. subroutine ddeformat (a, nb, nd, b) ! Converts the DDR number A into character form in the character(1) array B. ! NB (input) is the length of the output string, and ND (input) is the ! number of digits after the decimal point. The format is analogous to ! Fortran E format. The result is left-justified among the NB cells of B. ! The condition NB >= ND + 8 must hold or an error message will result. ! NB cells must be available in array B. implicit none real (ddknd), intent(in):: a(2) integer, intent(in):: nb, nd character(1), intent(out):: b(nb) ... -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-08 23:10 +1000 |
| Message-ID | <6aa0094e$1@news.ausics.net> |
| In reply to | #135603 |
On 8/09/2026 8:30 pm, Krishna Myneni wrote: > On 9/7/26 11:41 PM, dxf wrote: >> On 8/09/2026 5:30 am, marcel hendrix wrote: >>> ... >>> Still one other bug may be hiding ... >>> >>> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok >>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok >>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok >>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok >>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok >> >> The values themselves are correct but not necessarily shown in strict sci >> notation for that particular case (strings beginning with '9'). That's what >> you're saying? >> >> ... > There seem to be other problems as well: > > s" 99999999999999999999999999999999dd-31" >dd ddfs. > +0.9999999999999999635896294965249 dd 16 ok > > s" 99999999999999999999999999999999dd0" >dd ddfs. > +0.9999999999999999635896294965248 dd 47 ok > > > In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. > > A proper REPRESENT-DD may be a more involved problem. It appears the original >DD is limited to 16 digits before the decimal pt. Testing my input routine: s" 99999999999999999999999999999999d-31" >dd drop cr ddfs. 9.9999999999999999999999999999998E0 ok s" 9999999999999999999999999999999999999999999999999999d-31" >dd drop cr ddfs. 1.0000000000000000000000000000000E21 ok s" 99999999999999999999999999999999d" >dd drop cr ddfs. :.0000000000000000000000000000000E31 ok s" 100000000000000000000000000000000d" >dd drop cr ddfs. 1.0000000000000000000000000000000E32 ok s" 99999999999999999999999999999998d" >dd drop cr ddfs. 9.9999999999999999999999999999999E31 ok. s" 9999999999999999999999999999999999999999999999999999d0" >dd drop cr ddfs. 1.0000000000000000000000000000000E52 ok.. Not sure what to make of the one that failed. But if that's the only case I shouldn't be too worried.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-09 01:03 +1000 |
| Message-ID | <117p83u$8tg5$1@dont-email.me> |
| In reply to | #135607 |
On 8/09/2026 11:10 pm, dxf wrote:
> ...
> s" 99999999999999999999999999999999d" >dd drop cr ddfs.
> :.0000000000000000000000000000000E31 ok
That one is in DDFS. so we may as well fix it. Following code
is my DDFS. variant. Interested parties can adjust for theirs.
Works for both common/separate stacks.
: SHOLD HOLDS ;
32 CONSTANT maxdig
CREATE peeled maxdig CELLS ALLOT
: peeldigits ( y yy -- ) \ to integer array
maxdig 0 DO
FOVER F>S DUP peeled maxdig 1- I - CELLS + !
S>F 0e0 DD- dd10. DD*
LOOP DDDROP ;
CREATE dig$ maxdig ALLOT
: copydigits ( -- ) \ to character array
peeled maxdig 0 DO
DUP CELL+ SWAP @ DUP 0< IF ( fix-up)
10 + OVER -1 SWAP +!
THEN [CHAR] 0 + dig$ maxdig 1- I - + C!
LOOP DROP ;
: digit-fix ( a u -- a' u' n ) \ leading digit fix-up
OVER C@ CASE
[CHAR] 0 OF 1 /STRING -1 ENDOF
[CHAR] 9 1+ OF OVER [CHAR] 1 SWAP C! 1 ENDOF
0 SWAP
ENDCASE ;
: (DDFS.) ( dd -- c-addr u ) \ string double-double in E-format
<# FOVER F0= IF DDDROP S" 0.E0" SHOLD ELSE
getsign >R
getpower ( x xx n)
normalize >R ( y yy)
peeldigits copydigits
dig$ maxdig ( a u) digit-fix R> + \ adjust exp
( p) DUP ABS 0 #S 2DROP SIGN \ exponent
[char] E HOLD ( a u)
1- OVER 1+ SWAP SHOLD [char] . HOLD C@ HOLD
R> ( s) IF [char] - HOLD THEN
THEN 0 0 #> ;
: DDFS. ( dd -- ) \ display double-double in E-format
(DDFS.) TYPE SPACE ;
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-08 20:49 -0500 |
| Message-ID | <117qdue$mn2r$1@dont-email.me> |
| In reply to | #135607 |
On 9/8/26 08:10, dxf wrote: > On 8/09/2026 8:30 pm, Krishna Myneni wrote: >> On 9/7/26 11:41 PM, dxf wrote: >>> On 8/09/2026 5:30 am, marcel hendrix wrote: >>>> ... >>>> Still one other bug may be hiding ... >>>> >>>> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok >>>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok >>>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok >>>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok >>>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok >>> >>> The values themselves are correct but not necessarily shown in strict sci >>> notation for that particular case (strings beginning with '9'). That's what >>> you're saying? >>> >>> ... >> There seem to be other problems as well: >> >> s" 99999999999999999999999999999999dd-31" >dd ddfs. >> +0.9999999999999999635896294965249 dd 16 ok >> >> s" 99999999999999999999999999999999dd0" >dd ddfs. >> +0.9999999999999999635896294965248 dd 47 ok >> >> >> In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. >> >> A proper REPRESENT-DD may be a more involved problem. > > It appears the original >DD is limited to 16 digits before the decimal pt. > Testing my input routine: > > s" 99999999999999999999999999999999d-31" >dd drop cr ddfs. > 9.9999999999999999999999999999998E0 ok > > s" 9999999999999999999999999999999999999999999999999999d-31" >dd drop cr ddfs. > 1.0000000000000000000000000000000E21 ok > > s" 99999999999999999999999999999999d" >dd drop cr ddfs. > :.0000000000000000000000000000000E31 ok > > s" 100000000000000000000000000000000d" >dd drop cr ddfs. > 1.0000000000000000000000000000000E32 ok > > s" 99999999999999999999999999999998d" >dd drop cr ddfs. > 9.9999999999999999999999999999999E31 ok. > > s" 9999999999999999999999999999999999999999999999999999d0" >dd drop cr ddfs. > 1.0000000000000000000000000000000E52 ok.. > > Not sure what to make of the one that failed. But if that's the only case > I shouldn't be too worried. > Famlous last words. Better to specify that the string format should be in scientific notation. Best to fix the problem itself because you can't anticipate how >DD will be used. A string with at most 32 digits before the decimal point make sense for input to >DD . -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-09 13:31 +1000 |
| Message-ID | <6aa0d32a$1@news.ausics.net> |
| In reply to | #135614 |
On 9/09/2026 11:49 am, Krishna Myneni wrote: > On 9/8/26 08:10, dxf wrote: >> On 8/09/2026 8:30 pm, Krishna Myneni wrote: >>> On 9/7/26 11:41 PM, dxf wrote: >>>> On 8/09/2026 5:30 am, marcel hendrix wrote: >>>>> ... >>>>> Still one other bug may be hiding ... >>>>> >>>>> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok >>>>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok >>>>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok >>>>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok >>>>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok >>>> >>>> The values themselves are correct but not necessarily shown in strict sci >>>> notation for that particular case (strings beginning with '9'). That's what >>>> you're saying? >>>> >>>> ... >>> There seem to be other problems as well: >>> >>> s" 99999999999999999999999999999999dd-31" >dd ddfs. >>> +0.9999999999999999635896294965249 dd 16 ok >>> >>> s" 99999999999999999999999999999999dd0" >dd ddfs. >>> +0.9999999999999999635896294965248 dd 47 ok >>> >>> >>> In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. >>> >>> A proper REPRESENT-DD may be a more involved problem. >> >> It appears the original >DD is limited to 16 digits before the decimal pt. >> Testing my input routine: >> >> s" 99999999999999999999999999999999d-31" >dd drop cr ddfs. >> 9.9999999999999999999999999999998E0 ok >> >> s" 9999999999999999999999999999999999999999999999999999d-31" >dd drop cr ddfs. >> 1.0000000000000000000000000000000E21 ok >> >> s" 99999999999999999999999999999999d" >dd drop cr ddfs. >> :.0000000000000000000000000000000E31 ok >> >> s" 100000000000000000000000000000000d" >dd drop cr ddfs. >> 1.0000000000000000000000000000000E32 ok >> >> s" 99999999999999999999999999999998d" >dd drop cr ddfs. >> 9.9999999999999999999999999999999E31 ok. >> >> s" 9999999999999999999999999999999999999999999999999999d0" >dd drop cr ddfs. >> 1.0000000000000000000000000000000E52 ok.. >> >> Not sure what to make of the one that failed. But if that's the only case >> I shouldn't be too worried. >> > > Famlous last words. Well, I ate them almost immediately (because it proved an easy fix) > Better to specify that the string format should be in scientific notation. > Best to fix the problem itself because you can't anticipate how >DD will be used. A string with at most 32 digits before the decimal point make sense for input to >DD . While both >DD and DDFS. have had issues, I consider the latter salvageable. ISTM the FSM >DD was doomed from the beginning. The code is bulky and has proven more problematic than straight-forward methods. While it works 'sort of' on most double-prec forths, it doesn't on mine.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-09 20:02 -0500 |
| Message-ID | <117svid$1jrca$1@dont-email.me> |
| In reply to | #135616 |
On 9/8/26 22:31, dxf wrote: > On 9/09/2026 11:49 am, Krishna Myneni wrote: >> On 9/8/26 08:10, dxf wrote: >>> On 8/09/2026 8:30 pm, Krishna Myneni wrote: >>>> On 9/7/26 11:41 PM, dxf wrote: >>>>> On 8/09/2026 5:30 am, marcel hendrix wrote: >>>>>> ... >>>>>> Still one other bug may be hiding ... >>>>>> >>>>>> FORTH> s" 9.999999999999999999999D" >dd dd+e. 0.99999999999999999999990000000e+001 ok >>>>>> FORTH> s" 9.999999999999999999999999D" >dd dd+e. 0.99999999999999999999999990000e+001 ok >>>>>> FORTH> s" 9.99999999999999999999999999D" >dd dd+e. 0.99999999999999999999999999901e+001 ok >>>>>> FORTH> s" 9.9999999999999999999999999999D" >dd dd+e. 1.00000000000000000000000000000e+001 ok >>>>>> 53-bits! S" 0.99999999999999999999990000000e+001" >DD DD+E. 0.99999999999999999999990000001e+001 ok >>>>> >>>>> The values themselves are correct but not necessarily shown in strict sci >>>>> notation for that particular case (strings beginning with '9'). That's what >>>>> you're saying? >>>>> >>>>> ... >>>> There seem to be other problems as well: >>>> >>>> s" 99999999999999999999999999999999dd-31" >dd ddfs. >>>> +0.9999999999999999635896294965249 dd 16 ok >>>> >>>> s" 99999999999999999999999999999999dd0" >dd ddfs. >>>> +0.9999999999999999635896294965248 dd 47 ok >>>> >>>> >>>> In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. >>>> >>>> A proper REPRESENT-DD may be a more involved problem. >>> >>> It appears the original >DD is limited to 16 digits before the decimal pt. >>> Testing my input routine: >>> >>> s" 99999999999999999999999999999999d-31" >dd drop cr ddfs. >>> 9.9999999999999999999999999999998E0 ok >>> >>> s" 9999999999999999999999999999999999999999999999999999d-31" >dd drop cr ddfs. >>> 1.0000000000000000000000000000000E21 ok >>> >>> s" 99999999999999999999999999999999d" >dd drop cr ddfs. >>> :.0000000000000000000000000000000E31 ok >>> >>> s" 100000000000000000000000000000000d" >dd drop cr ddfs. >>> 1.0000000000000000000000000000000E32 ok >>> >>> s" 99999999999999999999999999999998d" >dd drop cr ddfs. >>> 9.9999999999999999999999999999999E31 ok. >>> >>> s" 9999999999999999999999999999999999999999999999999999d0" >dd drop cr ddfs. >>> 1.0000000000000000000000000000000E52 ok.. >>> >>> Not sure what to make of the one that failed. But if that's the only case >>> I shouldn't be too worried. >>> >> >> Famlous last words. > > Well, I ate them almost immediately (because it proved an easy fix) > >> Better to specify that the string format should be in scientific notation. > Best to fix the problem itself because you can't anticipate how >DD will be used. A string with at most 32 digits before the decimal point make sense for input to >DD . > > While both >DD and DDFS. have had issues, I consider the latter salvageable. > ISTM the FSM >DD was doomed from the beginning. The code is bulky and has > proven more problematic than straight-forward methods. While it works 'sort of' > on most double-prec forths, it doesn't on mine. > Yes, I think >DD never worked correctly. When I find some time, I will play with David Bailey's conversion words in Fortran. They will be easy to translate to Forth, which is what I assume JVN was attempting to do. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-10 12:46 +1000 |
| Message-ID | <6aa219fe$1@news.ausics.net> |
| In reply to | #135636 |
On 10/09/2026 11:02 am, Krishna Myneni wrote: > On 9/8/26 22:31, dxf wrote: >> On 9/09/2026 11:49 am, Krishna Myneni wrote: >>> On 9/8/26 08:10, dxf wrote: >>>> On 8/09/2026 8:30 pm, Krishna Myneni wrote: >>>>>> ... >>>>> There seem to be other problems as well: >>>>> >>>>> s" 99999999999999999999999999999999dd-31" >dd ddfs. >>>>> +0.9999999999999999635896294965249 dd 16 ok >>>>> >>>>> s" 99999999999999999999999999999999dd0" >dd ddfs. >>>>> +0.9999999999999999635896294965248 dd 47 ok >>>>> >>>>> >>>>> In addition to loss of significant digits in the conversion from a decimal digit string to a binary double-double number, the power is also incorrect for these two examples. >>>>> >>>>> A proper REPRESENT-DD may be a more involved problem. >>>> >>>> It appears the original >DD is limited to 16 digits before the decimal pt. >>>> Testing my input routine: >>>> >>>> s" 99999999999999999999999999999999d-31" >dd drop cr ddfs. >>>> 9.9999999999999999999999999999998E0 ok >>>> >>>> s" 9999999999999999999999999999999999999999999999999999d-31" >dd drop cr ddfs. >>>> 1.0000000000000000000000000000000E21 ok >>>> >>>> s" 99999999999999999999999999999999d" >dd drop cr ddfs. >>>> :.0000000000000000000000000000000E31 ok >>>> >>>> s" 100000000000000000000000000000000d" >dd drop cr ddfs. >>>> 1.0000000000000000000000000000000E32 ok >>>> >>>> s" 99999999999999999999999999999998d" >dd drop cr ddfs. >>>> 9.9999999999999999999999999999999E31 ok. >>>> >>>> s" 9999999999999999999999999999999999999999999999999999d0" >dd drop cr ddfs. >>>> 1.0000000000000000000000000000000E52 ok.. >>>> >>>> Not sure what to make of the one that failed. But if that's the only case >>>> I shouldn't be too worried. >>>> >>> >>> Famlous last words. >> >> Well, I ate them almost immediately (because it proved an easy fix) >> >>> Better to specify that the string format should be in scientific notation. > Best to fix the problem itself because you can't anticipate how >DD will be used. A string with at most 32 digits before the decimal point make sense for input to >DD . >> >> While both >DD and DDFS. have had issues, I consider the latter salvageable. >> ISTM the FSM >DD was doomed from the beginning. The code is bulky and has >> proven more problematic than straight-forward methods. While it works 'sort of' >> on most double-prec forths, it doesn't on mine. >> > > Yes, I think >DD never worked correctly. When I find some time, I will play with David Bailey's conversion words in Fortran. They will be easy to translate to Forth, which is what I assume JVN was attempting to do. There are definite limitations e.g. MaxPlaces (total mantissa digits) is set at 30 and there are references to 'MaxPlaces 2/'. It's unlikely these were arbitrary. I'd be curious whether Bailey's output routine is the same as Julian's but at this stage Fortran is beyond me... Thanks for identifying the numbers that created issues as it prompted me to check mine. I had failed to consider the first digit output could overflow as well as underflow as a result of the peelDigit fix-up. For the moment I'm happy with my latest version of the package. Input/output should work correctly with no surprises. Users should note my >DD leaves a flag (like >FLOAT). It is recommended DD# be used to input numbers instead. https://pastebin.com/TdcLJhXP
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-07 17:21 -0500 |
| Message-ID | <117ndck$3m5rs$1@dont-email.me> |
| In reply to | #135587 |
On 9/6/26 20:00, dxf wrote: > On 6/09/2026 10:42 pm, Krishna Myneni wrote: >> On 9/6/26 03:57, dxf wrote: >>> On 6/09/2026 12:40 pm, dxf wrote: >> ... >>> I think your conversion of >DD to common stack is incomplete and that's >>> producing the 0.0E results. Whereas the code I replaced it with was >>> known to work on common stack. >>> >> >> By the way, your working version is missing DDABS . I had to paste it in to make the high-precision ODE solver work. > > Where did you insert it? > > Here's a prospective bug-fix for dd_io.4th that you may wish to try: > > https://pastebin.com/mBisVvXv > > I've no way to test the separate stack KForth. For Win32 KForth: > > s" 9.99999999999D" >dd ddfs. cr > +9.9999999999900000000000000000000 dd 0 > > s" 9.999999999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999999 dd 1 > > s" 9.99999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999991 dd 1 > > s" 9.999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999000 dd 1 > > s" 9.999999999999999D" >dd ddfs. cr > +9.9999999999999990000000000000003 dd 0 > > While the correct values are now printed, the formatting is a bit off in > some cases. It doesn't seem occur with mine (for whatever reason). > Here's what I obtain for the 8 tests which are in JVN's dd_io.4th code (under kforth32 for Linux) using your most recent file from pastebin. Tests 2, 3, and 5 are supposed to be string inputs with error. The case of Test 5 appears to be lacking a check for missing exponent in the string. The output formatting is ok for these tests (1 -- 8) when the input string does not have an error -- they are all in scientific notation. The output for your other tests above are in agreement with the results you obtained with the Win32 version of kForth. It seems to be working! === begin output === include ans-words ok include ddarith FPU base = 2 FPU precision = 53 ok include dxforth_ddio ok ( 1) s" -11.1112222233333444445555566666dd-45" >dd ddfs. cr -1.1111222223333344444555556666598 dd -44 ok ( 2) s" +-11.1112222233333444445555566666dd-45" >dd ddfs. cr ERR1: Non-digit in significand! Line 7: VM Error(-56): ( 2) s" +-11.1112222233333444445555566666dd-45" >dd ddfs. cr ( 3) s" +11.1112222.233333444445555566666dd-45" >dd ddfs. cr ERR2: One dp to a customer! Line 9: VM Error(-56): ( 3) s" +11.1112222.233333444445555566666dd-45" >dd ddfs. cr ( 4) s" +11.1112222233333444445555566666dd+45" >dd ddfs. cr +1.1111222223333344444555556666598 dd 46 ( 5) s" +11.1112222233333444445555566666" >dd ddfs. cr Line 13: VM Error(-271): Unsigned double number overflow ( 5) s" +11.1112222233333444445555566666" >dd ddfs. cr ( 6) s" +11.1112222233333444445555566666dd" >dd ddfs. cr +1.1111222223333344444555556666598 dd 1 ( 7) s" +11.1112222233333444445555566666D" >dd ddfs. cr +1.1111222223333344444555556666598 dd 1 ( 8) s" 1111122.222333D" >dd ddfs. cr +1.1111222223330000000000000000000 dd 6 === end output === For dxforth's tests: === begin output === s" 9.99999999999D" >dd ddfs. cr +9.9999999999900000000000000000000 dd 0 s" 9.999999999999999999999999999999999D" >dd ddfs. cr +0.9999999999999999999999999999999 dd 1 s" 9.99999999999D" >dd ddfs. cr +9.9999999999900000000000000000000 dd 0 s" 9.999999999999999999999999999D" >dd ddfs. cr +0.9999999999999999999999999999000 dd 1 s" 9.999999999999999D" >dd ddfs. cr +9.9999999999999990000000000000003 dd 0 === end output === Yes, some of these are not in scientific notation, so there's still some formatting bug. -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-07 22:13 -0500 |
| Message-ID | <117nuhc$3qvd7$1@dont-email.me> |
| In reply to | #135587 |
On 9/6/26 20:00, dxf wrote: > On 6/09/2026 10:42 pm, Krishna Myneni wrote: >> On 9/6/26 03:57, dxf wrote: >>> On 6/09/2026 12:40 pm, dxf wrote: >> ... >>> I think your conversion of >DD to common stack is incomplete and that's >>> producing the 0.0E results. Whereas the code I replaced it with was >>> known to work on common stack. >>> >> >> By the way, your working version is missing DDABS . I had to paste it in to make the high-precision ODE solver work. > > Where did you insert it? > > Here's a prospective bug-fix for dd_io.4th that you may wish to try: > > https://pastebin.com/mBisVvXv > > I've no way to test the separate stack KForth. For Win32 KForth: > > s" 9.99999999999D" >dd ddfs. cr > +9.9999999999900000000000000000000 dd 0 > > s" 9.999999999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999999 dd 1 > > s" 9.99999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999991 dd 1 > > s" 9.999999999999999999999999999D" >dd ddfs. cr > +0.9999999999999999999999999999000 dd 1 > > s" 9.999999999999999D" >dd ddfs. cr > +9.9999999999999990000000000000003 dd 0 > > While the correct values are now printed, the formatting is a bit off in > some cases. It doesn't seem occur with mine (for whatever reason). > Your bug fixes to dd_io.4th have been committed to kForth-32/Win32/64, with acknowledgement. The git repos have been updated. Behavior is identical in kForth-64, a separate fp stack system. -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-05 21:27 -0500 |
| Message-ID | <117ij1t$20ovm$1@dont-email.me> |
| In reply to | #135562 |
On 9/4/26 21:22, dxf wrote:
> On 5/09/2026 4:50 am, Krishna Myneni wrote:
>> On 9/3/26 8:31 PM, dxf wrote:
>>> On 4/09/2026 12:02 am, Krishna Myneni wrote:
>>>> On 9/3/26 07:56, dxf wrote:
>>>>> On 3/09/2026 9:49 pm, Krishna Myneni wrote:
>>>>>> On 9/2/26 19:56, dxf wrote:
>>>>>>> ...
>>>>>>> More problematic was mantissa digits extraction that could result
>>>>>>> in junk output:
>>>>>>>
>>>>>>> s" 9.9999999999999999999999999999999dd" >dd CR DDFS.
>>>>>>> +1.0000000000000000000000000000000 dd 1 ok
>>>>>>>
>>>>>>> s" 9.999999999999dd" >dd CR DDFS.
>>>>>>> +0.0000000000007777777777600000000 dd 0 ok
>>>>>>>
>>>>>>> It seems this was never corrected.
>>>>>>>
>>>>>>
>>>>>> If the fpu is not configured for double precision and round to nearest mode, the double double words will likely fail. They rely on rounding to double-precision.
>>>>>
>>>>> Tested on Win32Forth (8 byte floats) and GForth.
>>>>>
>>>>
>>>> Please try the kForth implementation on any of kForth-32/64/Win-32.
>>>
>>> That seems worse ;)
>>>
>>> kForth-Win32 v 2.5.5 (Build: 2026-07-18)
>>>
>>> Ready!
>>> include ans-words
>>> include ddarith
>>>
>>> FPU base = 2 FPU precision = 53
>>> ok
>>> include dd_io
>>>
>>> precision .
>>> 32 ok
>>> s" 9.9999999999999999999999999999999dd" >dd CR DDFS.
>>>
>>> +0.0000000000000000000000000000000 dd -314 ok
>>>
>>> s" 9.999999999999dd" >dd CR DDFS.
>>> BUF->DD: Float conversion failed
>>> Line 7: VM Error(-56):
>>> s" 9.999999999999dd" >dd CR DDFS.
>>>
>>>
>>
>> These examples fail under kForth-Win32 and kForth-32 in the same way.
>>
>> Under kForth-64, the first example gives
>>
>> precision .
>> 32 ok
>> s" 9.9999999999999999999999999999999dd" >dd ddfs.
>> +1.0000000000000000000000000000005 dd 1 ok
>>
>> The second example gives,
>>
>> s" 9.999999999999dd" >dd DDFS.
>> BUF->DD: Float conversion failed
>> Line 402: VM Error(-56):
>>
>> Clearly there is a problem with the >DD conversion of a decimal string to double-double precision.
>
> Trawling through my files I discovered I'd developed a solution to the
> general issue of DDFS. back in 2012 but had totally forgotten about. It
> seems that peeling off the mantissa digits can result in negative values
> which then have to be corrected. It puzzled me other users of JVN's package
> hadn't encountered the same. That JVN never fixed it might be explained
> by his passing.
>
> The string to float parser seemed complicated so I replaced it. FWIW
> here's my 2012 version cleaned up, including mods for KForth.
>
> https://pastebin.com/1UMmpkf6
>
The double-double arithmetic demo, dd-test.4th, works with your version
(dxforth-dd.4th, from pastebin.com) as well as with my previous code.
Note that method 2 is omitted since DDCOS is not yet available in the
library.
--
KM
=== begin output ===
Double Double Arithmetic Demo -- Golden Ratio Calculation to 32 digits
1. phi = {1 + sqrt[5]}/2
1.6180339887498948482045868343656E0
3. phi = sqrt[1 + sqrt[1 + sqrt[1 + ...
1.6180339887498948482045868343656E0
4. phi = 1 + 1/(1 + 1/(1 + 1/...
1.6180339887498948482045868343656E0
ok
=== end output ===
=== begin dd-test.4th ===
\ dd-test.4th
\
\ Compute and print the Golden Ratio [1] to 32 significant digits,
\ using the ddarith library and several computing methods.
\
\ K. Myneni, 2020-09-27
\
\ 1. http://en.wikipedia.org/wiki/Golden_ratio
include ans-words
\ include ddarith
\ include dd_io
include dxforth-dd
DECIMAL
1e 0e ddconstant DD1.0
2e 0e ddconstant DD2.0
3e 0e ddconstant DD3.0
5e 0e ddconstant DD5.0
DD3.0 DD2.0 dd/ ddconstant DD3/2
\ 1. Soln. of quadratic eqn: phi = (1 + sqrt(5))/2
: phi-qu ( F: -- x xx )
DD5.0 ddsqrt DD1.0 dd+ DD2.0 dd/ ;
\ 2. Trigonometric eqn: phi = 2*cos(pi/5)
0 [IF]
: phi-tr ( F: -- x xx )
DDPI DD5.0 dd/ ddcos DD2.0 dd* ; \ no ddcos available at present
;
[THEN]
\ 3. Continued square root: phi = sqrt(1 + sqrt(1 + sqrt(1 + ...
: phi-cs ( nterms -- ) ( F: -- x xx )
>r DD2.0 ddsqrt
r> 0 ?DO DD1.0 dd+ ddsqrt LOOP ;
\ 4. Continued fraction: phi = 1 + 1/(1 + 1/(1 + 1/...
: phi-cf ( nterms -- ) ( F: -- x xx )
>r DD3/2
r> 0 ?DO DD1.0 ddswap dd/ DD1.0 dd+ LOOP ;
32 set-precision
cr
cr .( Double Double Arithmetic Demo -- Golden Ratio Calculation to 32
digits )
cr
cr .( 1. phi = {1 + sqrt[5]}/2 )
cr phi-qu ddfs. cr
0 [IF]
cr .( 2. phi = 2*cos[pi/5] )
cr phi-tr ddfs. cr
[THEN]
cr .( 3. phi = sqrt[1 + sqrt[1 + sqrt[1 + ... )
cr 100 phi-cs ddfs. cr
cr .( 4. phi = 1 + 1/(1 + 1/(1 + 1/... )
cr 100 phi-cf ddfs. cr
=== end dd-test.4th ===
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-05 21:55 -0500 |
| Message-ID | <117ikn0$20ovm$2@dont-email.me> |
| In reply to | #135577 |
On 9/5/26 21:27, Krishna Myneni wrote:
> On 9/4/26 21:22, dxf wrote:
>> On 5/09/2026 4:50 am, Krishna Myneni wrote:
>>> On 9/3/26 8:31 PM, dxf wrote:
>>>> On 4/09/2026 12:02 am, Krishna Myneni wrote:
>>>>> On 9/3/26 07:56, dxf wrote:
>>>>>> On 3/09/2026 9:49 pm, Krishna Myneni wrote:
>>>>>>> On 9/2/26 19:56, dxf wrote:
>>>>>>>> ...
>>>>>>>> More problematic was mantissa digits extraction that could result
>>>>>>>> in junk output:
>>>>>>>>
>>>>>>>> s" 9.9999999999999999999999999999999dd" >dd CR DDFS.
>>>>>>>> +1.0000000000000000000000000000000 dd 1 ok
>>>>>>>>
>>>>>>>> s" 9.999999999999dd" >dd CR DDFS.
>>>>>>>> +0.0000000000007777777777600000000 dd 0 ok
>>>>>>>>
>>>>>>>> It seems this was never corrected.
>>>>>>>>
>>>>>>>
>>>>>>> If the fpu is not configured for double precision and round to
>>>>>>> nearest mode, the double double words will likely fail. They rely
>>>>>>> on rounding to double-precision.
>>>>>>
>>>>>> Tested on Win32Forth (8 byte floats) and GForth.
>>>>>>
>>>>>
>>>>> Please try the kForth implementation on any of kForth-32/64/Win-32.
>>>>
>>>> That seems worse ;)
>>>>
>>>> kForth-Win32 v 2.5.5 (Build: 2026-07-18)
>>>>
>>>> Ready!
>>>> include ans-words
>>>> include ddarith
>>>>
>>>> FPU base = 2 FPU precision = 53
>>>> ok
>>>> include dd_io
>>>>
>>>> precision .
>>>> 32 ok
>>>> s" 9.9999999999999999999999999999999dd" >dd CR DDFS.
>>>>
>>>> +0.0000000000000000000000000000000 dd -314 ok
>>>>
>>>> s" 9.999999999999dd" >dd CR DDFS.
>>>> BUF->DD: Float conversion failed
>>>> Line 7: VM Error(-56):
>>>> s" 9.999999999999dd" >dd CR DDFS.
>>>>
>>>>
>>>
>>> These examples fail under kForth-Win32 and kForth-32 in the same way.
>>>
>>> Under kForth-64, the first example gives
>>>
>>> precision .
>>> 32 ok
>>> s" 9.9999999999999999999999999999999dd" >dd ddfs.
>>> +1.0000000000000000000000000000005 dd 1 ok
>>>
>>> The second example gives,
>>>
>>> s" 9.999999999999dd" >dd DDFS.
>>> BUF->DD: Float conversion failed
>>> Line 402: VM Error(-56):
>>>
>>> Clearly there is a problem with the >DD conversion of a decimal
>>> string to double-double precision.
>>
>> Trawling through my files I discovered I'd developed a solution to the
>> general issue of DDFS. back in 2012 but had totally forgotten about. It
>> seems that peeling off the mantissa digits can result in negative values
>> which then have to be corrected. It puzzled me other users of JVN's
>> package
>> hadn't encountered the same. That JVN never fixed it might be explained
>> by his passing.
>>
>> The string to float parser seemed complicated so I replaced it. FWIW
>> here's my 2012 version cleaned up, including mods for KForth.
>>
>> https://pastebin.com/1UMmpkf6
>>
>
> The double-double arithmetic demo, dd-test.4th, works with your version
> (dxforth-dd.4th, from pastebin.com) as well as with my previous code.
> Note that method 2 is omitted since DDCOS is not yet available in the
> library.
>
> --
> KM
>
> === begin output ===
> Double Double Arithmetic Demo -- Golden Ratio Calculation to 32 digits
>
> 1. phi = {1 + sqrt[5]}/2
> 1.6180339887498948482045868343656E0
>
> 3. phi = sqrt[1 + sqrt[1 + sqrt[1 + ...
> 1.6180339887498948482045868343656E0
>
> 4. phi = 1 + 1/(1 + 1/(1 + 1/...
> 1.6180339887498948482045868343656E0
> ok
> === end output ===
>
...
A computationally intensive test, using the dd arithmetic library to
solve coupled non-linear differential equations, the Lorenz equations,
to higher number of significant digits, using your code gives the same
output as my earlier code. Below are links to the solver.
Using dxforth-dd.4th, the following output is generated from kforth32
(v2.8.0) -- same results should be obtained in the Win32 version:
=== begin output ===
...
Loading the Double Double precision RK4 integrator
/home/krishna/kforth/fsl/dd/runge4-dd.4th
RUNGE4-DD V1.2f 19 February 2012 EFC
Integrate the Lorenz equations in double double precision
using 1000000 steps and fixed-step RK4 integrator
74194 ms
x_final = {
-1.3761887673550761813753723611998E1
-1.9792917599220586294300652662594E1
3.6294152437132484819827313218605E1
}
ok
=== end output ===
Using my version of ddarith.4th and dd_io.4th, the following output is
obtained:
=== begin output ===
...
Loading the Double Double precision RK4 integrator
/home/krishna/kforth/fsl/dd/runge4-dd.4th
RUNGE4-DD V1.2f 19 February 2012 EFC
Integrate the Lorenz equations in double double precision
using 1000000 steps and fixed-step RK4 integrator
74743 ms
x_final = {
-1.3761887673550761813753723611998 dd 1
-1.9792917599220586294300652662594 dd 1
+3.6294152437132484819827313218605 dd 1
}
ok
=== end output ===
The code which generated the prior outputs are two files, in addition to
the support libraries:
test-runge4-dd.4th ( loads and runs the solver )
runge4-dd.4th ( double-double precision version of FSL #29 )
Replace the include statements for ddarith.4th and dd_io.4th with the
file from pastebin.com, which I called dxforth-dd.4th.
https://github.com/mynenik/kForth-Win32/blob/master/forth-src/fsl/dd/test-runge4-dd.4th
https://github.com/mynenik/kForth-Win32/blob/master/forth-src/fsl/dd/runge4-dd.4th
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-29 07:38 -0500 |
| Message-ID | <116ujrg$37kao$1@dont-email.me> |
| In reply to | #135472 |
On 8/29/26 05:17, marcel hendrix wrote: > On 8/28/2026 9:40 PM, Krishna Myneni wrote: >> On 8/28/26 14:25, Krishna Myneni wrote: >> >> We will have to find a better example to satisfy dxforth. >> > > Maybe this: what is the last digit of 3^47 ? ( 7 ) > ( I did not solve it with floating point. ) > > -marcel ?? I got some rest and I am revisiting the stable oscillator calculation, using low quality x87 FSIN instruction and higher quality gcc sin(x) problem to verify the correct answer of what the apparent frequency error is in the calculation, due to numerical error in x87 FSIN instruction. For the oscillator example, all results I've obtained thus far should be treated as suspect. I was trying to do it in a rush. -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-30 11:12 +1000 |
| Message-ID | <6a938370$1@news.ausics.net> |
| In reply to | #135472 |
On 29/08/2026 8:17 pm, marcel hendrix wrote: > On 8/28/2026 9:40 PM, Krishna Myneni wrote: >> On 8/28/26 14:25, Krishna Myneni wrote: >> >> We will have to find a better example to satisfy dxforth. >> > > Maybe this: what is the last digit of 3^47 ? ( 7 ) > ( I did not solve it with floating point. ) If your intent is to show IEEE double-precision math is little better than regular double-precision math, then that was already demonstrated ... Gforth 0.7.9_20200709 50 set-precision ok 1e-6 fs. 9.9999999999999995474811182588625868561393870000000E-7 ok 1e-6 1e f+ 1e f- fs. 9.9999999991773336205369560047984123229980470000000E-7 ok Essentially the same can be had with no-frills double-precision: DX-Forth 4.68 2026-08-28 80387 15-digit floating point (separate stack) max-precision . 15 ok 1e-6 fs. 1.E-6 ok 1e-6 1e f+ 1e f- fs. 9.99999999917734E-7 ok With x87 extended precision one at least gets a few more usable digits: DX-Forth 4.68 2026-08-28 80387 18-digit floating point (separate stack) 1e-6 1e f+ 1e f- fs. 1.00000000000002431E-6 ok If the benefit of using IEEE double-precision is not immediately obvious to a user and one needs to cherry-pick examples, then it's fair to ask what good is it.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-29 13:18 -0500 |
| Message-ID | <116v7pf$3f4tt$1@dont-email.me> |
| In reply to | #135464 |
On 8/28/26 14:00, Krishna Myneni wrote: > On 8/28/26 12:40, albert@spenarnc.xs4all.nl wrote: >> In article <2026Aug28.161745@mips.complang.tuwien.ac.at>, >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> <SNIP> >>>> SwiftForth x64-Windows 4.1.6 01-Apr-2026 >>>> >>>> 1e100 fsin f. >>>> 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok >>> >>> FSIN returning a number outside the [-1,1] range is disappointing, >>> however. >> >> That is the result of using FSIN as a wrapper of the 8087 instruction: >> \ FCD9 FDD9 FED9 FFD9 >> 0100 FCD9 4 2FAMILY, FRNDINT, FSCALE, FSIN, FCOS, >> ... >> CODE FSIN FSIN, NEXT, END-CODE >> >> In ciforth I have likewise not bothered. It makes no sense >> to calculate sin(1_100) >> > > Maybe, but at the 1e9 level it is not hard to find a "real-world" example. > > Consider simulating a high-stability 1 GHz oscillator. We can compute > the amplitude of the waveform with sin(2*pi*nu*t), with nu = 1e9 Hz. > > What is the amplitude of the wave at t = 1 m, 11.1 ns? The argument to > the sin(x) function is x = 2*pi*1e9*60.0000000111e0 radians. > > With the x87 FSIN instruction, we get an amplitude of > > 5.8774328586351210e-01 > > With the glibc sin(x) function, we obtain > > 5.8774328547084587e-01 > ... Both amplitude numbers are low accuracy! There is an inherent built-in error due to the double-precision approximation to 2pi. The factor of 6e10 (sixty billion) amplifies this error, making the results have low accuracy with either the reduced-range calculation or with the native x87 FSIN instruction. The calculation is 2pi 1e9 f* 60e 11.1e-9 f+ f* FSIN-<type> fs. where <type> is gcc or x87 and 2pi is the double-precision representation of 2*pi. Shown below are the exact double-precision value and the corresponding digits of actual 2*pi: DP closest representation of 2pi: 53 set-precision 6. 283 185 307 179 586 231 995 926 937 088 370 883 703 231 811 523 437 5 ( trailing zeros follow if precision is set higher) Actual 2pi to precision of 53 (rounded to 52 decimal places): 6. 283 185 307 179 586 476 925 286 766 559 005 768 394 338 798 750 211 6 The error in 2pi is roughly 2e-16. Magnified by a scale of factor of 60 billion leads to an error of 1.2e-5. Thus, the results for FSIN with range reduction and without only have about 5 decimal places of accuracy. 17 set-precision fvariable phase 2pi 1e9 f* 60e 11.1e-9 f+ f* phase f! FSIN-gcc result: phase f@ FSIN-gcc fs, 5.8779266471562064e-01 FSIN-x87 result: phase f@ FSIN-x87 fs, 5.8779266510826944e-01 Note that the two results differ for the common argument. Unfortunately the common argument has a significant loss of accuracy due to double-precision floating point. The smart way to do this calculation is to write it as phase = sin( 2pi*10^9(60 + 11.1*10^-9) ) = sin( 2pi*60*10^9 + 2*pi*11.1 ) and using sin( a + b ) = sin(a)cos(b) + sin(b)*cos(a), with a = 2pi*m, b = 2pi*11.1, with the integer m = 6e10 or 60,000,000,000 Now sin(a) = 0 for any integer m, and cos(a) = -1^m. Since m is even for this problem, cos(a) = 1, and it reduces to phase = sin( 2pi*11.1 ) which can be evaluated with either FSIN-gcc or FSIN-x87 : 2pi 11.1e f* FSIN-<gcc/x87> fs. 5.8778525229246803e-01 This agrees, to within 14 significant digits, with the result from Wolfram alpha for the full expression, sin( 2*pi*1e9*(60 + 11.1e-9) ) which gives 0.5877852522924731 This is a problem we cannot tackle within the limits of double precision, without using further numerical analysis. In kForth-32/64, the definitions of FSIN-gcc and FSIN-x87 are : FSIN-gcc FSIN ; : FSIN-x87 FSINCOS FDROP ; -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 07:25 -0500 |
| Message-ID | <116run0$2b0tc$1@dont-email.me> |
| In reply to | #135447 |
On 8/27/26 8:14 PM, dxf wrote: > On 28/08/2026 12:24 am, Krishna Myneni wrote: >> On 8/26/26 03:57, dxf wrote: >> ... >>>> >>>> Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. >>> >>> I can print thousands of digits of PI. What good is that to someone that wants >>> to solve real-world problems? >>> >> >> If it was only that simple. In order to do range reduction for accurate evaluation of trig functions e.g. FSIN and FCOS you need to represent pi to a minimum of 53 decimal digits. Otherwise arguments to the native fpu instructions on x87 begin showing inaccuracies above arguments of 50,000 radians, with the accuracy rapidly degrading each order of magnitude above that, as demonstrated in an earlier thread. >> >> If you are not concerned about that i.e. not a "real-world" problem for you, that's fine. > > AFAIK commercial forth systems don't support more than native x87 SIN COS. > Not to say there isn't/won't be a need, rather it seems minimal. > You can check with SwiftForth regarding its accuracy for large angle (> 1e6 radians) trig functions. See my recent post, "Range Reduction Using Big Number Arithmetic" for reference values from glibc sin(x) and cos(x). It is my understanding that SwiftForth passes my fpio-test.4th tests for decimal string to binary conversions, processing at least 55 decimal digits in the conversion process. I don't know whether or not VFX passes these tests. > While my fp experience is next to nil, I felt reassured watching Richard > Wagner's (aerospace engineer designing simulators) presentation on YT. > He references using both SwiftForth and VFX in his projects. His reply > to a question about locals was equally enlightening. As was his entire > demeanour. He doesn't seem to find any problem with the forth tools he > uses. > Rigorous testing is the ultimate source for being reassured. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-28 23:43 +1000 |
| Message-ID | <6a91909b$1@news.ausics.net> |
| In reply to | #135453 |
On 28/08/2026 10:25 pm, Krishna Myneni wrote: > On 8/27/26 8:14 PM, dxf wrote: >> On 28/08/2026 12:24 am, Krishna Myneni wrote: >>> On 8/26/26 03:57, dxf wrote: >>> ... >>>>> >>>>> Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. >>>> >>>> I can print thousands of digits of PI. What good is that to someone that wants >>>> to solve real-world problems? >>>> >>> >>> If it was only that simple. In order to do range reduction for accurate evaluation of trig functions e.g. FSIN and FCOS you need to represent pi to a minimum of 53 decimal digits. Otherwise arguments to the native fpu instructions on x87 begin showing inaccuracies above arguments of 50,000 radians, with the accuracy rapidly degrading each order of magnitude above that, as demonstrated in an earlier thread. >>> >>> If you are not concerned about that i.e. not a "real-world" problem for you, that's fine. >> >> AFAIK commercial forth systems don't support more than native x87 SIN COS. >> Not to say there isn't/won't be a need, rather it seems minimal. >> > > You can check with SwiftForth regarding its accuracy for large angle (> 1e6 radians) trig functions. See my recent post, "Range Reduction Using > Big Number Arithmetic" for reference values from glibc sin(x) and cos(x). > > It is my understanding that SwiftForth passes my fpio-test.4th tests for decimal string to binary conversions, processing at least 55 decimal digits in the conversion process. I don't know whether or not VFX passes these tests. > ... SwiftForth appears to pass your test with 0 errors. But then so does my ext-precision x87 fp package. I took zero precautions wrt to accuracy when I implemented it. I wouldn't have known where to start. I leave it to you to draw any conclusions.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-28 23:56 +1000 |
| Message-ID | <6a91939a$1@news.ausics.net> |
| In reply to | #135454 |
On 28/08/2026 11:43 pm, dxf wrote:
> ...
> SwiftForth appears to pass your test with 0 errors. But then so does my
> ext-precision x87 fp package. I took zero precautions wrt to accuracy
> when I implemented it. I wouldn't have known where to start. I leave it
> to you to draw any conclusions.
VFX didn't like these ...
Including D:\MPE\VfxForth64\fpiotest.fth
FPIO-TEST V1.2 12 Mar 2026
Including ttester.f
F2DUP is redefined
F2DROP is redefined
-> is redefined
L@ is redefined
INCORRECT RESULT: hex_t{ r4 L@ -> 006ce3ee }t
INCORRECT RESULT: hex_t{ r8 2L@ -> 380b38fb 80000000 }t
INCORRECT RESULT: hex_t{ r4 L@ -> aedbe6ff }t
INCORRECT RESULT: hex_t{ r8 2L@ -> bddb7cdf e0000000 }t
System FP precision is not supported for the rounding tests.
Error Count: 4
End of Core Extension word tests
ok
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-08-27 12:38 +0200 |
| Message-ID | <nnd$355410b9$47450053@4c69c1baac31c52d> |
| In reply to | #135426 |
In article <116lpti$bdle$1@dont-email.me>, Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >On 8/25/26 10:24 PM, dxf wrote: >... >> E.EXACT is good for fooling people into believing a 64-bit >> float can hold a 66 digit number. ... >A correct REPRESENT shows the following using the latest commit >(2cc4eb0) of kForth-Win32. > >1e-6 pad 100 represent > ok >pad 100 type >9999999999999999547481118258862586856139387236908078193664550781250000000000000000000 >000000000000000 ok > >100 set-precision >1e-6 fs. >1e-6 fs. >9.99999999999999954748111825886258685613938723690807819366455078125000000000000000000 >0000000000000000e-07 ok > >\ FS. uses the digits provided by REPRESENT > >There is some problem with the version of Gforth which you are using. > >More importantly, do you believe a 64-bit floating point number can >represent 2^-1074? How many decimal digits does the significand of >2^-1074 have? You can go to Wolfram alpha and type this in, and keep >asking for more digits until it has no more to show. > >In IEEE-754 double precision encoding, this is exactly the meaning of >the following 64-bit hex number: > >$0000000000000001 > >Try it on kForth-32/64, or on the most recent commit (2cc4eb0) of >kForth-Win32. > >include ans-words > >pad 8 erase >1 pad ! > >17 set-precision >pad df@ fs. > >100 set-precision >pad df@ fs. > >500 set-precision >pad df@ fs. > >750 set-precision >pad df@ fs. > >800 set-precision >pad df@ fs. > >Yes, a 64-bit binary float in IEEE 754 format can hold a number with >more than 750 decimal digits in its significand. And one can correctly >print all of them. > >-- >Krishna Myneni > > > > > > > -- 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.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web