Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Introducing Angle type [Issue #88] #169

Open
wants to merge 23 commits into
base: main
Choose a base branch
from
+905 −45
Open

Introducing Angle type [Issue #88] #169

Changes from 1 commit
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
b313290
Introduced Angle type [Issue #88]
jkalias Dec 8, 2020
c924790
Removed hyperbolic functions
jkalias Dec 8, 2020
437b280
cos(Angle) changed, 270deg stil not giving 0
jkalias Dec 9, 2020
bb19809
cos works for all cases
jkalias Dec 9, 2020
d4a4c3c
sin(Angle) also works as expected
jkalias Dec 9, 2020
f676bc1
removed newline
jkalias Dec 9, 2020
bb474f5
more tests for cos and sin
jkalias Dec 9, 2020
2fad678
cos and sin tests along the whole (-π,π) interval
jkalias Dec 9, 2020
4844b2a
tests and implementation for tan
jkalias Dec 9, 2020
c5828b8
Strict equality in tests, not approximate
jkalias Dec 9, 2020
2fba7c7
Removed conformance to BinaryFloatingPoint
jkalias Dec 13, 2020
79f5f7a
Added conformance to AdditiveArithmetic and other utilities
jkalias Dec 13, 2020
5f57416
Added AdditiveArithmetic tests
jkalias Dec 13, 2020
e09ef7a
Fixed conformance to Equatable, and added range containment functions…
jkalias Dec 14, 2020
131774a
Updated public access modifier style
jkalias Dec 14, 2020
949c9a2
Refactored AngleTests
jkalias Dec 16, 2020
63bdaaf
cos and sin for exact degrees
jkalias Dec 18, 2020
acd67fb
exact tan implemented
jkalias Dec 18, 2020
14c520b
inverse trigonometric functions fixed
jkalias Dec 19, 2020
9e7fb84
range containment and distance checks
jkalias Dec 20, 2020
1743914
documentation
jkalias Dec 20, 2020
56c5ffc
Angle type with trig-pi branch (#85)
jkalias Mar 21, 2021
83ba41b
Merge branch 'main' into angle-type
jkalias Mar 18, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions Sources/RealModule/Angle.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,50 @@ public extension Angle {
static func atan2(y: T, x: T) -> Self { Angle.radians(T.atan2(y: y, x: x)) }
}

extension Angle: AdditiveArithmetic {
public static var zero: Angle<T> { .radians(0) }

public static func + (lhs: Angle<T>, rhs: Angle<T>) -> Angle<T> {
Angle(radians: lhs.radians + rhs.radians)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems unfortunate to me that adding two angles specified in degrees incurs rounding error seven times if I want the result in degrees. I think this dedicated type needs to store values given in degrees as-is if it offers such arithmetic.

Copy link
Author

@jkalias jkalias Dec 14, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I intended with my earlier comment, so degrees and radians are stored separately.
#169 (comment)

We could then switch on all operations performed on the input and essentially handle three cases:

  • degrees with degrees -> perform operation in degrees
  • radians with radians -> perform operation in radians
  • mixed units -> perform in a common unit

I'm not sure whether people agree on that

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 That would yield a superior result in the case of operations performed entirely in degrees or radians.

I wonder if there are alternative designs that can improve the result when working with both degrees and radians. If the type stored both radians and degrees, for example, then you could store the result of "90 degrees plus 1 radian" exactly. I haven't thought through the remainder of the design, but I offer it for your consideration here.

}

public static func += (lhs: inout Angle<T>, rhs: Angle<T>) {
lhs.radians += rhs.radians
}

public static func - (lhs: Angle<T>, rhs: Angle<T>) -> Angle<T> {
Angle(radians: lhs.radians - rhs.radians)
}

public static func -= (lhs: inout Angle<T>, rhs: Angle<T>) {
lhs.radians -= rhs.radians
}
}

public extension Angle {
static func * (lhs: Angle<T>, rhs: T) -> Angle<T> {
Angle(radians: lhs.radians * rhs)
}

static func *= (lhs: inout Angle<T>, rhs: T) {
lhs.radians *= rhs
}

static func * (lhs: T, rhs: Angle<T>) -> Angle<T> {
Angle(radians: rhs.radians * lhs)
}

static func / (lhs: Angle<T>, rhs: T) -> Angle<T> {
assert(rhs != 0)
return Angle(radians: lhs.radians / rhs)
}

static func /= (lhs: inout Angle<T>, rhs: T) {
assert(rhs != 0)
lhs.radians /= rhs
}
}

private func normalize<T>(_ input: T, limit: T) -> T
where T: Real {
var normalized = input
Expand Down