# Array2D newSize:

 Classic List Threaded
10 messages
Reply | Threaded
Open this post in threaded view
|

## Array2D newSize:

 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.  - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 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)
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 On Wed, 2015-07-15 at 15:23 -0700, Dan Norton wrote: > 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. > 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) > (whew) > > > > > -- > View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html> Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 In reply to this post by Dan Norton 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
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 In reply to this post by Dan Norton On 7/15/2015 7:23 PM, Dan Norton wrote: > 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) 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
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 In reply to this post by Phil B 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
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 In reply to this post by Juan Vuletich-4 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: > On 7/15/2015 7:23 PM, Dan Norton wrote: >> 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) > > 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> _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 In reply to this post by Juan Vuletich-4 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 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 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 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

## Re: Array2D newSize:

 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 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org