Bug #14350
closed
Strange behavior for Array.min in ruby 2.5.0
Added by artofhuman (Semyon Pupkov) almost 7 years ago.
Updated over 6 years ago.
Description
2.4.2
[[1, 0.0].max, 1.0].min
=> 1
2.5.0
[[1, 0.0].max, 1.0].min
=> 1.0
[[1, 0.0].max, 1.0]
=> [1, 1.0]
[1, 1.0].min
=> 1
I think it`s regression for ruby 2.5.0
- Description updated (diff)
I doubt if this behavioural change is a bug that should be fixed.
1
is not greater than 1.0
, and vice versa.
The both results are correct in this case.
But the previous behavior may be better in the case of Numeric
-like objects.
- Status changed from Open to Closed
Applied in changeset trunk|r61766.
vm_insnhelper.c: search in the indexing order
- vm_insnhelper.c (vm_opt_newarray_max, vm_opt_newarray_min):
search in the indexing order, as well as usual methods.
[ruby-core:84821] [Bug #14350]
This change afects PrawnPDF gems (I'm a maintainer).
From the maths point of view it is indeed insignificant, but there are other areas where exact value matters. For example, in Prawn these values are serialized. Integer 1
is serialized to a 1-byte string "1"
and Float 1.0
is serialized to 3-byte string "1.0"
. While in the context of PDF there's no difference between the values we don't want to change generated documents. PDF is hard to inspect for changes because it's essentially a binary format and a relatively complex one. Most our users rely on binary stability of output for caching purposes and we strive to make the output stable.
With this change we can not provide the stability between Ruby versions. We use it in our test suite among other things.
- Backport changed from 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN to 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED
- Backport changed from 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED to 2.3: DONTNEED, 2.4: DONTNEED, 2.5: DONE
ruby_2_5 r64195 merged revision(s) 61766.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0