.cap() for multi-dimensional arrays
Fellow ChucKists....
First; .cap() for multi-dimensional arrays isn't documented but works.
If we have this;
int foo[3][5];
then this;
<<
mån 2007-10-01 klockan 06:47 +0200 skrev Kassen:
Fellow ChucKists....
First; .cap() for multi-dimensional arrays isn't documented but works.
If we have this; int foo[3][5];
then this; <<
>>; will return "3". We can get the 5 by using this; <<
>>; Other numbers then 0 are also supported as long as it smaller then foo.cap() (otherwise we get a array out of bound error) so 0 is safest.
Next up; is this correct? The need for that "0" strikes me as rather in-elegant but omitting it results in a syntax error.
Eh? What are you... Hm... Okay, I can see your point now. You're right. Since we are dealing with arrays, every array inside foo[i] will be of equal length; it's not like we are dealing with lists where every slot is just a reference to another object. Good thinking there. Gasten
On 10/1/07, Martin Ahnelöv
Since we are dealing with arrays, every array inside foo[i] will be of equal length; it's not like we are dealing with lists where every slot is just a reference to another object.
Good thinking there.
It gets very useful. Suppose we have two positive integers X and Y in a file so that; ----------------------------------------------------------- array[X][Y] @=> Foo.foo_array; Foo foo; public class Foo { static int foo_array[][]; fun void bar(int blah) { ................ } } ---------------------------------------------------------- Because Foo is a public class holding a static array the array needs to be instantiated outside of the class or there will be errors. Now if Foo.bar() does something to that array it becomes quite important to determine what it's dimensions are, however, both X and Y are outside of Foo's namespace and it's quite possible that there will be many instances of Foo that are in different files altogether which won't have X or Y. At that point the .cap()'s of multi-dimensional arrays become very interesting so I thought I'd share because it's not in the manual nor does my workaround look very nice. Also; this took a while to figure out and it makes no sense for others to spend that time too. Yours, Kas.
It makes sense when you think of multi dimensional arrays as just arrays of arrays. Additionally each sub-array need not be of equal length. Try running this code for example: int a[4][5]; <<< "here", "" >>>; for( 0 => int i; i < a.cap(); i++ ) <<< a[i].cap(), "" >>>; <<< "there", "" >>>; int b[4] @=> a[1]; for( 0 => int i; i < a.cap(); i++ ) <<< a[i].cap(), "" >>>; In this case if you relied on a[0].cap() specifying the length for each sub-array you could get yourself a NullPointerException trying to access a[0][4]. spencer On Oct 1, 2007, at 2:49 AM, Kassen wrote:
On 10/1/07, Martin Ahnelöv
wrote: Eh? What are you... Hm... Okay, I can see your point now. You're right. Since we are dealing with arrays, every array inside foo[i] will be of equal length; it's not like we are dealing with lists where every slot is just a reference to another object.
Good thinking there.
It gets very useful. Suppose we have two positive integers X and Y in a file so that; ----------------------------------------------------------- array[X][Y] @=> Foo.foo_array; Foo foo;
public class Foo { static int foo_array[][];
fun void bar(int blah) { ................ } } ----------------------------------------------------------
Because Foo is a public class holding a static array the array needs to be instantiated outside of the class or there will be errors. Now if Foo.bar() does something to that array it becomes quite important to determine what it's dimensions are, however, both X and Y are outside of Foo's namespace and it's quite possible that there will be many instances of Foo that are in different files altogether which won't have X or Y.
At that point the .cap()'s of multi-dimensional arrays become very interesting so I thought I'd share because it's not in the manual nor does my workaround look very nice. Also; this took a while to figure out and it makes no sense for others to spend that time too.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 10/3/07, Spencer Salazar
It makes sense when you think of multi dimensional arrays as just arrays of arrays. Additionally each sub-array need not be of equal length.
Ah! I didn't think your could do that, I had assumed the sub-arrays needed to be equal length. In that case I withdraw my comment about the need for the index being ugly, obviously. In that case it's also quite coherent that we need ask to get the .cap() for higher dimensions in exactly that way but I still think a note about this in the manual couldn't hurt. Thanks for the demonstration! Kas.
In some languages (like C) multi-dimensional arrays do need to be rectangular. This is because it's really just one big array. i.e. If you int foo[2][3]; you're doing exactly the same as int foo[6]; except that the compiler will do a bit of sugar for you and multiply your outer index by the inner array size and add it to your inner index. In java this is not the case because each index into your outer array is infact a ref to an array object. _Mark On Oct 3, 2007, at 6:54 AM, Kassen wrote:
On 10/3/07, Spencer Salazar
wrote: It makes sense when you think of multi dimensional arrays as just arrays of arrays. Additionally each sub-array need not be of equal length. Ah! I didn't think your could do that, I had assumed the sub- arrays needed to be equal length.
In that case I withdraw my comment about the need for the index being ugly, obviously. In that case it's also quite coherent that we need ask to get the .cap() for higher dimensions in exactly that way but I still think a note about this in the manual couldn't hurt.
Thanks for the demonstration!
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (4)
-
Kassen
-
Mark Pauley
-
Martin Ahnelöv
-
Spencer Salazar