Correction " ... a protocol that only Double and Float conforms to ...".
On Sat, Aug 27, 2016 at 1:30 AM, 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> 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> 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> 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> wrote:
>>>
>>>> > On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <
>>>> 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
