This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: quaternions in the numeric tower
- From: Jamison Hope <jrh at theptrgroup dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: kawa at sourceware dot org
- Date: Thu, 13 Nov 2014 02:06:26 -0500
- Subject: Re: quaternions in the numeric tower
- Authentication-results: sourceware.org; auth=none
- References: <6000E8B8-620C-4080-9D53-740C1334B164 at theptrgroup dot com> <546406F6 dot 6020509 at bothner dot com> <FCC79058-B575-4465-A4F3-814E36C5D924 at theptrgroup dot com> <54644B70 dot 30609 at bothner dot com>
On Nov 13, 2014, at 1:10 AM, Per Bothner <per@bothner.com> wrote:
> On 11/12/2014 07:28 PM, Jamison Hope wrote:
>>> Note that implies the new functions should go in kawa/lib/kawa/quaternions.scm,
>>> not kawa/lib/numbers.scm.
>>
>> OK, I'll put the new functions there. But what about <quaternion> as
>> a type? That would still go in the LispLanguage type map, right?
>
> It doesn't really need to. The binding fpr quaternion can be
> in the (kawa quaternion) library. For example see how vector is defined
> in kawa/lib/scheme/base.scm.
Wait, but vector *is* in the LispLanguage type map. That's what
enables all the "::vector" type decorations in vectors.scm to work, no?
>> In which case at the very least the quaternion? function should get
>> defined automatically. It's like complex? and real? in that it should
>> return #true on both actual instances of <quaternion> as well as the
>> java.lang number types, so we would get incorrect results if Kawa
>> decides to do its (TYPE? x) -> (x instanceof TYPE) thing.
>
> Why does the quaternion? function need to be defined automatically?
> Just define it as a function, like we do for complex?.
That's what I'm trying to do. What I want to avoid is this:
#|kawa:1|# quaternion
ClassType gnu.math.Quaternion
#|kawa:2|# (quaternion? (java.lang.Double:valueOf 3))
#f
#|kawa:3|# (import (kawa quaternions))
#|kawa:4|# (quaternion? (java.lang.Double:valueOf 3))
#t
If the actual hand-written function doesn't get automatically inserted
into the global environment via initScheme(), then on Line 2 there
Kawa will work its usually-desirable magic of seeing the undefined
symbol named "quaternion?" and recognizing that it has the form of
typename + "?" and treating it as syntactic sugar for
(lambda (x) (instance? x <quaternion>)).
One solution would be not to define quaternion as a type, and then
the first two lines there would throw errors. But I want to be able
to use quaternion as a type for definitions (in numbers.scm and
elsewhere) like
(define (exp (x :: <quaternion>)) :: <quaternion>
(invoke x 'exp))
>> Is kawa/lib/numbers.scm permitted to require/import (kawa quaternions)?
>> Some of its functions now make use of quaternion functions. For example,
>> real-valued? is now
>>
>> (define (real-valued? x) ::boolean
>> (and (quaternion? x)
>> (zero? (imag-part x))
>> (zero? (jmag-part x))
>> (zero? (kmag-part x))
>> (real? (real-part x))))
>
> We shouldn't have numbers import (kawa quaternions), but it's ok
> to define quaternion? in numbers.scm if that makes things easier.
> I just prefer to reduce the number of classes that typically get loaded.
>
> If might make sense to slightly optimize real-valued? to
> (or (gnu.math.RealNum? x)
> (and (quaternion? x) ...)
> though it may not be used enough for it to matter.
It's not just for real-valued?, and it's not just the quaternion?
predicate. The trio of R6 *-valued? functions which previously had
bodies like
(and (complex? x) (zero? (imag-part x)) (PRED? (real-part x)))
must all now also check the jmag-part and kmag-part to behave
correctly.
More interestingly, the inverse trig functions involve big long
expressions like (- (* v (log (+ (* v q) (sqrt (- 1 (* q q)))))))
where v is (unit-vector q) [a function from quaternions.scm].
Clearly asin, acos, and atan still belong in numbers.scm, so
either I make use of unit-vector from (kawa quaternions), or I
reimplement it in as a private function in numbers.scm. Or I
move the big expression to Java code, but that wouldn't be any
fun.
--
Jamison Hope
The PTR Group
www.theptrgroup.com