Is there any good source for the logic behind some of the methods?

Discussion in 'Ruby' started by Michael W. Ryder, May 21, 2008.

  1. I am trying to figure out why methods that seem to do the same thing
    behave so differently. For example Integer("0377") returns 255 as
    expected for an octal number but "0377".to_i returns 377. Or why
    Integer("12e3") crashes while Float("12e3") returns 12000.0 as expected.
    I was hoping to find somewhere that tells when to use one or the other
    method depending upon expected inputs. It is very time consuming to
    have to keep testing a method to find out it's limitations.
     
    Michael W. Ryder, May 21, 2008
    #1
    1. Advertising

  2. Phlip wrote:
    >> I am trying to figure out why methods that seem to do the same thing behave
    >> so differently. For example Integer("0377") returns 255 as

    >
    > Where are you getting these Integer() methods? I never saw them before. (4
    > years, aggregate, working in Ruby.)
    >


    In Pickaxe they are listed in the Kernel module. I notice while reading
    it again that the Integer method honors 0x, 0b, etc. when converting
    strings while Float just uses to_f. Not sure why and this was part of
    my question.

    >> expected for an octal number but "0377".to_i returns 377. Or why
    >> Integer("12e3") crashes while Float("12e3") returns 12000.0 as expected. I
    >> was hoping to find somewhere that tells when to use one or the other
    >> method depending upon expected inputs. It is very time consuming to have
    >> to keep testing a method to find out it's limitations.

    >
    > Write unit tests for everything you do, starting with tests that probe the
    > libraries. This should be second nature; you should write a test for any
    > question you can think to ask about a system.
    >


    That's what I have been doing and this is why I keep having problems.
    Float(x) works fine until you try Float("0x11"). Then I had to upgrade
    to Float(Float(x) rescue Integer(x) rescue 0). It would be nice to be
    able to expect some of these problem cases and program around them,
    using testing to make sure that the code was correct, not that I used
    the correct method for the inputs.

    > And .to_i is for brute-force parsing; not for anything elaborate. Like the
    > hallowed C atoi().


    Yes, I found that out early on in my testing.

    >
    >
     
    Michael W. Ryder, May 21, 2008
    #2
    1. Advertising

  3. Re: Is there any good source for the logic behind some of themethods?

    Michael W. Ryder wrote:
    > I am trying to figure out why methods that seem to do the same thing
    > behave so differently. For example Integer("0377") returns 255 as
    > expected for an octal number but "0377".to_i returns 377. Or why
    > Integer("12e3") crashes while Float("12e3") returns 12000.0 as expected.
    > I was hoping to find somewhere that tells when to use one or the other
    > method depending upon expected inputs. It is very time consuming to
    > have to keep testing a method to find out it's limitations.


    Guessing:

    "0377".to_i returns 377 -- because #to_i has an default argument
    base=10, so in this case you have implicitly told #to_i to use decimal.

    Integer("0377") returns 255 -- because there's no base specified, so it
    has to be determined from the string itself.

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
     
    Joel VanderWerf, May 21, 2008
    #3
  4. Michael W. Ryder

    Mark Wilden Guest

    Re: Is there any good source for the logic behind some of themethods?

    On May 20, 2008, at 6:20 PM, Michael W. Ryder wrote:

    > I am trying to figure out why methods that seem to do the same thing
    > behave so differently. For example Integer("0377") returns 255 as
    > expected for an octal number but "0377".to_i returns 377. Or why
    > Integer("12e3") crashes while Float("12e3") returns 12000.0 as
    > expected. I was hoping to find somewhere that tells when to use one
    > or the other method depending upon expected inputs. It is very time
    > consuming to have to keep testing a method to find out it's
    > limitations.


    I would have to say that very few of us run into this problem,
    actually. :) Ruby is an agile language, meaning that it doesn't strive
    for completeness or perfection. It's just a tool to make some customer
    happy. And in my (and probably others') experience, parsing strings as
    octal integers simply doesn't arise in very many use cases.

    Which is not to say that I don't think you should explore Ruby just as
    you're doing. But I've found (through 24 years of programming) that
    asking "why" isn't generally as fruitful as asking "how." I prefer to
    start from a need, then figure out how the language will let me
    fulfill that need; rather than starting by learning all the nooks and
    crannies of a language that, when all is said and done, was designed
    by imperfect humans.

    Just some thoughts - not a criticism.

    ///ark
     
    Mark Wilden, May 21, 2008
    #4
  5. Michael W. Ryder

    Stephen Cox Guest

    Re: Is there any good source for the logic behind some of th

    Mark Wilden wrote:
    > On May 20, 2008, at 6:20 PM, Michael W. Ryder wrote:
    >
    >> I am trying to figure out why methods that seem to do the same thing
    >> behave so differently. For example Integer("0377") returns 255 as
    >> expected for an octal number but "0377".to_i returns 377. Or why
    >> Integer("12e3") crashes while Float("12e3") returns 12000.0 as
    >> expected. I was hoping to find somewhere that tells when to use one
    >> or the other method depending upon expected inputs. It is very time
    >> consuming to have to keep testing a method to find out it's
    >> limitations.

    >
    > I would have to say that very few of us run into this problem,
    > actually. :) Ruby is an agile language, meaning that it doesn't strive
    > for completeness or perfection. It's just a tool to make some customer
    > happy. And in my (and probably others') experience, parsing strings as
    > octal integers simply doesn't arise in very many use cases.
    >
    > Which is not to say that I don't think you should explore Ruby just as
    > you're doing. But I've found (through 24 years of programming) that
    > asking "why" isn't generally as fruitful as asking "how." I prefer to
    > start from a need, then figure out how the language will let me
    > fulfill that need; rather than starting by learning all the nooks and
    > crannies of a language that, when all is said and done, was designed
    > by imperfect humans.
    >
    > Just some thoughts - not a criticism.
    >
    > ///ark


    LOL. Total bs really. it's the guys who learn all the "nooks and
    crannies" that take a language to the next level. Or would you prefer
    Ruby stays "that language that Rails uses".?

    I'd prefer to see Ruby on par with the likes of Perl or Python. I'd
    prefer to see ruby used to write installation scripts, manage system
    processes, and build maps in games like Civ 4 (Python). Not just "that
    rails language".

    I applaud the OP for pointing this oddity out. And I hope he continues
    experimenting and posting.
    --
    Posted via http://www.ruby-forum.com/.
     
    Stephen Cox, May 21, 2008
    #5
  6. Michael W. Ryder

    Peña, Botp Guest

    From: Michael W. Ryder [mailto:]=20
    # I am trying to figure out why methods that seem to do the same thing=20
    # behave so differently. For example Integer("0377") returns 255 as=20
    # expected for an octal number but "0377".to_i returns 377. Or why=20
    # Integer("12e3") crashes while Float("12e3") returns 12000.0=20
    # as expected.=20
    # I was hoping to find somewhere that tells when to use one=20
    # or the other=20
    # method depending upon expected inputs. It is very time consuming to=20
    # have to keep testing a method to find out it's limitations.

    qri and irb are your friends.

    eg,

    botp@botp-desktop:~$ qri -f plain integer float string.to_i

    --------------------------------------------------------- Kernel#Integer
    Integer(arg) =3D> integer
    ------------------------------------------------------------------------
    Converts _arg_ to a +Fixnum+ or +Bignum+. Numeric types are
    converted directly (with floating point numbers being truncated).
    If _arg_ is a +String+, leading radix indicators (+0+, +0b+, and
    +0x+) are honored. Others are converted using +to_int+ and +to_i+.
    This behavior is different from that of +String#to_i+.

    Integer(123.999) #=3D> 123
    Integer("0x1a") #=3D> 26
    Integer(Time.new) #=3D> 1049896590

    ----------------------------------------------------------- Kernel#Float
    Float(arg) =3D> float
    ------------------------------------------------------------------------
    Returns _arg_ converted to a float. Numeric types are converted
    directly, the rest are converted using _arg_.to_f. As of Ruby 1.8,
    converting +nil+ generates a +TypeError+.

    Float(1) #=3D> 1.0
    Float("123.456") #=3D> 123.456

    ------------------------------------------------------------ String#to_i
    str.to_i(base=3D10) =3D> integer
    ------------------------------------------------------------------------
    Returns the result of interpreting leading characters in _str_ as
    an integer base _base_ (2, 8, 10, or 16). Extraneous characters
    past the end of a valid number are ignored. If there is not a valid
    number at the start of _str_, +0+ is returned. This method never
    raises an exception.

    "12345".to_i #=3D> 12345
    "99 red balloons".to_i #=3D> 99
    "0a".to_i #=3D> 0
    "0a".to_i(16) #=3D> 10
    "hello".to_i #=3D> 0
    "1100101".to_i(2) #=3D> 101
    "1100101".to_i(8) #=3D> 294977
    "1100101".to_i(10) #=3D> 1100101
    "1100101".to_i(16) #=3D> 17826049

    (note: don't try w ri, you'll be disappointed ;)

    then, try testing w irb,

    botp@botp-desktop:~$ irb

    001:0> Integer ""
    ArgumentError: invalid value for Integer: ""
    from (irb):1:in `Integer'
    from (irb):1

    002:0> Integer "1.1"
    ArgumentError: invalid value for Integer: "1.1"
    from (irb):2:in `Integer'
    from (irb):2

    irb(main):003:0> Integer "11"
    =3D> 11

    irb(main):005:0* "".to_i
    =3D> 0

    irb(main):006:0> "1.1".to_i
    =3D> 1

    irb(main):007:0> "11".to_i
    =3D> 11

    irb(main):010:0> "1a23".to_i
    =3D> 1

    irb(main):011:0> "a123".to_i
    =3D> 0

    Base on above, Integer() is strict and #to_i is friendly. If you want =
    to test if all chars in a string is of literal integer format, then use =
    Integer; Integer will give exception otherwise. OTOH, if a string does =
    not pass, #to_i will just give you 0 (ie zero).=20

    The biggest advantage of #to_i over Integer is that you can change the =
    base for conversion.

    irb(main):025:0> "ffff".to_i(16)
    =3D> 65535
    irb(main):026:0> "ffffg".to_i(16)
    =3D> 65535
    irb(main):027:0> "ffffg".to_i(17)
    =3D> 1331116

    ...but you've probably knew that already..

    hth.

    kind regards -botp

    ps: i think you can handle the Float part ;)
     
    Peña, Botp, May 21, 2008
    #6
  7. Peña, Botp wrote:
    >
    > (note: don't try w ri, you'll be disappointed ;)


    WTF would he try "w ri"?

    $ w ri
    13:56:51 up 3 days, 17:24, 11 users, load average: 0.89, 1.27, 1.51
    USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

    Yes, quite disappointing.
    --
    Posted via http://www.ruby-forum.com/.
     
    Albert Schlef, May 21, 2008
    #7
  8. Michael W. Ryder

    Marc Heiler Guest

    Re: Is there any good source for the logic behind some of themethods?

    > I'd prefer to see Ruby on par with the likes of Perl or Python. I'd
    > prefer to see ruby used to write installation scripts, manage system
    > processes, and build maps in games like Civ 4 (Python). Not just "that
    > rails language".


    Why do you think Ruby is not on par with perl? In my opinion perl is
    constantly losing people, especially new ones, younger ones, are much
    more likely to use php ruby or python.

    "build maps in games like Civ 4 (Python)"

    That is fine, you notice you used Python, not perl as example? ;-)


    > Not just "that rails language"


    You think that people only use ruby because of rails?
    I assure you that there are many people that use ruby heavily but have
    hardly any use for rails. I am sure the scenario is different for many
    rails-user, but what I dont like is your world view here -> "just a
    rails language"

    There is no homogeneous mass.

    Btw I think there are much more games that use python rather than perl.
    And I think ruby is more prevalent in game projects than perl, but we
    should rather make a list and compare that (and differ betwen games
    written completely in that language, and games that use a faster
    language and tie this with a scripting language, i think even lua might
    be ahead of python here)
    --
    Posted via http://www.ruby-forum.com/.
     
    Marc Heiler, May 21, 2008
    #8
  9. Michael W. Ryder

    Mark Wilden Guest

    Re: Is there any good source for the logic behind some of th

    On May 20, 2008, at 10:31 PM, Stephen Cox wrote:

    > LOL. Total bs really. it's the guys who learn all the "nooks and
    > crannies" that take a language to the next level. Or would you prefer
    > Ruby stays "that language that Rails uses".?


    Sure - and I almost pointed out that if you're interested in the
    language itself - not as a tool - then that's fine. I was just saying
    that most of us do not use Ruby this way.

    > I'd prefer to see Ruby on par with the likes of Perl or Python. I'd
    > prefer to see ruby used to write installation scripts, manage system
    > processes, and build maps in games like Civ 4 (Python). Not just "that
    > rails language".


    I really couldn't care less what Ruby is "on par with." I use Ruby
    because it gets things done. I've done a lot of work with Perl, and
    I'm teaching my son Lua. I'm not a fanboy.

    > I applaud the OP for pointing this oddity out. And I hope he continues
    > experimenting and posting.


    I wasn't criticizing him. I don't think there's anything wrong with
    his approach. I was just trying to explain to him why others don't
    share his pain.

    You're absolutely right that the people who question "why?" are the
    ones who make important changes.

    ///ark
     
    Mark Wilden, May 21, 2008
    #9
  10. Mark Wilden wrote:
    > On May 20, 2008, at 6:20 PM, Michael W. Ryder wrote:
    >
    >> I am trying to figure out why methods that seem to do the same thing
    >> behave so differently. For example Integer("0377") returns 255 as
    >> expected for an octal number but "0377".to_i returns 377. Or why
    >> Integer("12e3") crashes while Float("12e3") returns 12000.0 as
    >> expected. I was hoping to find somewhere that tells when to use one
    >> or the other method depending upon expected inputs. It is very time
    >> consuming to have to keep testing a method to find out it's
    >> limitations.

    >
    > I would have to say that very few of us run into this problem,
    > actually. :) Ruby is an agile language, meaning that it doesn't strive
    > for completeness or perfection. It's just a tool to make some customer
    > happy. And in my (and probably others') experience, parsing strings as
    > octal integers simply doesn't arise in very many use cases.
    >
    > Which is not to say that I don't think you should explore Ruby just as
    > you're doing. But I've found (through 24 years of programming) that
    > asking "why" isn't generally as fruitful as asking "how." I prefer to
    > start from a need, then figure out how the language will let me
    > fulfill that need; rather than starting by learning all the nooks and
    > crannies of a language that, when all is said and done, was designed
    > by imperfect humans.
    >


    My learning project started with a different implementation of the
    Rational module. While implementing the different methods I was also
    referring to Pickaxe and noted the ending paragraphs on duck typing.
    They mentioned that the programmer should try to expect any input and
    this is what I am trying to implement. The major difference between my
    implementation and the original was that I allow Strings, Floats, and
    Rationals as input in addition to the original's Integers.
    One of the advantages of Object Oriented Programming is that once a
    method is defined inheriting classes automatically have it. Since
    Integer(x) already allowed for entry of strings with other bases this
    was an advantage to me. My problem is that Float(x) does not work the
    same way and I was curious as to why. If I had not been testing
    different possible inputs I would never have found that out, and
    possibly no one else would.
    I have been programming for over 35 years and have found that pushing
    the envelope is sometimes necessary to accomplish a task. I remember
    taking other peoples programs and cutting big pieces out of them and
    replacing them with a couple of lines of code. Not only did I fix a
    problem with the original program but I made it much easier to maintain.
    While I could create a method (and have) that handles strings the way
    I expect I don't expect others to be able to understand what I am doing
    at a quick glance and it would be better if I could use existing methods
    the way I expect them to work.
    I have nothing against Ruby, it just seemed odd that methods that I
    thought would work the same don't.


    > Just some thoughts - not a criticism.
    >
    > ///ark
    >
     
    Michael W. Ryder, May 21, 2008
    #10
  11. Michael W. Ryder

    Mark Wilden Guest

    Re: Is there any good source for the logic behind some of themethods?

    On May 21, 2008, at 12:00 PM, Michael W. Ryder wrote:

    > I have nothing against Ruby, it just seemed odd that methods that I
    > thought would work the same don't.


    I don't think it's odd in the least. I've _never_ used a language that
    worked the way I thought it should. :)

    ///ark
     
    Mark Wilden, May 21, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    364
  2. Colin Song
    Replies:
    7
    Views:
    4,642
    pinto
    Feb 12, 2009
  3. Weng Tianxiang
    Replies:
    7
    Views:
    1,365
    Paul Uiterlinden
    Sep 11, 2009
  4. Eric Danstron

    Are there ANY good forums out there anymore???

    Eric Danstron, Sep 21, 2005, in forum: ASP General
    Replies:
    1
    Views:
    170
    Immediacy
    Sep 22, 2005
  5. Kenneth McDonald
    Replies:
    5
    Views:
    386
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page