[Accepted] SE-0104: Protocol-oriented integers


(Joe Groff) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

The re-review of SE-0104 ran from February 17...25, 2017. The proposal is accepted with the following revisions:

- The root `Number` protocol should be renamed `Numeric`.
- Instead of using single-case enums as mock trailing argument labels, the `FullWidth` and `ReportingOverflow` variants should include that information in their basename:

  multipliedFullWidth(by:)
  dividingFullWidth(_:slight_smile:

  addingReportingOverflow(_:slight_smile:
  subtractingReportingOverflow(_:slight_smile:
  multipliedReportingOverflow(by:)
  dividedReportingOverflow(by:)

- `popcount` should use the unabbreviated name `populationCount`.

The core team also observed that the proposed endianness-handling interfaces deserve further thought. In almost every known little-, big-, or mixed-endian format, converting to and from another endian are symmetric operations (going to and from big endian are the same operation, as are going to and from little endian), so there is no need for both sets of operations to be independent protocol requirements. The core team accepts the proposal as is for now, since it's a small corner of the larger proposal, but asks the authors for a follow-up proposal in this space.

-Joe


(Björn Forster) #2

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to
the rationale the design decision behind

  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral

being not comparable. It was pointed out by several reviewers that it is
against all intuition that a scalar is not comparable and therefore pretty
much useless.

It would be great if you could add the thoughts of the core team regarding
this to the rationale to document the reasons behind it.

Kind Regards,
Björn

···

On Thu, Mar 2, 2017 at 1:50 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

Proposal link: https://github.com/apple/swift-evolution/blob/
master/proposals/0104-improved-integers.md

The re-review of SE-0104 ran from February 17...25, 2017. The proposal is
*accepted* with the following revisions:

- The root `Number` protocol should be renamed `Numeric`.
- Instead of using single-case enums as mock trailing argument labels, the
`FullWidth` and `ReportingOverflow` variants should include that
information in their basename:

multipliedFullWidth(by:)
dividingFullWidth(_:slight_smile:

addingReportingOverflow(_:slight_smile:
subtractingReportingOverflow(_:slight_smile:
multipliedReportingOverflow(by:)
dividedReportingOverflow(by:)

- `popcount` should use the unabbreviated name `populationCount`.

The core team also observed that the proposed endianness-handling
interfaces deserve further thought. In almost every known little-, big-, or
mixed-endian format, converting to and from another endian are symmetric
operations (going to and from big endian are the same operation, as are
going to and from little endian), so there is no need for both sets of
operations to be independent protocol requirements. The core team accepts
the proposal as is for now, since it's a small corner of the larger
proposal, but asks the authors for a follow-up proposal in this space.

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #3

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

Is this correct? The “*" function has the “by” argument label and the “/“ function doesn’t?
    public func multipliedFullWidth(by other: Self) -> (high: Self, low: Self.Magnitude)
    public func dividingFullWidth(_ dividend: (high: Self, low: Self.Magnitude)) -> (quotient: Self, remainder: Self)
(These were copy/pasted from Xcode. There are a couple other differences between the snapshot and the proposal… that’s why the functions’ signatures don’t completely match.)

I glanced over the relevant mailing list threads, but didn’t see any discussion on the matter. Dunno, maybe I just missed it. Anyway, just thought I’d pass along what looks to me like a simple typo.

- Dave Sweeris


(David Sweeris) #4

(Obviously I'm not Joe, nor do I speak for anyone)

IIRC, that was discussed in the thread: It isn't required for any stdlib or commonly used algorithms, and the constraint can easily be added to any code that does need it.
func foo <T: Numeric> (x:T) where T.Magnitude: Comparable {...}

- Dave Sweeris

···

On Mar 2, 2017, at 06:22, Björn Forster via swift-evolution <swift-evolution@swift.org> wrote:

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to the rationale the design decision behind
  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral
being not comparable. It was pointed out by several reviewers that it is against all intuition that a scalar is not comparable and therefore pretty much useless.

It would be great if you could add the thoughts of the core team regarding this to the rationale to document the reasons behind it.


(Joe Groff) #5

Complex numbers have magnitude, but aren't comparable.

-Joe

···

On Mar 2, 2017, at 6:22 AM, Björn Forster <bjoern.forster@googlemail.com> wrote:

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to the rationale the design decision behind
  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral
being not comparable. It was pointed out by several reviewers that it is against all intuition that a scalar is not comparable and therefore pretty much useless.

It would be great if you could add the thoughts of the core team regarding this to the rationale to document the reasons behind it.


#6

Also not core team, but I didn’t realize this was missing during the
review. If I had I would have spoken up, because mathematically a magnitude
is *defined* as something that can be compared to see which underlying
object is bigger.

It is a measure of size, and it exists so that the sizes of objects can be
compared. Semantically, anything which is a magnitude must be comparable.

Putting that another way, if someone were to implement a type by giving it
a magnitude which wasn’t comparable, then that type should not be
considered numeric.

Even *vectors spaces*, where the objects aren’t even numeric because they
can’t be multiplied together, still have magnitudes which are comparable
since they must obey the triangle inequality.

I think the omission of ‘Comparable’ from ‘Magnitude’ should be considered
a bug in the proposal, and it should be amended as an obvious fix for an
oversight. Again, a magnitude is a measure of size, and it exists for the
purpose of being compared.

Nevin


(Björn Forster) #7

Hi Joe,
the point made here is about the magnitude of complex numbers.
The magnitude of one complex number can be compared to the magnitude of a
second number.

Kind Regards

···

On Thu, Mar 2, 2017 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:

On Mar 2, 2017, at 6:22 AM, Björn Forster <bjoern.forster@googlemail.com> > wrote:

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to
the rationale the design decision behind

  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral

being not comparable. It was pointed out by several reviewers that it is
against all intuition that a scalar is not comparable and therefore pretty
much useless.

It would be great if you could add the thoughts of the core team regarding
this to the rationale to document the reasons behind it.

Complex numbers have magnitude, but aren't comparable.

-Joe


(Björn Forster) #8

While it is true that the complex number itself is not comparable, the
magnitude of a complex number is only a scalar, and therefore it's
magnitude IS comparable.
It's only about the comparability of the magnitude, not about the number
itself. The number might actually not be comparable.

Kind Regards,
Björn

···

On Thu, Mar 2, 2017 at 6:21 PM, Joe Groff <jgroff@apple.com> wrote:

On Mar 2, 2017, at 6:22 AM, Björn Forster <bjoern.forster@googlemail.com> > wrote:

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to
the rationale the design decision behind

  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral

being not comparable. It was pointed out by several reviewers that it is
against all intuition that a scalar is not comparable and therefore pretty
much useless.

It would be great if you could add the thoughts of the core team regarding
this to the rationale to document the reasons behind it.

Complex numbers have magnitude, but aren't comparable.

-Joe


(Max Moiseev) #9

The Magnitude requirement was meant to be just Numeric (which does not refine Comparable), and only due to the lack of recursive constraints was desugared into Equatable and ExpressibleByIntegerLiteral.
Nevin has a very valid point that the very definition of Magnitude is about the ordering of things. FWIW, FloatingPoint defines Magnitude as Comparable (even though I could not find uses for it).
TL;DR: associatedtype Magnitude : Numeric, Comparable seems to be the right thing to do, after all.

···

On Mar 2, 2017, at 9:23 AM, Björn Forster via swift-evolution <swift-evolution@swift.org> wrote:

Hi Joe,
the point made here is about the magnitude of complex numbers.
The magnitude of one complex number can be compared to the magnitude of a second number.

Kind Regards

On Thu, Mar 2, 2017 at 6:21 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 2, 2017, at 6:22 AM, Björn Forster <bjoern.forster@googlemail.com <mailto:bjoern.forster@googlemail.com>> wrote:

Hello Joe,
I wanted to ask kindly if it would be possible that the core team adds to the rationale the design decision behind
  associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral
being not comparable. It was pointed out by several reviewers that it is against all intuition that a scalar is not comparable and therefore pretty much useless.

It would be great if you could add the thoughts of the core team regarding this to the rationale to document the reasons behind it.

Complex numbers have magnitude, but aren't comparable.

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#10

One use-case that springs immediately to mind is creating ranges of
magnitudes. It is not sufficient to use abs() because that returns the same
type which may not be comparable.

Also, a fairly common operation on complex numbers (or indeed any
metric space) is to see if two values are within distance d of each other.
In other words, to check whether the magnitude of their difference is less
than d. This again requires comparability of magnitudes.

Nevin