Hi,
Just thought it was weird that Ruby doesn’t automatically cast ints to
floats. Seems so un-rubyish
irb(main):006:0> 12/16
=> 0
irb(main):007:0> 12.to_f / 16.to_f
=> 0.75
Jeroen
Hi,
Just thought it was weird that Ruby doesn’t automatically cast ints to
floats. Seems so un-rubyish
irb(main):006:0> 12/16
=> 0
irb(main):007:0> 12.to_f / 16.to_f
=> 0.75
Jeroen
On 2006.04.02., at 10:16, Jeroen H. wrote:
Just thought it was weird that Ruby doesn’t automatically cast ints
to floats. Seems so un-rubyish
Try this one:
irb(main):003:0> 12.0 / 16
=> 0.75
irb(main):004:0>
Place a dot and zero digit after integers to have a floating number.
Here’s the same in Java:
itigga: segabor$ more test.java
class Test {
public static void main(String[] args) {
// first case
System.out.println("12/16 = " + 12/16);
// second case
System.out.println("12.0/16 = " + 12.0/16);
}
}
Running this the output will be:
12/16 = 0
12.0/16 = 0.75
If you write “12” language parser will mean it as integer. It is
normal. Why should it mean as floating point number?
I think it would be a major breakdown in memory footprint if Ruby
converted all integers to floating point numbers.
Gábor
Gábor SEBESTY�N wrote:
irb(main):004:0>
System.out.println("12.0/16 = " + 12.0/16);
I think it would be a major breakdown in memory footprint if Ruby
converted all integers to floating point numbers.
I’m not saying it should treat 12 as a float (I’m not saying it should
do anything really) but I wonder if it would be a bad thing to
automatically cast the outcome of a division if needed (like in PHP).
Vigor10:/tmp jeroen$ php test.php
integer
integer
double
integer
Jeroen
On Sun, Apr 02, 2006 at 10:41:36AM +0200, Jeroen H. wrote:
=> 0.75
irb(main):004:0>I’m not saying it should treat 12 as a float (I’m not saying it should
do anything really) but I wonder if it would be a bad thing to
automatically cast the outcome of a division if needed (like in PHP).
So you perform the integer division 12 / 16, get a result of 0, and then
cast that to a float 0.0? Not exactly useful. What you really need to
do
is perform a modulus operation and then do an integer division if the
result
of that is 0 and a floating point cast/division otherwise. Quite
expensive.
Also, if you really, really need integer division, then the PHP way
leaves
you out in the cold – AFAIK, there’s no ‘integer division’ operator in
PHP,
whereas, presumably, you can call .to_f on at least one of your
arguments in
Ruby if you want a floating point result.
There exists intuition to support that, although few commonly used
programming languages take this route. Exceptions seem to be PHP and
Python (soon) which admittedly are closer to ruby than C/C++.
I don’t like the idea of winding up with an IEEE float as a result of
an integer operation, being that integers and IEEE floats don’t
exactly behave in the same way. I also don’t think that it’s a good
idea for an operator to change its output type from a precise one to
an imprecise one based on user input. Imprecise and precise numbers
are fundamentally different and should probably not be mixed this
freely.
Maybe the real answer is to add precise math (rationals, decimals) to
ruby, like lisp has. Then you’d end up knowing whether your math was
‘precise’ at all times without exhibiting this mildly unintuitive
behavior. You’d of course need a div operator for this to work.
Jonathan W. wrote:
happen.
If I tell the computer to dived two integers, I get an integer back. If
I tell the computer to contatinate two strings I get a string back. If I
tell the computer to add a string to a number Ruby should tell me “I
can’t do it”.That’s the whole point abouot strongly typed languages!
That’s the kind of answer I was looking for. So I can definitely see why
strongly typed languages are safe and predictable and all, but why
(just out of interest) does PHP (and in the future phython?) have it?
Jeroen
Jeroen H. wrote:
Gábor SEBESTY�N wrote:
On 2006.04.02., at 10:16, Jeroen H. wrote:
Just thought it was weird that Ruby doesn’t automatically cast ints
to floats. Seems so un-rubyish
No, this is exactly why Ruby is a strong dynamically typed language.
Doing autoconversion is a very bad thing as unintentioned things can
happen.
If I tell the computer to dived two integers, I get an integer back. If
I tell the computer to contatinate two strings I get a string back. If I
tell the computer to add a string to a number Ruby should tell me “I
can’t do it”.
That’s the whole point abouot strongly typed languages!
Jonathan
Matthew P. wrote:
=> 0.75
irb(main):004:0>
I’m not saying it should treat 12 as a float (I’m not saying it should
do anything really) but I wonder if it would be a bad thing to
automatically cast the outcome of a division if needed (like in PHP).So you perform the integer division 12 / 16, get a result of 0, and then
cast that to a float 0.0? Not exactly useful. What you really need to do
is perform a modulus operation and then do an integer division if the result
of that is 0 and a floating point cast/division otherwise. Quite expensive.
No I just wanted a float as the result of a division between two
integers. I know how to do that (call .to_f on one of the integers). I
was just wondering why Ruby behaves the way it does.
J
On 4/2/06, Jeroen H. [email protected] wrote:
irb(main):003:0> 12.0 / 16
Well it would not make me happy, but I am all about choice
class Fixnum
def /(int)
self.to_f / int
end
end
p 12 / 16
pth
That’s the kind of answer I was looking for. So I can definitely see why
strongly typed languages are safe and predictable and all, but why
(just out of interest) does PHP (and in the future phython?) have it?
I can’t comment about Python but PHP is like Perl weakly typed.
So in PHP/Perl
5 + “6” results in 11
While in Ruby (or e.g. Java) you have to say
5 + “6”.to_i results in 11
Weakly typed languages do so because this behavious is somethimes handy
as you save some characters as you do not have to explicitly convert
types.
The problem is that this can become dangerous when you didn’t want the
autoconversion but forgot to explicitly tell the interpreter. Especially
if one part of the input comes from the user. Say hello to many kinds of
user injected code like SQLinjection or other malicious behaviour.
E.g. what is
5 + “6a” ??
Depending on the language it could be
11
“56a”
Or an exception. Now if it is the string “56a” and you really need a
number further down in your code?
Jonathan
On 3-apr-2006, at 9:26, Erik van Oosten wrote:
irb(main):001:0> 12.quo(16)
=> 0.75
Wow!
Le Lundi 03 Avril 2006 14:25, Julian ‘Julik’ Tarkhanov a écrit :
On 3-apr-2006, at 9:26, Erik van Oosten wrote:
irb(main):001:0> 12.quo(16)
=> 0.75
There’s also 12.0 / 16.0. You muste tell ruby that you’re using float
not
integer.
Bye.
Julian ‘Julik’ Tarkhanov wrote:
On 3-apr-2006, at 9:26, Erik van Oosten wrote:
irb(main):001:0> 12.quo(16)
=> 0.75Wow!
I anxiously await the day when I can see an example like that and say “I
knew that”. Of course, given my memory these days, maybe I had seen
that…
Keith
irb(main):001:0> 12.quo(16)
=> 0.75
Erik.
Jeroen H. schreef:
2006/4/3, Alan F. [email protected]:
What does Smalltalk do in similar circumstances ? (not a leading
question, I genuinely don’t know
The version of Squeak I tested has real Fraction objects. Which means
12/16 gets converted to a 3/4 Fraction.
Bye !
Jonathan W. wrote:
No, this is exactly why Ruby is a strong dynamically typed language.
Doing autoconversion is a very bad thing as unintentioned things can
happen.If I tell the computer to dived two integers, I get an integer back.
That’s the whole point abouot strongly typed languages!
irb(main):002:0> 10000000.class
=> Fixnum
irb(main):003:0> 10000000.class
=> Fixnum
irb(main):004:0> (10000000 * 1000000).class
=> Bignum
Except where Ruby does autoconversion to make your life easier.
For the record, I don’t think Ruby should do the int->float conversion,
but it’s for reasons of precision, not type purity.
What does Smalltalk do in similar circumstances ? (not a leading
question, I genuinely don’t know
Alan
irb(main):001:0> require ‘mathn’
=> true
irb(main):002:0> 12 / 16
=> 3/4
Erik.
Francois B. schreef:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs