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

[Michael W. Ryder]

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]

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.

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.

 

[Joel VanderWerf]

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.

 

[Mark Wilden]

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

 

[Stephen Cox]

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.

 

[Peña, Botp]

From: Michael W. Ryder [mailto:[email protected]]=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

 

[Albert Schlef]

(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.

 

[Marc Heiler]

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)

 

[Mark Wilden]

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

 

[Michael W. Ryder]

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.

 

[Mark Wilden]

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