On Fri, Mar 26, 2010 at 10:46 AM, Tim Newsham 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
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 par
Uf, I didn't have any idea of the risks implied.
Thanks for correcting me ;-)
2010/3/26 ron minnich :
> http://en.wikipedia.org/wiki/Fail-fast
>
> says it better than I can.
>
> ron
>
>
--
Hugo
http://en.wikipedia.org/wiki/Fail-fast
says it better than I can.
ron
On Fri, Mar 26, 2010 at 9:57 AM, hugo rivera wrote:
> 2010/3/26 ron minnich :
>> 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 thi
> 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
2010/3/26 ron minnich :
> 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 d
On Fri, Mar 26, 2010 at 4:58 AM, hugo rivera 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 aci
great! now I can throw all the garbage I want to my program :-)
Thanks a lot.
2010/3/26 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
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
s
> % echo 1.75e308+1.75e308 | hoc
> hoc 851: suicide: sys: trap: 19 (reserved) pc=0x3a75
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
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=0x3a75
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
13 matches
Mail list logo
