1. Math crashes with translated programs (Rob?)
Try the following:
atom x
x = 3000000000
? x
x = 1000000 * 3000
? x
x = 1000 * 3000
x = x * 1000
? x
With the interpreter, the output is as expected:
3000000000
3000000000
3000000000
Translated with LCC, it gives an illegal instruction on the third one (I
believe at x = x * 1000) and crashes.
Translated with Borland, it gives the output:
3000000000
3000000000
1
Translated with Watcom, it crashes on the third one again with a "The
instruction at <blank> referenced memory at <blank>. The memory could
not be read.
Now, I never use LCC cause it is too damn slow. Borland always seems to
crash when doing anything with big numbers, and I always figured well,
that's just Borland. This time it didn't crash, but gave an output of
"1", which is really scary.
Watcom has always worked indentically to the interpreter, but this
problem is screwing things up for me. Any explanation?
BTW, here's another one that I came across while trying to make a
safe_power() function of my own: power(.02,-300.24) gives a 0 in the
interpreter and a math overflow error translated with Watcom. The
problem seems to be the decimal as it works ok with just -300. ???
2. Re: Math crashes with translated programs (Rob?)
- Posted by a.tammer at hetnet.nl
Jun 09, 2002
Does it crash also if you change it to x *=3D 1000?
a@t
3. Re: Math crashes with translated programs (Rob?)
- Posted by a.tammer at hetnet.nl
Jun 09, 2002
OOPS
-300.24 has 2 decimals as well, I should have stated so
a@t
4. Re: Math crashes with translated programs (Rob?)
- Posted by a.tammer at hetnet.nl
Jun 09, 2002
second case you ask for an impossibilty.
0.02 pwr -300 goes below lowest FP-possible
a@t
5. Re: Math crashes with translated programs (Rob?)
Andy Serpa writes:
> Try the following:
>
> atom x
>
> x = 3000000000
> ? x
> x = 1000000 * 3000
> ? x
> x = 1000 * 3000
> x = x * 1000
> ? x
>
> With the interpreter, the output is as expected:
>
> 3000000000
> 3000000000
> 3000000000
Yes, you've found a Translator bug. Thanks for reporting it.
The C code generated by the Translator is wrong
in the 3rd case, so it doesn't matter which C compiler
you use, you will get a crash or a failure of some kind.
It seems the Translator let its guard down, and wasn't
expecting that two integer values would result in a number
greater than Euphoria's 31-bit integers at this particular
point in the code. You can work around the bug by adding
".0" to one or more of the numbers involved in the last
calculation, e.g. replace:
x = x * 1000
by
x = x * 1000.0
> BTW, here's another one that I came across while trying to make a
> safe_power() function of my own: power(.02,-300.24) gives a 0 in the
> interpreter and a math overflow error translated with Watcom. The
> problem seems to be the decimal as it works ok with just -300. ???
On my machine, using WATCOM 10.6, I get a math overflow
error with both the interpreter and the Translator with WATCOM,
and it doesn't matter if I use -300.24 or -300. So it's consistent.
I wonder if you are using a different version of WATCOM, and
if you have a different CPU. I have a 350MHz Pentium II. (although
I just got a Pentium 4 yesterday 
)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Math crashes with translated programs (Rob?)
On 8 Jun 2002, at 20:11, Robert Craig wrote:
<snip>
> I have a 350MHz Pentium II. (although
> I just got a Pentium 4 yesterday )
P4 benchmarks 30% slower than a P3, per mhz. Smaller caches and
fewer internal pipes. Maybe you can return it?
Kat
7. Re: Math crashes with translated programs (Rob?)
Andy Serpa writes:
> Is there any easy way to force all atoms to be considered floats?
For the time being, it would be safer to add ".0" to any numbers
used in an expression that is assigned to an atom variable.
When I read through the Translator code some more,
I'll have a better idea of exactly when the bug happens,
and I'll report back.
> Is this a problem for any calculation involving two integers (like
> addition), or just multiplication?
I think it would mainly occur with multiplication, but might happen
with addition and some other operations too. I'll check.
Note that it will only happen when the result of the calculation
exceeds +/- 1.07 billion.
> Can we get a quick patch on this, or will it be a long time?
When I fix it, I'll send you a new ecw.exe to test for me.
This is the first bug reported in the Translator since 2.3
was released. Lots of large programs are running flawlessly.
There's a lot of overhead in doing a proper release,
for example I would have to build and test 8 different versions
of the Translator (4 platforms x (PD + Complete)), plus 14 different
versions of the library (7 different C compilers),
update the Web site, respond to e-mails from all the registered users
who want a free upgrade etc. Then a day later someone would
report another bug. So I'll probably wait at least a couple of
months before doing a full 2.4 release, and include a bunch of
enhancements and bug fixes in one batch.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Math crashes with translated programs (Rob?)
I fixed the Translator bug that Andy Serpa reported
and I sent him a new Complete Edition ecw.exe.
I won't be doing a new release
of the Translator for a couple of months, but if you are a registered
user of the Translator, and you think you've encountered this bug,
I can give you the file I gave to Andy.
The bug occurs when:
- you declare a variable as atom or object
and
- you assign an obvious (at compile-time) integer value to it
and
- within a couple of statements (one basic block)
you re-assign the same variable with the result of a binary
operation (multiply, add, subtract) on two obviously integer values
and
- the binary operation on the integer values
overflows 31 bits (+/- 1.07 billion)
The result could be an incorrect value or a crash.
The fix was easy - just one statement in the Translator was changed.
Several large programs that I re-translated did not have this bug anywhere.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Math crashes with translated programs (Rob?)
Hi Andy,
I didn't get 0 with the interpreter! Correctly it reports:
tst.ex:5
math function overflow error
--> see ex.err
By the way: 0.05^-300.784 = 20^300.784 (~ 10^400) which is clearly not
representable as IEEE 64 fp. So, the overflow is correctly reported. Do
you expect +inf or something similar?
Have a nice day, Rolf
Andy Serpa wrote:
> ...
> BTW, I double-checked on that other anomaly. Using this code:
>
> atom x
>
> x = power(.02,-300.784)
> ? x
>
> I get the result 0 with the interpreter. Tranlated with Watcom, I get
> an overflow. With Borland, I get a msgbox that says overflow, then it
> prints "INF". With LCC, it prints "1.#INF". Same results on two
> different processors -- AMD k6-2 & and a brand new AMD Athlon 1800...
10. Re: Math crashes with translated programs (Rob?)
- Posted by r.schr at t-online.de
Jun 13, 2002
Andy Serpa wrote:
>
> > I didn't get 0 with the interpreter! Correctly it reports:
> >
> > tst.ex:5
> > math function overflow error
> > --> see ex.err
> >
> Really? Maybe it is a processor thing. Do you have an Intel?
No, it's an AMD K6-2 .
> ...
> So I need a COMPLETE safe_power() function, it seems, that will protect
> me from overflows from any possible atoms (integer or floating point,
> positive or negative) used for base and exponent. Anyone?
>
I wouldn't use a "save_power()" function. Instead, I would check the two
arguments before calling power(). May be the following function is
useful for this purpose:
--------------------------------------------------------
constant lim = log(3e+307) -- needed for chk_pow_args()
function chk_pow_args(atom a, atom b)
-- ------------
if a > 0.0 then
if b*log(a) < lim then
return 1
end if
elsif a < 0 and integer(a) then
if b*log(-a) < lim then
return 1
end if
end if
return 0
end function
-- test:
atom a, b
a = 0.0951
b = -300.784
if chk_pow_args(a,b) then
? power( a, b)
else
puts(1,"power() overflow! Abort.\n")
end if
--------------------------------------------------------
Have a nice day, Rolf
11. Re: Math crashes with translated programs (Rob?)
- Posted by tone.skoda at gmx.net
Jun 13, 2002
----- Original Message -----
From: "Andy Serpa" <renegade at earthling.net>
> So I need a COMPLETE safe_power() function, it seems, that will protect
> me from overflows from any possible atoms (integer or floating point,
> positive or negative) used for base and exponent. Anyone?
I translated this C++ function included below before I wrote that other
safe_power (with some help).
Maybe you will find it useful.
You can add some checks inside this functions if current result is bigger
than HIGHEST_ATOM (1e300).
If you find some better safe_power send it to me. I am doing something
similar like you: program which finds math formula from example arguments
and their example results.
--/*
-- safe_power_2 [Created on 2. June 2002, 11:10]
-- The 'safe_power_2' function is translation of C++ function.
-- It does exacly same thing as builting Euphoria power()
-- only slower and safer.
-- Advantage over builting power(): Program doesn't crash with message:
-- "math function overflow error"
-- if you do something like this: power (24, 576) but
-- this function returns infinity.
--
-- PARAMETERS
-- 'x'
-- Same as in built in 'power()'.
-- 'y'
-- Same as in built in 'power()'.
--
-- RETURN VALUES
-- power() or error if >= HIGHEST_ATOM or <= LOWEST_ATOM.
--
-- EXAMPLE USE
-- if safe_power_2 (10, 100000) > HIGHEST_ATOM then
-- puts (1, "overflow")
-- end if
--*/
global function safe_power_2 (atom x, atom y)
atom n, z
if (y >= 0) then
n = y
else
n = -y
end if
z = 1
while 1 do
if (and_bits (n, 1) != 0) then
z *= x
end if
n = shift_right (n, 1)
if n = 0 then
if y < 0 then
return 1 / z
else
return z
end if
end if
x *= x
end while
end function
global function shift_right (atom x, integer count)
return floor (x / power (2, count))
end function
12. Re: Math crashes with translated programs (Rob?)
- Posted by r.schr at t-online.de
Jun 13, 2002
Andy Serpa wrote:
>
>
> >
> > --------------------------------------------------------
> > constant lim = log(3e+307) -- needed for chk_pow_args()
> >
> > function chk_pow_args(atom a, atom b)
> > -- ------------
> > if a > 0.0 then
> > if b*log(a) < lim then
> > return 1
> > end if
> > elsif a < 0 and integer(a) then
> > if b*log(-a) < lim then
> > return 1
> > end if
> > end if
> > return 0
> > end function
> >
>
> Am I correct in thinking that should be integer(b) instead of integer(a)
> to guard against using a non-integer exponent when the base is negative?
You are right!
Have a nice day, Rolf
