[ruby-core:108051] [Ruby master Feature#18179] Add Math methods to Numeric

Issue #18179 has been updated by Eregon (Benoit Daloze).


Out of all Math methods:
```
  acos, acosh, asin, asinh, atan, atan2, atanh, cbrt, cos, cosh, erf,
  erfc, exp, frexp, gamma, hypot, ldexp, lgamma, log, log10, log2, sin,
  sinh, sqrt, tan, tanh
```
I think for me only sqrt would maybe feel natural as `num.sqrt`.

We already have `Integer.sqrt` (but no `#sqrt`), so that might be confusing.
`Math` always deals with Float numbers, so that's consistent, but having it on numeric is less clear, should `5.sqrt` be `2` (like `Integer.sqrt`) or `2.23606797749979` (like `Math.sqrt`)?
It's also not clear what should be `Rational(a, b).sqrt`, a Float, a Rational? The point of Rational is to be exact, converting to Float somewhat implicitly doesn't seem good.

At least I feel `num.sin`, `num.cos`, `num.acos`, `num.cosh`, etc, all look weird.
I would think many people would generally agree to that, but maybe I'm wrong.

`Math.hypot` seems also a good example why that should not be an instance method, because it takes two arguments as equal, there is no "receiver" and "operand" distinction.

---

Moving these methods to `Float` (instead of `Numeric`) would at least make it clear they use Float operands and return a Float, and sounds like a better change to me.
That would mean `integer.to_f.sqrt` if one wants the Float square root of an integer.

It seems Rust defines most of the Ruby Math methods on f64 (https://doc.rust-lang.org/std/primitive.f64.html) and much less (e.g., no sqrt) on i64 (https://doc.rust-lang.org/std/primitive.i64.html).

----------------------------------------
Feature #18179: Add Math methods to Numeric
https://bugs.ruby-lang.org/issues/18179#change-97013

* Author: ankane (Andrew Kane)
* Status: Open
* Priority: Normal
----------------------------------------
Hi, I wanted to get thoughts on adding class methods from `Math` as instance methods on `Numeric`.

```ruby
x.sqrt # vs Math.sqrt(x)
x.log  # vs Math.log(x)
```

Rust takes this approach and it (subjectively) feels more intuitive/object-oriented. It also seems more consistent with methods like `x.abs`.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>