I have confirmed your results back through 0.7.0-20100915, but at 0.7.0-20100807 it appears to have been worse:
# gforth-fast-0.7.0-20100807.exe Gforth 0.7.0-20100807, Copyright (C) 1995-2009 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit 1 2 3 pi cr .s f.s fsin cr .s f.s <3> 1 2 3 <1> 3.141592653590E0 <3> 1 2 2125807600 <1> 1.2246467991E-16 ok I only have back through 0.7.0-20090215 on this machine. DaR -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcel Hendrix Sent: Monday, February 13, 2012 1:14 PM To: [email protected] Subject: [gforth] Strange behavior of f! etc. - pinpointed Marcel Hendrix <[email protected]> writes Re: Strange behavior of f! etc. X-Online-Scanned: by Cloudmark authority (on smtp09.online.nl) > What has changed? It appears something is wrong with array indexing. > However, the official Gforth files from the FSL > (http://www.taygeta.com/fsl/scilib.html) are used? [..] First, apologies for the 'broad' question and the wrong pointer, I had no idea where the bug was. Actually, there's a problem a) Only on Windows 7 64bit, Intel processor, b) Only with gforth-fast, 32bit binary. Second, I narrowed down the problem -- at least FSIN, FCOS, FTAN, FSINCOS, FSINH, FASIN and FASINH produce undetected stack errors . Test: C:\gforth>gforth-fast Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit 1 2 3 pi cr .s f.s fsin cr .s f.s <3> 1 2 3 <1> 3.141592653590E0 <3> 1 2 2 <1> 1.2246467991E-16 ok The data stack has been corrupted. Fix: : FSIN 0 FSIN DROP ; : fsin 0 fsin drop ; redefined fsin ok 1 2 3 pi cr .s f.s fsin cr .s f.s <3> 1 2 3 <1> 3.141592653590E0 <3> 1 2 3 <1> 1.2246467991E-16 ok I looked at FCOS, FTAN, FSINCOS, FSINH, FASIN and FASINH and they have the same stack problem. However, FSQRT and FTRUNC are OK. David Kuehling <[email protected]> wrote: > BTW gforth comes with its own version of fsl-utilg.fth, try > require fsl-util.4th I used that too, but as I was not sure where that file came from (.4th extension?) I downloaded from Taygeta. Charles G Montgomery <[email protected]> writes: > BTW, the name of the official FSL file is walsh.fth rather than > walsh.fs. I think only the name of the file is different. True, I renamed while downloading. Charles G Montgomery <[email protected]> writes: > Stranger and stranger. When I use gforth-fast on amd64 I do not see > Marcel's problem; it runs correctly with either gforth or gforth-fast. > So I tried it on i386. There I get (apparently) correct results with > gforth. But with gforth-fast I get different results for "32 wtest- > init", The xx{ array starts with 195.09 11.8997 17.849 ... instead of > 195.09 382.683 555.57 ... That is probably an unrelated bug. -marcel
