I know that introducing new syntax into Ruby is probably far from being
accepted by matz…
Every now and then I accidentially pass an integer to a method and am
surprised than I get a wrong result. The reason is that the method
expected floats as arguments and not integers. These kind of bugs are
very hard to find, IMHO.
Imagine the following method:
def meth(a, b)
a / b
end
It works if a, b or both are floats, but not if both are integers.
Instead you have to write:
a.to_f / b
or
a / b.to_f
or
1.0 * a / b
…
My proposal is to add a /. operator, that treats both arguments as
floats, so that
1 /. 2 # => 0.5
Or alternatively:
class Float
alias fdiv /
end
class Integer
def fdiv(divisor)
self.to_f / divisor
end
end
a.fdiv(b)
Any comments?
IMHO, even better would be if / would always mean floating point
division and an extra // operator would mean integer division, but it’s
to late to change now (even for Ruby 2.0)
Maybe you could use the ‘mathn’ module?
irb(main):001:0> require ‘mathn’
=> true
irb(main):002:0> 1/1
=> 1
irb(main):003:0> 1/2
=> 1/2
irb(main):004:0> 3/2
=> 3/2
irb(main):005:0> 1+ (1/2)
=> 3/2
irb(main):006:0> 1.0+ (1/2)
=> 1.5
···
il Thu, 3 Jun 2004 01:53:18 +0900, Michael Neumann mneumann@ntecs.de ha scritto::
Hi,
I know that introducing new syntax into Ruby is probably far from being
accepted by matz…
Every now and then I accidentially pass an integer to a method and am
surprised than I get a wrong result. The reason is that the method
expected floats as arguments and not integers. These kind of bugs are
very hard to find, IMHO.
I know that introducing new syntax into Ruby is probably far from being
accepted by matz…
Every now and then I accidentially pass an integer to a method and am
surprised than I get a wrong result. The reason is that the method
expected floats as arguments and not integers. These kind of bugs are
very hard to find, IMHO.
Imagine the following method:
def meth(a, b)
a / b
end
It works if a, b or both are floats, but not if both are integers.
Instead you have to write:
a.to_f / b
or
a / b.to_f
or
1.0 * a / b
…
My proposal is to add a /. operator, that treats both arguments as
floats, so that
1 /. 2 # => 0.5
But you’ve still got a “have to write” case – meaning, when you write #meth, above, you still can’t just write “a / b”. So if the problem
is that you forget to write “a.to_f” instead of “a”, you’re still in
danger of forgetting to write “/.” instead of “/”.
Or alternatively:
class Float
alias fdiv /
end
class Integer
def fdiv(divisor)
self.to_f / divisor
end
end
I know that introducing new syntax into Ruby is probably far from being
accepted by matz…
Every now and then I accidentially pass an integer to a method and am
surprised than I get a wrong result. The reason is that the method
expected floats as arguments and not integers. These kind of bugs are
very hard to find, IMHO.
Imagine the following method:
def meth(a, b)
a / b
end
It works if a, b or both are floats, but not if both are integers.
Instead you have to write:
a.to_f / b
or
a / b.to_f
or
1.0 * a / b
…
You might better use Kernel#Float because of this:
Float 1
=> 1.0
Float “1”
=> 1.0
Float “1.0”
=> 1.0
Float nil
TypeError: cannot convert nil into Float
from (irb):8:in `Float’
from (irb):8
nil.to_f
=> 0.0
My proposal is to add a /. operator, that treats both arguments as
floats, so that
1 /. 2 # => 0.5
Or alternatively:
class Float
alias fdiv /
end
class Integer
def fdiv(divisor)
self.to_f / divisor
end
end
a.fdiv(b)
Any comments?
IMHO, even better would be if / would always mean floating point
division and an extra // operator would mean integer division, but it’s
to late to change now (even for Ruby 2.0)
I strongly oppose that one: Operators are overloaded and if I have two
int’s I want integer division, if I have to floats I want float division.
And I don’t want that changed, because often code is written with integer
divisions in mind. All sorts of indexing calculations depend on int math.
Michael Neumann <mneumann@ntecs.de> wrote in message news:<20040602165312.GA25813@miya.intranet.ntecs.de>...
IMHO, even better would be if / would always mean floating point
division and an extra // operator would mean integer division, but it's
to late to change now (even for Ruby 2.0)
We already have .div for integer division. (13.div(7) == 2)
/ has an established meaning in the mathn library: 13/7 is the
rational number 13/7. Since the standard libraries give wrong
answers when mathn is not required (and no one seems to have the
slightest interest in fixing them), the mathn meaning must be
the standard meaning. NEVER use / for integer division:
use .div instead.
I don't like the Ocamlish /. . It's fine for Ocaml, a strongly
and statically typed language, but it strikes me as alien to the
spirit of Ruby. I'd rather just use .to_f (as in 13/(7.to_f)) to
force floating point.
Sure, but when at the time of writing #meth, you think parameters a and
b will always be floats (and of course you don't document it, because
it's a quick hack :), you'll get in trouble later (e.g. meth(1,2) vs.
meth(1.0, 2.0)). So you want use fdiv, as you expect the division to be
a floating point division (and for me that's the usual case).
Regards,
Michael
···
On Thu, Jun 03, 2004 at 07:25:41AM +0900, David A. Black wrote:
Hi --
On Thu, 3 Jun 2004, Michael Neumann wrote:
> Hi,
>
> I know that introducing new syntax into Ruby is probably far from being
> accepted by matz....
>
> Every now and then I accidentially pass an integer to a method and am
> surprised than I get a wrong result. The reason is that the method
> expected floats as arguments and not integers. These kind of bugs are
> very hard to find, IMHO.
>
> Imagine the following method:
>
> def meth(a, b)
> a / b
> end
>
> It works if a, b or both are floats, but not if both are integers.
>
> Instead you have to write:
>
> a.to_f / b
>
> or
>
> a / b.to_f
>
> or
>
> 1.0 * a / b
>
> ...
>
> My proposal is to add a /. operator, that treats both arguments as
> floats, so that
>
> 1 /. 2 # => 0.5
But you've still got a "have to write" case -- meaning, when you write #meth, above, you still can't just write "a / b". So if the problem
is that you forget to write "a.to_f" instead of "a", you're still in
danger of forgetting to write "/." instead of "/".
Quoteing oinkoink+unet@rexx.com, on Fri, Jun 04, 2004 at 02:08:39AM +0900:
Michael Neumann <mneumann@ntecs.de> wrote in message news:<20040602165312.GA25813@miya.intranet.ntecs.de>...
> IMHO, even better would be if / would always mean floating point
> division and an extra // operator would mean integer division, but it's
> to late to change now (even for Ruby 2.0)
We already have .div for integer division. (13.div(7) == 2)
/ has an established meaning in the mathn library: 13/7 is the
rational number 13/7. Since the standard libraries give wrong
answers when mathn is not required (and no one seems to have the
slightest interest in fixing them), the mathn meaning must be
the standard meaning. NEVER use / for integer division:
use .div instead.
Its great that ruby allows programmers to extend even the standard
types... but it can be pretty harmful!
I would expect that after mathn is required much code would break... is
that what you meant? You seemed to suggest that things would work BETTER
when integer division is redefined to not do what it usually does!
David has said it all - here are some additional remarks.
"Michael Neumann" <mneumann@ntecs.de> schrieb im Newsbeitrag
news:20040602165312.GA25813@miya.intranet.ntecs.de...
IMHO, even better would be if / would always mean floating point
division and an extra // operator would mean integer division, but it's
to late to change now (even for Ruby 2.0)
I strongly oppose that one: Operators are overloaded and if I have two
int's I want integer division, if I have to floats I want float division.
And I don't want that changed, because often code is written with integer
divisions in mind. All sorts of indexing calculations depend on int math.
Then your code will break whenever it is used in a program that requires "mathn". You should always use div if you want integer division.
The truth is that Ruby's / operator is broken. Any time a programmer uses a / operation, they intend the operation to be either a float divide or an int divide, not something that polymorphically switches its semantics based on the operands. Anytime you use / to mean int division, it will break if given floats (or someone required mathn). Anytime you use / to mean float division, it will break if given 2 ints.
In a perfect world where backward compatibility wasn't an issue, I would make / always mean float division and // always mean int division.
If I were to worry about backward compatibility, leave / as is (and never use it!). And then provide specific operators for int and float division. /. and // aren't too bad. div and fdiv (as methods, not operators) are not bad either.
I recall in earlier threads on this topic that Matz was uncomfortable defining division of integers (exact values) so that it returns an inexact result. I think he was implying that a future ruby might return rationals for integer division. I think that makes sense.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
On Thu, Jun 03, 2004 at 07:25:41AM +0900, David A. Black wrote:
> But you've still got a "have to write" case -- meaning, when you write
> #meth, above, you still can't just write "a / b". So if the problem
> is that you forget to write "a.to_f" instead of "a", you're still in
> danger of forgetting to write "/." instead of "/".
Sure, but when at the time of writing #meth, you think parameters a and
b will always be floats (and of course you don't document it, because
it's a quick hack :), you'll get in trouble later (e.g. meth(1,2) vs.
meth(1.0, 2.0)). So you want use fdiv, as you expect the division to be
a floating point division (and for me that's the usual case).
OK, but what I mean is: given the same problem, you can also solve it
with to_f, and it should be no more or less difficult to remember than
remembering to use fdiv. (Assuming I'm following your argument
correctly.) I'm just making the conservative argument with regard to
change.
In message "Re: [RCR] Floating point division operator /. (or fdiv method)" on 04/06/04, Jim Weirich <jim@weirichhouse.org> writes:
If I were to worry about backward compatibility, leave / as is (and
never use it!). And then provide specific operators for int and float
division. /. and // aren't too bad. div and fdiv (as methods, not
operators) are not bad either.
Numeric#div does integer division and Numeric#quo does float (or
rational if available) division _now_.
I strongly disagree. It is mathn that is broken, not the / operator.
I use / all the time to indicate integer division (provided I'm working
with integers). My code will not work with mathn and I have no
intention of going out of my way to uglify my code just to make it
compatible with a broken library.
I've said it before and I will say it again. Code that changes builtin
classes without a really good reason (YAML is one such example) is
broken. See [ruby-talk:81923] for what I've written in the past on this
subject.
If we get selector namespaces in ruby 2.0, then mathn can be rewritten
such that users can get floating-point division with / in their
namespace only. Until then I recommend not using mathn.
Paul
···
On Fri, Jun 04, 2004 at 09:48:00AM +0900, Jim Weirich wrote:
Robert Klemme wrote:
>I strongly oppose that one: Operators are overloaded and if I have two
>int's I want integer division, if I have to floats I want float division.
>And I don't want that changed, because often code is written with integer
>divisions in mind. All sorts of indexing calculations depend on int math.
Then your code will break whenever it is used in a program that requires
"mathn". You should always use div if you want integer division.
"Paul Brannan" <pbrannan@atdesk.com> schrieb im Newsbeitrag
news:20040604135901.GD2788@atdesk.com...
> Robert Klemme wrote:
> >I strongly oppose that one: Operators are overloaded and if I have
two
> >int's I want integer division, if I have to floats I want float
division.
> >And I don't want that changed, because often code is written with
integer
> >divisions in mind. All sorts of indexing calculations depend on int
math.
>
> Then your code will break whenever it is used in a program that
requires
> "mathn". You should always use div if you want integer division.
> The truth is that Ruby's / operator is broken.
I strongly disagree. It is mathn that is broken, not the / operator.
I use / all the time to indicate integer division (provided I'm working
with integers). My code will not work with mathn and I have no
intention of going out of my way to uglify my code just to make it
compatible with a broken library.
I've said it before and I will say it again. Code that changes builtin
classes without a really good reason (YAML is one such example) is
broken. See [ruby-talk:81923] for what I've written in the past on this
subject.
That's especially true if an existing method's or standard operator's
behavior is changed.
If we get selector namespaces in ruby 2.0, then mathn can be rewritten
such that users can get floating-point division with / in their
namespace only. Until then I recommend not using mathn.
Thanks for expressing my feelings about this so well!
Regards
robert
···
On Fri, Jun 04, 2004 at 09:48:00AM +0900, Jim Weirich wrote:
Wrote Paul Brannan <pbrannan@atdesk.com>, on Fri, Jun 04, 2004 at 10:59:07PM +0900:
> Robert Klemme wrote:
> Then your code will break whenever it is used in a program that requires
> "mathn". You should always use div if you want integer division.
> The truth is that Ruby's / operator is broken.
I strongly disagree. It is mathn that is broken, not the / operator.
I agree, mathn's / operator is broken, not Ruby's!
I've said it before and I will say it again. Code that changes builtin
classes without a really good reason (YAML is one such example) is
broken. See [ruby-talk:81923] for what I've written in the past on this
subject.
If we get selector namespaces in ruby 2.0, then mathn can be rewritten
such that users can get floating-point division with / in their
namespace only. Until then I recommend not using mathn.
I think that the ability to extend the builtins is amazingly useful, but
I avoid using it in libraries because I can't do scope control.
Can somebody point me to a description, or ruby-talk thread, of how this
"selector" mechanism is going to work? Is it decided? I think its a
very, very interesting idea.
Cheers,
Sam
···
On Fri, Jun 04, 2004 at 09:48:00AM +0900, Jim Weirich wrote:
Paul Brannan <pbrannan@atdesk.com> wrote in message news:<20040604135901.GD2788@atdesk.com>...
I use / all the time to indicate integer division (provided I'm working
with integers). My code will not work with mathn and I have no
intention of going out of my way to uglify my code just to make it
compatible with a broken library.
Then your code is incompatible with the standard libraries and
you should not be writing anything other people will use. The
rational, complex, and matrix libraries need mathn in order
to work properly. In particular, matrix gives dramatically wrong
answers without so much as a warning if you don't include mathn.
The real problem is that mathn should be required automatically,
and it isn't, even when failure to require it gives incontrovertibly
wrong answers. See my previous posts on these issues for examples.
