Make `/` be float division

[asterite]

Similar to Python 3, we could have / return a float, and add another operator, maybe // (though that means an empty regex right now, but we could alternatively use %r() for that).

So:

# Now
1 / 2 # => 0

# With this change
1 / 2  # => 0.5
1 // 2 # => 0

I'm not 100% sure about this, mainly because:

• what type should the result be? Float64?
• x /= 2 changes the type of x, while previously it doesn't, but one could use x //= 2 now

I'm cc-ing @pbrusco because he originally proposed this :-)

Thoughts?

[Nephos]

Hello,
Usually I take care of my number's type, so I don't think adding a new operator like this one is useful.
Furthermore, Ruby does not provide such operator. I hope Crystal will stay close to Ruby and away from python ;)

Is a new operator very efficient against a cast (to_f64) ?
If yes, maybe adding a new operator can be useful, but why changing "/" ?

Plus, php do that. Do you really want to do something like php ?

[pbrusco]

Of course I agree on changing, keeping an ambiguous division causes lots of headaches. I've seen people struggling with results and then finding out that in that language. I'm sure that division related bugs are everywhere and I think this is the way to avoid them.

If performance is needed => //
If precision is needed => something else (a method)

@Nephos, I think crystal will be better than ruby, but it needs the "right" division :P

Here are the reasons (in the context of python): https://www.python.org/dev/peps/pep-0238/.

@asterite, Thanks you for opening the discussion

[bcardiff]

In crystal the user can have fine control of the numerical types. But when receiving just a number, might not be clear.

Having / to be floating point division, and // been the floor of the division would mean to have a unified semantic of the operation despite the numerical types. This favor more concistency IMO.

As for the type, Float64 by default sounds reasonable, unless Float32 is involved and no Float64. I think that will honor f32 operations for when the user cares.

[ozra]

You mean something like:?

F32#/(Number) -> F32
Number#/(Number) -> F64

[asterite]

I think the PEP has one very good reason to do this:

def average(elements)
  elements.sum / elements.size
end

The average should be a float, but this might give an integer back. We can solve this using fdiv:

def average(elements)
  elements.sum.fdiv(elements.size)
end

So right now we have:

• / is "floor division" or "float division", depending on the type of the first argument
• fdiv is always `"float division"

I think that's the main problem: that / has two meanings, depending on the type of the first argument. We could make it so that:

• / always means "float division"
• // always means "floor division"
• fdiv is removed from the language

I was initially against this change, but @pbrusco insisted so much I decided to open an issue. After considering it for a while I'm starting to like it. But then I thought "Hm, I'm sure this will break a lot of code, as / is probably used in the standard library for "floor division" in many places". Well, I searched and it turns out that floor division is needed in very few places, and in most places a .0 is added to the divisor, or an explicit to_f is used on either operands. It also happened to me that when seeing x / 3 in some places I wondered "Hm, is this intention here to do a "float division" or a "floor division"? One then has to trace back the type of x to know.

In summary, "floor division" is needed, but there's no reason to have / mean two things, we can have two operators with very clear semantics.

So now I'm very open to make this change :-)

[ysbaddaden]

I never heard of // ... to me that's a line comment, whatever the language :-/

[asterite]

Python, Elm and Lua have this operator.

Additionally, Visual Basic has it as a backslash.

We could choose another character combination, maybe /., but I think // is the most common and looks best, at least in non-C languages.

[ozra]

As I remember (it's been decades...) pascal used / : R, div : Z, and can't-remember-which-language-back-then used / : R, \ : Z. Anyway, it's not an entirely uncommon feature. And I must say the Python // does make some sense

[ozra]

Haha, there it was, VB.

[Nephos]

Python, Elm and Lua have this operator.

This is not a good thing to me.

In Ruby, someone making the mistake when using / instead of fdiv ou / + to_f just uses the wrong language.
When you do use a language like Python, you write / or //.
When you use C++, you write a cast.
If not, you must go back to the documentation. This is not an error of the language, just yours.

However, adding a method /. seems more expressive (to me) than force the fdiv with /.

[refi64]

I'm +100 on this. Implicit integer division should die a slow, painful death. I cannot count how many times bugs related to this have screwed me over in C++.

[bcardiff]

@ozra
I mean

F32#/(F64) -> F64
F32#/(Number*) -> F32

F64#/(F32) -> F64
Number*#/(F32) -> F32

Number#/(Number) -> F64

Number* will be any number but F64 due to order of the rules.