1. RE: Math crashes with translated programs (Rob?)
a.tammer at hetnet.nl wrote:
> second case you ask for an impossibilty.
> 0.02 pwr -300 goes below lowest FP-possible
> a@t
>
>
>
That's not the point.
Both the interpreter & the translated programs output 0 in that case,
which is fine by me. However, if you use something like -300.34, then
the translated program gives an overflow, but the interpreter still
outputs 0. An overflow is fine from the interpreter too, as long as I
can predict it and guard against it with a safe_power() function. It is
the inconsistacy that bothers me. But this one isn't so bad because it
can be easily avoided.
The main example I gave, which doesn't overflow (& shouldn't), but
outright crashes for no apparent reason, is the real problem.
2. RE: Math crashes with translated programs (Rob?)
>
> Yes, you've found a Translator bug. Thanks for reporting it.
>
I knew I could find one! Do I get a prize?
> 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
>
Ok, good to know I can get around it for now. But how do I get around
it when the 1000 is an a variable (an atom)?
y = 1000
x = x * y
How about this?
x = x * (y + 0.0)
or
y = y + 0.0, then x = x * y
Is there any easy way to force all atoms to be considered floats?
Is this a problem for any calculation involving two integers (like
addition), or just multiplication?
Can we get a quick patch on this, or will it be a long time?
> > 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 
)
>
I think it fails on both my machines here, but I haven't checked out
that case thoroughly, nor have I tried it on Borland or LCC. I don't
know what version of Watcom I have (sort of) because I got it via
Euman's method of downloading the 11.x patch, and then filling in the
libraries via Hutch's Masm32, so it may just be a little off, or could
be a processor thing...
3. RE: Math crashes with translated programs (Rob?)
> > 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.
>
I was just doing some more tests on this. I have only found errors with
multiplication so far. I guess division isn't possible because in would
have to divide by a decimal number to get bigger. Addition seems ok.
Note that sometimes it doesn't crash, but simply gives a completely
wrong answer, so this could be affecting existing code without anyone
noticing.
This came up in my genetic programming system, which does all manner of
random mathematical calculations, so I have the perfect testbed I guess.
> > 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.
>
Understood. If I could get the test version in the meantime, that's
good enough for me....
Thanks,
Andy Serpa
4. RE: Math crashes with translated programs (Rob?)
Robert Craig wrote:
> 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.
>
Thanks. I took out my "+ 0.0" in my mulipications, and retranslation.
Everything looks good so far.
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...
5. RE: Math crashes with translated programs (Rob?)
rolf.schroeder at desy.de wrote:
> Hi Andy,
>
> 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?
> 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?
>
I frankly wouldn't know to expect. My program generates RANDOM
mathematical expressions. They are all legal syntactically, but it is
up to me to use "safe" functions to keep everything in bounds so it
won't crash. It is just a pain to debug your program using the
interpreter, then translate it and have it crash. I'm not saying it is
Euphoria's fault.
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?
-- Andy
> 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...
>
>
>
6. RE: Math crashes with translated programs (Rob?)
r.schr at t-online.de wrote:
> 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 .
>
That's what mine is -- with the interpreter, huh? Well, I can't think
of an explanation for that. I use the PD interpreter -- is the complete
edition any different in that regard?
> > ...
> > 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:
>
Your function is exactly what I meant by safe_power(), and similar to
one that was posted here just a few days ago.
But the one I was using didn't catch something like (.02, -300.773)
> --------------------------------------------------------
> 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
>
>
>
7. RE: Math crashes with translated programs (Rob?)
>
> --------------------------------------------------------
> 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?
