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

[Stephen Canon]

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 <jens at 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 <scanon at apple.com <mailto:scanon at 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 <jens at bitcycle.com <mailto: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/7c28a94e/attachment.html>