Hi All,

The original array implementation supported that opcodes would specify
array arguments but that they could be of any-dimension.  i.e.:

k[] someopcode k[]k[]

would be the specification, and--I think--the semantic analysis phase
only checked that arrays of k-type were used as args, but not the # of
dimensions.  This allows things like the init.0 opcode (in
Top/arrays.c) to work with:

k[] init 5
k[][] init 2, 4
etc.

However, I think now that this might be a mistake.  My rationale is that:

1. The compiler not checking the array dimensions means the # of
dimensions has to be checked at run-time

2. An array of x-dimensions and an array of y-dimensions really are
two different datatypes.  So for example in C,

int calculate(int args[], int count);

You could not do something like:

int args2[2][3];
int output = calculate(args2, 2);

(in the test.c program I just wrote I got "test.c:17: warning: passing
argument 1 of ‘calculate’ from incompatible pointer type")


My thought now is that we move to remove any-dimension args and
instead use the number of dimensions listed in the opcode arg
specifier.  What the impact I see is that we can still write opcode
functions that might work for any number of dimensions, but we would
need extra OENTRY's for each case.

 For example, for init, we would need something like:

    { "init", sizeof(ARRAYINIT), 0, 1, ".[]", "i", (SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][]", "ii", (SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][][]", "iii", (SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][]", "iiii", (SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][]", "iiiii",
(SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][]", "iiiiii",
(SUBR)array_init },
    { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][][]", "iiiiiii",
(SUBR)array_init },

They can all use the same array_init and ARRAYINIT, but now the
function types are specific per # of dimensions.  (I used up to 7 in
this example because I seem to remember some programming language
supporting up to 7 dimensions, but I can't recall which one.)

I think this would, in the end simplify things:

1. The semantic analyzer would catch issues earlier regarding wrong
dimensions used and can report it at compile time.

2. Opcode writers would not have to test if an array has x number of
dimensions.  That leaves less to do at run time.

3. Array opcodes won't have to all check dimensions and it can be
checked all in one place.


How does this sound to everyone?

Thanks!
steven

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I just compiled a Java class that has an instance field of a
24-dimensional array of ints. Awesome, but impractical.

Seems like your suggestion of having an OENTRY for each dimension
wouldn't scale well unless the C code for that could be dynamically
generated (I think NumPy does this for some of the math IIR

On 7/11/13, Steven Yi  wrote:
> Hi All,
>
> The original array implementation supported that opcodes would specify
> array arguments but that they could be of any-dimension.  i.e.:
>
> k[] someopcode k[]k[]
>
> would be the specification, and--I think--the semantic analysis phase
> only checked that arrays of k-type were used as args, but not the # of
> dimensions.  This allows things like the init.0 opcode (in
> Top/arrays.c) to work with:
>
> k[] init 5
> k[][] init 2, 4
> etc.
>
> However, I think now that this might be a mistake.  My rationale is that:
>
> 1. The compiler not checking the array dimensions means the # of
> dimensions has to be checked at run-time
>
> 2. An array of x-dimensions and an array of y-dimensions really are
> two different datatypes.  So for example in C,
>
> int calculate(int args[], int count);
>
> You could not do something like:
>
> int args2[2][3];
> int output = calculate(args2, 2);
>
> (in the test.c program I just wrote I got "test.c:17: warning: passing
> argument 1 of ‘calculate’ from incompatible pointer type")
>
>
> My thought now is that we move to remove any-dimension args and
> instead use the number of dimensions listed in the opcode arg
> specifier.  What the impact I see is that we can still write opcode
> functions that might work for any number of dimensions, but we would
> need extra OENTRY's for each case.
>
>  For example, for init, we would need something like:
>
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[]", "i", (SUBR)array_init },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][]", "ii", (SUBR)array_init },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][]", "iii", (SUBR)array_init
> },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][]", "iiii", (SUBR)array_init
> },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][]", "iiiii",
> (SUBR)array_init },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][]", "iiiiii",
> (SUBR)array_init },
>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][][]", "iiiiiii",
> (SUBR)array_init },
>
> They can all use the same array_init and ARRAYINIT, but now the
> function types are specific per # of dimensions.  (I used up to 7 in
> this example because I seem to remember some programming language
> supporting up to 7 dimensions, but I can't recall which one.)
>
> I think this would, in the end simplify things:
>
> 1. The semantic analyzer would catch issues earlier regarding wrong
> dimensions used and can report it at compile time.
>
> 2. Opcode writers would not have to test if an array has x number of
> dimensions.  That leaves less to do at run time.
>
> 3. Array opcodes won't have to all check dimensions and it can be
> checked all in one place.
>
>
> How does this sound to everyone?
>
> Thanks!
> steven
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Adam,

I'm not sure I understand what you're saying by it not scaling.  On
the whole, I think there should be individual OENTRY's per array
dimension type.  On the other hand, from the example I posted, code
can also be developed such that it can be used with multiple OENTRY's.
 So in the case of the multiple init entries, there was only one C
function and C struct used with all of the entries. The benefit then
is that the type and dimensions would be checked correctly by the
semantic analyzer, and then would not be be necessary to check at
runtime.

Also, you raise a point I had forgotten to mention: in practice, I
don't think it is common to use a large number of dimensions.  Even
seven dimensions seem excessive.  I've seen 2 dimensions regularly,
but I can't recall any code recently I've looked at that uses 3
dimensions.  I also don't think I've ever seen any more than 3.

steven

On Thu, Jul 11, 2013 at 3:20 PM, Adam Puckett  wrote:
> I just compiled a Java class that has an instance field of a
> 24-dimensional array of ints. Awesome, but impractical.
>
> Seems like your suggestion of having an OENTRY for each dimension
> wouldn't scale well unless the C code for that could be dynamically
> generated (I think NumPy does this for some of the math IIR
>
> On 7/11/13, Steven Yi  wrote:
>> Hi All,
>>
>> The original array implementation supported that opcodes would specify
>> array arguments but that they could be of any-dimension.  i.e.:
>>
>> k[] someopcode k[]k[]
>>
>> would be the specification, and--I think--the semantic analysis phase
>> only checked that arrays of k-type were used as args, but not the # of
>> dimensions.  This allows things like the init.0 opcode (in
>> Top/arrays.c) to work with:
>>
>> k[] init 5
>> k[][] init 2, 4
>> etc.
>>
>> However, I think now that this might be a mistake.  My rationale is that:
>>
>> 1. The compiler not checking the array dimensions means the # of
>> dimensions has to be checked at run-time
>>
>> 2. An array of x-dimensions and an array of y-dimensions really are
>> two different datatypes.  So for example in C,
>>
>> int calculate(int args[], int count);
>>
>> You could not do something like:
>>
>> int args2[2][3];
>> int output = calculate(args2, 2);
>>
>> (in the test.c program I just wrote I got "test.c:17: warning: passing
>> argument 1 of ‘calculate’ from incompatible pointer type")
>>
>>
>> My thought now is that we move to remove any-dimension args and
>> instead use the number of dimensions listed in the opcode arg
>> specifier.  What the impact I see is that we can still write opcode
>> functions that might work for any number of dimensions, but we would
>> need extra OENTRY's for each case.
>>
>>  For example, for init, we would need something like:
>>
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[]", "i", (SUBR)array_init },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][]", "ii", (SUBR)array_init },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][]", "iii", (SUBR)array_init
>> },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][]", "iiii", (SUBR)array_init
>> },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][]", "iiiii",
>> (SUBR)array_init },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][]", "iiiiii",
>> (SUBR)array_init },
>>     { "init", sizeof(ARRAYINIT), 0, 1, ".[][][][][][][][]", "iiiiiii",
>> (SUBR)array_init },
>>
>> They can all use the same array_init and ARRAYINIT, but now the
>> function types are specific per # of dimensions.  (I used up to 7 in
>> this example because I seem to remember some programming language
>> supporting up to 7 dimensions, but I can't recall which one.)
>>
>> I think this would, in the end simplify things:
>>
>> 1. The semantic analyzer would catch issues earlier regarding wrong
>> dimensions used and can report it at compile time.
>>
>> 2. Opcode writers would not have to test if an array has x number of
>> dimensions.  That leaves less to do at run time.
>>
>> 3. Array opcodes won't have to all check dimensions and it can be
>> checked all in one place.
>>
>>
>> How does this sound to everyone?
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net