If BinaryFloatingPoint had init(_: RawSignificand), you could also
just write:
extension BinaryFloatingPoint {
init(unitRangeFromRawSignificand s: RawSignificand) {
self = Self(s) * .ulpOfOne
}
}
(this is why I ask if RawSignificand is really the type you want; if
you use some concrete integer type this will work). But once we have all
the new integer protocol conformances, we’ll have a generic init from any
integer type (this was already reviewed for FloatingPoint, but isn’t
implementable without the Integer support), which will also make this
possible.
On Aug 26, 2016, at 7:47 PM, Stephen Canon via swift-dev < >>>>> swift-dev@swift.org> wrote:
Assuming RawSignificand really is the type you want, I think this does
what you’re looking for?
protocol BinaryFloatingPointWithBitPattern: BinaryFloatingPoint {
init(bitPattern: RawSignificand)
var bitPattern: RawSignificand { get }
}
extension Float: BinaryFloatingPointWithBitPattern { }
extension Double: BinaryFloatingPointWithBitPattern { }
extension BinaryFloatingPointWithBitPattern {
init(unitRangeFromRawSignificand s: RawSignificand) {
self = Self(bitPattern: Self(1).bitPattern | s) - 1
}
}
On Aug 26, 2016, at 7:38 PM, Stephen Canon via swift-dev < >>>>> swift-dev@swift.org> wrote:
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@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@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@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@bitcycle.com> wr
ote:
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@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
