From: MonkeeSage <MonkeeSage@...>
Date: 2007-11-30T10:50:00+09:00
Subject: Re: FEATURE SUGGESTION: Accept default value for to_f and to_i

On Nov 27, 8:18 pm, Mr Magpie <gazmcghees...@yahoo.com.au> wrote:
> > All of the functionality you mention can be had now, it's just that it
> > wouldn't be as fast. So most of the points are moot. Only 5 & 6
> > remain. Also, 7 isn't exactly true, since it would require a extra
> > compare operation in the back-end to see if a default was given and
> > return that, or else return 0. But that is probably negligible.
>
> Wow, thanks for doing the numbers Jordan.
>
> I know it can be done now, but such basic functionality is best done
> fast and right ie. in C. There would be zillions of examples of tight
> loops in frameworks, libraries and peoples applications out there that
> does string to number conversions, eg. a SQL results to a Fixnum.
>
> Some have said that performance is less of an issue in the exceptional
> case, but just how exceptional bad input is depends on the application,
> and shouldn't cause a 20x time difference. eg if 1 in 20 input values
> are bad, the conversion takes twice as long.
>
> <very useful numbers deleted, see previous post>
>
>
>
> > If I may make three counter-points against your suggestion:
>
> > 1.) It is wierd and completely unintuitive for to_i to return anything
> > *other than integer*! Maybe it's just me, but that would be like
> > calling to_a and getting back a String. Holy return types Batman, what
> > gives?
>
> I get this, but it would only do so because "you asked for it". This
> kind of thing isn't uncommon in Ruby though.
>
>
>
> > 2.) Would a non-zero default really be used enough (or in cases where
> > the speed of using something like the code I listed above with regexps
> > is not fast enougg) to warrant inclusion? Do you have any real world
> > examples that are not just corner-cases?
>
> If I was implementing Ruby I would lean towards nil as the default (0
> would come a close second best in my mind). It would allow the 'or'
> operators to be used for any defaults eg. (aString.to_i || 0) would
> achieve a default of 0.
>
> The most common example that comes to mind is when reading in
> configuration where you are reading a value from a string source eg. xml
> and if a value isn't provided you return a sensible default which isn't
> normally 0.
>
>
>
> > 3.) (Like Ara said...) If you're worried about the performance of
> > exceptions, how helpful is it to do something like: "10a".to_i(nil) %
> > 2? That's either going to terminate with a NoMethodError, or you'll
> > have to rescue it (eating just as much cycles).
>
> In that example, you asked for a nil default, and thats what you got.
>
> matz reminds us that to_i already takes a base argument. I guess the
> default value would have to be the second default argument - not so
> pretty.
>
> Robert suggests a block handler. I don't know what the performance
> implications are of blocks, but I guess it would work, and obviously
> allow more advanced handling. Most of the time however I would just
> return a value, not do any logic.
>
> <Suggestion>
>
> Because of the existing base argument on to_i, and the need to keep such
> basic methods simple and fast, and the 7 points I listed previously, I
> propose the following :
>
> as_i(default=nil) and as_f(default=nil) methods added to Fixnum, Float,
> String
> For Float.as_i, NaN, Infinity etc would return the default.
>
> If I'm outnumbered on the default argument, then as_i and as_f could
> simply be equivalent to to_i and to_f, just with a nil default. I would
> then use (aString.as_i || DEFAULT_VALUE).
>
> If enough people would use an optional block and its not a significant
> performance drag, that could be added too.
>
> </Suggestion>
>
> Thanks again Jordan for the numbers,
>
> magpie.
> --
> Posted viahttp://www.ruby-forum.com/.

NP. I was curious about the performance penalty myself. Might I
suggest, if you think it is truly worthy, that you write a small ruby
extension in C to add as_i/_f to class String. You could get the
behavior and speed you desire, and still be compatible with mri, and
if enough people found it useful it could find its way into the
standard lib.

Regards,
Jordan