This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Overloading of /

15 replies
Jann Röder
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.

One thing that has always annoyed me in Java (and other languages,
unfortunately Scala as well) is that the / (division) operator is
overloaded. If both arguments are of type Int, / refers to integer
division, if at least one argument is of a floating point type, then /
refers to regular division.

I find this very unintuitive and I have often produced bugs in my code
because of this. I think / should always be regular division (with
result type float or double) and integer division should use a different
symbol.

I think the logic "Ok division is not generally defined on the integers,
so let's just do something else instead" is inconsistent and therefore
wrong.

What do you think?

Jann

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Overloading of /
I agree. Python had the same problem, and / is now defined in Python 3 to return a float (actually a "double") even if the operands are both integers. That eliminates a potential source of bugs, and that's a good thing as far as I am concerned. When I divide hits by "at bats," I don't want it rounded to zero or one! Actual integer division is rare enough that a special operator or function should be used. Python uses //, but that obviously won't work in Scala.

Russ P.

On Fri, Jul 9, 2010 at 9:53 AM, Jann Röder <roederja [at] ethz [dot] ch> wrote:
One thing that has always annoyed me in Java (and other languages,
unfortunately Scala as well) is that the / (division) operator is
overloaded. If both arguments are of type Int, / refers to integer
division, if at least one argument is of a floating point type, then /
refers to regular division.

I find this very unintuitive and I have often produced bugs in my code
because of this. I think / should always be regular division (with
result type float or double) and integer division should use a different
symbol.

I think the logic "Ok division is not generally defined on the integers,
so let's just do something else instead" is inconsistent and therefore
wrong.

What do you think?

Jann




--
http://RussP.us
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Overloading of /
new Rant {

My personal opinion is that int, float, short, double, long and byte are low-level number optimizations.

IMHO:

integer <- Any integer, encoding is up to the compiler
decimal <- An arbitrary precision fixed point number, encoding is up to the compiler
float and double would reside as some sort of scientific library

I still dont understand why we, at 2010, still have to worry about silent overflow.
Ideally I'd even go for lazy evaluation of arithmetics.

}

On Fri, Jul 9, 2010 at 8:09 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I agree. Python had the same problem, and / is now defined in Python 3 to return a float (actually a "double") even if the operands are both integers. That eliminates a potential source of bugs, and that's a good thing as far as I am concerned. When I divide hits by "at bats," I don't want it rounded to zero or one! Actual integer division is rare enough that a special operator or function should be used. Python uses //, but that obviously won't work in Scala.

Russ P.

On Fri, Jul 9, 2010 at 9:53 AM, Jann Röder <roederja [at] ethz [dot] ch> wrote:
One thing that has always annoyed me in Java (and other languages,
unfortunately Scala as well) is that the / (division) operator is
overloaded. If both arguments are of type Int, / refers to integer
division, if at least one argument is of a floating point type, then /
refers to regular division.

I find this very unintuitive and I have often produced bugs in my code
because of this. I think / should always be regular division (with
result type float or double) and integer division should use a different
symbol.

I think the logic "Ok division is not generally defined on the integers,
so let's just do something else instead" is inconsistent and therefore
wrong.

What do you think?

Jann




--
http://RussP.us



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang
ewilligers
Joined: 2008-08-20,
User offline. Last seen 3 years 17 weeks ago.
Re: Overloading of /

On 10/07/10 02:53, Jann Röder wrote:
> One thing that has always annoyed me in Java (and other languages,
> unfortunately Scala as well) is that the / (division) operator is
> overloaded. If both arguments are of type Int, / refers to integer
> division, if at least one argument is of a floating point type, then /
> refers to regular division.
>
> I find this very unintuitive and I have often produced bugs in my code
> because of this. I think / should always be regular division (with
> result type float or double) and integer division should use a different
> symbol.
>
> I think the logic "Ok division is not generally defined on the integers,
> so let's just do something else instead" is inconsistent and therefore
> wrong.
>
> What do you think?

Discussed by others here:-

http://scala-programming-language.1934581.n4.nabble.com/scala-Number-exp...

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: Re: Overloading of /
Nice discussion, also raises the interesting point of overloading based on return type.Something that the JVM actually supports, and much loved by obfuscators - but probably not the best idea to add as a language feature :)
There's a good use-case for adding Rational types though, and a `div` operator for when integer division really is called for


On 9 July 2010 22:20, Eric Willigers <ewilligers [at] gmail [dot] com> wrote:
On 10/07/10 02:53, Jann Röder wrote:
One thing that has always annoyed me in Java (and other languages,
unfortunately Scala as well) is that the / (division) operator is
overloaded. If both arguments are of type Int, / refers to integer
division, if at least one argument is of a floating point type, then /
refers to regular division.

I find this very unintuitive and I have often produced bugs in my code
because of this. I think / should always be regular division (with
result type float or double) and integer division should use a different
symbol.

I think the logic "Ok division is not generally defined on the integers,
so let's just do something else instead" is inconsistent and therefore
wrong.

What do you think?

Discussed by others here:-

http://scala-programming-language.1934581.n4.nabble.com/scala-Number-explicit-conversion-tp1993817p1993825.html




--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Jann Röder
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Overloading of /

>
> Discussed by others here:-
>
> http://scala-programming-language.1934581.n4.nabble.com/scala-Number-exp...
>

Thanks for pointing that out. It's good to know that Martin knows how it
should be :) I can see why he kept = instead of := for assignments which
would be more in line with mathematical conventions but in the end is
just a notational quirk.

The overloaded / operator however is plain wrong. Giving two different
operators the same name and then use one or the other based on arguments
is the prime example of how overloading should not be used. I hope that
Scala like Python is going to see reason with version 3 and fix this :)
Also since Scala is a compiled language with type checking the impact of
such a change would probably be quite small and easy to find and fix.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: Overloading of /
It depends a lot on what you do, I guess. In my own code, floating point division is usually the wrong thing to do -- but since the code works mostly with integers, that's hardly a problem. Only when I need something that's only defined on Double it shows up.
The problem with such discussions is that there are always two sides to these things, and trying to "fix" the problem will usually lead to one of two things: a worse situation for both sides, or a community split.
Take, for instance, the case of division in Forth. In Forth we are usually talking about integer division. In fact, there's an operator that returns both quotient and remainder. It so happened that integer division was a very big deal for people in Forth -- as operating with integers was fast and gave exact results, neither thing applying to floating point division.
It so happened that one standard, Forth-79, decreed symmetric division, while the following standard, Forth-83, decreed floored division. When time came to produce an ANSI standard, this seemingly silly issue almost derailed the whole effort. In the end, it was decreed that division and modulus operators would be unspecified in this regard, and that whole new operators would be created specifying both symmetric and floored division.
As a side note, ANS Forth doesn't specify numeric representation either: it can be one's complement, two's complement or signed magnitude. See http://lars.nocrew.org/dpans/dpansa3.htm#A.3.2 for a bit more detail, though I couldn't find any of the discussions surrounding the standard.
And here you are worrying that division of one integer by another has a different, well-specified, meaning than division mixing types... :-)

On Fri, Jul 9, 2010 at 7:14 PM, Jann Röder <roederja [at] ethz [dot] ch> wrote:
>
> Discussed by others here:-
>
> http://scala-programming-language.1934581.n4.nabble.com/scala-Number-explicit-conversion-tp1993817p1993825.html
>

Thanks for pointing that out. It's good to know that Martin knows how it
should be :) I can see why he kept = instead of := for assignments which
would be more in line with mathematical conventions but in the end is
just a notational quirk.

The overloaded / operator however is plain wrong. Giving two different
operators the same name and then use one or the other based on arguments
is the prime example of how overloading should not be used. I hope that
Scala like Python is going to see reason with version 3 and fix this :)
Also since Scala is a compiled language with type checking the impact of
such a change would probably be quite small and easy to find and fix.




--
Daniel C. Sobral

I travel to the future all the time.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Re: Overloading of /
I haven't done a study, but my guess is that truncated integer division is needed in programming far less than "regular" integer division that results in a real number. It seems to me, therefore, that the exception should not define the rule, especially considering that using / for truncated integer division can lead to subtle bugs that are difficult to detect and find.

I see that Martin O. agrees with that assessment, but he doesn't consider it a "battle worth fighting." Maybe when Scala becomes more widely used he'll re-evaluate that position.

I also see that Martin wanted to use := for assignment, but he decided not to fight that battle either. I for one am very glad that he chose not to fight that one! I tried to convince Ada folks years ago that := was a blemish on the language. I read somewhere that the guy who originated the use of := for assignment really wanted <=, but his ancient keyboard did not have a < key!

As for Forth, I went through a phase many years ago in which I was interested in it. I did a lot of reading about it, but I never used it much. I'd be surprised if it is still used much -- but then it wouldn't be the first time I've been surprised. Isn't it more or less a "write-only" language (i.e., unreadable)?

Russ P.

On Fri, Jul 9, 2010 at 4:18 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
It depends a lot on what you do, I guess. In my own code, floating point division is usually the wrong thing to do -- but since the code works mostly with integers, that's hardly a problem. Only when I need something that's only defined on Double it shows up.
The problem with such discussions is that there are always two sides to these things, and trying to "fix" the problem will usually lead to one of two things: a worse situation for both sides, or a community split.
Take, for instance, the case of division in Forth. In Forth we are usually talking about integer division. In fact, there's an operator that returns both quotient and remainder. It so happened that integer division was a very big deal for people in Forth -- as operating with integers was fast and gave exact results, neither thing applying to floating point division.
It so happened that one standard, Forth-79, decreed symmetric division, while the following standard, Forth-83, decreed floored division. When time came to produce an ANSI standard, this seemingly silly issue almost derailed the whole effort. In the end, it was decreed that division and modulus operators would be unspecified in this regard, and that whole new operators would be created specifying both symmetric and floored division.
As a side note, ANS Forth doesn't specify numeric representation either: it can be one's complement, two's complement or signed magnitude. See http://lars.nocrew.org/dpans/dpansa3.htm#A.3.2 for a bit more detail, though I couldn't find any of the discussions surrounding the standard.
And here you are worrying that division of one integer by another has a different, well-specified, meaning than division mixing types... :-)

On Fri, Jul 9, 2010 at 7:14 PM, Jann Röder <roederja [at] ethz [dot] ch> wrote:
>
> Discussed by others here:-
>
> http://scala-programming-language.1934581.n4.nabble.com/scala-Number-explicit-conversion-tp1993817p1993825.html
>

Thanks for pointing that out. It's good to know that Martin knows how it
should be :) I can see why he kept = instead of := for assignments which
would be more in line with mathematical conventions but in the end is
just a notational quirk.

The overloaded / operator however is plain wrong. Giving two different
operators the same name and then use one or the other based on arguments
is the prime example of how overloading should not be used. I hope that
Scala like Python is going to see reason with version 3 and fix this :)
Also since Scala is a compiled language with type checking the impact of
such a change would probably be quite small and easy to find and fix.




--
Daniel C. Sobral

I travel to the future all the time.



--
http://RussP.us
Raoul Duke
Joined: 2009-01-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Overloading of /

On Fri, Jul 9, 2010 at 5:22 PM, Russ Paielli wrote:
> I also see that Martin wanted to use := for assignment, but he decided not
> to fight that battle either. I for one am very glad that he chose not to
> fight that one! I tried to convince Ada folks years ago that := was a

yeah, well... while some folks in ppig (http://www.ppig.org/) disagree
with me (perhaps it is just semantics, haven't figured that out), i
think usability is tremendously subjective. i for one would rather use
:= for assignment!

sincerely.

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Overloading of /

On Friday July 9 2010, Jann Röder wrote:
> ...
>
> I think the logic "Ok division is not generally defined on the
> integers, so let's just do something else instead" is inconsistent
> and therefore wrong.

Division is certainly defined on the integers, it's just that the
integers are not closed under division.

> What do you think?

I think it is of no consequence 'cause it's far to late to change it in
Scala or any other extant programming language.

> Jann

Randall Schulz

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Overloading of /

I think it is of no consequence 'cause it's far to late to change it in
Scala or any other extant programming language.


I disagree. Python made the change. You just need to provide a sufficient transition period with an alternative operator or function for truncated integer division. In other words, you just need to "deprecate" the use of / for truncated integer division. Then, when the change is finally made, you need to highlight it very prominently, with flashing neon lights. You could even provide a compiler option to warn when / is used to divide one integer by another. In the end, you may create a few bugs, but you'll eliminate far more than you create. And you'll free up developer's minds to think about more important things.

Russ P.
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: Overloading of /
As I said, it depends on what you do. In my years as a developers with FreeBSD, I can't say I recall ever having used anything other than integer division.

On Fri, Jul 9, 2010 at 9:22 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I haven't done a study, but my guess is that truncated integer division is needed in programming far less than "regular" integer division that results in a real number. It seems to me, therefore, that the exception should not define the rule, especially considering that using / for truncated integer division can lead to subtle bugs that are difficult to detect and find.

I see that Martin O. agrees with that assessment, but he doesn't consider it a "battle worth fighting." Maybe when Scala becomes more widely used he'll re-evaluate that position.

I also see that Martin wanted to use := for assignment, but he decided not to fight that battle either. I for one am very glad that he chose not to fight that one! I tried to convince Ada folks years ago that := was a blemish on the language. I read somewhere that the guy who originated the use of := for assignment really wanted <=, but his ancient keyboard did not have a < key!

As for Forth, I went through a phase many years ago in which I was interested in it. I did a lot of reading about it, but I never used it much. I'd be surprised if it is still used much -- but then it wouldn't be the first time I've been surprised. Isn't it more or less a "write-only" language (i.e., unreadable)?

Russ P.

On Fri, Jul 9, 2010 at 4:18 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
It depends a lot on what you do, I guess. In my own code, floating point division is usually the wrong thing to do -- but since the code works mostly with integers, that's hardly a problem. Only when I need something that's only defined on Double it shows up.
The problem with such discussions is that there are always two sides to these things, and trying to "fix" the problem will usually lead to one of two things: a worse situation for both sides, or a community split.
Take, for instance, the case of division in Forth. In Forth we are usually talking about integer division. In fact, there's an operator that returns both quotient and remainder. It so happened that integer division was a very big deal for people in Forth -- as operating with integers was fast and gave exact results, neither thing applying to floating point division.
It so happened that one standard, Forth-79, decreed symmetric division, while the following standard, Forth-83, decreed floored division. When time came to produce an ANSI standard, this seemingly silly issue almost derailed the whole effort. In the end, it was decreed that division and modulus operators would be unspecified in this regard, and that whole new operators would be created specifying both symmetric and floored division.
As a side note, ANS Forth doesn't specify numeric representation either: it can be one's complement, two's complement or signed magnitude. See http://lars.nocrew.org/dpans/dpansa3.htm#A.3.2 for a bit more detail, though I couldn't find any of the discussions surrounding the standard.
And here you are worrying that division of one integer by another has a different, well-specified, meaning than division mixing types... :-)

On Fri, Jul 9, 2010 at 7:14 PM, Jann Röder <roederja [at] ethz [dot] ch> wrote:
>
> Discussed by others here:-
>
> http://scala-programming-language.1934581.n4.nabble.com/scala-Number-explicit-conversion-tp1993817p1993825.html
>

Thanks for pointing that out. It's good to know that Martin knows how it
should be :) I can see why he kept = instead of := for assignments which
would be more in line with mathematical conventions but in the end is
just a notational quirk.

The overloaded / operator however is plain wrong. Giving two different
operators the same name and then use one or the other based on arguments
is the prime example of how overloading should not be used. I hope that
Scala like Python is going to see reason with version 3 and fix this :)
Also since Scala is a compiled language with type checking the impact of
such a change would probably be quite small and easy to find and fix.




--
Daniel C. Sobral

I travel to the future all the time.



--
http://RussP.us



--
Daniel C. Sobral

I travel to the future all the time.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Re: Overloading of /
On Fri, Jul 9, 2010 at 7:57 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
As I said, it depends on what you do. In my years as a developers with FreeBSD, I can't say I recall ever having used anything other than integer division.


I'm guessing that's a difference between system-level programming and application programming.

Russ P.

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: Overloading of /

This is exactly the sort of thing that a static analysis tool could
flag, for those that are worried about it. It could be implemented as
a compiler plugin.

-jason

On Sat, Jul 10, 2010 at 3:42 AM, Russ Paielli wrote:
>
>> I think it is of no consequence 'cause it's far to late to change it in
>> Scala or any other extant programming language.
>>
>
> I disagree. Python made the change. You just need to provide a sufficient
> transition period with an alternative operator or function for truncated
> integer division. In other words, you just need to "deprecate" the use of /
> for truncated integer division. Then, when the change is finally made, you
> need to highlight it very prominently, with flashing neon lights. You could
> even provide a compiler option to warn when / is used to divide one integer
> by another. In the end, you may create a few bugs, but you'll eliminate far
> more than you create. And you'll free up developer's minds to think about
> more important things.
>
> Russ P.
>

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: Overloading of /
Interesting thought here...
Could we introduce the div and mod operators,  then deprecate / on integers from now until the end of time?


On 10 July 2010 07:04, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
This is exactly the sort of thing that a static analysis tool could
flag, for those that are worried about it. It could be implemented as
a compiler plugin.

-jason

On Sat, Jul 10, 2010 at 3:42 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
>
>> I think it is of no consequence 'cause it's far to late to change it in
>> Scala or any other extant programming language.
>>
>
> I disagree. Python made the change. You just need to provide a sufficient
> transition period with an alternative operator or function for truncated
> integer division. In other words, you just need to "deprecate" the use of /
> for truncated integer division. Then, when the change is finally made, you
> need to highlight it very prominently, with flashing neon lights. You could
> even provide a compiler option to warn when / is used to divide one integer
> by another. In the end, you may create a few bugs, but you'll eliminate far
> more than you create. And you'll free up developer's minds to think about
> more important things.
>
> Russ P.
>



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Jann Röder
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Overloading of /

>> I think the logic "Ok division is not generally defined on the
>> integers, so let's just do something else instead" is inconsistent
>> and therefore wrong.
>
> Division is certainly defined on the integers, it's just that the
> integers are not closed under division.

Ok sorry for the inaccurate wording here.

>> What do you think?
>
> I think it is of no consequence 'cause it's far to late to change it in
> Scala or any other extant programming language.

Well, at least one could introduce additional operators that always do
the same thing (for example div would always do truncated division and
maybe fdiv would always do normal division).

The main point is not whether truncated division or regular division is
more common in practice, the point is, that an operator should always do
the same thing regardless of the exact type of its arguments. I would
not care if / were always truncated division.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland