I still absolutely think the best proposal for this is to add a Fraction type to the standard library with easy conversions to and from all the numeric types.
Your precision is only limited by the size of IntMax, and you can do whatever operations you want without losing precision. There’s a great package for it by Jaden Geller on GitHub here: https://github.com/jadengeller/fractional — Harlan > On Mar 21, 2016, at 7:04 AM, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On 20 Mar 2016, at 17:54, Rainer Brockerhoff via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> On 3/20/16 14:43, Andrey Tarantsov via swift-evolution wrote: >>> I have no stake in this proposal, except for: >>> >>>> I suggest, therefore, that this acceptance be indicated by an >>>> annotation to the literal; a form such as ~0.1 might be easiest to >>>> read and implement, as the prefix ~ operator currently has no >>>> meaning for a floating-point value. >>> >>> Whatever you do, don't touch the literals! I specify NSTimeIntervals >>> of 0.1, 0.2, 0.25 etc all over the place, and I couldn't care less if >>> my animations are one femtosecond off. >>> >>> Don't pollute everyone's apps with tildes just because there's a >>> niche that needs to care about precision loss. >> >> Yes, I'm now agreeing that the ideal solution is to leave the whole >> binary floating-point mess alone and write a reasonable `Decimal` type. >> I'll update my text accordingly when I find time. > > The alternative would be to make the Decimal type the default anywhere that > Double or Float isn’t used; while this may be overkill, it shouldn’t impact > performance of most applications. At this point the less-safe but higher > performance types would be opt-in by either specifying the type or using the > tilde operator. > > This could actually expand the definition of the ± on constants to instead > imply “pick the type that can represent this”, so 0.1±0.01 would pick Double, > Float or Decimal as appropriate, favouring the higher performance types only > if they can represent that value without exceeding the allowable error. > > It is a tricky area though, Swift does have a goal of safety so it may be > worth pushing a change that promotes that, even if it means that means a few > changes to get maximum performance back; this could be partly avoided by the > way the change is handled though, providing warnings where the intent is > ambiguous, or assuming performance over safety for existing code? > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
