Project

General

Profile

Bug #14350

Strange behavior for Array.min in ruby 2.5.0

Added by artofhuman (Semyon Pupkov) 8 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:86789]

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

Associated revisions

Revision 83ac2dfe
Added by nobu (Nobuyoshi Nakada) 8 months ago

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. [Bug #14350]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61766 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 61766
Added by nobu (Nobuyoshi Nakada) 8 months ago

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. [Bug #14350]

Revision 61cb2958
Added by nagachika (Tomoyuki Chikanaga) about 2 months ago

merge revision(s) 61766: [Backport #14350]

    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.
       [Bug #14350]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_5@64195 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 64195
Added by nagachika (Tomoyuki Chikanaga) about 2 months ago

merge revision(s) 61766: [Backport #14350]

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.
   [Bug #14350]

History

#1 Updated by artofhuman (Semyon Pupkov) 8 months ago

  • Description updated (diff)

#2 [ruby-core:84823] Updated by shyouhei (Shyouhei Urabe) 8 months ago

I doubt if this behavioural change is a bug that should be fixed.

#3 [ruby-core:84827] Updated by nobu (Nobuyoshi Nakada) 8 months ago

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.

#4 Updated by nobu (Nobuyoshi Nakada) 8 months ago

  • 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. [Bug #14350]

#5 [ruby-core:86724] Updated by cheba (Alexander Mankuta) 5 months ago

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.

#6 Updated by nobu (Nobuyoshi Nakada) 5 months ago

  • Backport changed from 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN to 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED

#7 [ruby-core:88291] Updated by nagachika (Tomoyuki Chikanaga) about 2 months ago

  • 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