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 usage significands are much larger than exponents.
It sounds like maybe you actually want to be operating directly on bitPatterns, rather than the abstract fields of the types. – Steve > On Aug 26, 2016, at 7:21 PM, Jens Persson <j...@bitcycle.com> wrote: > > Oh, to more directly answer your question: I don't like having to create a > UInt (UInt64) value when all my bit manipulaton code happens in UInt32 (for > Float) for example. > > The most probable context for using these computed properties and types of > BinaryFloatingPoint is one in which specific fixed width types really matters > a lot (look at the name of the protocol and the properties and assocated > types we are talking about). > > /Jens > > > On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <j...@bitcycle.com > <mailto:j...@bitcycle.com>> wrote: > Reason for asking is that I have this: > > extension Double { > init(unitRangeFromRawSignificand s: RawSignificand) { > let bitPattern = s | (1023 << 52) > self = unsafeBitCast(bitPattern, to: Double.self) - 1.0 > } > } > extension Float { > init(unitRangeFromRawSignificand s: RawSignificand) { > let bitPattern = s | (127 << 23) > self = unsafeBitCast(bitPattern, to: Float.self) - 1.0 > } > } > > But they would be better as: > extension BinaryFloatingPoint { > init(unitRangeFromRawSignificand s: RawSignificand) { > ... problems here, have to try casting things into RawSignificand's > type ... > } > } > > Please have a go at that and perhaps you see what I mean or you will come up > with a nice solution that I have missed. (Speed is very important btw.) > > /Jens > > > On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <sca...@apple.com > <mailto:sca...@apple.com>> wrote: > > On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev > > <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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 just UInt64 and UInt32, resp.? > > Let me flip the question: why would they be UInt64 and UInt32? Absent a > reason to prefer a specific fixed-with type, Swift integers should generally > default to being [U]Int (and ideally Int, but RawExponent is Unsigned). > > – Steve > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
