Array2D newSize:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

<quote author="Dan Norton">
Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2@3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces: MatrixTransform2x3(
1.0 0.0 0.0
0.0 1.0 0.0
)

Please correct me if I'm wrong.

OK, you're wrong - as long as there is a subclass called Matrix in

LinearAlgebra.pck.st

Use Matrix instead of Array2d.

(whew)

On Wed, 2015-07-15 at 15:23 -0700, Dan Norton 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?

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)



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Dan,

On 7/15/2015 12:54 PM, Dan Norton wrote:

Maybe it's my dyslexia, but isn't this backward?

It is not you. It is the unfortunate fact that 2 conventions exist for this

"Array2D newSize: 2@3" produces an array with 3 rows and 2 columns:

| nil nil |

| nil nil |

| nil nil |

Yes. 2@3 is a point with x=2 and y=3. x is usually regarded as the horizontal coordinate and y as the vertical coordinate. This is the universal convention for pixels in Displays and Forms and for mathematical points in the Cartesian plane.

IMO it should be:

| nil nil nil |

| nil nil nil |

Yes. That's why Array2D class also has #height:width: and #width:height. Matrices are usually accessed with i, j; where i is the row and j the column. Array2D instances have #x:y: and #i:j: , and the order of the arguments is swapped. So you can pick the convention that bests suits what you are doing.

For example, in Squeak, "MatrixTransform2x3 identity" produces: MatrixTransform2x3(

1.0       0.0       0.0

0.0       1.0       0.0

)

Yes. It uses the matrix convention.

Please correct me if I'm wrong.

 - Dan

 HTH.

In addition to all this Matrices have origin (1,1), while the mathematical plane and Forms have origin (0,0). But Matrices and Forms have the origin at the topLeft, while the mathematical plane has the origin at the bottomLeft (or at the center if you allow negative coordinates).

To make things even more complicated, when mapping the mathematical plane to a Form, you can map integer numbers in the plane to the center of the pixels (the convention that makes most sense to me) or to pixel corners (as Squeak / Cuis Rectangles do).

All unnecesary complications, but that we can't avoid.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On 7/15/2015 7:23 PM, Dan Norton wrote:
No, you are not wrong.

But use Matrix, or maybe FloatMatrix if it makes sense for you.

Also keep in mind that Cuis has AffineTransformation, that is almost
identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some
very arguable rounding to integer of results).

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

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.

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

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

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Created an issue for me to sometime later this year add to the documentation

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/68

--Hannes

On 7/16/15, Juan Vuletich <[hidden email]> wrote:
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
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...)

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


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

On 7/16/2015 5:13 PM, Phil (list) wrote:
:) 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 )

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

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

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Fri, 2015-07-17 at 11:15 -0300, Juan Vuletich wrote:
Just aim for Apple Maps level of precision and call it good enough :-)

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)

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)

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

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.

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


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org