Michael W. Ryder wrote:
[snip]
> If I use Float("17") it returns 17.0 and Float(0x11) returns 17.0, both
> as expected.  Why doesn't Float("0x11") work?  As Ruby doesn't appear to
> handle Floats of bases other than 10 (or at least I haven't figured out
> how to yet) I can see it choking on Float("0x11.34") but it shouldn't
> choke on Float("0x11").

Actually, this is probably the most logical behavior. Integer() and 
Float() have the same defined behavior; they both can accept one of two 
inputs:
1. A Numeric that can be converted into the correct type;
2. A String that can be parsed into the correct type.

If a string is provided, then it must follow the same rules as the 
appropriate literal representation.... This is the source of the 
differences. So:
>> Integer("023")   #=> 19
>> Float("023")     #=> 23.0
>> Integer("0x23")  #=> 35
>> Float("0x23")    #=> ArgumentError!!!
>> Integer("1e3")   #=> ArgumentError!!!
>> Float("1e3")     #=> 1000.0

To make them truly cross-compatible would eliminate the error-checking.

> Part of what I am doing is trying to follow the statement in Pickaxe
> about duck typing and programming for any input, not just a select 
> subset.

Beware of doing *too much* duck typing. Figure out a reasonable point to 
stop. Unless there's a significant amount of value added by allowing 
strings, I wouldn't do it. If you can think of a reasonable circumstance 
where the programmer would want to pass a string instead of an actual 
number, go ahead; otherwise, it' just bloat, and bloat is a great source 
for bugs :)
-- 
Posted via http://www.ruby-forum.com/.