[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
matz@ruby-lang.org wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85577] [Ruby trunk Feature#14362] use BigDecimal instead of Float by default
From:
aaron.lasseigne@...
Date:
2018-02-15 04:04:24 UTC
List:
ruby-core #85577
Issue #14362 has been updated by AaronLasseigne (Aaron Lasseigne).
yugui,
> Why do you think they are not familiar with floating-point values like IEEE754?
In my experience, most developers are not intimately familiar with the details of floating point implementations. I have witnessed a number of developers who were surprised by the result of what they though was a straight forward calculation (like my example).
> If it is a matter of degree, why do you think it is more predictable than 129.95*100 != 129.95e2 that 1/n*n == 1 depends on the size of n?
I do think it's a matter of degree. I understand that `BigDecimal` isn't perfect but I think it's worth discussing whether it's better than `Float` or not. I feel like having to remember that each calculation results in a single stored number and that infinitely long answers (e.g. 1/3) can't be properly stored is easy to remember. Remembering which numbers can and cannot be represented by IEEE754 is much harder. To me, the limitations of `BigDecimal` seem easier to reason about than the quirks of `Float`.
> In my opinion, consistency is more important for predictability and less surprise.
I'll admit that my knowledge of `BigDecimal` is limited. Are there consistency issues across platforms? I'll agree that inconsistent results like that might be a big negative to switching.
mrkn,
> And the current BigDecimal is not better than Rational for representing rational numbers because it has problems in its precision handling by the historical reason, which I'm working to fix.
>
> I recommend using BigDecimal only for the case that needs to represent decimal numbers with the finite number of digits exactly.
This ticket is not suggesting a switch to `Rational` or claiming that `BigDecimal` is superior to `Rational`. I certainly acknowledge that `BigDecimal` has limitations. The question is only whether it's an improvement over `Float`.
> As a maintainer of BigDecimal, I don't agree with you about BigDecimal is more developer friendly than Float.
Can you explain why? Are there limitations that make it a poor replacement?
----------------------------------------
Feature #14362: use BigDecimal instead of Float by default
https://bugs.ruby-lang.org/issues/14362#change-70369
* Author: AaronLasseigne (Aaron Lasseigne)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
When writing a decimal the default type assigned is `Float`:
```ruby
> 1.2.class
=> Float
```
This is great for memory savings and for application speed but it comes with accuracy issues:
```ruby
> 129.95 * 100
=> 12994.999999999998
```
Ruby's own `BigDecimal` docs say:
> Decimal arithmetic is also useful for general calculation, because it provides the correct answers people expect窶努hereas normal binary floating point arithmetic often introduces subtle errors because of the conversion between base 10 and base 2.
What if `BigDecimal` was moved into the Ruby core and made the default for numbers like `1.2`?
```ruby
> 1.2.class
=> BigDecimal
```
I realize this goes against the 3x3 goal but I think `BigDecimal` is preferable over `Float` for developer happiness. I've seen lots of developers stumble when first learning about the pitfalls of `Float`. I've see test suites where a range is tested for because of answers like `12994.999999999998` instead of `12995.0`. At one point trading accuracy for performance made sense. I'm not sure that's still the case today.
Right now a decimal generates the faster and less accurate `Float`. Developers have to opt-in to the slower but safer `BigDecimal` by manually requesting a `BigDecimal`. By flipping this we default to the safer version and ask developers to opt-in to the faster but less accurate `Float` if needed.
```ruby
> 1.2.class
=> Decimal
> Float.new('1.2')
=> 1.2
```
There could also be a shorthand for float where the number is followed by an `f` (similar to Rational).
```ruby
1.2f # => Float
```
The change would help "provide the correct answers people expect". The change would be mostly seamless from an interface standpoint. The only methods on `Float` and not on `BigDecimal` appear to be `rationalize`, `next_float`, and `prev_float`. I suspect those methods are rarely used. The increased accuracy seems unlikely to cause code issues for people.
The two largest downsides that I can come up with are speed and display. I'm not sure what kind of hit is taken by handling all decimals as `BigDecimal`. Would an average Rails application see a large hit? Additionally, the display value of `BigDecimal` is engineering notation. This is also the default produced by `to_s`. It's harder to read and might mess up code by displaying things like "0.125e2" instead of "12.5". Certainly the default produced by `to_s` could change to the conventional floating point notation.
A change this significant would likely target Ruby 3 so there would be time to make some changes like adding a `BigDecimal#rationalize` method or changing the default output of `BigDecimal#to_s`.
Thank you for considering this.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>