[Cuis] Array2D newSize:

[Phil (list)]

Juan,

On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/15/2015 9:49 PM, Phil (list) wrote:
> > Glad that solved your problem but, ouch... that class is uncomfortably
> > close in name and function to the 3DTransform package I'm using for
> > OpenGL.  Juan: would you be open to using an extended version of my
> > classes so that we don't run into namespace conflicts?
> 
> Indeed we need to do something with this. Check the "Math 3D" package. 
> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
> double precision for satellite image processing at work.
> 

You space guys with your astronomically large numbers and being sooooo
concerned with precisely where things are.  Why can't you accept
'there-ish' like the rest of us? :-)

(disclaimer: the events depicted in Gravity should in no way cast
aspersions as to the inadequacies of 32-bit floats...)

Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
using a combination of the Collections-Arrayed, Collections-Balloon and
3DTransform (i.e. the 3DTransform package which provides the Vector* and
Matrix* classes, which came from Croquet, or whatever upstream source
they pulled from)

The Float64* class hierarchy in Math 3D appears to just be a parallel
64-bit hierarchy (with some slight naming convention differences) to the
32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
probably want to do there is merge them (i.e. keeping both the 64-bit
and 32-versions... when you need one or the other, you absolutely need
it) into a single package and make sure they have identical
functionality and consistent naming conventions (I have no preference on
which conventions we use other than that they be consistent.  Makes no
difference to me whether I'm using Vector2 or Float32Vector2 or whatever
else would make sense)  If we did that, this would just leave the
question of how the LinearAlgebra and Array2D classes fit into this (one
thing I don't currently have but would like is an arbitrary MxN 32-bit
float matrix class)...

At first glance, the naming convention mapping appears to be:

Float64Color4 -> VectorColor
Float64Matrix4x4 -> Matrix4x4
Float64Rotation -> Quaternion
Float64Vector2 -> Vector2
Float64Vector3 -> Vector3
Float64Vector4 -> Vector4

With the balances of the classes being unique to 3DTransform. (Just
curious: for Float64Vector* why don't you use a common base class
similar to Vector?)

> There is a lot of overlap with yours, but you are using 32 bit Floats.
> 

For now... at some point I'm sure I'll be needing 64-bit Floats as well.
Since both the VM and OpenGL are limited to 32-bits, that's been doing
the job for me. (my priority is currently performance over precision
since for me it's just an errant pixel, for you it might be a house or
your satellite heading for the ISS...)

> > One advantage that the Matrix* and Vector* classes I'm using have is
> > that they are mapped to native types which makes for transparent and
> > easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> > compute shaders and you have the fastest matrix math you've ever seen,
> > assuming you've got medium or larger sets of data)
> 
> Yes. This is indeed great. We need to build a single, uniform package 
> with this stuff, that handles both 32 and 64 bit Floats and can take 
> advantage of GPUs.
> 
> BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
> in a few months.
> 

Not yet, but pretty much all of the same issues I've run into with
OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
concerned unless you're going to create a plugin, but even then you
still have the same issues) so I think we should be able to get to a
unified vector/matrix structure that works for both of us.  In both
cases the key is to minimize the amount of work done to marshal native
data in and out (slow/expensive conversions have a dramatic and
detrimental cost for small data sets / short computations) while keeping
the data as easy to work with as possible in both the Smalltalk and FFI
(whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Something to keep in the back of your mind: OMeta.  One of the many
reasons I get so geeked out about it is that an OpenGL shader is just
another language that can be targeted via source-to-source translation
(i.e. dynamically generated GPU code written in something similar to
Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
different...

> Cheers,
> Juan Vuletich

Thanks,
Phil