[swift-evolution] [Pitch] Angle Type

Karl Wagner razielim at gmail.com
Sun Jan 14 05:36:17 CST 2018



> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I do a lot of geometry and spherical-related work and i have never found an Angle type to be worth having. Always use radians. It’s what sin() and cos() take, it’s what graphics APIs like Cairo expect, it’s what graphics formats like SVG use. plus,, do you *really* want to be case-branching on every angle value? that really adds up when you’re converting 100,000s of lat-long pairs to cartesian.

You can do it without case-branching. I too have an Angle type; this is what I use:

public struct Angle<T: FloatingPoint> {
  public var radians: T
  public var degrees: T {
    return (radians / .pi) * 180
  }

  public static func radians(_ rads: T) -> Angle {
    return Angle(radians: rads)
  }
  public static func degrees(_ degs: T) -> Angle {
    return Angle(radians: (degs / 180) * .pi)
  }
}

If you ask for “radians” (like most low-level trig code will), you just get the stored property. The conversion “overhead” is only done at construction time, so it makes a convenient parameter/return value.

- Karl

> 
> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> An Angle type already exists in Foundation; see Measurement<UnitAngle>. You could add some convenience methods in an extension pretty easily.
>> 
>> import Foundation
>> 
>> typealias Angle = Measurement<UnitAngle>
>> 
>> extension Measurement where UnitType == UnitAngle {
>>     var sine: Double {
>>         let radians = self.converted(to: .radians).value
>>         return sin(radians)
>>     }
>>     
>>     static var threeQuarterTurn: Angle {
>>         return Angle(value: 0.75, unit: .revolutions)
>>     }
>> }
>> 
>> let x = Angle.threeQuarterTurn
>> x.sine // -1
>> 
>> -BJ
>> 
>> 
>>> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I would like to see a full Geometry implementation but I don't think it should be part of the standard library.
>>> 
>>> I've kicked around some ideas here: 
>>> 
>>> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b <https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b>
>>> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721 <https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721>
>>> 
>>> and
>>> 
>>> * https://github.com/erica/SwiftGeometry <https://github.com/erica/SwiftGeometry>
>>> 
>>>> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Hi Evolution,
>>>> 
>>>> I would really like to see Swift gain an Angle type in the standard library.  Every time I have to deal with an angle in an api, I have to go figure out the conventions for that call.  Is it in degrees? Is it in radians?  What if it is in radians, but I want to think about it in degrees?
>>>> 
>>>> I ended up writing an Angle type for my own code a few years back, and I have to say it is really wonderful.  It has greatly simplified my graphics work.  It takes a lot of mental load off of my brain when dealing with Angles.
>>>> 
>>>> I can of course initialize it either as degrees or radians (or revolutions), but I can also just say things like ‘.threeQuarterTurn’, and then I can get the value back out in whatever format I like.  There are also useful additions that let me normalize the angle to different ranges and which let me snap to the nearest multiple of an angle. Both of these are enormously useful for user facing features.  I can also do math on angles in a way that makes geometric sense for angles.  It is also really useful for interacting with CGVectors in intelligent ways.
>>>> 
>>>> Using Doubles or CGFloats to represent angles everywhere is just semantically wrong IMHO, and it stops us from adding all of these angle-specific niceties.
>>>> 
>>>> Happy to provide code if there is interest…
>>>> 
>>>> Thanks,
>>>> Jon
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20180114/4baa9f91/attachment.html>


More information about the swift-evolution mailing list