On Nov 9, 7:13 am, "Michael Beauregard" <[EMAIL PROTECTED]> wrote: > That's not true. Matrix inversion is common enough in graphics > programming. I wrote a physics engine that neglected quantum effects > and still needed to invert matrices ;-) > > http://java.sun.com/javase/technologies/desktop/java3d/forDevelopers/...
Ah, that's because you're doing graphics programming, so the matrices are small enough that it's probably faster to multiply by the inverse than to use the L and U factors. (I once talked with some people who needed to solve 3x3 systems really really fast in hardware so they ended up using Craemer's Rule, which is about the stupidest, least accurate method possible, but had a lower instruction count so it was faster for them.) I'm not so familiar with the graphics programming world but am fairly certain that the costs will be dominated by the creation of matrix and vector temporaries, especially in tight loops. Notice how _all_ the matrix functions in the above API, except perhaps for the constructors, do destructive writes. The same is true for the Tuple3f API: http://java.sun.com/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/vecmath/Tuple3f.html You could of course just use the Matrix3f, etc. objects and methods directly in your Clojure code and just take care not to share objects between threads. Of course then you have to do destructive writes which makes the algebra less pretty, but there's a way to fix that. I knew someone who was hooking up a C arbitrary-precision floating-point arithmetic library to (ANSI Common) Lisp and wanted to avoid creating temporaries in arithmetic expressions in loops (because the arbitrary- precision floating-point objects may be large and also are expensive to allocate). He wrote a macro to transform ordinary arithmetic code in a loop into code that carefully allocates just as many temporaries as necessary at the beginning of the loop, and then replaces the arithmetic in the loop with destructive operations. It's basically the same register allocation problem that compilers know how to solve. Now that doesn't fix the concurrency problem so you as the programmer would have to be disciplined about not sharing those variables. mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
