[swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Stephen Canon]

Thanks for the feedback, Chris.

> On Apr 14, 2016, at 9:06 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> This proposal looks really really great, let me know when you want to start the review process (or just submit a PR for the -evolution repo) and I’ll happily review manage it for you.
> 
> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Provide basic constants (analogues of C's DBL_MAX, etc.)
> Nice, have you considered adding pi/e and other common constants?  I’d really really like to see use of M_PI go away… :-)

That’s a reasonable suggestion.  I’m not sure if FloatingPoint is the right protocol to attach them to, but I’m not sure that it’s wrong either.  I’d be interested to hear arguments from the community either way.

>> /// SignedArithmetic protocol will only be conformed to by signed numbers,
>> /// otherwise it would be possible to negate an unsigned value.
>> ///
>> /// The only method of this protocol has the default implementation in an
>> /// extension, that uses a parameterless initializer and subtraction.
>> public protocol SignedArithmetic : Arithmetic {
>>   func negate() -> Self
> Should this be negated / negate?  negate() seems like an in-place mutating version.

Yup, that seems right.

>> /// A floating-point type that provides most of the IEEE 754 basic (clause 5)
> Dumb Q, but is it “IEEE 754” or “IEEE-754”?

It’s commonly styled both ways, but I believe IEEE 754 is the “official" one.

>> /// operations.  The base, precision, and exponent range are not fixed in
>> /// any way by this protocol, but it enforces the basic requirements of
>> /// any IEEE 754 floating-point type.
>> ///
>> /// The BinaryFloatingPoint protocol refines these requirements and provides
>> /// some additional useful operations as well.
>> public protocol FloatingPoint: SignedArithmetic, Comparable {
>> 
>>   static var ulp: Self { get }
>>   var ulp: Self { get }
> Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future.  It would be great to avoid this in your design.

Interesting.  Both are definitely useful, but Type(1).ulp is sufficiently simple that only having the instance member may be good enough.  Otherwise, ulpOfOne or similar could work.

<snip>

> I’m certainly not a floating point guru, but I would have expected significant to be of type RawSignificand, and thought that the significant of a nan would return its payload.  Does this approach make sense?
> 
> … later: I see that you have this on the binary FP type, so I assume there is a good reason for this :-)

Both are useful to have in practice.  I have been attempting to keep the assumptions about representation to a minimum in the top-level FloatingPoint protocol.

<snip a few style notes that I’ll simply take as-is because they’re no-brainers>

>>   /// True if and only if `self` is subnormal.
>>   ///
>>   /// A subnormal number does not use the full precision available to normal
>>   /// numbers of the same format.  Zero is not a subnormal number.
>>   var isSubnormal: Bool { get }
> I’m used to this being called a “Denormal”, but I suspect that “subnormal” is the actually right name?  Maybe it would be useful to mention the “frequently known as denormal” in the comment, like you did with mantissa earlier.

Yes, “subnormal” is the preferred IEEE 754 terminology, but I’ll add a note referencing “denormal” as well.

Thanks,
– Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160414/98c40c19/attachment.html>