1. Euphoria bug found
The following bug was found when using 'get()' to read
a previously hand typed text into a text file, in the form
of a (greater than 13 digits) floating point number.
Apparently, when 14 digits are hand typed into a Euphoria source
file and compared to the same 14 digits hand typed into the text
file and read with get(), the first atom doesnt equal the
second atom.
Example:
create the file "test.txt" and type this exact line:
{1.2345678912341}
then save the file.
Now create a second file "get.exw" and copy and paste this code:
sequence filenameout
sequence s,t
atom a,b,fn
filenameout="test.txt"
s={1.2345678912341}
fn=open(current_dir()&"\\"&filenameout,"r")
t=get(fn)
close(fn)
b=t[2][1]
a=s[1]
printf(1,"%3.13f\n",t[2][1]) --prints "1.2345678912341" (ok)
?a=b --fails, prints "0"
?1.2345678912341=a --passes, prints "1"
?1.2345678912341=b --fails, prints "0"
ink=wait_key()
save and run the program, and note that the tests that fail
all include tests on the number read with 'get()'.
Now modify all numbers "1.2345678912341" in both program
and test.txt to "1.234567891234" (by deleting the last "1").
Save the modified files and run the program again, and
all the tests pass.
Maybe this should be fixed in the next update?
Shouldnt be hard to do, the source file has no
trouble doing it.
Of course the intent is to write and read 16 digits of precision
within the app.
--Al
2. Re: Euphoria bug found
------=_NextPart_000_01C0B629.36053840
Dear Al:
For me my mainframe-386/387
both on DOS32 and WIN32
prints
1.2345678912341
1
1
1
Test files attached
Regards,
Igor Kachan
kinz at peterlink.ru
------=_NextPart_000_01C0B629.36053840
Content-Description: Test.txt (Òåêñòîâûé äîêóìåíò)
3. Re: Euphoria bug found
Irv Mullins writes:
> Unfortunately, on 2.2 for Linux, it returns:
>
> 1.2345678912341
> 0
> 1
> 0
You shouldn't expect get() to always give you
*precisely* the same floating-point value
as you get from a literal constant. get()
performs a lot of f.p. operations to arrive at its
result. The interpreter might perform a slightly
different series of calculations on the literal constant.
In general, never expect floating-point numbers,
or calculations on them, to be mathematically perfect.
Any time you test two floating-point numbers
for exact equality (or inequality) an alarm should
go off in your head.
The fact that there's a slight difference here
between Linux and DOS/Windows, probably
reflects the different C libraries, or different
optimizations used in the C compilers.
If you are getting answers that are imperfect,
but correct to many significant digits, be happy. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
