[swift-evolution] Expanded support for numeric types in stdlib?

[Vinicius Vendramini]

If Swift’s Ints may go up to 2048 bits, I’d agree that they probably cover most cases. That’s not to say a big int would be useless, just that I think it should be separate, meant to be used by those who actually need it rather than interfering with normal Int logic, which is likely to be used more often.

> On Dec 4, 2015, at 2:45 AM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> 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 <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 <mailto:kevin at sb.org>> wrote:
> On Dec 3, 2015, at 9:48 PM, Dmitri Gribenko <gribozavr at gmail.com <mailto: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
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/b930887b/attachment.html>