System/Requests/Quaternions

Here's a preliminary model for quaternion implementation.

   NB. scalar is a vector of four floats
   ip=: +/ .*
   t4=. (_1^#:0 10 9 12)*0 7 16 23 A.=i.4

   NB. monads
   mag=: %:@ip~          NB. |
   sign=: % mag          NB. *
   conj=: 1 _1 _1 _1 * ] NB. +
   neg=:  -              NB. -
   inv=: conj % ip~      NB. %
NB. TODO: *. <. >.

   NB. dyads
   add=: +               NB. +
   sub=: -               NB. -
   mul=: ip t4 ip ]      NB. *
   div=: mul inv         NB. %
NB. TODO: | <. >.

The +. monad should be defined, and many opengl commands would take quaternion arguments.

Another point of view might use a Cayley-Dickson representation.

  NB. Cayley-Dickson -- quaternion scalar is a vector of two complex numbers
  m2=: * conj
  t2=. 2 2 2$1 0 0 1 0 _1 1 0

  NB. monads
  conj=: +@{., -@{:
  mag=: |@j./@:|
  sign=: % mag
  neg=: -
  inv=: conj % m2

  NB. dyads
  add=: +
  sub=: -
  mul=: ip t2 ip ]
  div=: mul inv

These models might be merged? That is, t4 (or some acceptable variant) should be derivable from t2.

Note also that the Cayley-Dickson approach suggests quaternion scalar constants have a form like 111j222k333j444, or perhaps 111j222j333j444, and that +. on quaternions could yield a pair of complex numbers. -- Raul Miller <<DateTime(2005-11-13T20:06:11Z)>> On the other hand, for documentation purposes it would be good to be able to have unambiguous names for each of the coordinate values in a quaternion. This suggests using letters in sequence. Perhaps 1, i, j, k would work. This can also be thought of as a reflection on the Cayley-Dickson approach with quaternions as "hypercomplex" numbers -- both the real part and the complex parts get complex parts and i is the name for the hypercomplex part of a real while k is the name for the hypercomplex part of an imaginary. This would not extend to octonions but so far as I know octonions don't have any compelling practical applications (they are mostly relevant in the context of Lie algebras).

Floor, Ceiling, and Modulo (the monads <. and >. and the dyad |) are a bit more problematic. See NumberTheoryForQuaternions for more detail on this issue. Personally, I think that the "Fractionality" constraint should be relaxed so that it applies to coordinate elements (1, j, ...) instead of to the magnitude of the result.

Another issue is the cd interface (15!:0). Complex numbers and quaternions are not data types in ANSI C. But one of the motivations for quaternions is that they provide a compact and convenient way of representing parameters for opengl interfaces. An issue here is that opengl coordinates are typically characterized as x, y, z, w while a quaternion implementation in J might order them as w, x, y, z.

-- Raul Miller <<DateTime(2006-04-24T09:51:21Z)>>