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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-04 11:31 +1000 |
| Message-ID | <6a9a1f89$1@news.ausics.net> |
| In reply to | #135542 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-04 13:50 -0500 |
| Message-ID | <117f3th$tbos$1@dont-email.me> |
| In reply to | #135547 |
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. -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-05 12:22 +1000 |
| Message-ID | <6a9b7cf3$1@news.ausics.net> |
| In reply to | #135558 |
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
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-05 08:59 -0500 |
| Message-ID | <117h78t$1hpi9$2@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 > Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS. Looking back at my code, the string to dd converter >DD originally made use of a finite state machine, which I commented out for reasons I don't remember (a case of bitrot). There wasn't any indication that I tested >DD ; however, I have used DDFS. without any observable problems. Thanks for the code! -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-06 02:49 +1000 |
| Message-ID | <6a9c4832$1@news.ausics.net> |
| In reply to | #135569 |
On 5/09/2026 11:59 pm, 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
>>
>
> Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS.
The original 'initialize' wasn't ANS compliant could fail. The fix is:
: initialize
hi# init_buffer \ buffers
lo# init_buffer
lo# [CHAR] 0 +char \ ** add **
lo# [CHAR] . +char
0 TO pre_dp 0 TO post_dp \ counts
0 >state ( <<hi/lo>>) \ fsm
;
Your >DD should then work, after which you can test DDFS.
(It never made sense to me that >FLOAT shouldn't accept a leading decimal pt
but that's what ANS specified.)
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-05 18:20 -0500 |
| Message-ID | <117i84b$1tflm$1@dont-email.me> |
| In reply to | #135570 |
On 9/5/26 11:49, dxf wrote: > On 5/09/2026 11:59 pm, 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 >>> >> >> Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS. > > The original 'initialize' wasn't ANS compliant could fail. The fix is: > > : initialize > hi# init_buffer \ buffers > lo# init_buffer > lo# [CHAR] 0 +char \ ** add ** > lo# [CHAR] . +char > 0 TO pre_dp 0 TO post_dp \ counts > 0 >state ( <<hi/lo>>) \ fsm > ; > > Your >DD should then work, after which you can test DDFS. > That didn't work. But I ran your version of ddarith/dd_io from pastebin under kForth-32 (2.8.0). Below are the results: === begin output === include ans-words /home/krishna/kforth/ans-words.4th ok include dxforth-dd \ code from pastebin (unchanged) SYSTEM is redefined Double-Double Precision FP Testing -1.1111222223333344444555556666600E-44 +-11.1112222233333444445555566666d-45 failed +11.1112222.233333444445555566666d-45 failed 1.1111222223333344444555556666599E46 1.1111222223333344444555556666599E1 1.1111222223333344444555556666599E1 1.1111222223333344444555556666599E1 1.1111222223330000000000000000000E6 0.0000000000000000000000000000000E0 6.6666666666666666666666666666666E-1 9.9999999999999999999999987654324E0 -9.9999999999999900000000123456788E0 -9.9999999999990000000000000000000E0 ok === end output === This is encouraging! Tests 2 and 3 failed as they should. Per JVN's notes, Test 5 was supposed to fail and output +0.0000000000000000000000000000000 dd 0 due to a lack of exponent in the input string. Your own tests are the last 5 above. I recommend sticking with the "dd" exponent indicator, otherwise you won't be able to differentiate double precision output from double double output. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-06 12:40 +1000 |
| Message-ID | <6a9cd297$1@news.ausics.net> |
| In reply to | #135574 |
On 6/09/2026 9:20 am, Krishna Myneni wrote: > On 9/5/26 11:49, dxf wrote: >> On 5/09/2026 11:59 pm, 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 >>>> >>> >>> Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS. >> >> The original 'initialize' wasn't ANS compliant could fail. The fix is: >> >> : initialize >> hi# init_buffer \ buffers >> lo# init_buffer >> lo# [CHAR] 0 +char \ ** add ** >> lo# [CHAR] . +char >> 0 TO pre_dp 0 TO post_dp \ counts >> 0 >state ( <<hi/lo>>) \ fsm >> ; >> >> Your >DD should then work, after which you can test DDFS. >> > > That didn't work. But it fixed the error msg on input conversion from dd-io.4th - no? > But I ran your version of ddarith/dd_io from pastebin under kForth-32 (2.8.0). Below are the results: > > === begin output === > include ans-words > > /home/krishna/kforth/ans-words.4th > ok > include dxforth-dd \ code from pastebin (unchanged) > SYSTEM is redefined > > Double-Double Precision FP > > Testing > > -1.1111222223333344444555556666600E-44 > +-11.1112222233333444445555566666d-45 failed > +11.1112222.233333444445555566666d-45 failed > 1.1111222223333344444555556666599E46 > 1.1111222223333344444555556666599E1 > 1.1111222223333344444555556666599E1 > 1.1111222223333344444555556666599E1 > 1.1111222223330000000000000000000E6 > > 0.0000000000000000000000000000000E0 > 6.6666666666666666666666666666666E-1 > 9.9999999999999999999999987654324E0 > -9.9999999999999900000000123456788E0 > -9.9999999999990000000000000000000E0 ok > > === end output === > > This is encouraging! Tests 2 and 3 failed as they should. > > Per JVN's notes, Test 5 was supposed to fail and output > > +0.0000000000000000000000000000000 dd 0 > > due to a lack of exponent in the input string. > > Your own tests are the last 5 above. I recommend sticking with the "dd" exponent indicator, otherwise you won't be able to differentiate double precision output from double double output. Perhaps. Other than adding a routine to handle DD input, I didn't feel the need to depart from convention. Besides which the package was limited to the basic four functions and there's only so much one can do with that. I didn't have the expertise or particular interest to expand it further.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-06 18:57 +1000 |
| Message-ID | <6a9d2ae0$1@news.ausics.net> |
| In reply to | #135578 |
On 6/09/2026 12:40 pm, dxf wrote: > On 6/09/2026 9:20 am, Krishna Myneni wrote: >> On 9/5/26 11:49, dxf wrote: >>> On 5/09/2026 11:59 pm, Krishna Myneni wrote: >>>> ... >>>> Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS. >>> >>> The original 'initialize' wasn't ANS compliant could fail. The fix is: >>> >>> : initialize >>> hi# init_buffer \ buffers >>> lo# init_buffer >>> lo# [CHAR] 0 +char \ ** add ** >>> lo# [CHAR] . +char >>> 0 TO pre_dp 0 TO post_dp \ counts >>> 0 >state ( <<hi/lo>>) \ fsm >>> ; >>> >>> Your >DD should then work, after which you can test DDFS. >>> >> >> That didn't work. > > But it fixed the error msg on input conversion from dd-io.4th - no? 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.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-06 07:36 -0500 |
| Message-ID | <117jmnk$2boon$1@dont-email.me> |
| In reply to | #135580 |
On 9/6/26 03:57, dxf wrote: > On 6/09/2026 12:40 pm, dxf wrote: >> On 6/09/2026 9:20 am, Krishna Myneni wrote: >>> On 9/5/26 11:49, dxf wrote: >>>> On 5/09/2026 11:59 pm, Krishna Myneni wrote: >>>>> ... >>>>> Are you sure DDFS. is the problem. In my case, I think the problem is with the decimal string to double double number conversion i.e., the problem lies in >DD and not in DDFS. >>>> >>>> The original 'initialize' wasn't ANS compliant could fail. The fix is: >>>> >>>> : initialize >>>> hi# init_buffer \ buffers >>>> lo# init_buffer >>>> lo# [CHAR] 0 +char \ ** add ** >>>> lo# [CHAR] . +char >>>> 0 TO pre_dp 0 TO post_dp \ counts >>>> 0 >state ( <<hi/lo>>) \ fsm >>>> ; >>>> >>>> Your >DD should then work, after which you can test DDFS. >>>> >>> >>> That didn't work. >> >> But it fixed the error msg on input conversion from dd-io.4th - no? > > 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. > Ok. I'll go through it carefully, and compare it with your string to dd conversion algorithm. But there is a problem with the separate stack version (kforth64) as well. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-06 07:42 -0500 |
| Message-ID | <117jn2q$2boon$2@dont-email.me> |
| In reply to | #135580 |
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. -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-07 11:00 +1000 |
| Message-ID | <6a9e0cc0$1@news.ausics.net> |
| In reply to | #135585 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-06 21:16 -0500 |
| Message-ID | <117l6pe$2sjp8$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?
>
: DDNEGATE ( f: x xx -- -x -xx)
FNEGATE FSWAP FNEGATE FSWAP
;
\ inserted here, as in JVN's original code
: DDABS ( f: x xx -- |x+xx|)
FOVER F0< IF DDNEGATE THEN
;
: DD- ( f: x xx y yy -- [x+xx] - [y+yy] )
DDNEGATE DD+
;
> Here's a prospective bug-fix for dd_io.4th that you may wish to try:
>
> https://pastebin.com/mBisVvXv
>
Thanks! Will try it.
> 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).
>
--
KM
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-09-07 08:45 +0200 |
| Message-ID | <117lmhg$2e74o$1@dont-email.me> |
| In reply to | #135588 |
On 9/7/2026 4:16 AM, Krishna Myneni wrote:
> On 9/6/26 20:00, dxf wrote:
[..]>> 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).
While experimenting/fooling around, I noticed something strange with my
own implementation:
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
fdrop 0e dd+e. 1.00000000000000000000000000000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-20 fmax dd+e. 1.00000000000000000001000000000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-21 fmax dd+e. 1.00000000000000000000100000000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-22 fmax dd+e. 1.00000000000000000000010000000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-23 fmax dd+e. 1.00000000000000000000000999999e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-24 fmax dd+e. 1.00000000000000000000000100000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-28 fmax dd+e. 1.00000000000000000000000000009e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-29 fmax dd+e. 1.00000000000000000000000000001e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
1e-30 fmax dd+e. 1.00000000000000000000000000000e+000 ok
FORTH> 53-bits! even-mode s" 0.9999999999999999999999999999D" >dd
fdup +e. dd+e. -1.0000030317734970271e-0028
1.00000000000000000000000000050e+000 ok
It looks like >DD leaves something small for the float having the LSBs,
instead of 0e. This must be related to a problem with the FPU stack not
obeying 53bits! for some reason:
FORTH> locate 53-bits!
File: d:\dfwforth/x64/inc/floatlib.inc
20:
21:
22: T: 24-bits! ( -- ) [ 'controlword ] LITERAL 16B@ $FCFF AND
[ 'controlword ] LITERAL 16B! 1E FTRUNC FDROP T;
23>> T: 53-bits! ( -- ) [ 'controlword ] LITERAL 16B@ $FCFF AND $200
OR [ 'controlword ] LITERAL 16B! 1E FTRUNC FDROP T;
24: T: 80-bits! ( -- ) [ 'controlword ] LITERAL 16B@ $FCFF AND $300
OR [ 'controlword ] LITERAL 16B! 1E FTRUNC FDROP T;
25:
( I forgot why the "1E FTRUNC FDROP" is there :--)
-marcel
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-07 21:11 +1000 |
| Message-ID | <6a9e9bfa@news.ausics.net> |
| In reply to | #135589 |
On 7/09/2026 4:45 pm, marcel hendrix wrote:
> On 9/7/2026 4:16 AM, Krishna Myneni wrote:
>> On 9/6/26 20:00, dxf wrote:
> [..]>> 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).
>
> While experimenting/fooling around, I noticed something strange with my own implementation:
> [...]
> It looks like >DD leaves something small for the float having the LSBs, instead of 0e. This must be related to a problem with the FPU stack not
> obeying 53bits! for some reason:
Try replacing:
ddprecision 0 ?DO peelDigit shiftBy10 LOOP
peelDigit
ddprecision 0 ?DO cnvrt LOOP FDEC @ HOLD cnvrt
with:
ddprecision 0 ?DO peelDigit shiftBy10 LOOP
peelDigit
ddprecision 0 ?DO
DUP 0< IF 10 + SWAP 1- SWAP THEN cnvrt
LOOP FDEC @ HOLD cnvrt
I found 'peelDigit' could return weird values and these messed up the output.
The above attempts to workaround those values.
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-09-07 21:30 +0200 |
| Message-ID | <117n3d1$12e1j$1@dont-email.me> |
| In reply to | #135591 |
On 9/7/2026 1:11 PM, dxf wrote: > DUP 0< IF 10 + SWAP 1- SWAP THEN cnvrt Wow, thanks, that is indeed helpful! Before fix: FORTH> 1e-16 PTEST Found 0 errors. ok FORTH> 1e-18 PTEST Found 1 errors. ok FORTH> 1e-20 PTEST Found 1 errors. ok FORTH> 1e-22 PTEST Found 1 errors. ok FORTH> 1e-28 PTEST Found 1 errors. ok FORTH> 1e-30 PTEST Found 31 errors. ok FORTH> 1e-29 PTEST Found 1 errors. ok After fix FORTH> 1e-16 PTEST Found 0 errors. ok FORTH> 1e-18 PTEST Found 0 errors. ok FORTH> 1e-21 PTEST Found 0 errors. ok FORTH> 1e-30 PTEST Found 30 errors. ok FORTH> BENCH exactmulbench -- double-doubles (53) -- 10,000,000 executions of dd* : 0.475 seconds elapsed. 10,000,000 executions of dd/ : 0.552 seconds elapsed. 10,000,000 executions of dd+ : 0.194 seconds elapsed. 10,000,000 executions of dd- : 0.203 seconds elapsed. 10,000,000 executions of ddsqrt : 0.508 seconds elapsed. 10,000,000 executions of dd^n : 1.239 seconds elapsed. 1,000,000 executions of ddexp : 1.905 seconds elapsed. 1,000,000 executions of ddln : 2.246 seconds elapsed. 1,000,000 executions of ddsin : 2.241 seconds elapsed. 1,000,000 executions of ddcos : 2.163 seconds elapsed. 1,000,000 executions of ddtan : 2.348 seconds elapsed. 1,000,000 executions of ddasin : 3.185 seconds elapsed. 1,000,000 executions of ddacos : 3.187 seconds elapsed. 1,000,000 executions of ddatan : 3.033 seconds elapsed. 1,000,000 executions of ddasinh : 2.359 seconds elapsed. 1,000,000 executions of ddacosh : 2.131 seconds elapsed. 1,000,000 executions of ddatanh : 1.235 seconds elapsed. -- doubles (53) -- 10,000,000 executions of f* : 0.010 seconds elapsed. 10,000,000 executions of f/ : 0.010 seconds elapsed. 10,000,000 executions of f+ : 0.009 seconds elapsed. 10,000,000 executions of f- : 0.010 seconds elapsed. 10,000,000 executions of fsqrt : 0.010 seconds elapsed. 10,000,000 executions of f^n : 0.141 seconds elapsed. 1,000,000 executions of fexp : 0.000 seconds elapsed. 1,000,000 executions of fln : 0.001 seconds elapsed. 1,000,000 executions of fsin : 0.001 seconds elapsed. 1,000,000 executions of fcos : 0.001 seconds elapsed. 1,000,000 executions of ftan : 0.001 seconds elapsed. 1,000,000 executions of fasin : 0.056 seconds elapsed. 1,000,000 executions of facos : 0.055 seconds elapsed. 1,000,000 executions of fatan : 0.001 seconds elapsed. 1,000,000 executions of fasinh : 0.051 seconds elapsed. 1,000,000 executions of facosh : 0.019 seconds elapsed. 1,000,000 executions of fatanh : 0.018 seconds elapsed. -- doubles (80) -- 10,000,000 executions of f* : 0.010 seconds elapsed. 10,000,000 executions of f/ : 0.008 seconds elapsed. 10,000,000 executions of f+ : 0.010 seconds elapsed. 10,000,000 executions of f- : 0.010 seconds elapsed. 10,000,000 executions of fsqrt : 0.009 seconds elapsed. 10,000,000 executions of f^n : 0.142 seconds elapsed. 1,000,000 executions of fexp : 0.001 seconds elapsed. 1,000,000 executions of fln : 0.001 seconds elapsed. 1,000,000 executions of fsin : 0.001 seconds elapsed. 1,000,000 executions of fcos : 0.001 seconds elapsed. 1,000,000 executions of ftan : 0.001 seconds elapsed. 1,000,000 executions of fasin : 0.060 seconds elapsed. 1,000,000 executions of facos : 0.055 seconds elapsed. 1,000,000 executions of fatan : 0.001 seconds elapsed. 1,000,000 executions of fasinh : 0.050 seconds elapsed. 1,000,000 executions of facosh : 0.020 seconds elapsed. 1,000,000 executions of fatanh : 0.019 seconds elapsed. 0.305 seconds elapsed. ok 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 -marcel
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-07 19:09 -0500 |
| Message-ID | <117njn9$3o0n4$1@dont-email.me> |
| In reply to | #135593 |
On 9/7/26 14:30, marcel hendrix wrote: > On 9/7/2026 1:11 PM, dxf wrote: >> DUP 0< IF 10 + SWAP 1- SWAP THEN cnvrt > > Wow, thanks, that is indeed helpful! > ... > > FORTH> BENCH exactmulbench > -- double-doubles (53) -- > 10,000,000 executions of dd* : 0.475 seconds elapsed. > 10,000,000 executions of dd/ : 0.552 seconds elapsed. > 10,000,000 executions of dd+ : 0.194 seconds elapsed. > 10,000,000 executions of dd- : 0.203 seconds elapsed. > 10,000,000 executions of ddsqrt : 0.508 seconds elapsed. > 10,000,000 executions of dd^n : 1.239 seconds elapsed. > 1,000,000 executions of ddexp : 1.905 seconds elapsed. > 1,000,000 executions of ddln : 2.246 seconds elapsed. > 1,000,000 executions of ddsin : 2.241 seconds elapsed. > 1,000,000 executions of ddcos : 2.163 seconds elapsed. > 1,000,000 executions of ddtan : 2.348 seconds elapsed. > 1,000,000 executions of ddasin : 3.185 seconds elapsed. > 1,000,000 executions of ddacos : 3.187 seconds elapsed. > 1,000,000 executions of ddatan : 3.033 seconds elapsed. > 1,000,000 executions of ddasinh : 2.359 seconds elapsed. > 1,000,000 executions of ddacosh : 2.131 seconds elapsed. > 1,000,000 executions of ddatanh : 1.235 seconds elapsed. ... Did you implement the double-double trig functions in Forth from translating Bailey's ddfun Fortran package? If so, would you please share the code? -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-09-08 14:06 +0200 |
| Message-ID | <117otp2$2h377$1@dont-email.me> |
| In reply to | #135596 |
On 9/8/2026 2:09 AM, Krishna Myneni wrote: > On 9/7/26 14:30, marcel hendrix wrote: [..]>> 1,000,000 executions of ddexp : 1.905 seconds elapsed. >> 1,000,000 executions of ddln : 2.246 seconds elapsed. >> 1,000,000 executions of ddsin : 2.241 seconds elapsed. >> 1,000,000 executions of ddcos : 2.163 seconds elapsed. >> 1,000,000 executions of ddtan : 2.348 seconds elapsed. >> 1,000,000 executions of ddasin : 3.185 seconds elapsed. >> 1,000,000 executions of ddacos : 3.187 seconds elapsed. >> 1,000,000 executions of ddatan : 3.033 seconds elapsed. >> 1,000,000 executions of ddasinh : 2.359 seconds elapsed. >> 1,000,000 executions of ddacosh : 2.131 seconds elapsed. >> 1,000,000 executions of ddatanh : 1.235 seconds elapsed. > ... > Did you implement the double-double trig functions in Forth from > translating Bailey's ddfun Fortran package? If so, would you please > share the code? The problem is that I had/have no convenient way to see if the routines are indeed accurate to 30 decimals. When I compare them to extended floats, they agree to about ~ 16 digits, of course. But if that were all, it is quicker to use extended float with a 0e underneath :-) Let me think on this a bit more when I have more time. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-08 12:14 -0500 |
| Message-ID | <117pfqa$cijg$1@dont-email.me> |
| In reply to | #135606 |
On 9/8/26 7:06 AM, marcel hendrix wrote: > On 9/8/2026 2:09 AM, Krishna Myneni wrote: >> On 9/7/26 14:30, marcel hendrix wrote: > [..]>> 1,000,000 executions of ddexp : 1.905 seconds elapsed. >>> 1,000,000 executions of ddln : 2.246 seconds elapsed. >>> 1,000,000 executions of ddsin : 2.241 seconds elapsed. >>> 1,000,000 executions of ddcos : 2.163 seconds elapsed. >>> 1,000,000 executions of ddtan : 2.348 seconds elapsed. >>> 1,000,000 executions of ddasin : 3.185 seconds elapsed. >>> 1,000,000 executions of ddacos : 3.187 seconds elapsed. >>> 1,000,000 executions of ddatan : 3.033 seconds elapsed. >>> 1,000,000 executions of ddasinh : 2.359 seconds elapsed. >>> 1,000,000 executions of ddacosh : 2.131 seconds elapsed. >>> 1,000,000 executions of ddatanh : 1.235 seconds elapsed. >> ... >> Did you implement the double-double trig functions in Forth from >> translating Bailey's ddfun Fortran package? If so, would you please >> share the code? > The problem is that I had/have no convenient way to see if the routines > are indeed accurate to 30 decimals. When I compare them to extended > floats, they agree to about ~ 16 digits, of course. But if that were > all, it is quicker to use extended float with a 0e underneath :-) > > Let me think on this a bit more when I have more time. > > -marcel If you send me your test cases, I can use the MPFR library to compute them to 30 significant digits or more. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-09-09 02:15 +0200 |
| Message-ID | <117q8g0$13rso$1@dont-email.me> |
| In reply to | #135610 |
On 9/8/2026 7:14 PM, Krishna Myneni wrote: > On 9/8/26 7:06 AM, marcel hendrix wrote: >> On 9/8/2026 2:09 AM, Krishna Myneni wrote: [..]>> The problem is that I had/have no convenient way to see if the routines >> are indeed accurate to 30 decimals. [..] > If you send me your test cases, I can use the MPFR library to compute > them to 30 significant digits or more. I have the MPFR dlls too, but I thought MATLAB would be easier because iForth can call it interactively. However, I encountered a bug / undocumented feature in its vpa() and am now waiting for the Mathworks to help me out. -marcel
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-08 14:41 +1000 |
| Message-ID | <6a9f91e8$1@news.ausics.net> |
| In reply to | #135593 |
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? I don't claim to know what's going on (even the 'peelDigit' thing). Anyone wanting to dig into the I/O routines is welcome. As regards the output quirk above, using a different *input* routine makes a difference. Note below the different hex floats produced. This seems sufficient to affect DDFS. output. The same output routine (with mod as previously described) is used in both cases. \ using JVN >DD include dd.f s" 9.9999999999999999d" >dd dddup cr ddfs. +0.9999999999999999900000000000000 dd 1 ok pad f! pad 1 floats + f! pad 2 floats dump 195FE0 | C3 89 D8 97 B2 D2 9C BC 00 00 00 00 00 00 24 40 \ using dxf >DD include ddfloat.f s" 9.9999999999999999d" >dd drop dddup cr ddfs. 9.9999999999999999000000000000000E0 ok. pad f! pad 1 floats + f! pad 2 floats dump 195FE0 | BD 89 D8 97 B2 D2 9C BC 00 00 00 00 00 00 24 40
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web