Hauke,
Thanks for your comments. I have been scribbling notes on howto go about
it, my initial thoughts are that I need:
genstar =: 3 : 0
generates an array of random numbers: initial x, initial y, dy, type
updstar =: 3 : 0
in-place updates y by adding dy*timer interval
if y is off screen then randomly reset this entry with y=0
Ha! This is going to be a lot of fun...
On Sun, 6 Dec 2020 at 20:36, 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
