Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135346 > unrolled thread
| Started by | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| First post | 2026-08-15 07:32 -0500 |
| Last post | 2026-09-12 10:33 -0500 |
| Articles | 7 on this page of 27 — 4 participants |
Back to article view | Back to comp.lang.forth
Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-15 07:32 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-15 07:48 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-20 22:01 -0500
Re: Range Reduction Using Big Number Arithmetic albert@spenarnc.xs4all.nl - 2026-08-22 19:31 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-31 08:49 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 10:39 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-08-28 10:42 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-03 18:03 -0500
Re: Range Reduction Using Big Number Arithmetic marcel hendrix <mhx@iae.nl> - 2026-09-04 07:29 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-04 07:45 -0500
Re: Range Reduction Using Big Number Arithmetic marcel hendrix <mhx@iae.nl> - 2026-09-04 15:29 +0200
Re: Range Reduction Using Big Number Arithmetic albert@spenarnc.xs4all.nl - 2026-09-05 12:27 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-05 08:39 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-09 07:37 -0500
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-09 18:49 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-09 15:06 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-10 19:03 -0500
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-11 14:56 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-11 09:17 -0500
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-11 17:04 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-11 10:46 -0500
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-11 13:24 -0500
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-11 23:21 +0200
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-12 00:42 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-11 18:33 -0500
Re: Range Reduction Using Big Number Arithmetic peter <peter.noreply@tin.it> - 2026-09-12 11:04 +0200
Re: Range Reduction Using Big Number Arithmetic Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-09-12 10:33 -0500
Page 2 of 2 — ← Prev page 1 [2]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-11 10:46 -0500 |
| Message-ID | <11817pa$310c4$1@dont-email.me> |
| In reply to | #135663 |
On 9/11/26 10:04, peter wrote: > On Fri, 11 Sep 2026 09:17:37 -0500 > Krishna Myneni <krishna.myneni@ccreweb.org> wrote: ... >> I successfully ran ulptest.4th under kForth-64 by adding definitions of >> ON and OFF. The output is shown below, but I don't know how to interpret >> the different columns: >> >> === begin === >> $ kforth64-0.8.0 >> kForth-64 v 0.8.0 (Build: 2026-05-03) >> Copyright (c) 1998--2026 Krishna Myneni >> Contributions by: dpw gd mu bk abs tn cmb bg dnw imss al >> Provided under the GNU Affero General Public License, v3.0 or later >> >> >> Ready! >> include ulptest >> >> /home/krishna/kforth/ans-words.4th >> >> Defined : on true swap ! ; >> Defined : off false swap ! ; >> Defined : h. base @ >r hex . r> base ! ; >> Defined : fcbrt 1e 3e f/ f** ; >> Defined : fcube 3e f** ; >> Defined : f10** falog ; >> Defined : f2** 2e fswap f** ; >> Defined : f1/10** fnegate f10** ; >> Defined : frsqrt -0.5e f** ; >> Defined : frsqr fdup f* 1e fswap f/ ; >> Defined : flg2 flog 2e flog f/ ; >> >> ulps error >> Function Total 0 1 2 3 4 5 6-10 >> >10 sign >> facosh 1877 963 911 3 0 0 0 0 >> 0 0 >> facos 1569 1115 454 0 0 0 0 0 >> 0 0 >> fasinh 2262 1129 1133 0 0 0 0 0 >> 0 0 >> fsinh 1655 802 853 0 0 0 0 0 >> 0 0 >> fatanh 1552 758 794 0 0 0 0 0 >> 0 0 >> fatan 1735 963 772 0 0 0 0 0 >> 0 0 >> fcbrt 138 60 78 0 0 0 0 0 >> 0 0 >> fcosh 2026 1081 945 0 0 0 0 0 >> 0 0 >> fcos 1576 884 692 0 0 0 0 0 >> 0 0 >> fcube 150 79 71 0 0 0 0 0 >> 0 0 >> f1/10** 538 269 269 0 0 0 0 0 >> 0 0 >> f10** 1668 829 828 11 0 0 0 0 >> 0 0 >> fexpm1 7578 4220 3358 0 0 0 0 0 >> 0 0 >> f2** 1145 560 585 0 0 0 0 0 >> 0 0 >> fexp 2268 1142 1126 0 0 0 0 0 >> 0 0 >> flog 1883 991 891 1 0 0 0 0 >> 0 0 >> flnp1 7550 3912 3638 0 0 0 0 0 >> 0 0 >> flg2 929 432 479 18 0 0 0 0 >> 0 0 >> fln 2813 2035 778 0 0 0 0 0 >> 0 0 >> fsinh 2215 1087 1125 3 0 0 0 0 >> 0 0 >> fsin 1611 857 754 0 0 0 0 0 >> 0 0 >> ftan 1706 919 787 0 0 0 0 0 >> 0 0 >> ftanh 1852 929 913 10 0 0 0 0 >> 0 0 >> frsqr 2202 1959 243 0 0 0 0 0 >> 0 0 >> frsqrt 2360 2323 37 0 0 0 0 0 >> 0 0 >> Total 52858 30298 22514 46 0 0 0 0 >> 0 0 >> ok >> === end === >> >> Btw, I had to convert file formats to unix before anything will load -- >> this is a deficiency in my Forth system. I would like it to be >> insensitive to text file format. >> >> -- >> Krishna >> > > If you look at the total, 52858 30298 22514 46 > > you ran 52858 tests > 30298 was correct > 22514 had an error in the last bit, 1 ulp error > 46 had 2 ulps error. > This is a good result and I could guess that you link to libm in glibc > ulps is calculated as abs(correct-calculated) doing the calculation > on the 64 bit integer representation of the double float. > I basically do fsin tmp df! tmp @ correct - > > If you run the other file ulptest2.4 you will have more trig functions > tested. There are 2 files as they come from different sources > ... Ah, thank you. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-11 13:24 -0500 |
| Message-ID | <1181h08$34q9g$1@dont-email.me> |
| In reply to | #135660 |
On 9/11/26 7:56 AM, peter wrote:
> On Thu, 10 Sep 2026 19:03:00 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>
>> On 9/9/26 11:49, peter wrote:
>>> On Wed, 9 Sep 2026 07:37:55 -0500
>> ...
>>>
>>> An alternative is to use the files from the Core-Math project
>>>
>>> https://gitlab.inria.fr/core-math/core-math
>>>
>>> They are claimed to be correctly rounded, my tests also show this.
>>> They are bloated and will compile to a large object file.
>>> I have seen that also glibc has started to use selected files from them.
>>> ...
>>
>> The latest kForth-Win32 (v2.6.9) implements the glibc sin(x) and cos(x)
>> functions. The words FSIN and FCOS call these functions which provide
>> high accuracy results even at large double-precision angles. This makes
>> consistent the accuracy of FSIN and FCOS across all kForth variants
>> -32/64/Win32.
>>
>> I have made a reference table of inputs and outputs for FCOS and FSIN
>> over a range of angles. These may be useful for others who implement the
>> same algorithm for FSIN and FCOS, for double precision floating point.
>> The reference table may be found at
>>
>> https://ccreweb.org/software/glibc/sincos/kForth-Win32_sincos_ref.txt
>>
>> I would be interested to know if the core-math sin(x) and cos(x)
>> functions give the same results for double precision.
>
> I have collected close to 100000 tests for different functions.
> They come from 2 sources
>
> - the crmlib project (correctly rounded libm). This looks now to be dead.
>
> - This site https://www.vinc17.net/research/testlibm/ I have taken the
> worst cases file and transferred to Forth
>
> I have put them on dropbox at this link
> https://www.dropbox.com/scl/fo/6j3md5qhll7sn4rtaf6mj/AFx3v5tB2Nwui9mb7Thw6oA?rlkey=savdo7h9gawbrhz3ctn9j63h5&st=59deulw0&dl=0
>
> (I hope this long url works now when i copied it)
>
> In the zip file there are 3 forth files ulptest.4 ulptest2.4 ulptest2h.4
> The first one has the worst cases. The other 2 use the .dat files
> and just show them in different way. These are based on crlibm data
> All rounding should be set to nearest. They will work also on x87 80 bit
> functions but you should set the fpu to operate at 53 bits. Expect most
> trig functions to fail under x87 as they test large arguments.
> All arguments and results are stored as 64 bit hex values. This avoids all
> conversion errors but make it difficult to see what you actually test!
>
> Here is the output from my system using core-math
>
> include ulptest.4
> Defined : f1/10** fnegate f10** ;
> ulps error
> Function Total 0 1 2 3 4 5 6-10 >10 sign
> facosh 1´877 1´877 0 0 0 0 0 0 0 0
> facos 1´569 1´569 0 0 0 0 0 0 0 0
> fasinh 2´262 2´262 0 0 0 0 0 0 0 0
> fsinh 1´655 1´655 0 0 0 0 0 0 0 0
> fatanh 1´552 1´552 0 0 0 0 0 0 0 0
> fatan 1´735 1´735 0 0 0 0 0 0 0 0
> fcbrt 138 138 0 0 0 0 0 0 0 0
> fcosh 2´026 2´026 0 0 0 0 0 0 0 0
> fcos 1´576 1´576 0 0 0 0 0 0 0 0
> fcube 150 150 0 0 0 0 0 0 0 0
> f1/10** 538 538 0 0 0 0 0 0 0 0
> f10** 1´668 1´668 0 0 0 0 0 0 0 0
> fexpm1 7´578 7´578 0 0 0 0 0 0 0 0
> f2** 1´145 1´145 0 0 0 0 0 0 0 0
> fexp 2´268 2´268 0 0 0 0 0 0 0 0
> flog 1´883 1´883 0 0 0 0 0 0 0 0
> flnp1 7´550 7´550 0 0 0 0 0 0 0 0
> flg2 929 929 0 0 0 0 0 0 0 0
> fln 2´813 2´813 0 0 0 0 0 0 0 0
> fsinh 2´215 2´215 0 0 0 0 0 0 0 0
> fsin 1´611 1´611 0 0 0 0 0 0 0 0
> ftan 1´706 1´706 0 0 0 0 0 0 0 0
> ftanh 1´852 1´852 0 0 0 0 0 0 0 0
> frsqr 2´202 2´202 0 0 0 0 0 0 0 0
> frsqrt 2´360 2´360 0 0 0 0 0 0 0 0
> Total 52´858 52´858 0 0 0 0 0 0 0 0
> ok
>
> include ulptest2.4
>
> ulps error
> Function Total 0 1 2 3 4 5 6-10 >10 sign
> sin 10´613 10´613 0 0 0 0 0 0 0 0
> cos 10´790 10´790 0 0 0 0 0 0 0 0
> tan 5´715 5´715 0 0 0 0 0 0 0 0
> asin 726 726 0 0 0 0 0 0 0 0
> acos 110 110 0 0 0 0 0 0 0 0
> atan 5´618 5´618 0 0 0 0 0 0 0 0
> sinh 416 416 0 0 0 0 0 0 0 0
> cosh 549 549 0 0 0 0 0 0 0 0
> pow 10´000 10´000 0 0 0 0 0 0 0 0
> exp 4´282 4´282 0 0 0 0 0 0 0 0
> expm1 238 238 0 0 0 0 0 0 0 0
> ln 1´127 1´127 0 0 0 0 0 0 0 0
> log10 52 52 0 0 0 0 0 0 0 0
> logp1 227 227 0 0 0 0 0 0 0 0
> To see records with a specific ulp difference run :
> n ulpshow ulpxxx.dat
> where n is the difference xxx the function sin asin etc
> ok
>
> If I switch fdlibm instead about 50% of the test show 1 ulp error.
> glibc libm is a bit better then that.
>
In ulptest.4th:
The 32-bit T2 test does not work the same way as the 64-bit T2 test.
Specifically, the 64-bit T2 test checks for same sign or nans while the
32-bit T2 tests only checks for same sign.
I think there is also somewhere in the 32-bit section where the order of
the bits is not correct, because I'm getting a lot of >10 ulp errors.
When I turn verbose on, I see that for some tests the byte order of the
32 msbits and the 32 lsbits of the result are reversed. It does not
occur for every test index number.
Example:
\ Single line is broken into multiple lines for readability
52245 tanh $3F062B4331584D27. T1 ftanh $3F062B43311F8E20. T2
\ 0x1.62b4331584d27p-15 0x1.62b43311f8e2p-15
\ Got $311F8E203F062B43
Under kForth-32 for Linux, I obtain the following:
=== begin output ===
$ kforth32-2.8.0
kForth-32 v 2.8.0 (Build: 2026-05-02)
Copyright (c) 1998--2026 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU Affero General Public License, v3.0 or later
Ready!
include ulptest
/home/krishna/kforth/ans-words.4th
Defined : on true swap ! ;
Defined : off false swap ! ;
Defined : h. base @ >r hex . r> base ! ;
Defined : fcbrt 1e 3e f/ f** ;
Defined : fcube 3e f** ;
Defined : f10** falog ;
Defined : f2** 2e fswap f** ;
Defined : f1/10** fnegate f10** ;
Defined : frsqrt -0.5e f** ;
Defined : frsqr fdup f* 1e fswap f/ ;
Defined : flg2 flog 2e flog f/ ;
ulps error
Function Total 0 1 2 3 4 5 6-10 >10
sign
facosh 1877 947 0 0 0 0 0 0 930
0
facos 1569 784 0 0 0 0 0 0 785
0
fasinh 2262 1130 0 0 0 0 0 0 132
0
fsinh 1655 832 0 0 0 0 0 0 82 0
fatanh 1552 748 0 0 0 0 0 0 803
1
fatan 1735 869 0 0 0 0 0 0 865
1
fcbrt 138 58 0 0 0 0 0 0 80
0
fcosh 2026 947 0 0 0 0 0 0 079
0
fcos 1576 889 0 0 0 0 0 0 687
0
fcube 150 73 0 0 0 0 0 0 77
0
f1/10** 538 86 0 0 0 0 0 0 452
0
f10** 1668 600 0 0 0 0 0 0 068
0
fexpm1 7578 3770 0 0 0 0 0 0 807
1
f2** 1145 776 0 0 0 0 0 0 369
0
fexp 2268 716 0 0 0 0 0 0 552
0
flog 1883 1014 0 0 0 0 0 0 869
0
flnp1 7550 3612 0 0 0 0 0 0 936
2
flg2 929 461 0 0 0 0 0 0 468
0
fln 2813 1598 0 0 0 0 0 0 215
0
fsinh 2215 840 0 0 0 0 0 0 375
0
fsin 1611 859 0 0 0 0 0 0 752
0
ftan 1706 893 0 0 0 0 0 0 813
0
ftanh 1852 901 0 0 0 0 0 0 951
0
frsqr 2202 1959 0 0 0 0 0 0 243
0
frsqrt 2360 2262 0 0 0 0 0 0 98
0
Total 52858 27624 0 0 0 0 0 0 5229
5
ok
=== end output ===
--
KM
[toc] | [prev] | [next] | [standalone]
| From | peter <peter.noreply@tin.it> |
|---|---|
| Date | 2026-09-11 23:21 +0200 |
| Message-ID | <20260911232156.00004f2b@tin.it> |
| In reply to | #135671 |
On Fri, 11 Sep 2026 13:24:06 -0500 Krishna Myneni <krishna.myneni@ccreweb.org> wrote: > On 9/11/26 7:56 AM, peter wrote: > > On Thu, 10 Sep 2026 19:03:00 -0500 > > Krishna Myneni <krishna.myneni@ccreweb.org> wrote: > > > >> On 9/9/26 11:49, peter wrote: > >>> On Wed, 9 Sep 2026 07:37:55 -0500 > >> ... > >>> > >>> An alternative is to use the files from the Core-Math project > >>> > >>> https://gitlab.inria.fr/core-math/core-math > >>> > >>> They are claimed to be correctly rounded, my tests also show this. > >>> They are bloated and will compile to a large object file. > >>> I have seen that also glibc has started to use selected files from them. > >>> ... > >> > >> The latest kForth-Win32 (v2.6.9) implements the glibc sin(x) and cos(x) > >> functions. The words FSIN and FCOS call these functions which provide > >> high accuracy results even at large double-precision angles. This makes > >> consistent the accuracy of FSIN and FCOS across all kForth variants > >> -32/64/Win32. > >> > >> I have made a reference table of inputs and outputs for FCOS and FSIN > >> over a range of angles. These may be useful for others who implement the > >> same algorithm for FSIN and FCOS, for double precision floating point. > >> The reference table may be found at > >> > >> https://ccreweb.org/software/glibc/sincos/kForth-Win32_sincos_ref.txt > >> > >> I would be interested to know if the core-math sin(x) and cos(x) > >> functions give the same results for double precision. > > > > I have collected close to 100000 tests for different functions. > > They come from 2 sources > > > > - the crmlib project (correctly rounded libm). This looks now to be dead. > > > > - This site https://www.vinc17.net/research/testlibm/ I have taken the > > worst cases file and transferred to Forth > > > > I have put them on dropbox at this link > > https://www.dropbox.com/scl/fo/6j3md5qhll7sn4rtaf6mj/AFx3v5tB2Nwui9mb7Thw6oA?rlkey=savdo7h9gawbrhz3ctn9j63h5&st=59deulw0&dl=0 > > > > (I hope this long url works now when i copied it) > > > > In the zip file there are 3 forth files ulptest.4 ulptest2.4 ulptest2h.4 > > The first one has the worst cases. The other 2 use the .dat files > > and just show them in different way. These are based on crlibm data > > All rounding should be set to nearest. They will work also on x87 80 bit > > functions but you should set the fpu to operate at 53 bits. Expect most > > trig functions to fail under x87 as they test large arguments. > > All arguments and results are stored as 64 bit hex values. This avoids all > > conversion errors but make it difficult to see what you actually test! > > > > Here is the output from my system using core-math > > > > include ulptest.4 > > Defined : f1/10** fnegate f10** ; > > ulps error > > Function Total 0 1 2 3 4 5 6-10 >10 sign > > facosh 1´877 1´877 0 0 0 0 0 0 0 0 > > facos 1´569 1´569 0 0 0 0 0 0 0 0 > > fasinh 2´262 2´262 0 0 0 0 0 0 0 0 > > fsinh 1´655 1´655 0 0 0 0 0 0 0 0 > > fatanh 1´552 1´552 0 0 0 0 0 0 0 0 > > fatan 1´735 1´735 0 0 0 0 0 0 0 0 > > fcbrt 138 138 0 0 0 0 0 0 0 0 > > fcosh 2´026 2´026 0 0 0 0 0 0 0 0 > > fcos 1´576 1´576 0 0 0 0 0 0 0 0 > > fcube 150 150 0 0 0 0 0 0 0 0 > > f1/10** 538 538 0 0 0 0 0 0 0 0 > > f10** 1´668 1´668 0 0 0 0 0 0 0 0 > > fexpm1 7´578 7´578 0 0 0 0 0 0 0 0 > > f2** 1´145 1´145 0 0 0 0 0 0 0 0 > > fexp 2´268 2´268 0 0 0 0 0 0 0 0 > > flog 1´883 1´883 0 0 0 0 0 0 0 0 > > flnp1 7´550 7´550 0 0 0 0 0 0 0 0 > > flg2 929 929 0 0 0 0 0 0 0 0 > > fln 2´813 2´813 0 0 0 0 0 0 0 0 > > fsinh 2´215 2´215 0 0 0 0 0 0 0 0 > > fsin 1´611 1´611 0 0 0 0 0 0 0 0 > > ftan 1´706 1´706 0 0 0 0 0 0 0 0 > > ftanh 1´852 1´852 0 0 0 0 0 0 0 0 > > frsqr 2´202 2´202 0 0 0 0 0 0 0 0 > > frsqrt 2´360 2´360 0 0 0 0 0 0 0 0 > > Total 52´858 52´858 0 0 0 0 0 0 0 0 > > ok > > > > include ulptest2.4 > > > > ulps error > > Function Total 0 1 2 3 4 5 6-10 >10 sign > > sin 10´613 10´613 0 0 0 0 0 0 0 0 > > cos 10´790 10´790 0 0 0 0 0 0 0 0 > > tan 5´715 5´715 0 0 0 0 0 0 0 0 > > asin 726 726 0 0 0 0 0 0 0 0 > > acos 110 110 0 0 0 0 0 0 0 0 > > atan 5´618 5´618 0 0 0 0 0 0 0 0 > > sinh 416 416 0 0 0 0 0 0 0 0 > > cosh 549 549 0 0 0 0 0 0 0 0 > > pow 10´000 10´000 0 0 0 0 0 0 0 0 > > exp 4´282 4´282 0 0 0 0 0 0 0 0 > > expm1 238 238 0 0 0 0 0 0 0 0 > > ln 1´127 1´127 0 0 0 0 0 0 0 0 > > log10 52 52 0 0 0 0 0 0 0 0 > > logp1 227 227 0 0 0 0 0 0 0 0 > > To see records with a specific ulp difference run : > > n ulpshow ulpxxx.dat > > where n is the difference xxx the function sin asin etc > > ok > > > > If I switch fdlibm instead about 50% of the test show 1 ulp error. > > glibc libm is a bit better then that. > > > > In ulptest.4th: > > The 32-bit T2 test does not work the same way as the 64-bit T2 test. > Specifically, the 64-bit T2 test checks for same sign or nans while the > 32-bit T2 tests only checks for same sign. > > I think there is also somewhere in the 32-bit section where the order of > the bits is not correct, because I'm getting a lot of >10 ulp errors. > When I turn verbose on, I see that for some tests the byte order of the > 32 msbits and the 32 lsbits of the result are reversed. It does not > occur for every test index number. I will have to look into this. I have not used the 32 bit version much the last 10 years! so probably I have forgotten to keep 64 and 32 bit aligned in implementation. my 32 bit lxf/ntf uses the 80 bits float. They will have a larger number of problems and I have not notised Peter > > Example: > \ Single line is broken into multiple lines for readability > 52245 tanh $3F062B4331584D27. T1 ftanh $3F062B43311F8E20. T2 > \ 0x1.62b4331584d27p-15 0x1.62b43311f8e2p-15 > \ Got $311F8E203F062B43 > > > > Under kForth-32 for Linux, I obtain the following: > > === begin output === > $ kforth32-2.8.0 > kForth-32 v 2.8.0 (Build: 2026-05-02) > Copyright (c) 1998--2026 Krishna Myneni > Contributions by: dpw gd mu bk abs tn cmb bg dnw > Provided under the GNU Affero General Public License, v3.0 or later > > > Ready! > include ulptest > > /home/krishna/kforth/ans-words.4th > > Defined : on true swap ! ; > Defined : off false swap ! ; > Defined : h. base @ >r hex . r> base ! ; > Defined : fcbrt 1e 3e f/ f** ; > Defined : fcube 3e f** ; > Defined : f10** falog ; > Defined : f2** 2e fswap f** ; > Defined : f1/10** fnegate f10** ; > Defined : frsqrt -0.5e f** ; > Defined : frsqr fdup f* 1e fswap f/ ; > Defined : flg2 flog 2e flog f/ ; > > ulps error > Function Total 0 1 2 3 4 5 6-10 >10 > sign > facosh 1877 947 0 0 0 0 0 0 930 > 0 > facos 1569 784 0 0 0 0 0 0 785 > 0 > fasinh 2262 1130 0 0 0 0 0 0 132 > 0 > fsinh 1655 832 0 0 0 0 0 0 82 0 > fatanh 1552 748 0 0 0 0 0 0 803 > 1 > fatan 1735 869 0 0 0 0 0 0 865 > 1 > fcbrt 138 58 0 0 0 0 0 0 80 > 0 > fcosh 2026 947 0 0 0 0 0 0 079 > 0 > fcos 1576 889 0 0 0 0 0 0 687 > 0 > fcube 150 73 0 0 0 0 0 0 77 > 0 > f1/10** 538 86 0 0 0 0 0 0 452 > 0 > f10** 1668 600 0 0 0 0 0 0 068 > 0 > fexpm1 7578 3770 0 0 0 0 0 0 807 > 1 > f2** 1145 776 0 0 0 0 0 0 369 > 0 > fexp 2268 716 0 0 0 0 0 0 552 > 0 > flog 1883 1014 0 0 0 0 0 0 869 > 0 > flnp1 7550 3612 0 0 0 0 0 0 936 > 2 > flg2 929 461 0 0 0 0 0 0 468 > 0 > fln 2813 1598 0 0 0 0 0 0 215 > 0 > fsinh 2215 840 0 0 0 0 0 0 375 > 0 > fsin 1611 859 0 0 0 0 0 0 752 > 0 > ftan 1706 893 0 0 0 0 0 0 813 > 0 > ftanh 1852 901 0 0 0 0 0 0 951 > 0 > frsqr 2202 1959 0 0 0 0 0 0 243 > 0 > frsqrt 2360 2262 0 0 0 0 0 0 98 > 0 > Total 52858 27624 0 0 0 0 0 0 5229 > 5 > ok > === end output === > > -- > KM > > > >
[toc] | [prev] | [next] | [standalone]
| From | peter <peter.noreply@tin.it> |
|---|---|
| Date | 2026-09-12 00:42 +0200 |
| Message-ID | <20260912004252.00007f04@tin.it> |
| In reply to | #135673 |
On Fri, 11 Sep 2026 23:21:56 +0200
peter <peter.noreply@tin.it> wrote:
> On Fri, 11 Sep 2026 13:24:06 -0500
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>
> > On 9/11/26 7:56 AM, peter wrote:
> > > On Thu, 10 Sep 2026 19:03:00 -0500
> > > Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> > >
> > >> On 9/9/26 11:49, peter wrote:
> > >>> On Wed, 9 Sep 2026 07:37:55 -0500
> > >> ...
> > >>>
> > >>> An alternative is to use the files from the Core-Math project
> > >>>
> > >>> https://gitlab.inria.fr/core-math/core-math
> > >>>
> > >>> They are claimed to be correctly rounded, my tests also show this.
> > >>> They are bloated and will compile to a large object file.
> > >>> I have seen that also glibc has started to use selected files from them.
> > >>> ...
> > >>
> > >> The latest kForth-Win32 (v2.6.9) implements the glibc sin(x) and cos(x)
> > >> functions. The words FSIN and FCOS call these functions which provide
> > >> high accuracy results even at large double-precision angles. This makes
> > >> consistent the accuracy of FSIN and FCOS across all kForth variants
> > >> -32/64/Win32.
> > >>
> > >> I have made a reference table of inputs and outputs for FCOS and FSIN
> > >> over a range of angles. These may be useful for others who implement the
> > >> same algorithm for FSIN and FCOS, for double precision floating point.
> > >> The reference table may be found at
> > >>
> > >> https://ccreweb.org/software/glibc/sincos/kForth-Win32_sincos_ref.txt
> > >>
> > >> I would be interested to know if the core-math sin(x) and cos(x)
> > >> functions give the same results for double precision.
> > >
> > > I have collected close to 100000 tests for different functions.
> > > They come from 2 sources
> > >
> > > - the crmlib project (correctly rounded libm). This looks now to be dead.
> > >
> > > - This site https://www.vinc17.net/research/testlibm/ I have taken the
> > > worst cases file and transferred to Forth
> > >
> > > I have put them on dropbox at this link
> > > https://www.dropbox.com/scl/fo/6j3md5qhll7sn4rtaf6mj/AFx3v5tB2Nwui9mb7Thw6oA?rlkey=savdo7h9gawbrhz3ctn9j63h5&st=59deulw0&dl=0
> > >
> > > (I hope this long url works now when i copied it)
> > >
> > > In the zip file there are 3 forth files ulptest.4 ulptest2.4 ulptest2h.4
> > > The first one has the worst cases. The other 2 use the .dat files
> > > and just show them in different way. These are based on crlibm data
> > > All rounding should be set to nearest. They will work also on x87 80 bit
> > > functions but you should set the fpu to operate at 53 bits. Expect most
> > > trig functions to fail under x87 as they test large arguments.
> > > All arguments and results are stored as 64 bit hex values. This avoids all
> > > conversion errors but make it difficult to see what you actually test!
> > >
> > > Here is the output from my system using core-math
> > >
> > > include ulptest.4
> > > Defined : f1/10** fnegate f10** ;
> > > ulps error
> > > Function Total 0 1 2 3 4 5 6-10 >10 sign
> > > facosh 1´877 1´877 0 0 0 0 0 0 0 0
> > > facos 1´569 1´569 0 0 0 0 0 0 0 0
> > > fasinh 2´262 2´262 0 0 0 0 0 0 0 0
> > > fsinh 1´655 1´655 0 0 0 0 0 0 0 0
> > > fatanh 1´552 1´552 0 0 0 0 0 0 0 0
> > > fatan 1´735 1´735 0 0 0 0 0 0 0 0
> > > fcbrt 138 138 0 0 0 0 0 0 0 0
> > > fcosh 2´026 2´026 0 0 0 0 0 0 0 0
> > > fcos 1´576 1´576 0 0 0 0 0 0 0 0
> > > fcube 150 150 0 0 0 0 0 0 0 0
> > > f1/10** 538 538 0 0 0 0 0 0 0 0
> > > f10** 1´668 1´668 0 0 0 0 0 0 0 0
> > > fexpm1 7´578 7´578 0 0 0 0 0 0 0 0
> > > f2** 1´145 1´145 0 0 0 0 0 0 0 0
> > > fexp 2´268 2´268 0 0 0 0 0 0 0 0
> > > flog 1´883 1´883 0 0 0 0 0 0 0 0
> > > flnp1 7´550 7´550 0 0 0 0 0 0 0 0
> > > flg2 929 929 0 0 0 0 0 0 0 0
> > > fln 2´813 2´813 0 0 0 0 0 0 0 0
> > > fsinh 2´215 2´215 0 0 0 0 0 0 0 0
> > > fsin 1´611 1´611 0 0 0 0 0 0 0 0
> > > ftan 1´706 1´706 0 0 0 0 0 0 0 0
> > > ftanh 1´852 1´852 0 0 0 0 0 0 0 0
> > > frsqr 2´202 2´202 0 0 0 0 0 0 0 0
> > > frsqrt 2´360 2´360 0 0 0 0 0 0 0 0
> > > Total 52´858 52´858 0 0 0 0 0 0 0 0
> > > ok
> > >
> > > include ulptest2.4
> > >
> > > ulps error
> > > Function Total 0 1 2 3 4 5 6-10 >10 sign
> > > sin 10´613 10´613 0 0 0 0 0 0 0 0
> > > cos 10´790 10´790 0 0 0 0 0 0 0 0
> > > tan 5´715 5´715 0 0 0 0 0 0 0 0
> > > asin 726 726 0 0 0 0 0 0 0 0
> > > acos 110 110 0 0 0 0 0 0 0 0
> > > atan 5´618 5´618 0 0 0 0 0 0 0 0
> > > sinh 416 416 0 0 0 0 0 0 0 0
> > > cosh 549 549 0 0 0 0 0 0 0 0
> > > pow 10´000 10´000 0 0 0 0 0 0 0 0
> > > exp 4´282 4´282 0 0 0 0 0 0 0 0
> > > expm1 238 238 0 0 0 0 0 0 0 0
> > > ln 1´127 1´127 0 0 0 0 0 0 0 0
> > > log10 52 52 0 0 0 0 0 0 0 0
> > > logp1 227 227 0 0 0 0 0 0 0 0
> > > To see records with a specific ulp difference run :
> > > n ulpshow ulpxxx.dat
> > > where n is the difference xxx the function sin asin etc
> > > ok
> > >
> > > If I switch fdlibm instead about 50% of the test show 1 ulp error.
> > > glibc libm is a bit better then that.
> > >
> >
> > In ulptest.4th:
> >
> > The 32-bit T2 test does not work the same way as the 64-bit T2 test.
> > Specifically, the 64-bit T2 test checks for same sign or nans while the
> > 32-bit T2 tests only checks for same sign.
> >
> > I think there is also somewhere in the 32-bit section where the order of
> > the bits is not correct, because I'm getting a lot of >10 ulp errors.
> > When I turn verbose on, I see that for some tests the byte order of the
> > 32 msbits and the 32 lsbits of the result are reversed. It does not
> > occur for every test index number.
>
> I will have to look into this. I have not used the 32 bit version much
> the last 10 years! so probably I have forgotten to keep 64 and 32 bit
> aligned in implementation. my 32 bit lxf/ntf uses the 80 bits float.
> They will have a larger number of problems and I have not notised
>
> Peter
>
> >
> > Example:
> > \ Single line is broken into multiple lines for readability
> > 52245 tanh $3F062B4331584D27. T1 ftanh $3F062B43311F8E20. T2
> > \ 0x1.62b4331584d27p-15 0x1.62b43311f8e2p-15
> > \ Got $311F8E203F062B43
> >
> >
> >
> > Under kForth-32 for Linux, I obtain the following:
> >
> > === begin output ===
> > $ kforth32-2.8.0
> > kForth-32 v 2.8.0 (Build: 2026-05-02)
> > Copyright (c) 1998--2026 Krishna Myneni
> > Contributions by: dpw gd mu bk abs tn cmb bg dnw
> > Provided under the GNU Affero General Public License, v3.0 or later
> >
> >
> > Ready!
> > include ulptest
> >
> > /home/krishna/kforth/ans-words.4th
> >
> > Defined : on true swap ! ;
> > Defined : off false swap ! ;
> > Defined : h. base @ >r hex . r> base ! ;
> > Defined : fcbrt 1e 3e f/ f** ;
> > Defined : fcube 3e f** ;
> > Defined : f10** falog ;
> > Defined : f2** 2e fswap f** ;
> > Defined : f1/10** fnegate f10** ;
> > Defined : frsqrt -0.5e f** ;
> > Defined : frsqr fdup f* 1e fswap f/ ;
> > Defined : flg2 flog 2e flog f/ ;
> >
> > ulps error
> > Function Total 0 1 2 3 4 5 6-10 >10
> > sign
> > facosh 1877 947 0 0 0 0 0 0 930
> > 0
> > facos 1569 784 0 0 0 0 0 0 785
> > 0
> > fasinh 2262 1130 0 0 0 0 0 0 132
> > 0
> > fsinh 1655 832 0 0 0 0 0 0 82 0
> > fatanh 1552 748 0 0 0 0 0 0 803
> > 1
> > fatan 1735 869 0 0 0 0 0 0 865
> > 1
> > fcbrt 138 58 0 0 0 0 0 0 80
> > 0
> > fcosh 2026 947 0 0 0 0 0 0 079
> > 0
> > fcos 1576 889 0 0 0 0 0 0 687
> > 0
> > fcube 150 73 0 0 0 0 0 0 77
> > 0
> > f1/10** 538 86 0 0 0 0 0 0 452
> > 0
> > f10** 1668 600 0 0 0 0 0 0 068
> > 0
> > fexpm1 7578 3770 0 0 0 0 0 0 807
> > 1
> > f2** 1145 776 0 0 0 0 0 0 369
> > 0
> > fexp 2268 716 0 0 0 0 0 0 552
> > 0
> > flog 1883 1014 0 0 0 0 0 0 869
> > 0
> > flnp1 7550 3612 0 0 0 0 0 0 936
> > 2
> > flg2 929 461 0 0 0 0 0 0 468
> > 0
> > fln 2813 1598 0 0 0 0 0 0 215
> > 0
> > fsinh 2215 840 0 0 0 0 0 0 375
> > 0
> > fsin 1611 859 0 0 0 0 0 0 752
> > 0
> > ftan 1706 893 0 0 0 0 0 0 813
> > 0
> > ftanh 1852 901 0 0 0 0 0 0 951
> > 0
> > frsqr 2202 1959 0 0 0 0 0 0 243
> > 0
> > frsqrt 2360 2262 0 0 0 0 0 0 98
> > 0
> > Total 52858 27624 0 0 0 0 0 0 5229
> > 5
> > ok
> > === end output ===
> >
> > --
> > KM
I have looked at the file and can not find an obvious error in swaping
high and low parts. But I can see also in your example that they are swaped
when printed in the .error function.
I also tried it on the 32 bit ntf and get
ulps error
Function Total 0 1 2 3 4 5 6-10 >10 sign
facosh 1877 401 431 23 19 15 8 28 952 0
facos 1569 255 313 34 14 6 7 25 915 0
fasinh 2262 725 766 65 36 27 17 57 569 0
fsinh 1655 848 807 0 0 0 0 0 0 0
fatanh 1552 778 774 0 0 0 0 0 0 0
fatan 1735 869 866 0 0 0 0 0 0 0
fcbrt 138 70 68 0 0 0 0 0 0 0
fcosh 2026 1018 1008 0 0 0 0 0 0 0
fcos 1576 806 770 0 0 0 0 0 0 0
fcube 150 76 74 0 0 0 0 0 0 0
f1/10** 538 266 272 0 0 0 0 0 0 0
f10** 1668 811 857 0 0 0 0 0 0 0
fexpm1 7578 3779 3799 0 0 0 0 0 0 0
f2** 1145 592 553 0 0 0 0 0 0 0
fexp 2268 1150 1118 0 0 0 0 0 0 0
flog 1883 997 886 0 0 0 0 0 0 0
flnp1 7550 3623 3927 0 0 0 0 0 0 0
flg2 929 526 403 0 0 0 0 0 0 0
fln 2813 1598 1215 0 0 0 0 0 0 0
fsinh 2215 1120 1095 0 0 0 0 0 0 0
fsin 1611 790 821 0 0 0 0 0 0 0
ftan 1706 816 890 0 0 0 0 0 0 0
ftanh 1852 916 936 0 0 0 0 0 0 0
frsqr 2202 2169 33 0 0 0 0 0 0 0
frsqrt 2360 2318 42 0 0 0 0 0 0 0
Total 52858 27317 22724 122 69 48 32 110 2436 0
ok
I had to redefine f2** and flg2 that are present in ntf but with completly
different meaning. the large number of problems in facosh, facos and fasinh
are not unexpected. They have very simplistic implementations.
Are you using glibc also on the 32 bit Kforth. Is it using the FPU or
other algorithms?
I got this for the same line
52545 tanh $3F28EE5F1F66AC0A. T1
ftanh $3F28EE5F1A5B5193. T2 \ 0x1.8ee5f1f66ac0ap-13
0x1.8ee5f1a5b5193p-13 Got $3F28EE5F1A5B5193
Wich is strange as they look identical and should not have been signaled
I see now that .error tests the ulp variable but it is never set anywhere
I will have to fix that
BR
Peter
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-11 18:33 -0500 |
| Message-ID | <1182350$3ak8r$1@dont-email.me> |
| In reply to | #135675 |
On 9/11/26 5:42 PM, peter wrote: > On Fri, 11 Sep 2026 23:21:56 +0200 > peter <peter.noreply@tin.it> wrote: > ... > > I have looked at the file and can not find an obvious error in swaping > high and low parts. But I can see also in your example that they are swaped > when printed in the .error function. > I also tried it on the 32 bit ntf and get > ulps error > Function Total 0 1 2 3 4 5 6-10 >10 sign > facosh 1877 401 431 23 19 15 8 28 952 0 > facos 1569 255 313 34 14 6 7 25 915 0 > fasinh 2262 725 766 65 36 27 17 57 569 0 > fsinh 1655 848 807 0 0 0 0 0 0 0 > fatanh 1552 778 774 0 0 0 0 0 0 0 > fatan 1735 869 866 0 0 0 0 0 0 0 > fcbrt 138 70 68 0 0 0 0 0 0 0 > fcosh 2026 1018 1008 0 0 0 0 0 0 0 > fcos 1576 806 770 0 0 0 0 0 0 0 > fcube 150 76 74 0 0 0 0 0 0 0 > f1/10** 538 266 272 0 0 0 0 0 0 0 > f10** 1668 811 857 0 0 0 0 0 0 0 > fexpm1 7578 3779 3799 0 0 0 0 0 0 0 > f2** 1145 592 553 0 0 0 0 0 0 0 > fexp 2268 1150 1118 0 0 0 0 0 0 0 > flog 1883 997 886 0 0 0 0 0 0 0 > flnp1 7550 3623 3927 0 0 0 0 0 0 0 > flg2 929 526 403 0 0 0 0 0 0 0 > fln 2813 1598 1215 0 0 0 0 0 0 0 > fsinh 2215 1120 1095 0 0 0 0 0 0 0 > fsin 1611 790 821 0 0 0 0 0 0 0 > ftan 1706 816 890 0 0 0 0 0 0 0 > ftanh 1852 916 936 0 0 0 0 0 0 0 > frsqr 2202 2169 33 0 0 0 0 0 0 0 > frsqrt 2360 2318 42 0 0 0 0 0 0 0 > Total 52858 27317 22724 122 69 48 32 110 2436 0 > ok > > I had to redefine f2** and flg2 that are present in ntf but with completly > different meaning. the large number of problems in facosh, facos and fasinh > are not unexpected. They have very simplistic implementations. > Are you using glibc also on the 32 bit Kforth. Is it using the FPU or > other algorithms? > > I got this for the same line > 52545 tanh $3F28EE5F1F66AC0A. T1 > ftanh $3F28EE5F1A5B5193. T2 \ 0x1.8ee5f1f66ac0ap-13 > 0x1.8ee5f1a5b5193p-13 Got $3F28EE5F1A5B5193 > > Wich is strange as they look identical and should not have been signaled > I see now that .error tests the ulp variable but it is never set anywhere > I will have to fix that > Thanks. Yes, kForth-32 uses glibc functions. kForth-Win32 uses the Digital Mars C/C++ math library, except for the sin and cos functions which have been ported from glibc (because the native library functions simply execute the fpu FSIN and FCOS instructions with the argument to the corresponding Forth words). The only way the glibc sin and cos functions use the fpu is for standard floating point arithmetic in the specified precision and rounding modes, i.e. they do not execute the fpu FSIN and FCOS instructions. I think this is true for the tan function as well, but I don't know about others. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | peter <peter.noreply@tin.it> |
|---|---|
| Date | 2026-09-12 11:04 +0200 |
| Message-ID | <20260912110431.000025b3@tin.it> |
| In reply to | #135676 |
On Fri, 11 Sep 2026 18:33:52 -0500 Krishna Myneni <krishna.myneni@ccreweb.org> wrote: > On 9/11/26 5:42 PM, peter wrote: > > On Fri, 11 Sep 2026 23:21:56 +0200 > > peter <peter.noreply@tin.it> wrote: > > > ... > > > > I have looked at the file and can not find an obvious error in swaping > > high and low parts. But I can see also in your example that they are swaped > > when printed in the .error function. > > I also tried it on the 32 bit ntf and get > > ulps error > > Function Total 0 1 2 3 4 5 6-10 >10 sign > > facosh 1877 401 431 23 19 15 8 28 952 0 > > facos 1569 255 313 34 14 6 7 25 915 0 > > fasinh 2262 725 766 65 36 27 17 57 569 0 > > fsinh 1655 848 807 0 0 0 0 0 0 0 > > fatanh 1552 778 774 0 0 0 0 0 0 0 > > fatan 1735 869 866 0 0 0 0 0 0 0 > > fcbrt 138 70 68 0 0 0 0 0 0 0 > > fcosh 2026 1018 1008 0 0 0 0 0 0 0 > > fcos 1576 806 770 0 0 0 0 0 0 0 > > fcube 150 76 74 0 0 0 0 0 0 0 > > f1/10** 538 266 272 0 0 0 0 0 0 0 > > f10** 1668 811 857 0 0 0 0 0 0 0 > > fexpm1 7578 3779 3799 0 0 0 0 0 0 0 > > f2** 1145 592 553 0 0 0 0 0 0 0 > > fexp 2268 1150 1118 0 0 0 0 0 0 0 > > flog 1883 997 886 0 0 0 0 0 0 0 > > flnp1 7550 3623 3927 0 0 0 0 0 0 0 > > flg2 929 526 403 0 0 0 0 0 0 0 > > fln 2813 1598 1215 0 0 0 0 0 0 0 > > fsinh 2215 1120 1095 0 0 0 0 0 0 0 > > fsin 1611 790 821 0 0 0 0 0 0 0 > > ftan 1706 816 890 0 0 0 0 0 0 0 > > ftanh 1852 916 936 0 0 0 0 0 0 0 > > frsqr 2202 2169 33 0 0 0 0 0 0 0 > > frsqrt 2360 2318 42 0 0 0 0 0 0 0 > > Total 52858 27317 22724 122 69 48 32 110 2436 0 > > ok > > > > I had to redefine f2** and flg2 that are present in ntf but with completly > > different meaning. the large number of problems in facosh, facos and fasinh > > are not unexpected. They have very simplistic implementations. > > Are you using glibc also on the 32 bit Kforth. Is it using the FPU or > > other algorithms? > > > > I got this for the same line > > 52545 tanh $3F28EE5F1F66AC0A. T1 > > ftanh $3F28EE5F1A5B5193. T2 \ 0x1.8ee5f1f66ac0ap-13 > > 0x1.8ee5f1a5b5193p-13 Got $3F28EE5F1A5B5193 > > > > Wich is strange as they look identical and should not have been signaled > > I see now that .error tests the ulp variable but it is never set anywhere > > I will have to fix that > > > > Thanks. Yes, kForth-32 uses glibc functions. kForth-Win32 uses the > Digital Mars C/C++ math library, except for the sin and cos functions > which have been ported from glibc (because the native library functions > simply execute the fpu FSIN and FCOS instructions with the argument to > the corresponding Forth words). > > The only way the glibc sin and cos functions use the fpu is for standard > floating point arithmetic in the specified precision and rounding modes, > i.e. they do not execute the fpu FSIN and FCOS instructions. I think > this is true for the tan function as well, but I don't know about others. > > -- > Krishna > I installed the latest snapshot of kforth 32bit for windows. I can not get it to understand double number input. I read in the manual that you do not support it. How were you able to work around this? Peter
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-09-12 10:33 -0500 |
| Message-ID | <1183rce$3s5pj$2@dont-email.me> |
| In reply to | #135681 |
On 9/12/26 4:04 AM, peter wrote: > On Fri, 11 Sep 2026 18:33:52 -0500 > Krishna Myneni <krishna.myneni@ccreweb.org> wrote: > >> On 9/11/26 5:42 PM, peter wrote: >>> On Fri, 11 Sep 2026 23:21:56 +0200 >>> peter <peter.noreply@tin.it> wrote: >>> >> ... >>> >>> I have looked at the file and can not find an obvious error in swaping >>> high and low parts. But I can see also in your example that they are swaped >>> when printed in the .error function. >>> I also tried it on the 32 bit ntf and get >>> ulps error >>> Function Total 0 1 2 3 4 5 6-10 >10 sign >>> facosh 1877 401 431 23 19 15 8 28 952 0 >>> facos 1569 255 313 34 14 6 7 25 915 0 >>> fasinh 2262 725 766 65 36 27 17 57 569 0 >>> fsinh 1655 848 807 0 0 0 0 0 0 0 >>> fatanh 1552 778 774 0 0 0 0 0 0 0 >>> fatan 1735 869 866 0 0 0 0 0 0 0 >>> fcbrt 138 70 68 0 0 0 0 0 0 0 >>> fcosh 2026 1018 1008 0 0 0 0 0 0 0 >>> fcos 1576 806 770 0 0 0 0 0 0 0 >>> fcube 150 76 74 0 0 0 0 0 0 0 >>> f1/10** 538 266 272 0 0 0 0 0 0 0 >>> f10** 1668 811 857 0 0 0 0 0 0 0 >>> fexpm1 7578 3779 3799 0 0 0 0 0 0 0 >>> f2** 1145 592 553 0 0 0 0 0 0 0 >>> fexp 2268 1150 1118 0 0 0 0 0 0 0 >>> flog 1883 997 886 0 0 0 0 0 0 0 >>> flnp1 7550 3623 3927 0 0 0 0 0 0 0 >>> flg2 929 526 403 0 0 0 0 0 0 0 >>> fln 2813 1598 1215 0 0 0 0 0 0 0 >>> fsinh 2215 1120 1095 0 0 0 0 0 0 0 >>> fsin 1611 790 821 0 0 0 0 0 0 0 >>> ftan 1706 816 890 0 0 0 0 0 0 0 >>> ftanh 1852 916 936 0 0 0 0 0 0 0 >>> frsqr 2202 2169 33 0 0 0 0 0 0 0 >>> frsqrt 2360 2318 42 0 0 0 0 0 0 0 >>> Total 52858 27317 22724 122 69 48 32 110 2436 0 >>> ok >>> >>> I had to redefine f2** and flg2 that are present in ntf but with completly >>> different meaning. the large number of problems in facosh, facos and fasinh >>> are not unexpected. They have very simplistic implementations. >>> Are you using glibc also on the 32 bit Kforth. Is it using the FPU or >>> other algorithms? >>> >>> I got this for the same line >>> 52545 tanh $3F28EE5F1F66AC0A. T1 >>> ftanh $3F28EE5F1A5B5193. T2 \ 0x1.8ee5f1f66ac0ap-13 >>> 0x1.8ee5f1a5b5193p-13 Got $3F28EE5F1A5B5193 >>> >>> Wich is strange as they look identical and should not have been signaled >>> I see now that .error tests the ulp variable but it is never set anywhere >>> I will have to fix that >>> >> >> Thanks. Yes, kForth-32 uses glibc functions. kForth-Win32 uses the >> Digital Mars C/C++ math library, except for the sin and cos functions >> which have been ported from glibc (because the native library functions >> simply execute the fpu FSIN and FCOS instructions with the argument to >> the corresponding Forth words). >> >> The only way the glibc sin and cos functions use the fpu is for standard >> floating point arithmetic in the specified precision and rounding modes, >> i.e. they do not execute the fpu FSIN and FCOS instructions. I think >> this is true for the tan function as well, but I don't know about others. >> >> -- >> Krishna >> > > I installed the latest snapshot of kforth 32bit for windows. I can not > get it to understand double number input. I read in the manual that you > do not support it. How were you able to work around this? > > Peter > Hi Peter, The recent versions of kForth-32/64 for Linux do support double number input using the base prefix and a trailing decimal point, in the same manner you use to within your code. This feature was added with the recognizers and is only documented within the commits -- I have yet to update the documentation. kForth-Win32 has not yet gotten the recognizers update, so it is missing this feature. Therefore, I am not presently using the ulptest code on kForth-Win32. The upgrade to the recognizer-based interpreter is major surgery on the code, so it's taking a bit longer. At present, if you can run kForth-32 on linux, that will give you another 32-bit Forth platform on which to run the ulptest code. Regards, Krishna
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.forth
csiph-web