Yes, I did indeed just notice I had made a mistake with the ;.
My state spaces typically have more than two values, so they're more likely
hundreds-by-hundreds instead of 2-by-2.
What does the "right dimensions for locality" mean? Are you referring to
the memory addresses (to make sure I'm not jumping all over the place) or
what does "locality" mean in this context? Sorry if this is basic stuff.
On Thursday, September 17, 2015 at 11:25:45 PM UTC-4, Steven G. Johnson
wrote:
>
>
>
> On Thursday, September 17, 2015 at 11:11:57 PM UTC-4, Patrick Kofod
> Mogensen wrote:
>>
>> Second, I can create a vector, and store [F1; F2] as F, and simply do
>> F[1] to access F given a = 1, and F[2] to access F given a = 2. I think it
>> makes the code so much easier to read when looping over A = {1, 2, ..., J}
>> - but I am not sure if it is a good idea or not performance wise. Since
>> I've done this so many times, I really just wanted to put my ignorance out
>> there, and ask if there is a particular reason why I shouldn't be doing
>> this, and if there is some other great way to do it.
>>
>
> This is perfectly reasonable, and there is no reason it can't be fast. (I
> think you mean [F1, F2] rather than [F1; F2], as the latter concatenates
> into a single matrix.)
>
> The only case I can think of where it would be better to use a single
> concatenated matrix would be if your individual F1 and F2 matrices were
> tiny (say 2x2), in which case it might be better to avoid the slight cost
> of the nested indexing operations. But you wouldn't want to use slicing
> either in that case (which does indeed create a temporary array): you would
> want to index directly into the big matrix via F[i, j+offset] (taking care
> to concatenate along the right dimensions for locality!) and inline
> everything. But it doesn't sound like that level of micro-optimization is
> going to be worth it for you.
>
