[Cuis] Array2D newSize:

[Phil (list)]

Juan,

On Fri, 2015-07-17 at 11:15 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/16/2015 5:13 PM, Phil (list) wrote:
> > 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? :-)
> 
> :) I would... But if you want Google Earth level of precision, you do 
> need them...
> 

Just aim for Apple Maps level of precision and call it good enough :-)

> > (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)
> 
> Croquet was done by Andreas, who previously wrote all the Baloon 3d 
> stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
> package I did )

Ah, I knew Andreas did most of the graphics stuff in Croquet but wasn't
sure about the math code (just spot-checking, I see 'das' listed as the
person who last touched most of the code back in 2005 with some by
Andreas both before and after)

> 
> > 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?)
> 
> This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
> be able to write very efficient slang code for the Ballon3D VM plugin.
> 
> WRT to naming conventions, we just need to agree on one. I have no 
> preference.
> 

I'm OK with changing my stuff to use Float32*.  Since both hierarchies
are dependent on their underlying native types, that would probably be
the most straightforward approach.  Would it make sense to you to use
FloatXXQuaternion? (Rotation seems a bit vague to me since, while
unlikely, there could potentially be other rotation solutions
implemented)

> >> 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...)
> 
> That's totally ok. Just a remark: the VM is not limited to 32 bits. 
> Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
> is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
> double) primitives to it.
> 

That's good to know.  I've been meaning to dig back into the VM source
as there are still some questions I have about how FFI is doing some of
what it is doing.  Just lack of time on my part vs other priorities...

> WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
> System), but the image processing pipeline. So, a numeric error would be 
> like saying that a picture of L.A. is in Mexico, or such :)
> 

Awww... you've destroyed my Dr. Evil mental image of you at work ;-)

> >>> 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.
> 
> Yes.
> 
> Something that I would like (and I don't know how to do it without 
> Traits) is to share most of the source code between the 32 and 64 bits 
> versions. We would need something like two parallel inheritance hierarchies:
> 
> GeneralFloatArray
> --- FloatArray32
> --- --- FloatVector32
> --- --- FloatQuaternion32
> --- FloatArray64
> --- --- FloatVector64
> --- --- FloatQuaternion64
> for the inheritance of size specific code (#at: #at:put: primitives)
> 
> and something like
> FloatVector
> --- FloatQuaternion
> --- --- FloatQuaternion32
> --- --- FloatQuaternion64
> to share quaternion specific code...
> 
> Any idea on this? If code sharing is not possible, at least some help to 
> keep both consistent...
> 

That would be the ideal.  But like you, I can only think of ways that
are a bit messy:

1) Traits (dependency complexity)
2) OMeta (using it as a templating system to emit both variants,
dependency complexity)
3) Using class composition rather than inheritance (adds a bit of
complexity as you would need to call something like myMatrix #contents
to actually get at the data to pass to FFI)

Probably the simplest solution short term is just keep a parallel class
hierarchy in the same package and ensure that they stay in sync using
test cases.

> > 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...
> 
> Yes... Although as OpenCL is close to C, I was thinking on a variant of 
> Slang... Especially after Bert did a translator Slang -> js
> 

However you go about it, just keep language abstraction in mind.  Just
as OpenGL continues to go through backwards-incompatible changes to
'fix' its abstraction layer issues, I suspect we're entering a similar
phase with OpenCL and CUDA.  We will likely end up with something
different such as Vulcan or Metal as the GPU compute standard a few
years from now.  Hopefully it won't take them as many iterations as it
has with OpenGL... (wishful thinking on my part, I fear)

> Cheers,
> Juan Vuletich

Thanks,
Phil