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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 09:41 -0500 |
| Message-ID | <116s6ls$2dpj8$3@dont-email.me> |
| In reply to | #135458 |
On 8/28/26 09:17, Anton Ertl wrote: > 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 1e22 would be fine if they were not using the native x87 instructions. For 1e19 the native fpu FSIN gives a nan and FCOS jus returns 1e19. This is why I recommended using 1e18. -- KM
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-08-28 19:40 +0200 |
| Message-ID | <nnd$270a0ef9$1e25b41c@c1212810329f950c> |
| In reply to | #135458 |
In article <2026Aug28.161745@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>>SwiftForth x64-Windows 4.1.6 01-Apr-2026
>>
>>1e100 fsin f. 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok
>
>FSIN returning a number outside the [-1,1] range is disappointing,
>however.
That is the result of using FSIN as a wrapper of the 8087 instruction:
\ FCD9 FDD9 FED9 FFD9
0100 FCD9 4 2FAMILY, FRNDINT, FSCALE, FSIN, FCOS,
...
CODE FSIN FSIN, NEXT, END-CODE
In ciforth I have likewise not bothered. It makes no sense
to calculate sin(1_100)
The people at Swiftforth were of the same opinion.
The difference between an industrial and academic mindset?
>
>- 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
--
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 | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 14:00 -0500 |
| Message-ID | <116slt9$2k0en$1@dont-email.me> |
| In reply to | #135463 |
On 8/28/26 12:40, albert@spenarnc.xs4all.nl wrote: > In article <2026Aug28.161745@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > <SNIP> >>> SwiftForth x64-Windows 4.1.6 01-Apr-2026 >>> >>> 1e100 fsin f. 99999999999999998760·7777777700000007000000000000000000000000000000000000000000000000000000000000000.00000000 ok >> >> FSIN returning a number outside the [-1,1] range is disappointing, >> however. > > That is the result of using FSIN as a wrapper of the 8087 instruction: > \ FCD9 FDD9 FED9 FFD9 > 0100 FCD9 4 2FAMILY, FRNDINT, FSCALE, FSIN, FCOS, > ... > CODE FSIN FSIN, NEXT, END-CODE > > In ciforth I have likewise not bothered. It makes no sense > to calculate sin(1_100) > Maybe, but at the 1e9 level it is not hard to find a "real-world" example. Consider simulating a high-stability 1 GHz oscillator. We can compute the amplitude of the waveform with sin(2*pi*nu*t), with nu = 1e9 Hz. What is the amplitude of the wave at t = 1 m, 11.1 ns? The argument to the sin(x) function is x = 2*pi*1e9*60.0000000111e0 radians. With the x87 FSIN instruction, we get an amplitude of 5.8774328586351210e-01 With the glibc sin(x) function, we obtain 5.8774328547084587e-01 The fractional error in using the x87 FSIN, without range reduction, is on the order of -1e-9. The oscillator (clock) appears to be running about 1 Hz slower than the frequency used in the simulation because of the numerical error in the raw FSIN instruction. -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 14:25 -0500 |
| Message-ID | <116snc1$2k0en$2@dont-email.me> |
| In reply to | #135464 |
On 8/28/26 14:00, Krishna Myneni wrote: ... > > Consider simulating a high-stability 1 GHz oscillator. We can compute > the amplitude of the waveform with sin(2*pi*nu*t), with nu = 1e9 Hz. > > What is the amplitude of the wave at t = 1 m, 11.1 ns? The argument to > the sin(x) function is x = 2*pi*1e9*60.0000000111e0 radians. > > With the x87 FSIN instruction, we get an amplitude of > > 5.8774328586351210e-01 > > With the glibc sin(x) function, we obtain > > 5.8774328547084587e-01 > > The fractional error in using the x87 FSIN, without range reduction, is > on the order of -1e-9. The oscillator (clock) appears to be running > about 1 Hz slower than the frequency used in the simulation because of > the numerical error in the raw FSIN instruction. > A careful calculation gives the frequency error to be +1.3 milliHz. I mistakenly took the fractional error in the amplitude to be comparable to the phase error, which it isn't. Nevertheless, the issue is that there are numerical artifacts which may appear from the FSIN instruction, and which can be important to take into account. -- KM
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-28 14:40 -0500 |
| Message-ID | <116so74$2k0en$3@dont-email.me> |
| In reply to | #135465 |
On 8/28/26 14:25, Krishna Myneni wrote: > > A careful calculation gives the frequency error to be +1.3 milliHz. I > mistakenly took the fractional error in the amplitude to be comparable > to the phase error, which it isn't. > > Nevertheless, the issue is that there are numerical artifacts which may > appear from the FSIN instruction, and which can be important to take > into account. > Crap! It seems I can't read units after lunch. The frequency error is +1.3 pico-Hz, not milli-Hz. As a real-world phenomena, this is negligible. We will have to find a better example to satisfy dxforth. -- KM
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-08-29 12:17 +0200 |
| Message-ID | <116ubjb$34u1v$1@dont-email.me> |
| In reply to | #135466 |
On 8/28/2026 9:40 PM, Krishna Myneni wrote: > On 8/28/26 14:25, Krishna Myneni wrote: > > We will have to find a better example to satisfy dxforth. > Maybe this: what is the last digit of 3^47 ? ( 7 ) ( I did not solve it with floating point. ) -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-29 10:35 +0000 |
| Message-ID | <2026Aug29.123526@mips.complang.tuwien.ac.at> |
| In reply to | #135472 |
marcel hendrix <mhx@iae.nl> writes:
>Maybe this: what is the last digit of 3^47 ? ( 7 )
That's trivial:
: ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7"
It's unclear to me what the relevance for the original topic is,
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]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-08-29 15:02 +0200 |
| Message-ID | <116ul9s$mj0h$1@dont-email.me> |
| In reply to | #135473 |
On 8/29/2026 12:35 PM, Anton Ertl wrote: > marcel hendrix <mhx@iae.nl> writes: >> Maybe this: what is the last digit of 3^47 ? ( 7 ) > > That's trivial: > > : ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7" > > It's unclear to me what the relevance for the original topic is, > however. I was assuming something like 100 set-precision ok 3e 47e f** fs. would work on a suitable Forth. -marcel
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-08-29 15:51 +0200 |
| Message-ID | <nnd$57e392fe$164f21c7@952a43c4d6a59389> |
| In reply to | #135475 |
In article <116ul9s$mj0h$1@dont-email.me>, marcel hendrix <mhx@iae.nl> wrote:
>On 8/29/2026 12:35 PM, Anton Ertl wrote:
>> marcel hendrix <mhx@iae.nl> writes:
>>> Maybe this: what is the last digit of 3^47 ? ( 7 )
>>
>> That's trivial:
>>
>> : ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7"
>>
>> It's unclear to me what the relevance for the original topic is,
>> however.
Same with me.
>
>I was assuming something like
> 100 set-precision ok
> 3e 47e f** fs.
>
>would work on a suitable Forth.
This is a number theory problem.
3 has order 4 modulo 10 (3**4 = 81, that is 1 modulo 10)
So we can take 47 modulo 4, this is 3.
3**3 = 27 so the answer is 7
To illustrate that inexact numbers ("floating point") are not
helpful here, a problem that is out of reach.
What are the last three digits of
333 ** 1234567890
WANT x^x \ Loading modulo package
( +m -m *m /m %:m **m x^x ) \ AvdH B6mar23
333 1234567890 1000 . x^x
49 OK
(Compare pow() of Python.
>
>-marcel
--
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-08-29 14:45 +0000 |
| Message-ID | <2026Aug29.164549@mips.complang.tuwien.ac.at> |
| In reply to | #135475 |
marcel hendrix <mhx@iae.nl> writes:
>On 8/29/2026 12:35 PM, Anton Ertl wrote:
>> marcel hendrix <mhx@iae.nl> writes:
>>> Maybe this: what is the last digit of 3^47 ? ( 7 )
>>
>> That's trivial:
>>
>> : ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7"
>>
>> It's unclear to me what the relevance for the original topic is,
>> however.
>
>I was assuming something like
> 100 set-precision ok
> 3e 47e f** fs.
>
>would work on a suitable Forth.
3^47 takes 75 mantissa bits. The 128-bit FP option of VFX may be able
to do it.
- 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-29 14:50 -0500 |
| Message-ID | <116vd6n$3gogv$1@dont-email.me> |
| In reply to | #135475 |
On 8/29/26 08:02, marcel hendrix wrote: > On 8/29/2026 12:35 PM, Anton Ertl wrote: >> marcel hendrix <mhx@iae.nl> writes: >>> Maybe this: what is the last digit of 3^47 ? ( 7 ) >> >> That's trivial: >> >> : ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7" >> >> It's unclear to me what the relevance for the original topic is, >> however. > > I was assuming something like > 100 set-precision ok > 3e 47e f** fs. > > would work on a suitable Forth. > > -marcel You can use the FSL module, big.4th, with my extra definitions in big-extras.4th to compute this: From kforth64: include ans-words ok include modules ok include fsl/big BIG V1.2 12 August 2026 LFZ, KM ok include fsl/extras/big-extras ok 3 47 big_s^n big. 26588814358957503287787 ok -- km
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-29 15:01 -0500 |
| Message-ID | <116vdq6$3gogv$2@dont-email.me> |
| In reply to | #135482 |
On 8/29/26 14:50, Krishna Myneni wrote: > On 8/29/26 08:02, marcel hendrix wrote: >> On 8/29/2026 12:35 PM, Anton Ertl wrote: >>> marcel hendrix <mhx@iae.nl> writes: >>>> Maybe this: what is the last digit of 3^47 ? ( 7 ) >>> >>> That's trivial: >>> >>> : ldo3^47 1 47 0 ?do 3 * 10 mod loop ; ldo3^47 . \ prints "7" >>> >>> It's unclear to me what the relevance for the original topic is, >>> however. >> >> I was assuming something like >> 100 set-precision ok >> 3e 47e f** fs. >> >> would work on a suitable Forth. >> >> -marcel > > You can use the FSL module, big.4th, with my extra definitions in big- > extras.4th to compute this: > > From kforth64: > > include ans-words > ok > include modules > ok > include fsl/big > > BIG V1.2 12 August 2026 LFZ, KM ok > include fsl/extras/big-extras > ok > 3 47 big_s^n big. > 26588814358957503287787 ok > You can also do this in kforth64 with the word DS* which produces a triple length result on the data stack. Note that the result fits in a double length integer on 64-bit forth: 1 s>d 3 47 0 do dup >r ds* drop r> loop drop ud. 26588814358957503287787 ok -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-08-29 23:26 +0200 |
| Message-ID | <116viqp$mvdi$1@dont-email.me> |
| In reply to | #135483 |
On 8/29/2026 10:01 PM, Krishna Myneni wrote: > On 8/29/26 14:50, Krishna Myneni wrote: >> On 8/29/26 08:02, marcel hendrix wrote: >>> On 8/29/2026 12:35 PM, Anton Ertl wrote: [..]>>>> It's unclear to me what the relevance for the original topic is, >>>> however. >>> >>> I was assuming something like >>> 100 set-precision ok >>> 3e 47e f** fs. >>> >>> would work on a suitable Forth. >>> [..]>> include fsl/big >> >> BIG V1.2 12 August 2026 LFZ, KM ok >> include fsl/extras/big-extras >> ok >> 3 47 big_s^n big. >> 26588814358957503287787 ok I tried double-double in iForth, but DD+E.R is not good enough: 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! 2.658881435895750328778699999999e+022 ok Maybe I'll check out big_s^n some day. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-08-29 17:16 -0500 |
| Message-ID | <116vloq$3jk7h$1@dont-email.me> |
| In reply to | #135485 |
On 8/29/26 16:26, marcel hendrix wrote: > On 8/29/2026 10:01 PM, Krishna Myneni wrote: >> On 8/29/26 14:50, Krishna Myneni wrote: >>> On 8/29/26 08:02, marcel hendrix wrote: >>>> On 8/29/2026 12:35 PM, Anton Ertl wrote: > [..]>>>> It's unclear to me what the relevance for the original topic is, >>>>> however. >>>> >>>> I was assuming something like >>>> 100 set-precision ok >>>> 3e 47e f** fs. >>>> >>>> would work on a suitable Forth. >>>> > [..]>> include fsl/big >>> >>> BIG V1.2 12 August 2026 LFZ, KM ok >>> include fsl/extras/big-extras >>> ok >>> 3 47 big_s^n big. >>> 26588814358957503287787 ok > > I tried double-double in iForth, but DD+E.R is not good enough: > > 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! > 2.658881435895750328778699999999e+022 ok > > Maybe I'll check out big_s^n some day. > I have DDFS. from JVN's original code, dd_io.4th, and it works under kForth-64. include ans-words include ddarith include dd_io DECIMAL 32 SET-PRECISION 3e 0e ddconstant DD3.0 dd3.0 47 dd^n ddfs. +2.6588814358957503287787000000000 dd 22 ok -- km
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-03 10:56 +1000 |
| Message-ID | <6a98c5d1$1@news.ausics.net> |
| In reply to | #135485 |
On 30/08/2026 7:26 am, marcel hendrix wrote: > On 8/29/2026 10:01 PM, Krishna Myneni wrote: >> On 8/29/26 14:50, Krishna Myneni wrote: >>> On 8/29/26 08:02, marcel hendrix wrote: >>>> On 8/29/2026 12:35 PM, Anton Ertl wrote: > [..]>>>> It's unclear to me what the relevance for the original topic is, >>>>> however. >>>> >>>> I was assuming something like >>>> 100 set-precision ok >>>> 3e 47e f** fs. >>>> >>>> would work on a suitable Forth. >>>> > [..]>> include fsl/big >>> >>> BIG V1.2 12 August 2026 LFZ, KM ok >>> include fsl/extras/big-extras >>> ok >>> 3 47 big_s^n big. >>> 26588814358957503287787 ok > > I tried double-double in iForth, but DD+E.R is not good enough: > > 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! 2.658881435895750328778699999999e+022 ok > ... Trying out Julian Noble's double-double package again brought back issues I originally encountered. 134217729 S>F FCONSTANT split which silently didn't work on my 16-bit forth. More problematic was mantissa digits extraction that could result in junk output: s" 9.9999999999999999999999999999999dd" >dd CR DDFS. +1.0000000000000000000000000000000 dd 1 ok s" 9.999999999999dd" >dd CR DDFS. +0.0000000000007777777777600000000 dd 0 ok It seems this was never corrected.
[toc] | [prev] | [next] | [standalone]
| From | marcel hendrix <mhx@iae.nl> |
|---|---|
| Date | 2026-09-03 11:52 +0200 |
| Message-ID | <117bg19$so8b$1@dont-email.me> |
| In reply to | #135537 |
On 9/3/2026 2:56 AM, dxf wrote: > On 30/08/2026 7:26 am, marcel hendrix wrote: [..] > More problematic was mantissa digits extraction that could result > in junk output: > > s" 9.9999999999999999999999999999999dd" >dd CR DDFS. > +1.0000000000000000000000000000000 dd 1 ok > > s" 9.999999999999dd" >dd CR DDFS. > +0.0000000000007777777777600000000 dd 0 ok > > It seems this was never corrected. ISTR I posted a few corrections, check CLF around that time frame. -marcel
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-03 21:00 +1000 |
| Message-ID | <6a995350$1@news.ausics.net> |
| In reply to | #135538 |
On 3/09/2026 7:52 pm, marcel hendrix wrote: > On 9/3/2026 2:56 AM, dxf wrote: >> On 30/08/2026 7:26 am, marcel hendrix wrote: > [..] >> More problematic was mantissa digits extraction that could result >> in junk output: >> >> s" 9.9999999999999999999999999999999dd" >dd CR DDFS. >> +1.0000000000000000000000000000000 dd 1 ok >> >> s" 9.999999999999dd" >dd CR DDFS. >> +0.0000000000007777777777600000000 dd 0 ok >> >> It seems this was never corrected. > > ISTR I posted a few corrections, check CLF around that time frame. I located a copy of yours at web.archive.org dated 'February 12, 2006'. There are no obvious changes around 'peeldigit' but if the case quoted above works on yours, then I guess you fixed it.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-03 06:49 -0500 |
| Message-ID | <117bmre$3lgr0$1@dont-email.me> |
| In reply to | #135537 |
On 9/2/26 19:56, dxf wrote: > On 30/08/2026 7:26 am, marcel hendrix wrote: >> On 8/29/2026 10:01 PM, Krishna Myneni wrote: >>> On 8/29/26 14:50, Krishna Myneni wrote: >>>> On 8/29/26 08:02, marcel hendrix wrote: >>>>> On 8/29/2026 12:35 PM, Anton Ertl wrote: >> [..]>>>> It's unclear to me what the relevance for the original topic is, >>>>>> however. >>>>> >>>>> I was assuming something like >>>>> 100 set-precision ok >>>>> 3e 47e f** fs. >>>>> >>>>> would work on a suitable Forth. >>>>> >> [..]>> include fsl/big >>>> >>>> BIG V1.2 12 August 2026 LFZ, KM ok >>>> include fsl/extras/big-extras >>>> ok >>>> 3 47 big_s^n big. >>>> 26588814358957503287787 ok >> >> I tried double-double in iForth, but DD+E.R is not good enough: >> >> 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! 2.658881435895750328778699999999e+022 ok >> ... > > Trying out Julian Noble's double-double package again brought back > issues I originally encountered. > > 134217729 S>F FCONSTANT split > > which silently didn't work on my 16-bit forth. > > More problematic was mantissa digits extraction that could result > in junk output: > > s" 9.9999999999999999999999999999999dd" >dd CR DDFS. > +1.0000000000000000000000000000000 dd 1 ok > > s" 9.999999999999dd" >dd CR DDFS. > +0.0000000000007777777777600000000 dd 0 ok > > It seems this was never corrected. > If the fpu is not configured for double precision and round to nearest mode, the double double words will likely fail. They rely on rounding to double-precision. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-09-03 22:56 +1000 |
| Message-ID | <6a996e70$1@news.ausics.net> |
| In reply to | #135540 |
On 3/09/2026 9:49 pm, Krishna Myneni wrote: > On 9/2/26 19:56, dxf wrote: >> On 30/08/2026 7:26 am, marcel hendrix wrote: >>> On 8/29/2026 10:01 PM, Krishna Myneni wrote: >>>> On 8/29/26 14:50, Krishna Myneni wrote: >>>>> On 8/29/26 08:02, marcel hendrix wrote: >>>>>> On 8/29/2026 12:35 PM, Anton Ertl wrote: >>> [..]>>>> It's unclear to me what the relevance for the original topic is, >>>>>>> however. >>>>>> >>>>>> I was assuming something like >>>>>> 100 set-precision ok >>>>>> 3e 47e f** fs. >>>>>> >>>>>> would work on a suitable Forth. >>>>>> >>> [..]>> include fsl/big >>>>> >>>>> BIG V1.2 12 August 2026 LFZ, KM ok >>>>> include fsl/extras/big-extras >>>>> ok >>>>> 3 47 big_s^n big. >>>>> 26588814358957503287787 ok >>> >>> I tried double-double in iForth, but DD+E.R is not good enough: >>> >>> 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! 2.658881435895750328778699999999e+022 ok >>> ... >> >> Trying out Julian Noble's double-double package again brought back >> issues I originally encountered. >> >> 134217729 S>F FCONSTANT split >> >> which silently didn't work on my 16-bit forth. >> >> More problematic was mantissa digits extraction that could result >> in junk output: >> >> s" 9.9999999999999999999999999999999dd" >dd CR DDFS. >> +1.0000000000000000000000000000000 dd 1 ok >> >> s" 9.999999999999dd" >dd CR DDFS. >> +0.0000000000007777777777600000000 dd 0 ok >> >> It seems this was never corrected. >> > > If the fpu is not configured for double precision and round to nearest mode, the double double words will likely fail. They rely on rounding to double-precision. Tested on Win32Forth (8 byte floats) and GForth.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-03 09:02 -0500 |
| Message-ID | <117bulh$3oe72$1@dont-email.me> |
| In reply to | #135541 |
On 9/3/26 07:56, dxf wrote: > On 3/09/2026 9:49 pm, Krishna Myneni wrote: >> On 9/2/26 19:56, dxf wrote: >>> On 30/08/2026 7:26 am, marcel hendrix wrote: >>>> On 8/29/2026 10:01 PM, Krishna Myneni wrote: >>>>> On 8/29/26 14:50, Krishna Myneni wrote: >>>>>> On 8/29/26 08:02, marcel hendrix wrote: >>>>>>> On 8/29/2026 12:35 PM, Anton Ertl wrote: >>>> [..]>>>> It's unclear to me what the relevance for the original topic is, >>>>>>>> however. >>>>>>> >>>>>>> I was assuming something like >>>>>>> 100 set-precision ok >>>>>>> 3e 47e f** fs. >>>>>>> >>>>>>> would work on a suitable Forth. >>>>>>> >>>> [..]>> include fsl/big >>>>>> >>>>>> BIG V1.2 12 August 2026 LFZ, KM ok >>>>>> include fsl/extras/big-extras >>>>>> ok >>>>>> 3 47 big_s^n big. >>>>>> 26588814358957503287787 ok >>>> >>>> I tried double-double in iForth, but DD+E.R is not good enough: >>>> >>>> 53-bits! 3e F>DD 47 DD^n 30 DD+E.R 80-bits! 2.658881435895750328778699999999e+022 ok >>>> ... >>> >>> Trying out Julian Noble's double-double package again brought back >>> issues I originally encountered. >>> >>> 134217729 S>F FCONSTANT split >>> >>> which silently didn't work on my 16-bit forth. >>> >>> More problematic was mantissa digits extraction that could result >>> in junk output: >>> >>> s" 9.9999999999999999999999999999999dd" >dd CR DDFS. >>> +1.0000000000000000000000000000000 dd 1 ok >>> >>> s" 9.999999999999dd" >dd CR DDFS. >>> +0.0000000000007777777777600000000 dd 0 ok >>> >>> It seems this was never corrected. >>> >> >> If the fpu is not configured for double precision and round to nearest mode, the double double words will likely fail. They rely on rounding to double-precision. > > Tested on Win32Forth (8 byte floats) and GForth. > Please try the kForth implementation on any of kForth-32/64/Win-32. -- KM
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web