Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

On Nov 2, 2017, at 7:22 PM, Xiaodi Wu via swift-dev wrote: > On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson > wrote: > >> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev > > wrote: >> >> It looks like we have a good solution.

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 1, 2017, at 12:51 PM, Greg Titus via swift-dev > wrote: > >> On Nov 1, 2017, at 9:16 AM, Ben Cohen via swift-dev >> wrote: >>> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev >>> wrote: >>> On Oct 31, 2017, at

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Replying to the thread as a whole] There have been a bunch of suggestions for variants of `==` that either trap on NaN or return `Bool?`. I think that these suggestions result from people getting tunnel-vision on the idea of “make FloatingPoint equality satisfy desired axioms of Equatable / Co

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 23, 2017, at 1:47 AM, Brent Royal-Gordon via swift-dev > wrote: > >> On Oct 21, 2017, at 6:27 PM, Xiaodi Wu via swift-dev >> wrote: >> >> Steve can describe the exact number of additional machine instructions on >> each architecture, but from my cursory reading the performance cos

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 20, 2017, at 8:21 AM, David Zarzycki via swift-dev > wrote: > >> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev > > wrote: >> >> On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull > > wrote: >> +1 for trapping unless using &==. In the

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 2:55 PM, John McCall via swift-dev > wrote: > >> On Oct 24, 2016, at 8:49 AM, Joe Groff via swift-dev >> wrote: >>> On Oct 22, 2016, at 10:39 AM, Chris Lattner wrote: >>> On Oct 20, 2016, at 2:59 PM, Joe Groff via swift-dev wrote: > > copysign( ) i

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 20, 2016, at 10:04 AM, Joe Groff via swift-dev > wrote: > > >> On Oct 20, 2016, at 9:42 AM, Jordan Rose wrote: >> >> Some disconnected thoughts: >> >> - “Does not interpret” does not mean “does not preserve”. The very next >> sentence in the standard is "Note, however, that operat

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

and s: RawSignificand) { >> self = Self(s) * .ulpOfOne >> } >> } >> >> (this is why I ask if RawSignificand is really the type you want; if you use >> some concrete integer type this will work). But once we have all the new >> integer protocol

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

type you want; if you use > some concrete integer type this will work). But once we have all the new > integer protocol conformances, we’ll have a generic init from any integer > type (this was already reviewed for FloatingPoint, but isn’t implementable > without the Integer supp

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

26, 2016, at 7:47 PM, Stephen Canon via swift-dev > wrote: > > Assuming RawSignificand really is the type you want, I think this does what > you’re looking for? > > protocol BinaryFloatingPointWithBitPattern: BinaryFloatingPoint { > init(bitPattern: RawSignifica

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

{ } extension Double: BinaryFloatingPointWithBitPattern { } extension BinaryFloatingPointWithBitPattern { init(unitRangeFromRawSignificand s: RawSignificand) { self = Self(bitPattern: Self(1).bitPattern | s) - 1 } } > On Aug 26, 2016, at 7:38 PM, Stephen Canon via swift-

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Where does your RawSignificand input come from? Is that really the type that you want? I don’t think you really need very much boilerplate at all here. > On Aug 26, 2016, at 7:30 PM, Jens Persson wrote: > > I understand. > It's just very tempting to try and use the new static computed propert

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

This doesn’t really scale up very well, though. BinaryFloatingPoint needs to also be able to model e.g. Float2048 or similar; we generally don't want to require that RawExponent to be the same type as RawSignificand (which I think is what you’re really suggesting), because in typical bignum usa

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

> On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev > wrote: > > I can understand why > Double.RawSignificand is UInt64 > and > Float.RawSignificand is UInt32 > > But I can't understand why both > Double.RawExponent > and > Float.RawExponent > should be UInt. > > Why aren't they also jus

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

Nadav, can you clarify what we’re really trying to accomplish here? "Smaller binaries” isn’t too important of a goal in and of itself. Are we trying to: – reduce storage used on disk – reduce load time – reduce loaded memory footprint – make emitting swift binaries more efficient – something els

Re: [swift-dev] Starter project: Initializers for converting UnsafePointers to integers

When writing high-performance code, it is fairly common to check the alignment of pointers so that initial elements can be processed until some suitable alignment is reached to use a faster implementation, or to verify that a fast algorithm can be used. > On Dec 8, 2015, at 10:59 AM, Michael Bu