I would be tempted to go with variables named X, Y and dY, I think. It's also possible to merge them into an array, and have rows for X, Y and dY, but my gut feeling is that that's not the right approach here. I could be wrong, of course.
-- Raul On Sun, Dec 6, 2020 at 3:36 PM Hauke Rehr <[email protected]> wrote: > > If the atoms of x, y and dy are all numbers (or tuples thereofª), > you can use a 3(or moreª)×(whatever common shape they have) array. > Index into them along the correct axes, and you’ll get > back (or modify) a triplet (or triplets) (again, or moreª). > > And updating ought to be done in place as much as possible. > You don’t do updating most of the time, but when you need to, > do it in place if at all possible. > You’re guaranteed to work in place if you immediately assign > back to the name of the structure you amend, for example. > Also, take a look at the special combinations. > Personally, I avoid boxing as much as possible. > > Then again, that’s just my thoughts and I’m far from > as experienced as the average person on this list, I guess. > > Am 06.12.20 um 21:13 schrieb emacstheviking: > > What's the conventional wisdom / best practice on defining data structures > > for an application? > > > > Given there is no explicit keyword/operator support like C (typdef, > > struct) is it merely a case of convention and using boxed structures. I > > have read several operators that can modify structures both as new aliased > > copies and in-place modifications but I do not have the experience with J > > to know what's efficient at run time in time / memory etc. > > > > My specific use case is that of a vertically scrolling star field... I > > intend to recreate and hopeful extend the tiny little game I wrote but > > never finished, screenshot here: > > http://seancharles.xyz/posts/2019-10-06-all-at-c.html > > > > In that I had a struct that had the x, y, dy and type values but it seems > > to me that given that J is all about arrays, it might be more efficient > > using parallel arrays i.e. x array, y array, dy array etc. > > > > Also, given that the state is being updated in a tight event loop using the > > time differential between frames to calculate the step motion (i.e. CPU > > speed independently), what are your thoughts on immutable updates producing > > new arrays or updating in place ? > > > > Thanks, > > Sean. > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > -- > ---------------------- > mail written using NEO > neo-layout.org > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
