Fixed size polymorphic vectors
- Module documentation is published on Pursuit.
In a nutshell:
import Data.Vector2 (Vec(..))
va :: Vec Int
va = Vec 2 3
vb :: Vec Int
vb = Vec 7 6
vc :: Vec Int
vc = va + vb
Vectors are defined in separate fixed sized types. Currently for 2D and 3D vectors.
If you need an implementation that is polymorphic on the size of the vectors, you can check out the fast-vect package.
Vectors in this library are polymorphic on the inner type. Thus you can use it as Vec Int
Vec Number
or any other type.
newtype PosInt = PosInt Int
type V = Vec PosInt
Even though there can also be something like Vec String
most operations defined in here are constrained to types that define numeric instances such as Ring
or Semiring
.
There may be more specific types provided by other libraries. E.g. a VecNumber
may provide operations which are Number
specific. Moreover it could be implemented as JavaScript's Float64Array
for better interoperablity with WebGL or similar. This is for instance how it's handled in Elm's linear-algebra library.
The library only provide data types and functions for vectors of different sizes, as well as some conversions between them. There will be no matrices or other geometric shapes included in this library. So it will stay a lightweight dependency.
In many Programs either only 3D Vectors or only 2D Vectors are used. Thus all of the the vector data types are named equally.
import Data.Vector2 (Vec)
import Data.Vector2 as Vec
f :: Vec -> Vec -> Int
f (Vec x y) ...
If you need more than one in a module you can still import them qualified.
import Data.Vector2 as V2
import Data.Vector3 as V3
f :: V2.Vec -> V3.Vec -> Int
f (V2.Vec x y) ...
Vec
was chosen as it's somewhere in the middle of "descriptive" and "short". Other options were Vector
, Vect
, V
. Note that we could have provides a short infix alternative only for the 2D vector, so this was't provided at all for consistency reasons.
Implementation is exposed. This allows easy and clean destructuring of vector components. However it does not allow to change the implementation behind the scenes to something that is maybe more performant. Clarity and convenience was a higher priority than optimization. However with a contemporary code optimizer this tradeoff is probably vastly reduced.
- Haskell's linear package
- Elm's linear-algebra package
- Elm's geometry package
- PureScript's sized-vectors
- PureScript's fast-vect