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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-20 03:40 -0500 |
| Message-ID | <1166ei9$3baem$1@dont-email.me> |
| In reply to | #135376 |
On 8/19/26 21:35, dxf wrote: > 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. > It took me a while to see it too. We are used to thinking about output PRECISION, but one could also define an input precision for floating point numbers. Therefore I think using PRECISION which specifies output precision is a bad idea, because then it would confuse whether we are talking about modifying the input precision or output precision. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-08-22 18:43 +0200 |
| Message-ID | <nnd$6f208860$68a10a50@f74d0630bb9d26c6> |
| In reply to | #135350 |
In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; Again this f that you pass is inherently imprecise. Don't expect reproducible results. Groetjes Albert -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-23 18:47 +1000 |
| Message-ID | <6a8ab39b$1@news.ausics.net> |
| In reply to | #135389 |
On 23/08/2026 2:43 am, albert@spenarnc.xs4all.nl wrote: > In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; > > Again this f that you pass is inherently imprecise. Don't > expect reproducible results. It's user beware. What works at double-precision on the x87 won't necessarily work at extended precision.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-23 14:34 -0500 |
| Message-ID | <116fhve$26f3o$1@dont-email.me> |
| In reply to | #135399 |
On 8/23/26 03:47, dxf wrote: > On 23/08/2026 2:43 am, albert@spenarnc.xs4all.nl wrote: >> In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; >> >> Again this f that you pass is inherently imprecise. Don't >> expect reproducible results. > > It's user beware. What works at double-precision on the x87 won't > necessarily work at extended precision. > Except that it doesn't work at double-precision either. -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-24 11:42 +1000 |
| Message-ID | <6a8ba185$1@news.ausics.net> |
| In reply to | #135402 |
On 24/08/2026 5:34 am, Krishna Myneni wrote: > On 8/23/26 03:47, dxf wrote: >> On 23/08/2026 2:43 am, albert@spenarnc.xs4all.nl wrote: >>> In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; >>> >>> Again this f that you pass is inherently imprecise. Don't >>> expect reproducible results. >> >> It's user beware. What works at double-precision on the x87 won't >> necessarily work at extended precision. >> > > Except that it doesn't work at double-precision either. The #EXP test I posted indicates no errors. What is a user to think? IEEE stipulates of a 'no error' binary/ascii conversion. Every step of the way, users are told 'don't worry, we have you covered'. After all, they're being sold a product. It's like the dual-xt solution to state-smartness. If one doesn't look too closely, it appears to work.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-23 22:11 -0500 |
| Message-ID | <116gcoo$2dtuf$1@dont-email.me> |
| In reply to | #135403 |
On 8/23/26 8:42 PM, dxf wrote: > On 24/08/2026 5:34 am, Krishna Myneni wrote: >> On 8/23/26 03:47, dxf wrote: >>> On 23/08/2026 2:43 am, albert@spenarnc.xs4all.nl wrote: >>>> In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; >>>> >>>> Again this f that you pass is inherently imprecise. Don't >>>> expect reproducible results. >>> >>> It's user beware. What works at double-precision on the x87 won't >>> necessarily work at extended precision. >>> >> >> Except that it doesn't work at double-precision either. > > The #EXP test I posted indicates no errors. What is a user to think? > IEEE stipulates of a 'no error' binary/ascii conversion. ... I will search for and post some examples which won't work at double precision with your definition above. > Every step > of the way, users are told 'don't worry, we have you covered'. ... It is complex for a number of reasons: 1. the discrete nature of floating point numbers with a finite number of significand bits, 2. mapping the significand, exponent pair from one base to another, and 3. *doing it within 1 ulp of accuracy.* Add to that further complexity from having to take into account different rounding modes, IEEE special values, and the feature of underflow to occur gradually, using subnormal numbers. There is example code for correct binary to ascii decimal conversion, such as David Gay's dtoa.c. From his paper, the aim is to show that it can be done fast for most cases. It appears that much of the complexity in his code is a result of optimizations for speed. If one throws away the idea of efficiency and special values, the algorithm for the conversion is fairly easy to express using big integer arithmetic. I posted partially complete Forth code, using big integer arithmetic, elsewhere for the conversion. /* dtoa for IEEE arithmetic (dmg): convert double to ASCII string. * * Inspired by "How to Print Floating-Point Numbers Accurately" by * Guy L. Steele, Jr. and Jon L. White [Proc. ACM SIGPLAN '90, pp. 112-126]. * * Modifications: * 1. Rather than iterating, we use a simple numeric overestimate * to determine k = floor(log10(d)). ... -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-24 14:37 +1000 |
| Message-ID | <6a8bca85$1@news.ausics.net> |
| In reply to | #135404 |
On 24/08/2026 1:11 pm, Krishna Myneni wrote: > On 8/23/26 8:42 PM, dxf wrote: >> On 24/08/2026 5:34 am, Krishna Myneni wrote: >>> On 8/23/26 03:47, dxf wrote: >>>> On 23/08/2026 2:43 am, albert@spenarnc.xs4all.nl wrote: >>>>> In article <115qthh$3pnrg$1@dont-email.me>, dxf <dxforth@gmail.com> 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 ; >>>>> >>>>> Again this f that you pass is inherently imprecise. Don't >>>>> expect reproducible results. >>>> >>>> It's user beware. What works at double-precision on the x87 won't >>>> necessarily work at extended precision. >>>> >>> >>> Except that it doesn't work at double-precision either. >> >> The #EXP test I posted indicates no errors. What is a user to think? >> IEEE stipulates of a 'no error' binary/ascii conversion. ... > > I will search for and post some examples which won't work at double precision with your definition above. You may but IEEE's intention was to hide such as far as possible. >> Every step >> of the way, users are told 'don't worry, we have you covered'. ... > > It is complex for a number of reasons: > > 1. the discrete nature of floating point numbers with a finite number of significand bits, > > 2. mapping the significand, exponent pair from one base to another, and > > 3. *doing it within 1 ulp of accuracy.* > > Add to that further complexity from having to take into account different rounding modes, IEEE special values, and the feature of underflow to occur gradually, using subnormal numbers. > > There is example code for correct binary to ascii decimal conversion, such as David Gay's dtoa.c. From his paper, the aim is to show that it can be done fast for most cases. It appears that much of the complexity in his code is a result of optimizations for speed. If one throws away the idea of efficiency and special values, the algorithm for the conversion is fairly easy to express using big integer arithmetic. I posted partially complete Forth code, using big integer arithmetic, elsewhere for the conversion. > ... Would you have done any of that had IEEE not required it? I don't regret being caught out by 1E-3 #EXP at 80-bits giving me an answer I wasn't expecting. I got to see reality as opposed to what IEEE wants me to see. The result is I'm more suspicious of IEEE than without. Most (all?) forths using the x87 are using native precision. Apparently forthers prefer higher precision with the ugliness of fp exposed, than an air-brushed lower precision.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-24 06:42 +0000 |
| Message-ID | <2026Aug24.084259@mips.complang.tuwien.ac.at> |
| In reply to | #135405 |
dxf <dxforth@gmail.com> writes:
>On 24/08/2026 1:11 pm, Krishna Myneni wrote:
>> There is example code for correct binary to ascii decimal conversion, such as David Gay's dtoa.c. From his paper, the aim is to show that it can be done fast for most cases. It appears that much of the complexity in his code is a result of optimizations for speed. If one throws away the idea of efficiency and special values, the algorithm for the conversion is fairly easy to express using big integer arithmetic. I posted partially complete Forth code, using big integer arithmetic, elsewhere for the conversion.
>> ...
>
>Would you have done any of that had IEEE not required it?
Does IEEE 754 require it? Since when?
>I don't regret being
>caught out by 1E-3 #EXP at 80-bits giving me an answer I wasn't expecting. I
>got to see reality as opposed to what IEEE wants me to see.
What is it that IEEE supposedly wants you to see?
>The result is I'm
>more suspicious of IEEE than without. Most (all?) forths using the x87 are using
>native precision. Apparently forthers prefer higher precision with the ugliness
>of fp exposed, than an air-brushed lower precision.
Intels 80-bit format can represent more values than binary64 (IEEE 754
DP FP), but, like any binary formats, it cannot represent 1/5, powers
of 1/5, and integer multiples of such numbers, while decimal
respresentation can: 1/5=0.2. In particular, neither the 80-bit
format nor binary64 can represent 1e-3. The closest binary64 number
to 1e-3 is (represented in decimal):
.001000000000000000020816681711721685132943093776702880859375e
So when you compute the decimal exponent exactly, you get -3.
However, for 1e-6 the closest binary64 number is:
9.99999999999999954748111825886258685613938723690807819366455078125e-7
And when I use PAD 100 REPRESENT on this number (with a REPRESENT that
produces the exact result, given a big-enough buffer), REPRESENT
returns an exponent of -6 (while the naively expected value is -5, for
"0.1e-5").
Concerning the method using FLOG, the rounding involved in that may
compensate the necessary conversion error in the conversion to binary
FP, but I would not rely on it without numerical analysis (moreover,
AFAIK 1/2 ulp error is not required by IEEE 754 for transcendental
functions like FLOG). For the number close to 1e-6 above, FLOG in
Gforth (using glibc's log10() implementation) gives me -6e, however,
so in this case the rounding does compensate the conversion error.
Concerning 80387 80-bit numbers, how accurate is the FLOG computation?
And how accurate is your string->FP conversion? The "reality" you see
may be due to inherent limitations of binary FP (with binary64 dodging
them just by luck), or it may be due to inaccuracies coming from the
implementation of these functions.
Just to check whether FLOG really works for binary64, I wrote:
: foo
324 1 do
cr i 0 <<# #s s" 1e-" holds #> 2dup type >float drop flog space e. #>>
loop ;
This shows the naively expected FLOG result for i=1 to i=311, whith
last lines of the output being:
1e-308 -308e
1e-309 -309e
1e-310 -310e
1e-311 -311e
1e-312 -312.0000000000007e
1e-313 -312.9999999999942e
1e-314 -314.0000000000157e
1e-315 -315.0000000006594e
1e-316 -316.0000000070965e
1e-317 -316.99999989981154e
1e-318 -318.0000005435218e
1e-319 -319.000004834948e
1e-320 -320.000004834948e
1e-321 -321.0008639736692e
1e-322 -322.0051853474518e
1e-323 -323.0051853474518e
The subnormal numbers start around 1e-308, and with subnormal numbers
fewer and fewer mantissa bits are significant the smaller they get.
It is interesting that even for 1e-311 we still get the expected
result, and the inaccuracies from subnormality only become apparent
with 1e-312. Given that, I would expect that accurate string->FP
conversion and an accurate FLOG would also produce the expected
results for normal numbers in the 80387 80-bit format.
- 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-26 01:56 +1000 |
| Message-ID | <6a8dbb2d$1@news.ausics.net> |
| In reply to | #135407 |
On 24/08/2026 4:42 pm, Anton Ertl wrote: > ... > Intels 80-bit format can represent more values than binary64 (IEEE 754 > DP FP), but, like any binary formats, it cannot represent 1/5, powers > of 1/5, and integer multiples of such numbers, while decimal > respresentation can: 1/5=0.2. In particular, neither the 80-bit > format nor binary64 can represent 1e-3. The closest binary64 number > to 1e-3 is (represented in decimal): > > .001000000000000000020816681711721685132943093776702880859375e > > So when you compute the decimal exponent exactly, you get -3. > > However, for 1e-6 the closest binary64 number is: > > 9.99999999999999954748111825886258685613938723690807819366455078125e-7 > > And when I use PAD 100 REPRESENT on this number (with a REPRESENT that > produces the exact result, given a big-enough buffer), REPRESENT > returns an exponent of -6 (while the naively expected value is -5, for > "0.1e-5"). > ... All those digits are impressive but shine a light on them and they vanish like apparitions at a seance: Gforth 0.7.9_20200709 1e-6 pad 100 represent 2drop cr . pad 100 dump -6 6FFFFF877278: 39 39 39 39 39 39 39 39 - 39 39 39 39 39 39 39 39 9999999999999999 6FFFFF877288: 35 34 37 34 38 31 31 31 - 38 32 35 38 38 36 32 35 5474811182588625 6FFFFF877298: 38 36 38 35 36 31 33 39 - 33 38 37 30 30 30 30 30 8685613938700000 6FFFFF8772A8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772B8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772C8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772D8: 30 30 30 30 - 0000 ok 1e-6 1e f+ 1e f- pad 100 represent 2drop cr . pad 100 dump -6 6FFFFF877278: 39 39 39 39 39 39 39 39 - 39 39 31 37 37 33 33 33 9999999999177333 6FFFFF877288: 36 32 30 35 33 36 39 35 - 36 30 30 34 37 39 38 34 6205369560047984 6FFFFF877298: 31 32 33 32 32 39 39 38 - 30 34 37 30 30 30 30 30 1232299804700000 6FFFFF8772A8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772B8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772C8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 6FFFFF8772D8: 30 30 30 30 - 0000 ok
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-25 16:24 +0000 |
| Message-ID | <2026Aug25.182436@mips.complang.tuwien.ac.at> |
| In reply to | #135422 |
dxf <dxforth@gmail.com> writes:
>Gforth 0.7.9_20200709
>
>1e-6 pad 100 represent 2drop cr . pad 100 dump
>-6
>6FFFFF877278: 39 39 39 39 39 39 39 39 - 39 39 39 39 39 39 39 39 9999999999999999
>6FFFFF877288: 35 34 37 34 38 31 31 31 - 38 32 35 38 38 36 32 35 5474811182588625
>6FFFFF877298: 38 36 38 35 36 31 33 39 - 33 38 37 30 30 30 30 30 8685613938700000
>6FFFFF8772A8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000
>6FFFFF8772B8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000
>6FFFFF8772C8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000
>6FFFFF8772D8: 30 30 30 30 - 0000
This is interesting. This REPRESENT produces zeros instead of the
trailing non-zero digits 23690807819366455078125, i.e., it is unfit
for E.EXACT. But the first 43 digits look perfect. Which libc is
this Gforth using?
Concerning the number of digits, you use E.EXACT only when you want to
know the exact decimal representation for the FP number. The main use
is for showing the exact numbers involved. The number of digits that
is necessary to distinguish one binary64 number from the next one is
17 or less.
>1e-6 1e f+ 1e f- pad 100 represent 2drop cr . pad 100 dump
This phenomenon is called cancellation
<https://en.wikipedia.org/wiki/Catastrophic_cancellation>. Let's look
at the individual steps with e.exact:
1e-6 fdup e.exact \ 9.99999999999999954748111825886258685613938723690807819366455078125e-7
1e fdup e.exact \ 1e
f+ fdup e.exact \ 1.0000009999999999177333620536956004798412322998046875e
1e f- e.exact \ 9.999999999177333620536956004798412322998046875e-7
So E.EXACT shows us nicely that the loss of digits from the FP number
close to 1e-6 occurs during the addition, and the subtraction then
amplifies the relative size of the error. Let's see how that is shown
with E.:
1e-6 fdup e. \
1e fdup e. \
f+ fdup e. \
1e f- e. \
1e-6 fdup e. \ 1e-6
1e fdup e. \ 1e
f+ fdup e. \ 1.000001e
1e f- e. \ 9.999999999177334e-7
So the resulting number has an error in the last 6 digits,
corresponding to the 6 digits that 1e is larger than 1e-6. In this
notation it is far less obvious why you get some other result than
1e-6 as output. That's what E.EXACT is good for.
- 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-26 13:24 +1000 |
| Message-ID | <6a8e5c71$1@news.ausics.net> |
| In reply to | #135423 |
On 26/08/2026 2:24 am, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> Gforth 0.7.9_20200709 >> >> 1e-6 pad 100 represent 2drop cr . pad 100 dump >> -6 >> 6FFFFF877278: 39 39 39 39 39 39 39 39 - 39 39 39 39 39 39 39 39 9999999999999999 >> 6FFFFF877288: 35 34 37 34 38 31 31 31 - 38 32 35 38 38 36 32 35 5474811182588625 >> 6FFFFF877298: 38 36 38 35 36 31 33 39 - 33 38 37 30 30 30 30 30 8685613938700000 >> 6FFFFF8772A8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 >> 6FFFFF8772B8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 >> 6FFFFF8772C8: 30 30 30 30 30 30 30 30 - 30 30 30 30 30 30 30 30 0000000000000000 >> 6FFFFF8772D8: 30 30 30 30 - 0000 > > This is interesting. This REPRESENT produces zeros instead of the > trailing non-zero digits 23690807819366455078125, i.e., it is unfit > for E.EXACT. But the first 43 digits look perfect. Which libc is > this Gforth using? > > Concerning the number of digits, you use E.EXACT only when you want to > know the exact decimal representation for the FP number. The main use > is for showing the exact numbers involved. The number of digits that > is necessary to distinguish one binary64 number from the next one is > 17 or less. > >> 1e-6 1e f+ 1e f- pad 100 represent 2drop cr . pad 100 dump > > This phenomenon is called cancellation > <https://en.wikipedia.org/wiki/Catastrophic_cancellation>. Let's look > at the individual steps with e.exact: > > 1e-6 fdup e.exact \ 9.99999999999999954748111825886258685613938723690807819366455078125e-7 > 1e fdup e.exact \ 1e > f+ fdup e.exact \ 1.0000009999999999177333620536956004798412322998046875e > 1e f- e.exact \ 9.999999999177333620536956004798412322998046875e-7 > > So E.EXACT shows us nicely that the loss of digits from the FP number > close to 1e-6 occurs during the addition, and the subtraction then > amplifies the relative size of the error. Let's see how that is shown > with E.: > > 1e-6 fdup e. \ > 1e fdup e. \ > f+ fdup e. \ > 1e f- e. \ > 1e-6 fdup e. \ 1e-6 > 1e fdup e. \ 1e > f+ fdup e. \ 1.000001e > 1e f- e. \ 9.999999999177334e-7 > > So the resulting number has an error in the last 6 digits, > corresponding to the 6 digits that 1e is larger than 1e-6. In this > notation it is far less obvious why you get some other result than > 1e-6 as output. That's what E.EXACT is good for. E.EXACT is good for fooling people into believing a 64-bit float can hold a 66 digit number. Luckily when most users apply 1E-6 PAD 100 REPRESENT they get nothing like that. I wouldn't call demonstrating the limits of what floating-point can do "a phenomena". Reality-check would be closer to the mark.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-25 23:26 -0500 |
| Message-ID | <116lpti$bdle$1@dont-email.me> |
| In reply to | #135424 |
On 8/25/26 10:24 PM, dxf wrote: ... > E.EXACT is good for fooling people into believing a 64-bit > float can hold a 66 digit number. ... A correct REPRESENT shows the following using the latest commit (2cc4eb0) of kForth-Win32. 1e-6 pad 100 represent ok pad 100 type 9999999999999999547481118258862586856139387236908078193664550781250000000000000000000 000000000000000 ok 100 set-precision 1e-6 fs. 1e-6 fs. 9.99999999999999954748111825886258685613938723690807819366455078125000000000000000000 0000000000000000e-07 ok \ FS. uses the digits provided by REPRESENT There is some problem with the version of Gforth which you are using. More importantly, do you believe a 64-bit floating point number can represent 2^-1074? How many decimal digits does the significand of 2^-1074 have? You can go to Wolfram alpha and type this in, and keep asking for more digits until it has no more to show. In IEEE-754 double precision encoding, this is exactly the meaning of the following 64-bit hex number: $0000000000000001 Try it on kForth-32/64, or on the most recent commit (2cc4eb0) of kForth-Win32. include ans-words pad 8 erase 1 pad ! 17 set-precision pad df@ fs. 100 set-precision pad df@ fs. 500 set-precision pad df@ fs. 750 set-precision pad df@ fs. 800 set-precision pad df@ fs. Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. -- Krishna Myneni
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-26 18:57 +1000 |
| Message-ID | <6a8eaa6a$1@news.ausics.net> |
| In reply to | #135426 |
On 26/08/2026 2:26 pm, Krishna Myneni wrote: > On 8/25/26 10:24 PM, dxf wrote: > ... >> E.EXACT is good for fooling people into believing a 64-bit >> float can hold a 66 digit number. ... > A correct REPRESENT shows the following using the latest commit (2cc4eb0) of kForth-Win32. > > 1e-6 pad 100 represent > ok > pad 100 type > 9999999999999999547481118258862586856139387236908078193664550781250000000000000000000 > 000000000000000 ok > > 100 set-precision > 1e-6 fs. > 1e-6 fs. > 9.99999999999999954748111825886258685613938723690807819366455078125000000000000000000 > 0000000000000000e-07 ok > > \ FS. uses the digits provided by REPRESENT AFAICS there's no such requirement in ANS and 'common practice' certainly isn't that. > There is some problem with the version of Gforth which you are using. Given its age, I'm surprised it gave what it did. > More importantly, do you believe a 64-bit floating point number can represent 2^-1074? How many decimal digits does the significand of 2^-1074 have? You can go to Wolfram alpha and type this in, and keep asking for more digits until it has no more to show. > > In IEEE-754 double precision encoding, this is exactly the meaning of the following 64-bit hex number: > > $0000000000000001 > > Try it on kForth-32/64, or on the most recent commit (2cc4eb0) of kForth-Win32. > > include ans-words > > pad 8 erase > 1 pad ! > > 17 set-precision > pad df@ fs. > > 100 set-precision > pad df@ fs. > > 500 set-precision > pad df@ fs. > > 750 set-precision > pad df@ fs. > > 800 set-precision > pad df@ fs. > > Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. I can print thousands of digits of PI. What good is that to someone that wants to solve real-world problems?
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-27 09:24 -0500 |
| Message-ID | <116phat$1hrjd$1@dont-email.me> |
| In reply to | #135430 |
On 8/26/26 03:57, dxf wrote: > On 26/08/2026 2:26 pm, Krishna Myneni wrote: >> On 8/25/26 10:24 PM, dxf wrote: >> ... >>> E.EXACT is good for fooling people into believing a 64-bit >>> float can hold a 66 digit number. ... >> A correct REPRESENT shows the following using the latest commit (2cc4eb0) of kForth-Win32. >> >> 1e-6 pad 100 represent >> ok >> pad 100 type >> 9999999999999999547481118258862586856139387236908078193664550781250000000000000000000 >> 000000000000000 ok >> >> 100 set-precision >> 1e-6 fs. >> 1e-6 fs. >> 9.99999999999999954748111825886258685613938723690807819366455078125000000000000000000 >> 0000000000000000e-07 ok >> >> \ FS. uses the digits provided by REPRESENT > > AFAICS there's no such requirement in ANS and 'common practice' certainly isn't that. > ... >> >> Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. > > I can print thousands of digits of PI. What good is that to someone that wants > to solve real-world problems? > If it was only that simple. In order to do range reduction for accurate evaluation of trig functions e.g. FSIN and FCOS you need to represent pi to a minimum of 53 decimal digits. Otherwise arguments to the native fpu instructions on x87 begin showing inaccuracies above arguments of 50,000 radians, with the accuracy rapidly degrading each order of magnitude above that, as demonstrated in an earlier thread. If you are not concerned about that i.e. not a "real-world" problem for you, that's fine. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-28 11:14 +1000 |
| Message-ID | <6a90e0fb$1@news.ausics.net> |
| In reply to | #135444 |
On 28/08/2026 12:24 am, Krishna Myneni wrote: > On 8/26/26 03:57, dxf wrote: > ... >>> >>> Yes, a 64-bit binary float in IEEE 754 format can hold a number with more than 750 decimal digits in its significand. And one can correctly print all of them. >> >> I can print thousands of digits of PI. What good is that to someone that wants >> to solve real-world problems? >> > > If it was only that simple. In order to do range reduction for accurate evaluation of trig functions e.g. FSIN and FCOS you need to represent pi to a minimum of 53 decimal digits. Otherwise arguments to the native fpu instructions on x87 begin showing inaccuracies above arguments of 50,000 radians, with the accuracy rapidly degrading each order of magnitude above that, as demonstrated in an earlier thread. > > If you are not concerned about that i.e. not a "real-world" problem for you, that's fine. AFAIK commercial forth systems don't support more than native x87 SIN COS. Not to say there isn't/won't be a need, rather it seems minimal. While my fp experience is next to nil, I felt reassured watching Richard Wagner's (aerospace engineer designing simulators) presentation on YT. He references using both SwiftForth and VFX in his projects. His reply to a question about locals was equally enlightening. As was his entire demeanour. He doesn't seem to find any problem with the forth tools he uses.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Pelc <stephen@vfxforth.com> |
|---|---|
| Date | 2026-08-28 10:23 +0000 |
| Message-ID | <116rnis$27njv$1@dont-email.me> |
| In reply to | #135447 |
On 28 Aug 2026 at 02:14:34 GMT+1, "dxf" <dxforth@gmail.com> wrote: > AFAIK commercial forth systems don't support more than native x87 SIN COS. > Not to say there isn't/won't be a need, rather it seems minimal. VFX supports: X87 with x87 stack X87. with external stack SSE with external stack 128 bit software with external stack and there's VFP64 for Arm64 systems Stephen -- Stephen Pelc, stephen@vfxforth.com Wodni & Pelc GmbH Vienna, Austria Tel: +44 (0)7803 903612, +34 649 662 974 http://www.vfxforth.com/downloads/VfxCommunity/ free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-08-28 21:28 +1000 |
| Message-ID | <6a9170ca$1@news.ausics.net> |
| In reply to | #135450 |
On 28/08/2026 8:23 pm, Stephen Pelc wrote: > On 28 Aug 2026 at 02:14:34 GMT+1, "dxf" <dxforth@gmail.com> wrote: > >> AFAIK commercial forth systems don't support more than native x87 SIN COS. >> Not to say there isn't/won't be a need, rather it seems minimal. > > VFX supports: > X87 with x87 stack > X87. with external stack > SSE with external stack > 128 bit software with external stack > > and there's > VFP64 for Arm64 systems > > Stephen My comment was in respect of range reduction for the x87 SIN/COS functions. Not complaining, just saying ... Wolfram sin(1e100) -0.372376123661276688262086695553164295719667883567434702364415388... Gforth 0.7.9_20200709 1e100 fsin f. -0.380637731005029 ok VFX Forth 64 for Windows x64 Version: 5.43 [build 4241] Build date: 22 December 2023 1e100 fsin f. 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ok SwiftForth x64-Windows 4.1.6 01-Apr-2026 1e100 fsin f. 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 09:04 -0500 |
| Message-ID | <116s4ho$2dpj8$1@dont-email.me> |
| In reply to | #135451 |
On 8/28/26 06:28, dxf wrote: > On 28/08/2026 8:23 pm, Stephen Pelc wrote: >> On 28 Aug 2026 at 02:14:34 GMT+1, "dxf" <dxforth@gmail.com> wrote: >> >>> AFAIK commercial forth systems don't support more than native x87 SIN COS. >>> Not to say there isn't/won't be a need, rather it seems minimal. >> >> VFX supports: >> X87 with x87 stack >> X87. with external stack >> SSE with external stack >> 128 bit software with external stack >> >> and there's >> VFP64 for Arm64 systems >> >> Stephen > > My comment was in respect of range reduction for the x87 SIN/COS functions. > Not complaining, just saying ... > > Wolfram > > sin(1e100) > > -0.372376123661276688262086695553164295719667883567434702364415388... > > Gforth 0.7.9_20200709 > > 1e100 fsin f. -0.380637731005029 ok > > VFX Forth 64 for Windows x64 > Version: 5.43 [build 4241] > Build date: 22 December 2023 > > 1e100 fsin f. 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ok > > SwiftForth x64-Windows 4.1.6 01-Apr-2026 > > 1e100 fsin f. 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok > > Please check 1e18 as the argument to FSIN and FCOS for SwiftForth and VFX Forth. If the native x87 FSIN and FCOS instructions are being used, then, for double precision args, the expected results at a precision of 17 are FSIN: -9.9281610405300346e-01 FCOS: 1.1965025504785125e-01 The above numbers have large error without range reduction. glibc sin(x) and cos(x), unless they are fairly old, should give the range-reduced results, gcc sin(1e18) = -9.9296932074040511e-01 gcc cos(1e18) = 1.1837199021871073e-01 -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 09:10 -0500 |
| Message-ID | <116s4s9$2dpj8$2@dont-email.me> |
| In reply to | #135456 |
On 8/28/26 09:04, Krishna Myneni wrote: > On 8/28/26 06:28, dxf wrote: >> On 28/08/2026 8:23 pm, Stephen Pelc wrote: >>> On 28 Aug 2026 at 02:14:34 GMT+1, "dxf" <dxforth@gmail.com> wrote: >>> >>>> AFAIK commercial forth systems don't support more than native x87 >>>> SIN COS. >>>> Not to say there isn't/won't be a need, rather it seems minimal. >>> >>> VFX supports: >>> X87 with x87 stack >>> X87. with external stack >>> SSE with external stack >>> 128 bit software with external stack >>> >>> and there's >>> VFP64 for Arm64 systems >>> >>> Stephen >> >> My comment was in respect of range reduction for the x87 SIN/COS >> functions. >> Not complaining, just saying ... >> >> Wolfram >> >> sin(1e100) >> >> -0.372376123661276688262086695553164295719667883567434702364415388... >> >> Gforth 0.7.9_20200709 >> >> 1e100 fsin f. -0.380637731005029 ok >> >> VFX Forth 64 for Windows x64 >> Version: 5.43 [build 4241] >> Build date: 22 December 2023 >> >> 1e100 fsin f. >> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ok >> >> SwiftForth x64-Windows 4.1.6 01-Apr-2026 >> >> 1e100 fsin f. >> 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok >> >> > > Please check 1e18 as the argument to FSIN and FCOS for SwiftForth and > VFX Forth. If the native x87 FSIN and FCOS instructions are being used, > then, for double precision args, the expected results at a precision of > 17 are > > FSIN: -9.9281610405300346e-01 Sorry, that should be FSIN: -9.9281610405300347e-01 > FCOS: 1.1965025504785125e-01 > > The above numbers have large error without range reduction. glibc sin(x) > and cos(x), unless they are fairly old, should give the range-reduced > results, > > gcc sin(1e18) = -9.9296932074040511e-01 > gcc cos(1e18) = 1.1837199021871073e-01 >
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-28 14:17 +0000 |
| Message-ID | <2026Aug28.161745@mips.complang.tuwien.ac.at> |
| In reply to | #135451 |
dxf <dxforth@gmail.com> writes:
>Wolfram
>
>sin(1e100)
>
>-0.372376123661276688262086695553164295719667883567434702364415388...
>
>Gforth 0.7.9_20200709
>
>1e100 fsin f. -0.380637731005029 ok
Note that when you convert 1e100 to an FP value in Gforth (with
binary64 FP), you get an FP value with the exact value
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104e
So even with perfect range reduction, the result of FSIN will be
close to the sine of 100e only by luck.
The largest power of 10 that binary64 can represent accurately is 1e22
(why not just 1e16 or so? because 1e22 actually has the mantissa
5^22=2384185791015625, which is a 16-digit number, or, more
importantly, it fits in the 52+1 bits that's available for the
mantissa; the rest of 10e22 is in the exponent).
The 80-bit numbers with their 64-bit mantissa have more headroom, but
still by far not enough for 1e100.
>VFX Forth 64 for Windows x64
> Version: 5.43 [build 4241]
> Build date: 22 December 2023
>
>1e100 fsin f. 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ok
>
>SwiftForth x64-Windows 4.1.6 01-Apr-2026
>
>1e100 fsin f. 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok
FSIN returning a number outside the [-1,1] range is disappointing,
however.
- 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]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web