The to_rotation_matrix/1 function should have two variants to explicitly state the output format:

• to_rotation_matrix_33/1 to make a 3x3 matrix
• to_rotation_matrix_44/1 to make a 4x4 matrix

We forgot to add transforming vectors by quaternions, and we also forgot to add checking for equality between vectors.

Alright, what do we want to tackle next?

@Host32

Let's add the l-infinity norm.

From here, "How to integrate a quaternion" section.

This is needed for the work on ERP, but would probably benefit others.

Apparently adding type guards on numerical functions can let the BEAM optimizer generate better code, Wings3D uses this heavily. If you're interested I can try it out and benchmark how much it actually helps.

   1) test round with 2 sigfigs (Graphmath.Mat33.Round_Mat33)
     test/mat33/mat33_round_test.exs:16
     Assertion with == failed
     code:  {1.1, 2.1, 3.1, 4.6, 5.7, 6.8, 7.0, 8.4, 10.0} == Graphmath.Mat33.round({1.14, 2.14, 3.14, 4.55, 5.66, 6.77, 7.03, 8.36, 9.99}, 1)
     left:  {1.1, 2.1, 3.1, 4.6, 5.7, 6.8, 7.0, 8.4, 10.0}
     right: {1.1, 2.1, 3.1, 4.5, 5.7, 6.8, 7.0, 8.4, 10.0}
     stacktrace:
       test/mat33/mat33_round_test.exs:17: (test)

Did something in the representation of floats maybe change that 4.54 is internally represented as 4.549....?

At the time this library was created, Travis didn't have any Elixir support. This is now at least in beta support by those folks: https://docs.travis-ci.com/user/languages/elixir/

Sample:
defmodule Vec2 do
def x: 0.0, y: 0,0
end

I'm not sure about the cost of performance when using that, but we will have to use practicalities for example vec.x or vec.y

We need a way of creating the identity quaternion and also comparing that two quaternions are in fact equivalent.

Vec2d.rotate here I believe is slightly off.

I believe it should be this for CCW, but I'm not 100% sure according to this here.

def rotate( a, theta) do
  { x,y } = a
   ct = :math.cos(theta)
   st = :math.sin(theta)
  { x*ct - y*st, x*st + y*ct } # this line changed
end

The issue I'm having is that Graphmath.rotate({0,1}, :math.pi) produces {0,1} instead of {0,-1}.

Reviewing the tests, I noticed there is no case for testing the y axis, so adding something like this

@tag :vec2
@tag :rotate
test "rotate( {0,1}, :math.pi) returns {0,-1}" do
  {x,y} = Graphmath.Vec2.rotate( {0,1}, :math.pi)
  assert {0,-1} == { Float.round(x,6), Float.round(y,6)}
end

should fail. I can issue a PR for it, tomorrow just noting it. Again maybe completely wrong, not exactly the strongest in math.

Hi, thanks for graphmath! It solves a lot of problems with 3D rendering and physics simulations.

There are a few things that could be added to make this more complete for realtime 3D interactive applications, as well as 2D UIs, such as Scenic.

A few things such as Vec4, Mat22, some added functions such as trace, determinant, look_at, perspective, ortho, maybe some others, would be nice for both 3D rendering and some physics-based simulations.

The main interest I have is to unify many of these common math functions into a package that something like Scenic could utilize, as well as my own projects with OpenGL rendering. I'm not sure if this is outside the scope of this project, but if it seems it would fit, I'd be happy to open a (or some) PRs.

Let's add the p-norm.

Let's add the Minkowski distance.

So, the documentation for the modules is a little hard to navigate.

Also, the description for the library as it appears in Hex is a bit off.

Lastly, thanks to @RobertDober's help, we have a chance to update to a new version of ex_doc and to acknowledge his help as a contributor. :)

We want this project to pass through Dialyzer/Dialyxer without complaint.

Super TBD, but the idea is to have support for geometric products, rotors, wedge products, and all that other good stuff.

This was found in #9.

Filing an issue here so I can make sure not to lose it.

This submodule handles Quaternion using tuples of floats. i.e. a rotation around an axis.

Consider the quatern format: { w, x, y, z } where w is the angle, and x y z are the axis coordinates

@type quatern :: {float, float, float, float}

An implementation in C ++ to serve as inspiration:
https://bitbucket.org/sinbad/ogre/src/5ee010d450fd064007b61442124222bfb3d57a58/OgreMain/include/OgreQuaternion.h?at=default

It's time to add more random numbers to Graphmath!

• Add Quatern.random/0 for generating random quaternions.
• Add Vec2.random_circle/0 for generating vec2s on a unit circle.
• Add Vec2.random_disc/0 for generating vec2s on a unit disc.
• Add Vec2.random_square/0 for generating vec2s on unit square.
• Add Vec3.random_box/0 for generating vec3s inside a unit box.
• Add Vec3.random_sphere/0 for generating vec3s on a unit sphere.
• Add Vec3.random_ball/0 for generating vec3s on or inside the unit sphere.

Unless I'm wrong, converting to a rotation matrix and back should be reversible, right?

iex> Graphmath.Quatern.create(1,2,3,4)
...> |> Graphmath.Quatern.to_rotation_matrix()
...> |> Graphmath.Quatern.from_rotation_matrix()
{2.0, 3.0, 4.0, 1.0}

So it looks like the elements of the quatern tuple are being reversed. Is this a bug?

Quaternions of norm 0 cause the current normalize implementation to blow up, which is no good.

We should fix it to return a 0 quaternion in such cases, and maybe add a normalizeStrict that explodes otherwise.

Quatern.create has too many variants that do similar things. This is about renaming and splitting them out to more friendly versions.

• Quatern.create/0 to Quatern.zero/0.
• Quatern.create/1 to Quatern.from_list/0.
• Quatern.create/2 to Quatern.from_axis_angle/2
• Add Quatern.from_axis_angle_packed/1