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.
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 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
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
···
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 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.
qri and irb are your friends.
eg,
botp@botp-desktop:~$ qri -f plain integer float string.to_i
--------------------------------------------------------- Kernel#Integer
Integer(arg) => integer
···
From: Michael W. Ryder [mailto:_mwryder@worldnet.att.net]
------------------------------------------------------------------------
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) #=> 123
Integer("0x1a") #=> 26
Integer(Time.new) #=> 1049896590
----------------------------------------------------------- Kernel#Float
Float(arg) => 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) #=> 1.0
Float("123.456") #=> 123.456
------------------------------------------------------------ String#to_i
str.to_i(base=10) => 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 #=> 12345
"99 red balloons".to_i #=> 99
"0a".to_i #=> 0
"0a".to_i(16) #=> 10
"hello".to_i #=> 0
"1100101".to_i(2) #=> 101
"1100101".to_i(8) #=> 294977
"1100101".to_i(10) #=> 1100101
"1100101".to_i(16) #=> 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"
=> 11
irb(main):005:0* "".to_i
=> 0
irb(main):006:0> "1.1".to_i
=> 1
irb(main):007:0> "11".to_i
=> 11
irb(main):010:0> "1a23".to_i
=> 1
irb(main):011:0> "a123".to_i
=> 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).
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)
=> 65535
irb(main):026:0> "ffffg".to_i(16)
=> 65535
irb(main):027:0> "ffffg".to_i(17)
=> 1331116
...but you've probably knew that already..
hth.
kind regards -botp
ps: i think you can handle the Float part
Mark Wilden 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.
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.
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/\.
Mark Wilden 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.
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.
···
On May 20, 2008, at 6:20 PM, Michael W. Ryder wrote:
Just some thoughts - not a criticism.
///ark
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/\.
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
···
On May 20, 2008, at 10:31 PM, Stephen Cox wrote:
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
···
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.