Proposal: A standard library Fraction type


(Harlan Haskins) #1

If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins


(TJ Usiyan) #2

I'm all for a stdlib Rational Type. I've written one as well and would be
glad not to have to include it as a dependency everywhere.
TJ

···

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution < swift-evolution@swift.org> wrote:

If Swift 3 is going to focus on re-thinking the Numerics in the system, it
might be worth considering adding a Fraction (or Rational) type to the
standard library. This, coupled with an arbitrary-precision integer type,
would be a great way to handle arbitrary-precision decimal arithmetic, and
can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the
ones I’ve seen haven’t been implemented fully generically.
My favorite is this one:
https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast
implementations of all the common algorithms (GCD, LCD, LCM, reduction,
etc) and good conformance to the builtin integer protocols. Maybe even
FloatLiteralConvertible, too, with some logic for converting rational
floats.

Thoughts?

- Harlan Haskins

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


(plx) #3

Anything where you *specify* angles benefits from a rational type (e.g. representing fractions-of-π) that gets converted to floating-point only when necessary (e.g. to use trig functions).

···

On Dec 7, 2015, at 8:11 AM, Stephen Canon via swift-evolution <swift-evolution@swift.org> wrote:

Can you guys specify some of the use cases that you have in mind for a Rational type? You mention "alleviating the pain points of floating-point math,” but rationals tend to be used *very* differently from floating-point types in computation.

Thanks,
– Steve

On Dec 7, 2015, at 5:44 AM, Davide De Franceschi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I agree that a Rational type, one that would preserve quotient and denominator info, would be very nice, I think that it's more fit for a Math framework.
If we're just talking about a type that holds precise decimal info, I think making NSDecimal (planned to be renamed as Decimal in the future) usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins

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


(Stephen Canon) #4

Can you guys specify some of the use cases that you have in mind for a Rational type? You mention "alleviating the pain points of floating-point math,” but rationals tend to be used *very* differently from floating-point types in computation.

Thanks,
– Steve

···

On Dec 7, 2015, at 5:44 AM, Davide De Franceschi via swift-evolution <swift-evolution@swift.org> wrote:

While I agree that a Rational type, one that would preserve quotient and denominator info, would be very nice, I think that it's more fit for a Math framework.
If we're just talking about a type that holds precise decimal info, I think making NSDecimal (planned to be renamed as Decimal in the future) usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins


(Davide De Franceschi) #5

While I agree that a Rational type, one that would preserve quotient and denominator info, would be very nice, I think that it's more fit for a Math framework.
If we're just talking about a type that holds precise decimal info, I think making NSDecimal (planned to be renamed as Decimal in the future) usable is what we should do.

···

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins

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

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


(Adrian Kashivskyy) #6

(resending to mailing list)

I'm all for Fraction type as well, although I would prefer it to be called Rational for the following reasons:

- Although all rational numbers are technically fractions (with whole numbers having denominator of 1), it might mislead developers that it's applicable only to fractions of type p/q: q ≠ 1, q ≠ 0
- The name Rational is mathematically-correct

Pozdrawiam – Regards,
Adrian Kashivskyy

Wysłane z iPhone'a

···

Dnia 07.12.2015 o godz. 11:44 Davide De Franceschi via swift-evolution <swift-evolution@swift.org> napisał(a):

While I agree that a Rational type, one that would preserve quotient and denominator info, would be very nice, I think that it's more fit for a Math framework.
If we're just talking about a type that holds precise decimal info, I think making NSDecimal (planned to be renamed as Decimal in the future) usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution <swift-evolution@swift.org> wrote:
If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins

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

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

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


(TJ Usiyan) #7

Musical time signatures and note duration. Visual code with proportional
relationships.

···

On Mon, Dec 7, 2015 at 7:41 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote:

Can you guys specify some of the use cases that you have in mind for a
Rational type? You mention "alleviating the pain points of floating-point
math,” but rationals tend to be used *very* differently from floating-point
types in computation.

Thanks,
– Steve

On Dec 7, 2015, at 5:44 AM, Davide De Franceschi via swift-evolution < > swift-evolution@swift.org> wrote:

While I agree that a Rational type, one that would preserve quotient and
denominator info, would be very nice, I think that it's more fit for a Math
framework.
If we're just talking about a type that holds precise decimal info, I
think making NSDecimal (planned to be renamed as Decimal in the future)
usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be
glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution < > swift-evolution@swift.org> wrote:

If Swift 3 is going to focus on re-thinking the Numerics in the system,
it might be worth considering adding a Fraction (or Rational) type to the
standard library. This, coupled with an arbitrary-precision integer type,
would be a great way to handle arbitrary-precision decimal arithmetic, and
can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the
ones I’ve seen haven’t been implemented fully generically.
My favorite is this one:
https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast
implementations of all the common algorithms (GCD, LCD, LCM, reduction,
etc) and good conformance to the builtin integer protocols. Maybe even
FloatLiteralConvertible, too, with some logic for converting rational
floats.

Thoughts?

- Harlan Haskins

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


(Matthew Johnson) #8

Musical time signatures and note duration. Visual code with proportional relationships.

Time signatures cannot be properly modeled with a rational type you would expect to find in a numerics library. 3/4 is not the same as 6/8 in music!


(Stephen Canon) #9

Musical time signatures is an odd case, because you really have pairs of integers (i.e. if they were rational numbers, then 6/8 would be the same as 3/4. They are not the same).

···

On Dec 7, 2015, at 9:36 AM, T.J. Usiyan <griotspeak@gmail.com> wrote:

Musical time signatures and note duration. Visual code with proportional relationships.

On Mon, Dec 7, 2015 at 7:41 PM, Stephen Canon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Can you guys specify some of the use cases that you have in mind for a Rational type? You mention "alleviating the pain points of floating-point math,” but rationals tend to be used *very* differently from floating-point types in computation.

Thanks,
– Steve

On Dec 7, 2015, at 5:44 AM, Davide De Franceschi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I agree that a Rational type, one that would preserve quotient and denominator info, would be very nice, I think that it's more fit for a Math framework.
If we're just talking about a type that holds precise decimal info, I think making NSDecimal (planned to be renamed as Decimal in the future) usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If Swift 3 is going to focus on re-thinking the Numerics in the system, it might be worth considering adding a Fraction (or Rational) type to the standard library. This, coupled with an arbitrary-precision integer type, would be a great way to handle arbitrary-precision decimal arithmetic, and can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the ones I’ve seen haven’t been implemented fully generically.
My favorite is this one: https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast implementations of all the common algorithms (GCD, LCD, LCM, reduction, etc) and good conformance to the builtin integer protocols. Maybe even FloatLiteralConvertible, too, with some logic for converting rational floats.

Thoughts?

- Harlan Haskins

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


(TJ Usiyan) #10

If your implementation of Rational simplifies immediately, sure. Mine
doesn't and it is useful in many other cases not to as well. You might, for
example, want to present the original numerator/denominator provided by the
user.

TJ

···

On Mon, Dec 7, 2015 at 8:16 PM, Matthew Johnson <matthew@anandabits.com> wrote:

> Musical time signatures and note duration. Visual code with proportional
relationships.

Time signatures cannot be properly modeled with a rational type you would
expect to find in a numerics library. 3/4 is not the same as 6/8 in music!


(TJ Usiyan) #11

The example of time signatures has much less to do with modeling the two
integers presented to the user and more to do with resolving the absolute
duration of a note which is part of why I mentioned both time signature
*and* note duration.

···

On Mon, Dec 7, 2015 at 8:15 PM, Stephen Canon <scanon@apple.com> wrote:

Musical time signatures is an odd case, because you really have pairs of
integers (i.e. if they were rational numbers, then 6/8 would be the same as
3/4. They are not the same).

On Dec 7, 2015, at 9:36 AM, T.J. Usiyan <griotspeak@gmail.com> wrote:

Musical time signatures and note duration. Visual code with proportional
relationships.

On Mon, Dec 7, 2015 at 7:41 PM, Stephen Canon via swift-evolution < > swift-evolution@swift.org> wrote:

Can you guys specify some of the use cases that you have in mind for a
Rational type? You mention "alleviating the pain points of floating-point
math,” but rationals tend to be used *very* differently from floating-point
types in computation.

Thanks,
– Steve

On Dec 7, 2015, at 5:44 AM, Davide De Franceschi via swift-evolution < >> swift-evolution@swift.org> wrote:

While I agree that a Rational type, one that would preserve quotient and
denominator info, would be very nice, I think that it's more fit for a Math
framework.
If we're just talking about a type that holds precise decimal info, I
think making NSDecimal (planned to be renamed as Decimal in the future)
usable is what we should do.

On 7 Dec 2015, at 10:28, T.J. Usiyan via swift-evolution < >> swift-evolution@swift.org> wrote:

I'm all for a stdlib Rational Type. I've written one as well and would be
glad not to have to include it as a dependency everywhere.
TJ

On Mon, Dec 7, 2015 at 1:31 PM, Harlan Haskins via swift-evolution < >> swift-evolution@swift.org> wrote:

If Swift 3 is going to focus on re-thinking the Numerics in the system,
it might be worth considering adding a Fraction (or Rational) type to the
standard library. This, coupled with an arbitrary-precision integer type,
would be a great way to handle arbitrary-precision decimal arithmetic, and
can alleviate almost all the pain points of floating-point math.

There exist now some really nice implementations of Fractions, but the
ones I’ve seen haven’t been implemented fully generically.
My favorite is this one:
https://gist.github.com/JadenGeller/5e80ebf32442acc62e8e

I’d love to see some standard library support with rock-solid, fast
implementations of all the common algorithms (GCD, LCD, LCM, reduction,
etc) and good conformance to the builtin integer protocols. Maybe even
FloatLiteralConvertible, too, with some logic for converting rational
floats.

Thoughts?

- Harlan Haskins

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


(Matthew Johnson) #12

If your implementation of Rational simplifies immediately, sure. Mine doesn't and it is useful in many other cases not to as well. You might, for example, want to present the original numerator/denominator provided by the user.

How does your implementation implement equality? From a numeric standpoint I think most people would consider 3/4 to be equal to 6/8 whereas this would not be correct for a time signature.

In any case, I agree that a rational type would be a useful addition to the library. I don't think I would use it to model time signatures but there are plenty of other uses.


(TJ Usiyan) #13

We seem to have become distracted with the whole Time Signature thing. Time
signatures themselves are not Rationals. I should have said "Metrical Time"
and left it at that. My point has always been that metrical time calls for
the use of Rationals.
TJ

···

On Mon, Dec 7, 2015 at 9:20 PM, Matthew Johnson <matthew@anandabits.com> wrote:

> If your implementation of Rational simplifies immediately, sure. Mine
doesn't and it is useful in many other cases not to as well. You might, for
example, want to present the original numerator/denominator provided by the
user.

How does your implementation implement equality? From a numeric
standpoint I think most people would consider 3/4 to be equal to 6/8
whereas this would not be correct for a time signature.

In any case, I agree that a rational type would be a useful addition to
the library. I don't think I would use it to model time signatures but
there are plenty of other uses.


(TJ Usiyan) #14

Calculating precession time of two frequencies is an example. (consider
displaying two waveforms)

···

On Mon, Dec 7, 2015 at 5:43 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

We seem to have become distracted with the whole Time Signature thing.
Time signatures themselves are not Rationals. I should have said "Metrical
Time" and left it at that. My point has always been that metrical time
calls for the use of Rationals.
TJ

On Mon, Dec 7, 2015 at 9:20 PM, Matthew Johnson <matthew@anandabits.com> > wrote:

> If your implementation of Rational simplifies immediately, sure. Mine
doesn't and it is useful in many other cases not to as well. You might, for
example, want to present the original numerator/denominator provided by the
user.

How does your implementation implement equality? From a numeric
standpoint I think most people would consider 3/4 to be equal to 6/8
whereas this would not be correct for a time signature.

In any case, I agree that a rational type would be a useful addition to
the library. I don't think I would use it to model time signatures but
there are plenty of other uses.