[swift-evolution] Proposal: floating point static min / max properties

John Calsbeek john.calsbeek+lists at gmail.com
Sat Dec 5 12:39:47 CST 2015

+1 on not calling them `max` and `min`.

I don’t have the history of the internal discussion, but I am not thrilled about that particular set of constants. Their names accurately describe the standard set of floating point constants (infinity, `FLT_MAX`, `FLT_MIN`, and smallest positive subnormal), but is that the best set of constants to expose?

How should I pick a starting value for a loop that takes the `min` or `max` of ints or floats in a sequence? With floats I should use `Float.greatestFiniteMagnitude` and `-Float.greatestFiniteMagnitude`, whereas with ints I should use `Int.max` and `Int.min`, because `-Int.max != Int.min`. Rather than parsing the three qualifiers in the name `greatestFiniteMagnitude` and reassure myself that negating it is the proper way to get the smallest finite value, I would rather type `Float.largestFinite` and `Float.smallestFinite` or something along those lines.

I have no problem with the name `leastNormalMagnitude`—if you want such a thing, you hopefully understand floats well enough for the name to not be confusing—but `leastMagnitude` is surprising to me. I think of subnormal numbers as being exceptional in the same way that infinities and NaNs are, so I wouldn’t expect to get a subnormal from a property called `leastMagnitude`. If there was a qualifier that explicitly meant “either normal or subnormal,” it would be the obvious choice here. I don’t know any, but I hope leaving off the qualifier entirely is not the best solution.

If I had to decide at this instant, I would probably pick `largestFinite`, `smallestFinite`, `leastNormalMagnitude`, and leave out `lastMagnitude` in favor of spelling it `Float(0).nextUp`.



> On Dec 5, 2015, at 9:41 AM, Stephen Canon <scanon at apple.com> wrote:
> Hi Matthew —
> This is something that we’ve discussed quite a bit internally, and are close to consensus on.  Many people feel that “max” and “min” are confusing or misleading, as they are not actually the largest / smallest values of the type, so the plan is to use much more explicit names (you can see an early sketch of this in test/Prototypes/FloatingPoint.swift, though there are a number of things that will be changed as well).  I’ve excerpted the relevant section here for convenience:
>   /// Positive infinity.
>   ///
>   /// Compares greater than all finite numbers.
>   static var infinity: Self { get }
>   /// The greatest finite value.
>   ///
>   /// Compares greater than or equal to all finite numbers, but less than
>   /// infinity.
>   static var greatestFiniteMagnitude: Self { get }
>   /// The least positive normal value.
>   ///
>   /// Compares less than or equal to all positive normal numbers.  There may
>   /// be smaller positive numbers, but they are "subnormal", meaning that
>   /// they are represented with less precision than normal numbers.
>   static var leastNormalMagnitude: Self { get }
>   /// The least positive value.
>   ///
>   /// Compares less than or equal to all positive numbers, but greater than
>   /// zero.  If the target supports subnormal values, this is smaller than
>   /// `leastNormalMagnitude`; otherwise they are equal.
>   static var leastMagnitude: Self { get }
> – Steve
>> On Dec 5, 2015, at 11:10 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> In the spirit of small commits and incremental change I have a very small proposal.  I am not sure if this belongs on the list or if small changes like this are ok as pull requests, but am starting here because it involves adding public API in the standard library.  
>> Integer types have static min / max properties, but floating point types currently do not.  The Darwin implementation is very straightforward.  
>> import Darwin
>> public extension Float {
>>   static let min = -FLT_MAX
>>   static let max = FLT_MAX
>> }
>> public extension Double {
>>   static let min = -DBL_MAX
>>   static let max = DBL_MAX
>> }
>> Is there interest in adding this?  If so, what is the right way to proceed?
>> Matthew
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/15cc3459/attachment-0001.html>

More information about the swift-evolution mailing list