4.0.0

Despite the major version bump, this is really just a clean-up release with three main changes.

Changing 3D vector/direction rotation functions to take a Direction3d instead of an Axis3d

Previously, Vector3d.rotateAround and Direction3d.rotateAround took an Axis3d as an argument even though the origin point of the axis wasn't used, only the axis direction. This was to be consistent with all other 3D rotateAround functions, but can be confusing and in some cases could force you to create an axis with a dummy origin point, which seems messy. These two functions now accept a Direction3d instead, so you may need to change some code from (e.g.)

Direction3d.rotateAround someAxis someDirection

to

Direction3d.rotateAround (Axis3d.direction someAxis) someDirection

Thanks @MartinSStewart for bringing this up!

Renaming ArcLengthParameterization to ArcLength

I originally used the longer name for this module since it's the only module in elm-geometry that doesn't have a 2d or 3d suffix, and I wanted to add something to make the name less likely to conflict with modules in other packages. However, several years later the Elm package repository still doesn't have any other packages that mention arc length, so it looks like the simpler name is probably OK.

No functionality has been changed, but all the names have:

3.x	4.0
ArcLengthParameterization.ArcLengthParameterization	ArcLength.Parameterization
ArcLengthParameterization.build	ArcLength.parameterization
ArcLengthParameterization.totalArcLength	ArcLength.total
ArcLengthParameterization.arcLengthToParameterValue	ArcLength.toParameterValue
ArcLengthParameterization.parameterValueToArcLength	ArcLength.fromParameterValue

I personally now like using the Parameterization type qualified; instead of

import ArcLengthParameterization exposing (ArcLengthParameterization)
import Length exposing (Meters)

type alias Model =
    { parameterization : ArcLengthParameterization Meters
    , -- other stuff
    }

I now tend to write

import ArcLength
import Length exposing (Meters)

type alias Model =
    { parameterization : ArcLength.Parameterization Meters
    , -- other stuff
    }

Relaxing vector construction/transformation type signatures

This one is subtle and shouldn't actually be a breaking change for any code, since the only change is making some type signatures more permissive (all existing code should still type-check just fine, and the behaviour is unchanged). The short version is that a few vector-related functions were requiring units types to match when they didn't actually need to, and those type signatures have now been relaxed to be more permissive (and more correct!).

For example, in elm-geometry 3.x, the Vector3d.mirrorAcross function had the following signature:

Plane3d units coordinates -> Vector3d units coordinates -> Vector3d units coordinates

The units type parameter here will most commonly be Meters, meaning that:

• The plane's origin point has coordinates which are Length (a.k.a. Quantity Float Meters) values; that is, the coordinates are measured in meters, centimeters, feet, inches etc.
• The vector's components are also Length values; that is, the vector is a displacement (a vector between two points).

However, it's not actually necessary for those two units types to match! Since mirroring a vector across a plane doesn't involve the plane's origin point (just the plane's normal direction, which is unitless) it's not actually necessary that the units of the vector match the units of the plane's origin point. For example, it's totally valid (and sometimes useful) to mirror a velocity vector (with units of MetersPerSecond) across a plane with units of Meters. As a result, Vector3d.mirrorAcross now has the signature

Plane3d planeUnits coordinates -> Vector3d units coordinates -> Vector3d units coordinates

That is, the plane and vector are still enforced to be defined in the same coordinate system, and the units of the mirrored vector are enforced to be the same as the original vector, but the units of the plane and vector are allowed be different.

Of course, the units don't have to be different, so any existing code that (for example) mirrors a Vector3d Meters WorldCoordinates across a Plane3d Meters WorldCoordinates will still compile and run exactly the same as before. The Elm compiler considers this change a breaking one, but all it actually does is allow certain kinds of code that weren't allowed previously.

It's not just transformation functions like mirrorAcross that have been updated - several vector construction functions have had similar changes. For example, it is now possible to do things like construct a velocity vector with units of MetersPerSecond by providing its components within a sketch plane with units of Meters:

-- elm-geometry 3.x
Vector3d.xyOn :
    SketchPlane3d units coordinates3d { defines : coordinates2d }
    -> Quantity Float units
    -> Quantity Float units
    -> Vector3d units coordinates3d

-- elm-geometry 4.0
Vector3d.xyOn :
    SketchPlane3d sketchPlaneUnits coordinates3d { defines : coordinates2d }
    -> Quantity Float units
    -> Quantity Float units
    -> Vector3d units coordinates3d

(Note how the vector units are now allowed to be different from the sketch plane units.)

Full list of functions with updated signatures:

Vector2d

• xyIn
• rThetaIn
• relativeTo
• placeIn
• projectOnto

(Note that Vector2d.mirrorAcross was the one function that actually had the correct type signature already, so didn't need to be updated.)

Vector3d

• xyzIn
• on
• xyOn
• rThetaOn
• relativeTo
• placeIn
• rotateAround
• mirrorAcross
• projectOnto
• projectInto