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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-16 09:42 +1000 |
| Subject | Getting the exponent of an x87 float |
| Message-ID | <115qthh$3pnrg$1@dont-email.me> |
Implementers of floating point output have likely encountered the exponent function which returns the exponent of a given fp number. It's typically defined: : exp# ( f -- exp ) fdup f0= if fdrop 0 exit then fabs flog floor f>s ; It works well enough until applied to the x87 FPU where the FLOG FLOOR calculation is done at 80-bit precision: 1e-1 exp# . -1 ok 1e-2 exp# . -2 ok 1e-3 exp# . -4 ok 1e-4 exp# . -4 ok 1e-5 exp# . -5 ok In the third case -3 was expected but -4 was produced. Needless to say this can/has resulted in problems down the track. Testing over the full range of exponents (0..4932) 235 such duplicated exponents were found. Below is the test program used, along with a potential fix. Enjoy ----------------- create aa 8 allot : exp# ( f -- exp ) fdup f0= if fdrop 0 exit then fabs flog \ aa df! aa df@ \ fix floor f>s ; 4932 value size \ assume 80 bit extended precision variable last variable start variable cnt : .duplicates ( -- ) start @ size 0 do dup @ dup last @ = if dup . 1 cnt +! then last ! 1 cells + loop drop ; : test+ ( -- ) -10000 last ! here start ! 1e size 1+ 0 do fdup exp# , 10e f* loop fdrop .duplicates ; : test- ( -- ) -10000 last ! here start ! 0.1e size 1+ 0 do fdup exp# , 10e f/ loop fdrop .duplicates ; : test ( -- ) cr cr ." Testing for duplicated exponents ... " 0 cnt ! test+ test- cr cr cnt @ . ." duplicates " ; test --------------------
[toc] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-17 15:11 +0000 |
| Message-ID | <2026Aug17.171145@mips.complang.tuwien.ac.at> |
| In reply to | #135350 |
dxf <dxforth@gmail.com> writes:
>Implementers of floating point output have likely encountered the exponent
>function which returns the exponent of a given fp number. It's typically
>defined:
>
>: exp# ( f -- exp )
> fdup f0= if fdrop 0 exit then
> fabs flog
> floor f>s ;
>
>It works well enough until applied to the x87 FPU where the FLOG FLOOR
>calculation is done at 80-bit precision:
>
>1e-1 exp# . -1 ok
>1e-2 exp# . -2 ok
>1e-3 exp# . -4 ok
>1e-4 exp# . -4 ok
>1e-5 exp# . -5 ok
>
>In the third case -3 was expected but -4 was produced. Needless to say this
>can/has resulted in problems down the track. Testing over the full range of
>exponents (0..4932) 235 such duplicated exponents were found. Below is the
>test program used, along with a potential fix.
Given that 1/5 cannot be represented exactly in binary floating point
(whether binary64, binary32, binary128 or Intels 80-bit format), the
numbers you get when you type in 1e-1 etc. can be either above or
below the value you would like (typically half of the numbers are
above and half of them are below the value). Next, you check by using
FLOG, which also performs some rounding. With luck, the result will
be what you would like to see, but without either proper numerical
analysis or (in this case possible) exhaustive testing I would not
rely on it. Your exhaustive testing has shown that mistrust is
justified.
>create aa 8 allot
>
>: exp# ( f -- exp )
> fdup f0= if fdrop 0 exit then
> fabs flog
>\ aa df! aa df@ \ fix
> floor f>s ;
That's interesting. Your fix is to introduce additional rounding
after the FLOG step (the rounding happens implicitly in the DF!).
Yes, this will help for 1e-3 and friends, but it also means that
0.999999999999999999e-4 exp# .
prints -4 instead of -5.
One way to implement exp# so it always produces the result you expect
would be to have a table of the 1e-N values, and use (binary) search
to find the exponent.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-18 03:47 +1000 |
| Message-ID | <6a834928$1@news.ausics.net> |
| In reply to | #135355 |
On 18/08/2026 1:11 am, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> Implementers of floating point output have likely encountered the exponent >> function which returns the exponent of a given fp number. It's typically >> defined: >> >> : exp# ( f -- exp ) >> fdup f0= if fdrop 0 exit then >> fabs flog >> floor f>s ; >> >> It works well enough until applied to the x87 FPU where the FLOG FLOOR >> calculation is done at 80-bit precision: >> >> 1e-1 exp# . -1 ok >> 1e-2 exp# . -2 ok >> 1e-3 exp# . -4 ok >> 1e-4 exp# . -4 ok >> 1e-5 exp# . -5 ok >> >> In the third case -3 was expected but -4 was produced. Needless to say this >> can/has resulted in problems down the track. Testing over the full range of >> exponents (0..4932) 235 such duplicated exponents were found. Below is the >> test program used, along with a potential fix. > > Given that 1/5 cannot be represented exactly in binary floating point > (whether binary64, binary32, binary128 or Intels 80-bit format), the > numbers you get when you type in 1e-1 etc. can be either above or > below the value you would like (typically half of the numbers are > above and half of them are below the value). Next, you check by using > FLOG, which also performs some rounding. With luck, the result will > be what you would like to see, but without either proper numerical > analysis or (in this case possible) exhaustive testing I would not > rely on it. Your exhaustive testing has shown that mistrust is > justified. > >> create aa 8 allot >> >> : exp# ( f -- exp ) >> fdup f0= if fdrop 0 exit then >> fabs flog >> \ aa df! aa df@ \ fix >> floor f>s ; > > That's interesting. Your fix is to introduce additional rounding > after the FLOG step (the rounding happens implicitly in the DF!). > Yes, this will help for 1e-3 and friends, but it also means that > > 0.999999999999999999e-4 exp# . > > prints -4 instead of -5. The output routine using it doesn't seem affected. My problem was output wasn't switching to sci notation when input fell below 0.001. I'd seen the patch years ago in another forth. Only now did I realize what it was for. > One way to implement exp# so it always produces the result you expect > would be to have a table of the 1e-N values, and use (binary) search > to find the exponent. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-17 21:18 +0000 |
| Message-ID | <2026Aug17.231810@mips.complang.tuwien.ac.at> |
| In reply to | #135356 |
dxf <dxforth@gmail.com> writes:
>The output routine using it doesn't seem affected. My problem was
>output wasn't switching to sci notation when input fell below 0.001.
>I'd seen the patch years ago in another forth. Only now did I realize
>what it was for.
For output I would use the exponent coming from REPRESENT. E.g., consider a
number that can can be output as
0.9999e5
If you make the buffer shorter (say to three digits, REPRESENT would
produce output that is more in line with
0.1e4
So an exponent without the rest does not help.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-18 12:15 +1000 |
| Message-ID | <6a83c032$1@news.ausics.net> |
| In reply to | #135357 |
On 18/08/2026 7:18 am, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> The output routine using it doesn't seem affected. My problem was >> output wasn't switching to sci notation when input fell below 0.001. >> I'd seen the patch years ago in another forth. Only now did I realize >> what it was for. > > For output I would use the exponent coming from REPRESENT. E.g., consider a > number that can can be output as > > 0.9999e5 > > If you make the buffer shorter (say to three digits, REPRESENT would > produce output that is more in line with > > 0.1e4 > > So an exponent without the rest does not help. I did that for cases where FLOG might not be available. OTOH if EXP# already exists the inclination will be to use it (simpler, faster). AFAICS used in isolation a patched EXP# that works on every decade with quirks elsewhere is better than an unpatched EXP# known to have tripped up users. Used within REPRESENT does a patched EXP# adversely affect it? Original implementer notes suggest the patch was introduced some two decades ago. It's still there. Not a definitive answer but in the absence of anything else...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-18 09:01 +0000 |
| Message-ID | <2026Aug18.110144@mips.complang.tuwien.ac.at> |
| In reply to | #135358 |
dxf <dxforth@gmail.com> writes:
>On 18/08/2026 7:18 am, Anton Ertl wrote:
>> dxf <dxforth@gmail.com> writes:
>>> The output routine using it doesn't seem affected. My problem was
>>> output wasn't switching to sci notation when input fell below 0.001.
>>> I'd seen the patch years ago in another forth. Only now did I realize
>>> what it was for.
>>
>> For output I would use the exponent coming from REPRESENT. E.g., consider a
>> number that can can be output as
>>
>> 0.9999e5
>>
>> If you make the buffer shorter (say to three digits, REPRESENT would
>> produce output that is more in line with
>>
>> 0.1e4
>>
>> So an exponent without the rest does not help.
>
>I did that for cases where FLOG might not be available. OTOH if EXP#
>already exists the inclination will be to use it (simpler, faster).
If you want to output, you use REPRESENT or something like it anyway.
The important part is that the mantissa part and the exponent part are
in sync, not that the exponent part is rounded in some way that the
production of the mantissa part is not aware of.
>AFAICS used in isolation a patched EXP# that works on every decade with
>quirks elsewhere is better than an unpatched EXP# known to have tripped
>up users. Used within REPRESENT does a patched EXP# adversely affect
>it?
If the exponent is not in sync with the mantissa, I expect outputs
that are off by a factor if 10. Maybe only a few of those, but even
one is one too many.
>Original implementer notes suggest the patch was introduced some
>two decades ago. It's still there. Not a definitive answer but in the
>absence of anything else...
Maybe it only tells us that nobody cares.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-18 20:04 +1000 |
| Message-ID | <6a842e17$1@news.ausics.net> |
| In reply to | #135359 |
On 18/08/2026 7:01 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> On 18/08/2026 7:18 am, Anton Ertl wrote: >>> dxf <dxforth@gmail.com> writes: >>>> The output routine using it doesn't seem affected. My problem was >>>> output wasn't switching to sci notation when input fell below 0.001. >>>> I'd seen the patch years ago in another forth. Only now did I realize >>>> what it was for. >>> >>> For output I would use the exponent coming from REPRESENT. E.g., consider a >>> number that can can be output as >>> >>> 0.9999e5 >>> >>> If you make the buffer shorter (say to three digits, REPRESENT would >>> produce output that is more in line with >>> >>> 0.1e4 >>> >>> So an exponent without the rest does not help. >> >> I did that for cases where FLOG might not be available. OTOH if EXP# >> already exists the inclination will be to use it (simpler, faster). > > If you want to output, you use REPRESENT or something like it anyway. > The important part is that the mantissa part and the exponent part are > in sync, not that the exponent part is rounded in some way that the > production of the mantissa part is not aware of. > >> AFAICS used in isolation a patched EXP# that works on every decade with >> quirks elsewhere is better than an unpatched EXP# known to have tripped >> up users. Used within REPRESENT does a patched EXP# adversely affect >> it? > > If the exponent is not in sync with the mantissa, I expect outputs > that are off by a factor if 10. Maybe only a few of those, but even > one is one too many. Here's output using the troublesome value you pinpointed earlier. If it were going fail I'd expect it here. 18 set-precision ok 0.999999999999999999e-4 17 0 fs.r 1.00000000000000000E-04 ok 0.999999999999999997e-4 17 0 fs.r 1.00000000000000000E-04 ok 0.999999999999999996e-4 17 0 fs.r 1.00000000000000000E-04 ok 0.999999999999999995e-4 17 0 fs.r 9.99999999999999990E-05 ok 0.99999999999999999e-4 17 0 fs.r 9.99999999999999990E-05 ok 0.9999999999999999e-4 17 0 fs.r 9.99999999999999900E-05 ok 0.999999999999999e-4 17 0 fs.r 9.99999999999999000E-05 ok 0.99999999999999e-4 17 0 fs.r 9.99999999999990001E-05 ok 0.9999999999999e-4 17 0 fs.r 9.99999999999900001E-05 ok 0.999999999999e-4 17 0 fs.r 9.99999999999000001E-05 ok 0.99999999999e-4 17 0 fs.r 9.99999999990000001E-05 ok >> Original implementer notes suggest the patch was introduced some >> two decades ago. It's still there. Not a definitive answer but in the >> absence of anything else... > > Maybe it only tells us that nobody cares. Nobody cares to report bugs? > - anton
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-19 02:30 +1000 |
| Message-ID | <6a8488a2$1@news.ausics.net> |
| In reply to | #135360 |
On 18/08/2026 8:04 pm, dxf wrote: > On 18/08/2026 7:01 pm, Anton Ertl wrote: >> dxf <dxforth@gmail.com> writes: >>> On 18/08/2026 7:18 am, Anton Ertl wrote: >> ... >> If you want to output, you use REPRESENT or something like it anyway. >> The important part is that the mantissa part and the exponent part are >> in sync, not that the exponent part is rounded in some way that the >> production of the mantissa part is not aware of. >> >>> AFAICS used in isolation a patched EXP# that works on every decade with >>> quirks elsewhere is better than an unpatched EXP# known to have tripped >>> up users. Used within REPRESENT does a patched EXP# adversely affect >>> it? >> >> If the exponent is not in sync with the mantissa, I expect outputs >> that are off by a factor if 10. Maybe only a few of those, but even >> one is one too many. > > Here's output using the troublesome value you pinpointed earlier. > If it were going fail I'd expect it here. > > 18 set-precision ok > 0.999999999999999999e-4 17 0 fs.r 1.00000000000000000E-04 ok > 0.999999999999999997e-4 17 0 fs.r 1.00000000000000000E-04 ok > 0.999999999999999996e-4 17 0 fs.r 1.00000000000000000E-04 ok > 0.999999999999999995e-4 17 0 fs.r 9.99999999999999990E-05 ok > 0.99999999999999999e-4 17 0 fs.r 9.99999999999999990E-05 ok > 0.9999999999999999e-4 17 0 fs.r 9.99999999999999900E-05 ok > 0.999999999999999e-4 17 0 fs.r 9.99999999999999000E-05 ok > 0.99999999999999e-4 17 0 fs.r 9.99999999999990001E-05 ok > 0.9999999999999e-4 17 0 fs.r 9.99999999999900001E-05 ok > 0.999999999999e-4 17 0 fs.r 9.99999999999000001E-05 ok > 0.99999999999e-4 17 0 fs.r 9.99999999990000001E-05 ok > ... Further investigation shows not all REPRESENTs will be minimally affected by the change to EXP# . So it's not a general solution. 'Forget it, Jake. It's floating point.'
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-18 09:16 -0500 |
| Message-ID | <1161pgg$1sm82$1@dont-email.me> |
| In reply to | #135359 |
On 8/18/26 04:01, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> On 18/08/2026 7:18 am, Anton Ertl wrote: ... > If you want to output, you use REPRESENT or something like it anyway. > The important part is that the mantissa part and the exponent part are > in sync, not that the exponent part is rounded in some way that the > production of the mantissa part is not aware of. > ... > > If the exponent is not in sync with the mantissa, I expect outputs > that are off by a factor if 10. Maybe only a few of those, but even > one is one too many. > Yes. The foolproof way I can think of for converting the binary floating point number to a decimal number to obtain the decimal exponent is to use big number arithmetic. An outline of the procedure using big arithmetic is: 1. Extract the binary significand as a big integer. Ignore the sign bit for the fp number. 2. Multiply the big significand by 10^(max_exp), where max_exp is the maximum decimal exponent. The result is the big number prod1. 3. Extract the fp binary exponent, and unbias it. Compute 2^exp where exp is the unbiased binary exponent. This is a big number also, bigexp. 4. If exp > 0, multiply prod1 by bigexp. If exp < 0, divide prod1 by bigexp. The result is prod2. 5. Convert prod2 to a string (with no leading zeros). The number of characters in the string will be related to the decimal exponent. I haven't tested this. The dtoa() function in dtoa.c will also give a string, from which the decimal exponent may be extracted. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-23 06:06 -0500 |
| Message-ID | <116ek7e$1s69r$1@dont-email.me> |
| In reply to | #135363 |
On 8/18/26 9:16 AM, Krishna Myneni wrote:
> On 8/18/26 04:01, Anton Ertl wrote:
>> dxf <dxforth@gmail.com> writes:
>>> On 18/08/2026 7:18 am, Anton Ertl wrote:
> ...
...
> The dtoa() function in dtoa.c will also give a string, from which the
> decimal exponent may be extracted.
>
I've been experimenting with the dtoa() function from dtoa.c (for use in
kForth-Win32). The decimal exponent for the double precision argument d,
rounded to a given number of digits, ndigits, can be determined from the
returned value in the argument *decpt -- it is simply decpt-1.
I believe this is what the OP wants.
--
Krishna
C declaration:
char *dtoa( double d, int mode, int ndigits, int *decpt, int *sign, char
**rve );
C++ declaration will have preceding, extern "C" .
See the following line and below in dtoa.c for a description of parameters:
/* dtoa for IEEE arithmetic (dmg): convert double to ASCII string.
=== begin abridged descr. of parameters for dtoa() ===
d = double precision floating point number
mode = 0 through 9:
0 shortest string that yields d when read in and rounded to nearest.
1 like 0, but with Steele & White stopping rule
e.g. with IEEE P754 arithmetic , mode 0 gives 1e23 whereas mode
1 gives 9.999999999999999e22.
2 max(1,ndigits) significant digits. This gives a return value
similar to that of ecvt, except that trailing zeros are suppressed.
3 through ndigits past the decimal point. This gives a return
value similar to that from fcvt, except that trailing zeros are
suppressed, and ndigits can be negative.
4,5 similar to 2 and 3, respectively, but (in round-nearest mode)
with the tests of mode 0 to possibly return a shorter string that rounds
to d. ...
ndigits: specifies Forth PRECISION for mode 2 or #decimal places for mode 3
decpt: specifies the position of the decimal point in the string, and
can be negative. [ * The decimal exponent is decpt - 1 * ]
sign: is 0 for positive d, 1 for negative d
rve: end pointer for digits without trailing zeros.
=== end abridged descr. ===
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-08-18 17:55 +0000 |
| Message-ID | <11626b8$v1c9$3@paganini.bofh.team> |
| In reply to | #135356 |
dxf <dxforth@gmail.com> wrote:
> On 18/08/2026 1:11 am, Anton Ertl wrote:
>> dxf <dxforth@gmail.com> writes:
>>> Implementers of floating point output have likely encountered the exponent
>>> function which returns the exponent of a given fp number. It's typically
>>> defined:
>>>
>>> : exp# ( f -- exp )
>>> fdup f0= if fdrop 0 exit then
>>> fabs flog
>>> floor f>s ;
>>>
>>> It works well enough until applied to the x87 FPU where the FLOG FLOOR
>>> calculation is done at 80-bit precision:
>>>
>>> 1e-1 exp# . -1 ok
>>> 1e-2 exp# . -2 ok
>>> 1e-3 exp# . -4 ok
>>> 1e-4 exp# . -4 ok
>>> 1e-5 exp# . -5 ok
>>>
>>> In the third case -3 was expected but -4 was produced. Needless to say this
>>> can/has resulted in problems down the track. Testing over the full range of
>>> exponents (0..4932) 235 such duplicated exponents were found. Below is the
>>> test program used, along with a potential fix.
>>
>> Given that 1/5 cannot be represented exactly in binary floating point
>> (whether binary64, binary32, binary128 or Intels 80-bit format), the
>> numbers you get when you type in 1e-1 etc. can be either above or
>> below the value you would like (typically half of the numbers are
>> above and half of them are below the value). Next, you check by using
>> FLOG, which also performs some rounding. With luck, the result will
>> be what you would like to see, but without either proper numerical
>> analysis or (in this case possible) exhaustive testing I would not
>> rely on it. Your exhaustive testing has shown that mistrust is
>> justified.
>>
>>> create aa 8 allot
>>>
>>> : exp# ( f -- exp )
>>> fdup f0= if fdrop 0 exit then
>>> fabs flog
>>> \ aa df! aa df@ \ fix
>>> floor f>s ;
>>
>> That's interesting. Your fix is to introduce additional rounding
>> after the FLOG step (the rounding happens implicitly in the DF!).
>> Yes, this will help for 1e-3 and friends, but it also means that
>>
>> 0.999999999999999999e-4 exp# .
>>
>> prints -4 instead of -5.
>
> The output routine using it doesn't seem affected. My problem was
> output wasn't switching to sci notation when input fell below 0.001.
> I'd seen the patch years ago in another forth. Only now did I realize
> what it was for.
If your goal is printing, then natural approach is to produce a
pair of integers m and k so that m*10^k is good approximation to
f. Modern libraries aim for "correctly rounded" result, that
is pair (m, k) should represent decimal floating point number
closest to f. That requires increased precision in intermediate
calculations. If you are satified with close but possibly not
closest number than needed calculation can be done in normal
floating point.
Once you have m and k as above you can produce digits of m and
_after_ that decide if number should be printed in scientific
notation. The only tricky case there is if you are requested
to produce number in traditional notation and exponent is
large and you want all printed digits to be correct. Then you
need intermediate calculations with high precion (proportional
to the number of printed digits).
One more thing: when printing it is typically expected that
result will be rounded. Directly using floor in such case
is problematic. One possible work around is to add a fuzz
factor bigger than possible error and apply floor after
that.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-19 13:48 +1000 |
| Message-ID | <6a852781$1@news.ausics.net> |
| In reply to | #135366 |
On 19/08/2026 3:55 am, Waldek Hebisch wrote: > dxf <dxforth@gmail.com> wrote: >> On 18/08/2026 1:11 am, Anton Ertl wrote: >>> dxf <dxforth@gmail.com> writes: >>>> Implementers of floating point output have likely encountered the exponent >>>> function which returns the exponent of a given fp number. It's typically >>>> defined: >>>> >>>> : exp# ( f -- exp ) >>>> fdup f0= if fdrop 0 exit then >>>> fabs flog >>>> floor f>s ; >>>> >>>> It works well enough until applied to the x87 FPU where the FLOG FLOOR >>>> calculation is done at 80-bit precision: >>>> >>>> 1e-1 exp# . -1 ok >>>> 1e-2 exp# . -2 ok >>>> 1e-3 exp# . -4 ok >>>> 1e-4 exp# . -4 ok >>>> 1e-5 exp# . -5 ok >>>> >>>> In the third case -3 was expected but -4 was produced. Needless to say this >>>> can/has resulted in problems down the track. Testing over the full range of >>>> exponents (0..4932) 235 such duplicated exponents were found. Below is the >>>> test program used, along with a potential fix. >>> >>> Given that 1/5 cannot be represented exactly in binary floating point >>> (whether binary64, binary32, binary128 or Intels 80-bit format), the >>> numbers you get when you type in 1e-1 etc. can be either above or >>> below the value you would like (typically half of the numbers are >>> above and half of them are below the value). Next, you check by using >>> FLOG, which also performs some rounding. With luck, the result will >>> be what you would like to see, but without either proper numerical >>> analysis or (in this case possible) exhaustive testing I would not >>> rely on it. Your exhaustive testing has shown that mistrust is >>> justified. >>> >>>> create aa 8 allot >>>> >>>> : exp# ( f -- exp ) >>>> fdup f0= if fdrop 0 exit then >>>> fabs flog >>>> \ aa df! aa df@ \ fix >>>> floor f>s ; >>> >>> That's interesting. Your fix is to introduce additional rounding >>> after the FLOG step (the rounding happens implicitly in the DF!). >>> Yes, this will help for 1e-3 and friends, but it also means that >>> >>> 0.999999999999999999e-4 exp# . >>> >>> prints -4 instead of -5. >> >> The output routine using it doesn't seem affected. My problem was >> output wasn't switching to sci notation when input fell below 0.001. >> I'd seen the patch years ago in another forth. Only now did I realize >> what it was for. > > If your goal is printing, then natural approach is to produce a > pair of integers m and k so that m*10^k is good approximation to > f. Modern libraries aim for "correctly rounded" result, that > is pair (m, k) should represent decimal floating point number > closest to f. That requires increased precision in intermediate > calculations. If you are satified with close but possibly not > closest number than needed calculation can be done in normal > floating point. > > Once you have m and k as above you can produce digits of m and > _after_ that decide if number should be printed in scientific > notation. The only tricky case there is if you are requested > to produce number in traditional notation and exponent is > large and you want all printed digits to be correct. Then you > need intermediate calculations with high precion (proportional > to the number of printed digits). > > One more thing: when printing it is typically expected that > result will be rounded. Directly using floor in such case > is problematic. One possible work around is to add a fuzz > factor bigger than possible error and apply floor after > that. I'm satisfied with 'close' as anything else becomes prohibitive. It's nevertheless interesting how most (all?) REPRESENTs can start out with the wrong exponent for 1E-3 and produce the correct result with basic math. It's doubtful implementers knew 1E-3 etc were problematic, let alone planned for it. Consequently there seems to be a good deal of 'luck' involved in fp. Since IEEE however, there's been the perception floating point can, should be, 'foolproof'. A good deal of effort has been thrown into it. I can't but help feel it's misguided. In my case I took Anton's advice and used REPRESENT to calculate the exponent of 1E-3. I don't like it - it's clumsy - but everything else has proven worse.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-19 17:14 +1000 |
| Message-ID | <6a8557d4$1@news.ausics.net> |
| In reply to | #135368 |
On 19/08/2026 1:48 pm, dxf wrote:
> ...
> In my case
> I ... used REPRESENT to calculate the exponent of
> 1E-3.
Hmm, testing shows REPRESENT to be way worse than an unpatched FLOG
for grabbing the exponent. If the following fails I give up!
: (G.) ( F: r -- ) ( n -- c-addr u )
>R FDUP FABS FDUP 1E-3 F< 0= >R 1E6 F< R> AND
R> SWAP IF (F.) ELSE (FS.) THEN ;
[toc] | [prev] | [next] | [standalone]
| From | peter <peter.noreply@tin.it> |
|---|---|
| Date | 2026-08-19 09:58 +0200 |
| Message-ID | <20260819095809.000026dc@tin.it> |
| In reply to | #135370 |
On Wed, 19 Aug 2026 17:14:28 +1000
dxf <dxforth@gmail.com> wrote:
> On 19/08/2026 1:48 pm, dxf wrote:
> > ...
> > In my case
> > I ... used REPRESENT to calculate the exponent of
> > 1E-3.
>
> Hmm, testing shows REPRESENT to be way worse than an unpatched FLOG
> for grabbing the exponent. If the following fails I give up!
>
> : (G.) ( F: r -- ) ( n -- c-addr u )
> >R FDUP FABS FDUP 1E-3 F< 0= >R 1E6 F< R> AND
> R> SWAP IF (F.) ELSE (FS.) THEN ;
>
What does the n do. It looks like it just remains on the stack.
I have
: E. ( F: r -- )
fdup (e.) dup >r
(es.) dup r> < if 2swap then 2drop type space ;
to decide what output function to use. It works as (f.) (fs.)
uses a circular buffer with 16 slots. (e.) (es.) are variants
of (f.) (fs.)
BR
Peter
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-19 19:14 +1000 |
| Message-ID | <6a8573e9$1@news.ausics.net> |
| In reply to | #135371 |
On 19/08/2026 5:58 pm, peter wrote: > On Wed, 19 Aug 2026 17:14:28 +1000 > dxf <dxforth@gmail.com> wrote: > >> On 19/08/2026 1:48 pm, dxf wrote: >>> ... >>> In my case >>> I ... used REPRESENT to calculate the exponent of >>> 1E-3. >> >> Hmm, testing shows REPRESENT to be way worse than an unpatched FLOG >> for grabbing the exponent. If the following fails I give up! >> >> : (G.) ( F: r -- ) ( n -- c-addr u ) >> >R FDUP FABS FDUP 1E-3 F< 0= >R 1E6 F< R> AND >> R> SWAP IF (F.) ELSE (FS.) THEN ; >> > > What does the n do. It looks like it just remains on the stack. n is the parameter for (F.) and (FS.). n>=0 prints that many decimal places and PRECISION has no effect. n<0 selects 'compact mode' and prints up to PRECISION significant digits with unnecessary signs and 0's removed. F. FS. G. use compact mode (implied n=-1). precision . 6 ok fpi fs. 3.14159E0 ok fpi 20 0 fs.r 3.14159265358979324000E+00 ok fpi -1 0 fs.r 3.14159E0 ok G. (compact mode, auto F. FS. switching) is the general purpose function. > I have > > : E. ( F: r -- ) > fdup (e.) dup >r > (es.) dup r> < if 2swap then 2drop type space ; > > to decide what output function to use. It works as (f.) (fs.) > uses a circular buffer with 16 slots. (e.) (es.) are variants > of (f.) (fs.) > > BR > Peter >
[toc] | [prev] | [next] | [standalone]
| From | peter <peter.noreply@tin.it> |
|---|---|
| Date | 2026-08-19 15:36 +0200 |
| Message-ID | <20260819153656.0000654a@tin.it> |
| In reply to | #135373 |
On Wed, 19 Aug 2026 19:14:16 +1000 dxf <dxforth@gmail.com> wrote: > On 19/08/2026 5:58 pm, peter wrote: > > On Wed, 19 Aug 2026 17:14:28 +1000 > > dxf <dxforth@gmail.com> wrote: > > > >> On 19/08/2026 1:48 pm, dxf wrote: > >>> ... > >>> In my case > >>> I ... used REPRESENT to calculate the exponent of > >>> 1E-3. > >> > >> Hmm, testing shows REPRESENT to be way worse than an unpatched FLOG > >> for grabbing the exponent. If the following fails I give up! > >> > >> : (G.) ( F: r -- ) ( n -- c-addr u ) > >> >R FDUP FABS FDUP 1E-3 F< 0= >R 1E6 F< R> AND > >> R> SWAP IF (F.) ELSE (FS.) THEN ; > >> > > > > What does the n do. It looks like it just remains on the stack. > > n is the parameter for (F.) and (FS.). n>=0 prints that many decimal > places and PRECISION has no effect. n<0 selects 'compact mode' and > prints up to PRECISION significant digits with unnecessary signs and > 0's removed. F. FS. G. use compact mode (implied n=-1). > > precision . 6 ok > fpi fs. 3.14159E0 ok > fpi 20 0 fs.r 3.14159265358979324000E+00 ok > fpi -1 0 fs.r 3.14159E0 ok > > G. (compact mode, auto F. FS. switching) is the general purpose function. I suspected something like that. I might borrow that! Peter > > I have > > > > : E. ( F: r -- ) > > fdup (e.) dup >r > > (es.) dup r> < if 2swap then 2drop type space ; > > > > to decide what output function to use. It works as (f.) (fs.) > > uses a circular buffer with 16 slots. (e.) (es.) are variants > > of (f.) (fs.) > > > > BR > > Peter > > >
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-20 12:36 +1000 |
| Message-ID | <6a86682f$1@news.ausics.net> |
| In reply to | #135374 |
On 19/08/2026 11:36 pm, peter wrote: > On Wed, 19 Aug 2026 19:14:16 +1000 > dxf <dxforth@gmail.com> wrote: > >> On 19/08/2026 5:58 pm, peter wrote: >>> On Wed, 19 Aug 2026 17:14:28 +1000 >>> dxf <dxforth@gmail.com> wrote: >>> >>>> On 19/08/2026 1:48 pm, dxf wrote: >>>>> ... >>>>> In my case >>>>> I ... used REPRESENT to calculate the exponent of >>>>> 1E-3. >>>> >>>> Hmm, testing shows REPRESENT to be way worse than an unpatched FLOG >>>> for grabbing the exponent. If the following fails I give up! >>>> >>>> : (G.) ( F: r -- ) ( n -- c-addr u ) >>>> >R FDUP FABS FDUP 1E-3 F< 0= >R 1E6 F< R> AND >>>> R> SWAP IF (F.) ELSE (FS.) THEN ; >>>> >>> >>> What does the n do. It looks like it just remains on the stack. >> >> n is the parameter for (F.) and (FS.). n>=0 prints that many decimal >> places and PRECISION has no effect. n<0 selects 'compact mode' and >> prints up to PRECISION significant digits with unnecessary signs and >> 0's removed. F. FS. G. use compact mode (implied n=-1). >> >> precision . 6 ok >> fpi fs. 3.14159E0 ok >> fpi 20 0 fs.r 3.14159265358979324000E+00 ok >> fpi -1 0 fs.r 3.14159E0 ok >> >> G. (compact mode, auto F. FS. switching) is the general purpose function. > > I suspected something like that. I might borrow that! > > Peter Details should you want them are at: FPOUT_SwiftForth4.zip https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-19 08:38 +0000 |
| Subject | Floating point (was: Getting the exponent of an x87 float) |
| Message-ID | <2026Aug19.103851@mips.complang.tuwien.ac.at> |
| In reply to | #135368 |
dxf <dxforth@gmail.com> writes:
>It's
>nevertheless interesting how most (all?) REPRESENTs can start out with
>the wrong exponent for 1E-3 and produce the correct result with basic
>math. It's doubtful implementers knew 1E-3 etc were problematic, let
>alone planned for it.
I don't know what REPRESENT implementations you have in mind. I am
sure that the glibc implementation of ecvt_r() (and REPRESENT in
Gforth is just the Forth word for ecvt_r()) was done by people who
knew about the various problems of the conversion between binary FP
and decimal string representation (in both directions).
>Consequently there seems to be a good deal of
>'luck' involved in fp.
That's one way to approach it. Another way is numerical analysis, but
that requires a lot of knowledge and a lot of work. So many people
just practice the "luck" approach: just do the computation without
analysis, and hope that the errors are small enough that the result is
good enough. Often it works, sometimes it doesn't.
>Since IEEE however, there's been the perception
>floating point can, should be, 'foolproof'.
Who had this perception? The Gforth manual contains the
following since before the first release (0.2.0 in 1996):
|Floating point numbers have a number of unpleasant surprises for the
|unwary (e.g., floating point addition is not associative) and even a
|few for the wary. You should not use them unless you know what you are
|doing or you don’t care that the results you get may be totally
|bogus. If you want to learn about the problems of floating point
|numbers (and how to avoid them), you might start with David Goldberg,
|What Every Computer Scientist Should Know About Floating-Point
|Arithmetic, ACM Computing Surveys 23(1):5−48, March 1991.
A link to that paper is:
<https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-19 18:44 -0500 |
| Message-ID | <1165f5a$32q5k$1@dont-email.me> |
| In reply to | #135350 |
On 8/15/26 18:42, dxf wrote: > Implementers of floating point output have likely encountered the exponent > function which returns the exponent of a given fp number. It's typically > defined: > > : exp# ( f -- exp ) > fdup f0= if fdrop 0 exit then > fabs flog > floor f>s ; > > It works well enough until applied to the x87 FPU where the FLOG FLOOR > calculation is done at 80-bit precision: > > 1e-1 exp# . -1 ok > 1e-2 exp# . -2 ok > 1e-3 exp# . -4 ok > 1e-4 exp# . -4 ok > 1e-5 exp# . -5 ok > > In the third case -3 was expected but -4 was produced. ... The expectation of -3 was based on an assumption of how many significant digits you want to round the result to. The correct answer may well be -4 based on the nearest binary representation to the decimal string for 80-bit precision i.e. 0.999999999....(non-9 digits)e-03. The notion of an EXP# definition is flawed without another argument which states the number of decimal digits to which the internal binary representation should be rounded. You could make that an argument or use the value of PRECISION. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-20 12:35 +1000 |
| Message-ID | <6a8667de$1@news.ausics.net> |
| In reply to | #135375 |
On 20/08/2026 9:44 am, Krishna Myneni wrote: > On 8/15/26 18:42, dxf wrote: >> Implementers of floating point output have likely encountered the exponent >> function which returns the exponent of a given fp number. It's typically >> defined: >> >> : exp# ( f -- exp ) >> fdup f0= if fdrop 0 exit then >> fabs flog >> floor f>s ; >> >> It works well enough until applied to the x87 FPU where the FLOG FLOOR >> calculation is done at 80-bit precision: >> >> 1e-1 exp# . -1 ok >> 1e-2 exp# . -2 ok >> 1e-3 exp# . -4 ok >> 1e-4 exp# . -4 ok >> 1e-5 exp# . -5 ok >> >> In the third case -3 was expected but -4 was produced. ... > The expectation of -3 was based on an assumption of how many significant digits you want to round the result to. The correct answer may well be -4 based on the nearest binary representation to the decimal string for 80-bit precision i.e. 0.999999999....(non-9 digits)e-03. The notion of an EXP# definition is flawed without another argument which states the number of decimal digits to which the internal binary representation should be rounded. You could make that an argument or use the value of PRECISION. I agree. Because I was seeing 1E-3 G. give '1E-3' in 80-bit versions instead of the expected '0.001' that it led down the proverbial rabbit hole. It wasn't until Peter asked 'what does n in (G.) do' that it clicked EXP# wasn't the only variable at play here. In short, my expectations for G. had been unrealistic.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web