[swift-evolution] Expanded support for numeric types in stdlib?
Austin Zheng
austinzheng at gmail.com
Fri Dec 4 01:45:41 CST 2015
Clojure also performs automatic reduction of rational numbers. However, the
source code seems to indicate that reduction is built into the definitions
of the methods that perform arithmetic on rational numbers, and the "Ratio"
class that implements rational number support does not do any reduction
itself.
(c.f.
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java,
ll. 350-364, 704-727, et al)
>From a semantic standpoint, I would be very surprised if e.g. 2/6 and 1/3
were not considered equal, or for that matter if they weren't completely
interchangeable.
- Austin
On Thu, Dec 3, 2015 at 11:21 PM, Kevin Ballard <kevin at sb.org> wrote:
> On Dec 3, 2015, at 9:48 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> >
> >> A good invariant for Rationals might be having them always
> >> represented in the most simplified form - for example, Rational(2, 6)
> should
> >> be represented internally as 1/3 when constructed.
> >
> > This has performance tradeoffs. What do other libraries and languages
> do?
>
> I know Haskell always reduces Rationals to their reduced form. This does
> have performance implications, but not doing so has surprising consequences
> for operations you perform on them. For example, it’s reasonable to expect
> that Rational(2,6) == Rational(1,3), but implementing that without reduced
> Rationals pretty much requires reducing them on the fly. The alternative,
> of saying they’re not equal, would probably surprise most people.
>
> -Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151203/d4edb0e8/attachment.html>
More information about the swift-evolution
mailing list