[9fans] float overflow

[9fans] float overflow

[hugo rivera]

Hello,
float operations are causing me some headaches on plan 9 (9vx).
I have a program that crashes badly when I feed it with near-the-top
doubles ~1.1e308. This causes an overflow in a function that needs to
square this values and acid points the line where the first call to
pow(2) occurs when I debug it. The problem is that this doesn't happen
at all when the program is compiled with gcc (9c) on linux. Obviously
my results aren't useful, but I get '+Inf' on my output and the
program doesn't crash. I thought of using isInf(2) to avoid Infs in my
operations, but this would make the code really ugly and probably
slow.
I've seen that hoc also suffers from this. On 9vx

% echo 1.75e308+1.75e308 | hoc
hoc 851: suicide: sys: trap: 19 (reserved) pc=0x00003a75

but on linux

echo 1.75e308+1.75e308 | hoc
+Inf

is there something I can do to remedy this situation? maybe this
doesn't happen on a native plan 9 installation, but I don't have
access to any.
Saludos,

--
Hugo

Re: [9fans] float overflow

[erik quanstrom]

> % echo 1.75e308+1.75e308 | hoc
> hoc 851: suicide: sys: trap: 19 (reserved) pc=0x00003a75

trap 19 is SIMD floating point error.  (sse or mmx.)
it's no longer reserved.  it's quite curious that x87
floating point would generate such an exception in

plan 9 gives the following error (even with sse enabled)

; echo 1.75e308+1.75e308 | hoc
hoc 17322: suicide: sys: fp: numeric overflow fppc=0x30f4 status=0xb988 pc=0x3b65

i wonder if vx32 translates floating point to sse or mmx?
if so, the trap should be translated back.

>
> but on linux
>
> echo 1.75e308+1.75e308 | hoc
> +Inf

this is caused by different fcr settings: see
getfcr(2).

- erik

Re: [9fans] float overflow

[maht]

On 26/03/2010 11:58, hugo rivera wrote:
> maybe this doesn't happen on a native plan 9 installation
>
>
loop%  echo 1.75e308+1.75e308 | hoc
hoc 6137: suicide: sys: fp: numeric overflow fppc=0x3004 status=0xb988
pc=0x00003a75

Re: [9fans] float overflow

[Federico G. Benavento]

garbage in, garbage out

lotte% echo 1.75e308+1.75e308 | hoc
hoc 730809: suicide: sys: fp: numeric overflow fppc=0x3004
status=0xb988 pc=0x3a75
lotte%

if you want to keep feeding garbage to your program disable the exceptions

see getfcr(2)

or http://plan9.bell-labs.com/magic/man2html/2/getfcr

setfcr(getfcr()&~(FPINVAL));

feel free to turn division by 0 trap too

On Fri, Mar 26, 2010 at 8:58 AM, hugo rivera <uair00@gmail.com> wrote:
> Hello,
> float operations are causing me some headaches on plan 9 (9vx).
> I have a program that crashes badly when I feed it with near-the-top
> doubles ~1.1e308. This causes an overflow in a function that needs to
> square this values and acid points the line where the first call to
> pow(2) occurs when I debug it. The problem is that this doesn't happen
> at all when the program is compiled with gcc (9c) on linux. Obviously
> my results aren't useful, but I get '+Inf' on my output and the
> program doesn't crash. I thought of using isInf(2) to avoid Infs in my
> operations, but this would make the code really ugly and probably
> slow.
> I've seen that hoc also suffers from this. On 9vx
>
> % echo 1.75e308+1.75e308 | hoc
> hoc 851: suicide: sys: trap: 19 (reserved) pc=0x00003a75
>
> but on linux
>
> echo 1.75e308+1.75e308 | hoc
> +Inf
>
> is there something I can do to remedy this situation? maybe this
> doesn't happen on a native plan 9 installation, but I don't have
> access to any.
> Saludos,
>
> --
> Hugo
>
>



--
Federico G. Benavento

Re: [9fans] float overflow

[hugo rivera]

great! now I can throw all the garbage I want to my program :-)
Thanks a lot.

2010/3/26 Federico G. Benavento <benavento@gmail.com>:
> garbage in, garbage out
>
> lotte% echo 1.75e308+1.75e308 | hoc
> hoc 730809: suicide: sys: fp: numeric overflow fppc=0x3004
> status=0xb988 pc=0x3a75
> lotte%
>
> if you want to keep feeding garbage to your program disable the exceptions
>
> see getfcr(2)
>
> or http://plan9.bell-labs.com/magic/man2html/2/getfcr
>
> setfcr(getfcr()&~(FPINVAL));
>
> feel free to turn division by 0 trap too
>


--
Hugo

Re: [9fans] float overflow

[ron minnich]

On Fri, Mar 26, 2010 at 4:58 AM, hugo rivera <uair00@gmail.com> wrote:
> Hello,
> float operations are causing me some headaches on plan 9 (9vx).
> I have a program that crashes badly when I feed it with near-the-top
> doubles ~1.1e308. This causes an overflow in a function that needs to
> square this values and acid points the line where the first call to
> pow(2) occurs when I debug it. The problem is that this doesn't happen
> at all when the program is compiled with gcc (9c) on linux. Obviously
> my results aren't useful,

yes, so I wonder, under what circumstances would you want this
non-useful output? Are you going to do further computation with the
number that you can not represent? I almost prefer the Plan 9 behavior
in this case ...

ron

Re: [9fans] float overflow

[hugo rivera]

2010/3/26 ron minnich <rminnich@gmail.com>:
> yes, so I wonder, under what circumstances would you want this
> non-useful output? Are you going to do further computation with the
> number that you can not represent? I almost prefer the Plan 9 behavior
> in this case ...

Well, I was expecting this question :-)
But I don't actually have a good answer. It just felt wrong to let the
program crash.

--
Hugo

Re: [9fans] float overflow

[erik quanstrom]

> Well, I was expecting this question :-)
> But I don't actually have a good answer. It just felt wrong to let the
> program crash.

use notify(2) to do something with the signal.

- erik

Re: [9fans] float overflow

[ron minnich]

On Fri, Mar 26, 2010 at 9:57 AM, hugo rivera <uair00@gmail.com> wrote:
> 2010/3/26 ron minnich <rminnich@gmail.com>:
>> yes, so I wonder, under what circumstances would you want this
>> non-useful output? Are you going to do further computation with the
>> number that you can not represent? I almost prefer the Plan 9 behavior
>> in this case ...
>
> Well, I was expecting this question :-)
> But I don't actually have a good answer. It just felt wrong to let the
> program crash.

Wrong answer for many cases. This is like saying you're happy with
undetected memory corruption which might change data or break
pointers. Would you accept that too?

You just computed a number than can not be represented -- what do you
intend to do with that? I think Plan 9 is right, and Linux wrong.

ron

Re: [9fans] float overflow

[ron minnich]

http://en.wikipedia.org/wiki/Fail-fast

says it better than I can.

ron

Re: [9fans] float overflow

[hugo rivera]

Uf, I didn't have any idea of the risks implied.
Thanks for correcting me ;-)

2010/3/26 ron minnich <rminnich@gmail.com>:
> http://en.wikipedia.org/wiki/Fail-fast
>
> says it better than I can.
>
> ron
>
>



--
Hugo

Re: [9fans] float overflow

[Tim Newsham]

>> But I don't actually have a good answer. It just felt wrong to let the
>> program crash.
>
> Wrong answer for many cases. This is like saying you're happy with
> undetected memory corruption which might change data or break
> pointers. Would you accept that too?

You're being a little extreme. In this particular case, it keeps
carrying around infinities. It's not silently reducing it modulo
some number or replacing values with other undistinguished values
(that does happen with integer arithmetic, though, *guh*!).
At the end, you know that you got an answer or that you got
an unrepresentable value.

Yah, you could have known that with a lot less computation if you
stopped earlier, but you're not exactly left computing with garbage.

> ron

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] float overflow

[ron minnich]

On Fri, Mar 26, 2010 at 10:46 AM, Tim Newsham <newsham@lava.net> wrote:

> Yah, you could have known that with a lot less computation if you
> stopped earlier, but you're not exactly left computing with garbage.


Good point.

ron