From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 634B71F5AE for ; Thu, 16 Jul 2020 17:17:53 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CDD9A120A8F; Fri, 17 Jul 2020 02:17:20 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 02793120A8C for ; Fri, 17 Jul 2020 02:17:17 +0900 (JST) Received: by filterdrecv-p3mdw1-75c584b9c6-xjd6c with SMTP id filterdrecv-p3mdw1-75c584b9c6-xjd6c-20-5F108BB8-41 2020-07-16 17:17:44.74833587 +0000 UTC m=+1728486.721026624 Received: from herokuapp.com (unknown) by geopod-ismtpd-6-3 (SG) with ESMTP id PYj9_7bRSuiZVxkQxpVfpg for ; Thu, 16 Jul 2020 17:17:44.674 +0000 (UTC) Date: Thu, 16 Jul 2020 17:17:44 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 74983 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17017 X-Redmine-Issue-Author: sambostock X-Redmine-Sender: jeremyevans0 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BI+8D2yIv56U34wIJts1U1u1jrqyzbtl7mAxaLd?= =?us-ascii?Q?XP+wN1GIj4QyzhS5BrQYBEsetnA6KGAuGcf4hCT?= =?us-ascii?Q?OqtTiz195VQZm6viKRPL1b+Qkf60az5MyxpQWVX?= =?us-ascii?Q?QJCWB+Jd2zFygN49Ehou9oyCGiPFsUTl0rNKe8y?= =?us-ascii?Q?BEvq+iplKguCvFcr8=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99194 Subject: [ruby-core:99194] [Ruby master Bug#17017] Range#max & Range#minmax incorrectly use Float end as max X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #17017 has been updated by jeremyevans0 (Jeremy Evans). I've added a pull request to restore compatibility for Range#max with integer beginning and Float::Infinity end: https://github.com/ruby/ruby/pull/3326 I think this pull request should require matz approval because it is a deliberate tradeoff of correctness in order to keep compatibility. The correct behavior should be raising RangeError, as that is what an endless range returns. If you would like matz to consider it, please bring it up for discussion at a future Ruby developers meeting. ---------------------------------------- Bug #17017: Range#max & Range#minmax incorrectly use Float end as max https://bugs.ruby-lang.org/issues/17017#change-86574 * Author: sambostock (Sam Bostock) * Status: Open * Priority: Normal * ruby -v: ruby 2.8.0dev (2020-07-14T04:19:55Z master e60cd14d85) [x86_64-darwin17] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- While continuing to add edge cases to [`Range#minmax` specs](https://github.com/ruby/spec/pull/777), I discovered the following bug: ```ruby (1..3.1).to_a == [1, 2, 3] # As expected (1..3.1).to_a.max == 3 # As expected (1..3.1).to_a.minmax == [1, 3] # As expected (1..3.1).max == 3.1 # Should be 3, as above (1..3.1).minmax == [1, 3.1] # Should be [1, 3], as above ``` One way to detect this scenario might be to do (whatever the C equivalent is of) ```ruby range_end.is_a?(Numeric) // Is this a numeric range? && (range_end - range_begin).modulo(1) == 0 // Can we reach the range_end using the standard step size (1) ``` As for how to handle it, a couple options come to mind: - We could error out and do something similar to what we do for exclusive ranges ```ruby raise TypeError, 'cannot exclude non Integer end value' ``` - We might be able to calculate the range end by doing something like ```ruby num_steps = (range_end / range_beg).to_i - 1 # one fewer steps than would exceed the range_end max = range_beg + num_steps # take that many steps all at once ``` - We could delegate to `super` and enumerate the range to find the max ```ruby super ``` - We could update the documentation to define the max for this case as the `range_end`, similarly to how the documentation for `include?` says it behaves like `cover?` for numeric ranges. -- https://bugs.ruby-lang.org/