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 <j...@bitcycle.com> wrote: > > I understand. > It's just very tempting to try and use the new static computed properties for > eg 23 and 52 etc. > I guess I'll just have to write a lot of boilerplate, or perhaps a protocol > that is just implemented by Double and Float (that will be very similar to > BinaryFloatingPoint in a lot of ways). > /Jens > > On Sat, Aug 27, 2016 at 1:25 AM, Stephen Canon <sca...@apple.com > <mailto:sca...@apple.com>> wrote: > 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 >> <mailto: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
