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

[Stephen Canon]

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 <jens at 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 <jens at bitcycle.com <mailto:jens at 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 <scanon at apple.com <mailto:scanon at apple.com>> wrote:
> > On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160826/6b173a55/attachment.html>