Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > error handling

Reply
Thread Tools

error handling

 
 
Phidippus
Guest
Posts: n/a
 
      04-01-2004
I'm evaluating a function at various values in a for loop. The
function works most of the times (99% of parameter range I am
investigating), but at some values, it gives error like below and
crushes. I guess something wrong with sqrt function. I'm not going to
attempt to show the function here because it is 1.5Mb. If I evaluate
the exact same function in Maple at the value it crushed in Ruby, it
behaves fine.

Is there any way that when the (sqrt) function crushes, it gives some
sort of error value and go on to evaluating at the next value without
crushing the program? I don't want to manually restart the program at
the next value each time the program crushes. In R, there is "try"
function that can used for this kind of situation.

Thank you.

#####
/usr/lib/ruby/1.6/complex.rb:82:in `initialize': stack level too deep
(SystemStackError)
from /usr/lib/ruby/1.6/complex.rb:63:in `new'
from /usr/lib/ruby/1.6/complex.rb:63:in `Complex'
from /usr/lib/ruby/1.6/complex.rb:130:in `/'
from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
... 1461 levels...
from rubyHopf0.rb:17:in `each'
from rubyHopf0.rb:17
from rubyHopf0.rb:16:in `each'
from rubyHopf0.rb:16
 
Reply With Quote
 
 
 
 
Mark Hubbart
Guest
Posts: n/a
 
      04-01-2004

On Apr 1, 2004, at 8:29 AM, Phidippus wrote:

> I'm evaluating a function at various values in a for loop. The
> function works most of the times (99% of parameter range I am
> investigating), but at some values, it gives error like below and
> crushes. I guess something wrong with sqrt function. I'm not going to
> attempt to show the function here because it is 1.5Mb. If I evaluate
> the exact same function in Maple at the value it crushed in Ruby, it
> behaves fine.
>
> Is there any way that when the (sqrt) function crushes, it gives some
> sort of error value and go on to evaluating at the next value without
> crushing the program? I don't want to manually restart the program at
> the next value each time the program crushes. In R, there is "try"
> function that can used for this kind of situation.
>
> Thank you.
>
> #####
> /usr/lib/ruby/1.6/complex.rb:82:in `initialize': stack level too deep
> (SystemStackError)
> from /usr/lib/ruby/1.6/complex.rb:63:in `new'
> from /usr/lib/ruby/1.6/complex.rb:63:in `Complex'
> from /usr/lib/ruby/1.6/complex.rb:130:in `/'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> ... 1461 levels...
> from rubyHopf0.rb:17:in `each'
> from rubyHopf0.rb:17
> from rubyHopf0.rb:16:in `each'
> from rubyHopf0.rb:16


This looks like a bug... sqrt() is recursing too deeply here, 1461
levels seems a bit excessive. What values are causing it to dump like
that? Could you give a specific example?

Normally, you could catch an error like this:

begin
0 / 0
rescue
puts "no dividing by zero in integer division!"
end

... but that doesn't work for me with a SystemStackError. I guess those
are always fatal errors.

--Mark



 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      04-01-2004

"Mark Hubbart" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
>
> On Apr 1, 2004, at 8:29 AM, Phidippus wrote:
>
> > I'm evaluating a function at various values in a for loop. The
> > function works most of the times (99% of parameter range I am
> > investigating), but at some values, it gives error like below and
> > crushes. I guess something wrong with sqrt function. I'm not going to
> > attempt to show the function here because it is 1.5Mb.


Are you serious? A single function with 1.5MB source code?

> If I evaluate
> > the exact same function in Maple at the value it crushed in Ruby, it
> > behaves fine.


Well, you can't compare Ruby with Maple on this: Maple is a math system
built to efficiency solve mathematical problems. Ruby is more of a general
purpose language and especially not very good at recursion. The stack
nesting problem surfaces every now and then.

AFAIK there is a compiler switch that you can employ during building of Ruby
that will increase the stack size. Alternatively you can implement sqrt as
iterative function yourself.

> > Is there any way that when the (sqrt) function crushes, it gives some
> > sort of error value and go on to evaluating at the next value without
> > crushing the program? I don't want to manually restart the program at
> > the next value each time the program crushes. In R, there is "try"
> > function that can used for this kind of situation.


See below.

> > Thank you.
> >
> > #####
> > /usr/lib/ruby/1.6/complex.rb:82:in `initialize': stack level too deep
> > (SystemStackError)
> > from /usr/lib/ruby/1.6/complex.rb:63:in `new'
> > from /usr/lib/ruby/1.6/complex.rb:63:in `Complex'
> > from /usr/lib/ruby/1.6/complex.rb:130:in `/'
> > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > ... 1461 levels...
> > from rubyHopf0.rb:17:in `each'
> > from rubyHopf0.rb:17
> > from rubyHopf0.rb:16:in `each'
> > from rubyHopf0.rb:16

>
> This looks like a bug... sqrt() is recursing too deeply here, 1461
> levels seems a bit excessive. What values are causing it to dump like
> that? Could you give a specific example?


I guess they are quite big so sqrt needs to many steps to identify the
square root.

> Normally, you could catch an error like this:
>
> begin
> 0 / 0
> rescue
> puts "no dividing by zero in integer division!"
> end
>
> .. but that doesn't work for me with a SystemStackError. I guess those
> are always fatal errors.


Works perfectly for me:

irb(main):036:0> def rec; rec; end
=> nil
irb(main):037:0> begin
irb(main):038:1* rec
irb(main):039:1> rescue SystemStackError => e
irb(main):040:1> puts "Caught it: #{e.inspect}"
irb(main):041:1> end
Caught it: #<SystemStackError: stack level too deep>
=> nil

Regards

robert

 
Reply With Quote
 
Mark Hubbart
Guest
Posts: n/a
 
      04-02-2004

On Apr 1, 2004, at 11:44 AM, Robert Klemme wrote:

>
> "Mark Hubbart" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
>
> [...]
>
>> This looks like a bug... sqrt() is recursing too deeply here, 1461
>> levels seems a bit excessive. What values are causing it to dump like
>> that? Could you give a specific example?

>
> I guess they are quite big so sqrt needs to many steps to identify the
> square root.


Oh. I hadn't realized that sqrt was supposed to recurse that much at
all... even using two 60 digit numbers to create a Complex number to
take the square root of, I couldn't get sqrt to cause me any problems,
using 1.6.8...

>
>> Normally, you could catch an error like this:
>>
>> begin
>> 0 / 0
>> rescue
>> puts "no dividing by zero in integer division!"
>> end
>>
>> .. but that doesn't work for me with a SystemStackError. I guess those
>> are always fatal errors.

>
> Works perfectly for me:
>
> irb(main):036:0> def rec; rec; end
> => nil
> irb(main):037:0> begin
> irb(main):038:1* rec
> irb(main):039:1> rescue SystemStackError => e
> irb(main):040:1> puts "Caught it: #{e.inspect}"
> irb(main):041:1> end
> Caught it: #<SystemStackError: stack level too deep>
> => nil


Okay, that's kind of surprising. It works for me too, but only if I
specify the error type like in your code... I tried it the other time
in the same way as my example code above, and it failed. I thought that
if you didn't specify the error type, it would catch anything;
apparently that's not the case.

--Mark



 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      04-02-2004

"Mark Hubbart" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
>
> On Apr 1, 2004, at 11:44 AM, Robert Klemme wrote:
>
> >
> > "Mark Hubbart" <(E-Mail Removed)> schrieb im Newsbeitrag
> > news:(E-Mail Removed)...
> >
> > [...]
> >
> >> This looks like a bug... sqrt() is recursing too deeply here, 1461
> >> levels seems a bit excessive. What values are causing it to dump like
> >> that? Could you give a specific example?

> >
> > I guess they are quite big so sqrt needs to many steps to identify the
> > square root.

>
> Oh. I hadn't realized that sqrt was supposed to recurse that much at
> all... even using two 60 digit numbers to create a Complex number to
> take the square root of, I couldn't get sqrt to cause me any problems,
> using 1.6.8...


That was just a wild guess. I'd normally not expect sqrt to be written as
recursive function at all. But the stacktrace seemed to indicate that.

> >> Normally, you could catch an error like this:
> >>
> >> begin
> >> 0 / 0
> >> rescue
> >> puts "no dividing by zero in integer division!"
> >> end
> >>
> >> .. but that doesn't work for me with a SystemStackError. I guess

those
> >> are always fatal errors.

> >
> > Works perfectly for me:
> >
> > irb(main):036:0> def rec; rec; end
> > => nil
> > irb(main):037:0> begin
> > irb(main):038:1* rec
> > irb(main):039:1> rescue SystemStackError => e
> > irb(main):040:1> puts "Caught it: #{e.inspect}"
> > irb(main):041:1> end
> > Caught it: #<SystemStackError: stack level too deep>
> > => nil

>
> Okay, that's kind of surprising. It works for me too, but only if I
> specify the error type like in your code... I tried it the other time
> in the same way as my example code above, and it failed. I thought that
> if you didn't specify the error type, it would catch anything;


I thought that once, too. But I got wiser in the meantime.

> apparently that's not the case.


"If you write a rescue clause with no parameter list, the parameter
defaults to StandardError."
http://www.rubycentral.com/book/tut_exceptions.html

Regards

robert

 
Reply With Quote
 
Phidippus
Guest
Posts: n/a
 
      04-03-2004
I'm having hard time pinpointing where the error is generated since
there are so many places sqrt are used...

http://www.velocityreviews.com/forums/(E-Mail Removed) (Phidippus) wrote in message news:<(E-Mail Removed). com>...
> I'm evaluating a function at various values in a for loop. The
> function works most of the times (99% of parameter range I am
> investigating), but at some values, it gives error like below and
> crushes. I guess something wrong with sqrt function. I'm not going to
> attempt to show the function here because it is 1.5Mb. If I evaluate
> the exact same function in Maple at the value it crushed in Ruby, it
> behaves fine.
>
> Is there any way that when the (sqrt) function crushes, it gives some
> sort of error value and go on to evaluating at the next value without
> crushing the program? I don't want to manually restart the program at
> the next value each time the program crushes. In R, there is "try"
> function that can used for this kind of situation.
>
> Thank you.
>
> #####
> /usr/lib/ruby/1.6/complex.rb:82:in `initialize': stack level too deep
> (SystemStackError)
> from /usr/lib/ruby/1.6/complex.rb:63:in `new'
> from /usr/lib/ruby/1.6/complex.rb:63:in `Complex'
> from /usr/lib/ruby/1.6/complex.rb:130:in `/'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> ... 1461 levels...
> from rubyHopf0.rb:17:in `each'
> from rubyHopf0.rb:17
> from rubyHopf0.rb:16:in `each'
> from rubyHopf0.rb:16

 
Reply With Quote
 
Simon Strandgaard
Guest
Posts: n/a
 
      04-03-2004
On Sat, 03 Apr 2004 09:47:00 -0800, Phidippus wrote:
> I'm having hard time pinpointing where the error is generated since
> there are so many places sqrt are used...
>


I don't know if overloading Math.sqrt will help you?

Then you could log every time #sqrt is invoked.

--
Simon Strandgaard
 
Reply With Quote
 
Phidippus
Guest
Posts: n/a
 
      04-03-2004
Yes, one single function is 1.5Mb. It is rediculous, but true. I tried
whether the exact same function also works in R, and it worked fine.
But R is also developed for numerical computations, so it is probably
not a fair comparison for Ruby, I suppose.

"Robert Klemme" <(E-Mail Removed)> wrote in message news:<c4hrb3$2i812u$(E-Mail Removed)-berlin.de>...
> "Mark Hubbart" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
> >
> > On Apr 1, 2004, at 8:29 AM, Phidippus wrote:
> >
> > > I'm evaluating a function at various values in a for loop. The
> > > function works most of the times (99% of parameter range I am
> > > investigating), but at some values, it gives error like below and
> > > crushes. I guess something wrong with sqrt function. I'm not going to
> > > attempt to show the function here because it is 1.5Mb.

>
> Are you serious? A single function with 1.5MB source code?
>
> > If I evaluate
> > > the exact same function in Maple at the value it crushed in Ruby, it
> > > behaves fine.

>
> Well, you can't compare Ruby with Maple on this: Maple is a math system
> built to efficiency solve mathematical problems. Ruby is more of a general
> purpose language and especially not very good at recursion. The stack
> nesting problem surfaces every now and then.
>
> AFAIK there is a compiler switch that you can employ during building of Ruby
> that will increase the stack size. Alternatively you can implement sqrt as
> iterative function yourself.
>
> > > Is there any way that when the (sqrt) function crushes, it gives some
> > > sort of error value and go on to evaluating at the next value without
> > > crushing the program? I don't want to manually restart the program at
> > > the next value each time the program crushes. In R, there is "try"
> > > function that can used for this kind of situation.

>
> See below.
>
> > > Thank you.
> > >
> > > #####
> > > /usr/lib/ruby/1.6/complex.rb:82:in `initialize': stack level too deep
> > > (SystemStackError)
> > > from /usr/lib/ruby/1.6/complex.rb:63:in `new'
> > > from /usr/lib/ruby/1.6/complex.rb:63:in `Complex'
> > > from /usr/lib/ruby/1.6/complex.rb:130:in `/'
> > > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > > from /usr/lib/ruby/1.6/mathn.rb:244:in `sqrt'
> > > ... 1461 levels...
> > > from rubyHopf0.rb:17:in `each'
> > > from rubyHopf0.rb:17
> > > from rubyHopf0.rb:16:in `each'
> > > from rubyHopf0.rb:16

> >
> > This looks like a bug... sqrt() is recursing too deeply here, 1461
> > levels seems a bit excessive. What values are causing it to dump like
> > that? Could you give a specific example?

>
> I guess they are quite big so sqrt needs to many steps to identify the
> square root.
>
> > Normally, you could catch an error like this:
> >
> > begin
> > 0 / 0
> > rescue
> > puts "no dividing by zero in integer division!"
> > end
> >
> > .. but that doesn't work for me with a SystemStackError. I guess those
> > are always fatal errors.

>
> Works perfectly for me:
>
> irb(main):036:0> def rec; rec; end
> => nil
> irb(main):037:0> begin
> irb(main):038:1* rec
> irb(main):039:1> rescue SystemStackError => e
> irb(main):040:1> puts "Caught it: #{e.inspect}"
> irb(main):041:1> end
> Caught it: #<SystemStackError: stack level too deep>
> => nil
>
> Regards
>
> robert

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      04-08-2004

"Phidippus" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) om...
> Yes, one single function is 1.5Mb. It is rediculous, but true. I tried
> whether the exact same function also works in R, and it worked fine.
> But R is also developed for numerical computations, so it is probably
> not a fair comparison for Ruby, I suppose.


Whatever language is used, 1.5 GB source code for a single function is
definitely too much. Some systems might gracefully deal with it, but what
about human maintainers? IMHO heavy refactoring is indicated.

Regards

robert

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
signal handling and (structured) exception handling Peter C++ 34 10-17-2009 10:03 AM
python list handling and Lisp list handling Mark Tarver Python 22 04-26-2009 09:36 PM
Is faster handling hexadecimal values than handling chars? IƱaki Baz Castillo Ruby 1 04-15-2008 09:04 AM
Global Error handling in Applicatio_Error() of Global.asax VSK ASP .Net 1 07-29-2003 03:12 AM
Error Handling Kenneth Keeley ASP .Net 0 07-01-2003 03:45 AM



Advertisments