[Cuis] Array2D newSize:

[Juan Vuletich]

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...

> (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 )

> 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.

>> 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.

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 :)

>>> 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...

> 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

Cheers,
Juan Vuletich