* [9fans] float overflow
@ 2010-03-26 11:58 hugo rivera
2010-03-26 12:43 ` erik quanstrom
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: hugo rivera @ 2010-03-26 11:58 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 11:58 [9fans] float overflow hugo rivera
@ 2010-03-26 12:43 ` erik quanstrom
2010-03-26 12:44 ` maht
` (2 subsequent siblings)
3 siblings, 0 replies; 13+ messages in thread
From: erik quanstrom @ 2010-03-26 12:43 UTC (permalink / raw)
To: 9fans
> % 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 11:58 [9fans] float overflow hugo rivera
2010-03-26 12:43 ` erik quanstrom
@ 2010-03-26 12:44 ` maht
2010-03-26 12:54 ` Federico G. Benavento
2010-03-26 16:44 ` ron minnich
3 siblings, 0 replies; 13+ messages in thread
From: maht @ 2010-03-26 12:44 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 11:58 [9fans] float overflow hugo rivera
2010-03-26 12:43 ` erik quanstrom
2010-03-26 12:44 ` maht
@ 2010-03-26 12:54 ` Federico G. Benavento
2010-03-26 13:37 ` hugo rivera
2010-03-26 16:44 ` ron minnich
3 siblings, 1 reply; 13+ messages in thread
From: Federico G. Benavento @ 2010-03-26 12:54 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 11:58 [9fans] float overflow hugo rivera
` (2 preceding siblings ...)
2010-03-26 12:54 ` Federico G. Benavento
@ 2010-03-26 16:44 ` ron minnich
2010-03-26 16:57 ` hugo rivera
3 siblings, 1 reply; 13+ messages in thread
From: ron minnich @ 2010-03-26 16:44 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 16:44 ` ron minnich
@ 2010-03-26 16:57 ` hugo rivera
2010-03-26 17:01 ` erik quanstrom
2010-03-26 17:05 ` ron minnich
0 siblings, 2 replies; 13+ messages in thread
From: hugo rivera @ 2010-03-26 16:57 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 16:57 ` hugo rivera
@ 2010-03-26 17:01 ` erik quanstrom
2010-03-26 17:05 ` ron minnich
1 sibling, 0 replies; 13+ messages in thread
From: erik quanstrom @ 2010-03-26 17:01 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 16:57 ` hugo rivera
2010-03-26 17:01 ` erik quanstrom
@ 2010-03-26 17:05 ` ron minnich
2010-03-26 17:05 ` ron minnich
2010-03-26 17:46 ` Tim Newsham
1 sibling, 2 replies; 13+ messages in thread
From: ron minnich @ 2010-03-26 17:05 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 17:05 ` ron minnich
@ 2010-03-26 17:05 ` ron minnich
2010-03-26 17:22 ` hugo rivera
2010-03-26 17:46 ` Tim Newsham
1 sibling, 1 reply; 13+ messages in thread
From: ron minnich @ 2010-03-26 17:05 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
http://en.wikipedia.org/wiki/Fail-fast
says it better than I can.
ron
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] float overflow
2010-03-26 17:05 ` ron minnich
2010-03-26 17:05 ` ron minnich
@ 2010-03-26 17:46 ` Tim Newsham
2010-03-26 20:23 ` ron minnich
1 sibling, 1 reply; 13+ messages in thread
From: Tim Newsham @ 2010-03-26 17:46 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-03-26 20:23 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-26 11:58 [9fans] float overflow hugo rivera
2010-03-26 12:43 ` erik quanstrom
2010-03-26 12:44 ` maht
2010-03-26 12:54 ` Federico G. Benavento
2010-03-26 13:37 ` hugo rivera
2010-03-26 16:44 ` ron minnich
2010-03-26 16:57 ` hugo rivera
2010-03-26 17:01 ` erik quanstrom
2010-03-26 17:05 ` ron minnich
2010-03-26 17:05 ` ron minnich
2010-03-26 17:22 ` hugo rivera
2010-03-26 17:46 ` Tim Newsham
2010-03-26 20:23 ` ron minnich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).