Hi, list, I find ChucK's reaction to the following lines rather surprising. //this works, obviously 1.0 => float foo; //this is fine with chuck as well 1 => float bar; //this works as well, also obviously [1.0] @=> float fooray[]; //then why does this cause a error? [1] @=> float barray[]; Is this intentional and if so could we considder a more readable error? Right now this last line gives a error that looks (to me) like the dimentions of a multi-dimentional array don't add up which is a bit confusing Yours, Kas.
Hi, The error that I get is this: [newtest.ck]:line(9): cannot assign '@=>' on types 'int[]' @=> 'float []'... [newtest.ck]:line(9): ...(reason: --- incompatible types for assignment) What is happening is that the implicit cast of an int to a float that happens in non-array land isn't happening inside of the array. Remember that if you put a number on the left then you are initializing the values and if you put the numbers in the bracket beside the type you are declaring the size of the array. // an array of size 1 with a value of 9 [9] @=> int foo[]; // sparse array with a size of 9 with the value 1 at index 0 [1] @=>int bar[9]; You seem to be a bit confused about the meaning of these lines. But yes, there is a bug there, just not the one you thought. --art On 11-Nov-06, at 12:23 PM, Kassen wrote:
Hi, list,
I find ChucK's reaction to the following lines rather surprising.
//this works, obviously 1.0 => float foo; //this is fine with chuck as well 1 => float bar;
//this works as well, also obviously [1.0] @=> float fooray[]; //then why does this cause a error? [1] @=> float barray[];
Is this intentional and if so could we considder a more readable error? Right now this last line gives a error that looks (to me) like the dimentions of a multi-dimentional array don't add up which is a bit confusing
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
What is happening is that the implicit cast of an int to a float that happens in non-array land isn't happening inside of the array.
Yes, I got that, that's the problem I wanted to report, also see below for complications. Remember that if you put a number on the left then you are
initializing the values and if you put the numbers in the bracket beside the type you are declaring the size of the array.
Yeah, I think I understood that correctly, maybe it didn't come across from my examples. I tried to simplify those as much as possible but typed them from memory since I'm on a borowed computer and didn't think it would be correct to go install ChucK everywhere. This might've been unclear or even incorect, sorry. Actually, I think it's a bit more mysterious then what we argeed on above. I encountered this bug/feature when dealing with a 3x3 array of floats that I wanted to asign a set of values too. These values went something like this; [ [-1.25, -1, -0.75], [0, 1, 0], [1.25, 1, 0.75]] @=> float foo[][]; Asignment kept failing, I kept looking and couldn't find the issue. This isn't improved by ChucK talking about a "@array" or something along those lines. After much frustration I tried asigning the sub-arrarys one by one and discovered the first went in fine and it was only the second one that caused a issue. It seems to me that you can asign a array that holds ints to a array of floats with implicit casting as long as there is at least one float already in there (notice the integer -1 in the first one, that one seems fine with ChucK). I think this should be fine; [ [-1.25, -1, -0.75], [0, 1.0, 0], [1.25, 1, 0.75]] @=> float foo[][]; But I think I padded every int in sight with a extra ".0" to be sure. I hope that clarifies? Yours, Kas.
participants (2)
-
Adam Tindale -
Kassen