Join GitHub today
Arithmetic division for all types #8120
Note: Final behavior described at #8120 (comment)
This PR makes
1 / 2 # => 0.5
As a reminder, for integer or floor division
1 // 2 # => 0
Given a binary operator
There are 17 "numeric" types in the stdlib:
All the combinations can be viewed in the following table:
Note: I checked if
I have a couple of leftovers or further thoughts after these changes:
I tried to avoid changing as less as possible, but there is still some work to do in order to get some neat implementation. But for now is an improvement and I needed to fill some missing gaps in
I disagree here. We should use
Oops, my brain must have default it to Float32 like Int32.
I'm not sure. It is convenient to have a proper implementation of
If we make
Would that be comfortable enough?
What's the difference between how
I think so.
def //(other) self.fdiv(other).floor end
Also, in this pr
Ooooh... sorry, I got confused. I meant to ask the difference between
But then to keep the typing rule symmetrical there are some operations that will not fit:
1f32 / UInt128::MAX ≈ 2.938e-39 < 1.175e-38 ≈ Float32::MIN_POSITIVE
It also bugs me a little that if Int / Float32 is Float32, then the typing rule formulation is a bit more complex, but is paperwork on the formality side. I will leave on the side.
@bcardiff the same reasoning applies to all other binary operations with a Float32. Lower precision means that the value will be rounded, so
I don't understand why
There are use cases where we want lower precision. While documenting on alternative float sizes (16, 80 an 128-bit) I read that AI / ML algorithms sometimes cast to Float16 to specifically lose precision, which reduces memory usage, but also improves results: AI behaves better with blurry results, being too precise is counter productive.
@ysbaddaden yes I recall the same use cases even losing some precision.
For native types:
with that, the table will look like follows
Separating native types and extensions seem needed because otherwise Float64 * BigInt would've been Float64 according to the rules for native types, instead of BigFloat which I think is preferred.