[swift-evolution] [pitch] Comparison Reform

[Jonathan Hull]

Agreed.  I think the first step if we are interested in unums is to make a 3rd party library. (There are apparently chips already in the pipeline, but it won’t affect iOS or Macs, which are the main targets for Swift.)

That said, whether the implementation is based on unums or not, I would really like to see Swift 5/6 move towards having a core floating point type which abstracts away most of the legacy issues.  It is crazy to me that we are continuing to bake-in issues based on the limitations of 1980’s tech.  

Ideally, there would be a “Float” or “Decimal" type that would Just Work™ for typical / everyday calculations involving decimals (as an analog to Int which just works for integer calculations, but doesn’t guarantee a specific precision), and then various specific formats for people who need specific guarantees (like IEEE conformance or a specific precision).  This would replace things like CGFloat and most uses of Float/Double.  It should be abstract enough that we could change the internal implementation as needed (or even to have various implementations ala CGFloat).  It should not even mess with things like NaN and infinity, leaving those concepts to the specific formats (and using optionals, trapping, or swift error handling when operations can fail).

Thanks,
Jon

> On Apr 27, 2017, at 5:46 PM, Stephen Canon <scanon at apple.com> wrote:
> 
> On Apr 27, 2017, at 7:35 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I doubt we would get rid of Double/Float, but I would love to see it used as a core type in Swift 5.
> 
> Not to be discouraging, but Swift 5 is wildly ambitious for the inclusion of unum in the stdlib core. Unums will be multiple orders of magnitude slower (and more importantly, less energy efficient) than Float or Double for the foreseeable future, due to the complete lack of hardware support. Hardware can be designed, but no one’s doing it yet, and the timeline from “functional unit is proposed” to “working hardware appears” is around 3-5 years *minimum*. For a large feature without any real precedent, tack on a couple more years. Then you have another 3-5 years before the feature is widely available on a majority of machines in the field.
> 
> For that matter, the actual definition of what “unums” are keeps changing. It wouldn’t make sense to put them in the stdlib until the definitions stabilize. Meanwhile we don’t even have bignum integers or complex numbers in the stdlib yet. There’s lots of lower-hanging fruit with a much wider audience to sort out while we wait to see what happens with unum.
> 
> If you want to explore unums, I encourage you to do so. I think it would be great for someone to throw a Swift unum library up on GitHub for people to try out. There’s just a whole lot of stuff that should happen before it becomes part of the stdlib.
> 
> – Steve

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