Problem with mixed float int lists
ChucK does not admit explicit lists with numbers bot having and not having the decimal point, as in the example below. The problem is really that I made a program that writes tuning data to a file, which then should be pasted back into a .ck file. If the float value has not fractional part, 'chuck' writes it without decimal point. For example, it writes 440 Hz not 440.0 Hz. The first idea would be have 'chuck' always writing floats with a decimal point. But if the tuning data comes from some other source, it may not have a decimal point. One then ends up editing this data by hand, which is cumbersome. So I think 'chuck' should be able to convert explicit mixed float-int lists to float[]. There might also be some floats formatting capabilities. Hans ---- float_int_list.ck ---- [0.0, 1.0] @=> float as[]; // OK. [0, 1.0] @=> float bs[]; // array init [...] contains incompatible types... fun void f(float xs[]) {} f([0.0, 1.2]); // OK. f([0, 1.0]); // array init [...] contains incompatible types... f([0, 1]); // argument type(s) do not match: --------
The rule that 'chuck' seems to use on explicit lists is to look at the first entry. If that number is without a decimal point, the list is of type int[], if has one, it is float[]. It would be easy to fix: look at all entries, and set it to int[] exactly when all numbers are without a decimal point. One then still has to write separate function arguments of types float[] and int[]. A second rule might be that if an function argument of type int[] isn't defined in function argument overloading, passing an int[] list to an argument of type float[] will convert it. Hans
2009/12/9 Hans Aberg
The rule that 'chuck' seems to use on explicit lists is to look at the first entry. If that number is without a decimal point, the list is of type int[], if has one, it is float[].
Yes, and I agree this is at times inconvenient.
It would be easy to fix: look at all entries, and set it to int[] exactly when all numbers are without a decimal point.
I disagree. I want it to be set to float when I tell it to be a float. I may want to use a list of numbers without decimals as a float. This may be because the numbers will later change, or because of member function overloading (for example with LiSa.rate() it matters a lot whether the argument is a float or int), or because I want divisions to work in a certain way. As I see it array definitions are currently inconsistent with the implicit cast from int to float that we have elsewhere. Yours, Kas.
On 9 Dec 2009, at 23:03, Kassen wrote:
The rule that 'chuck' seems to use on explicit lists is to look at the first entry. If that number is without a decimal point, the list is of type int[], if has one, it is float[].
Yes, and I agree this is at times inconvenient.
It would be easy to fix: look at all entries, and set it to int[] exactly when all numbers are without a decimal point.
I disagree. I want it to be set to float when I tell it to be a float. I may want to use a list of numbers without decimals as a float. This may be because the numbers will later change, or because of member function overloading (for example with LiSa.rate() it matters a lot whether the argument is a float or int), or because I want divisions to work in a certain way.
So then you want the conversion rule of int[] to float[] in case no int[] argument has been defined. The problem is that one may define fun A f(int xs[]) {...} fun A f(float xs[]) {...} The rules I gave ensure that if both are defined, only a list where all numbers do not have a decimal point is treated as int[] and passed to the first definition. If one number has a decimal point, the whole list is treated as float[], and passed to the second function. If only the second function is defined, then I gave a second rule: the list which is int[] is converted to a float[]. So isn't this what you want? One could also think of the case where inly the first is defined. In C, float's can be converted to int's. As that may loose the decimal part in unintended ways, I think one should not have it.
As I see it array definitions are currently inconsistent with the implicit cast from int to float that we have elsewhere.
Then it would be consistent, I think. Hans
Hans, So isn't this what you want?
Hmmm, this is a tricky case, I see what you mean now. You are talking about callig overloaded functions using anonymous arrays, as a example of determining the type of these arrays, right? I see no real harm in your plan but mainly I think that this sounds quite dangerous as a practice and should probably be considered bad-ish form anyway. I don't have a strong opinion on this, right now. I thought you were talking about assigning a anonymous array to a named one at instantiation, like this; [1, 1.1, 1.2] @=> float foo[]; //this won't fly That's one case where I think it's perfectly clear what is meant and that the "1"(int) can safely be cast to float, as it can here; 1 => float bar; //this is fine This may be as bit of a exception because here we can determine very clearly what was meant, like we can when returning arrays from functions, but those are also the cases where I get annoyed by my own typos most. In the general case it does seem a bit odd indeed, though at least the behaviour is consistent and predictable. As a side note; some time ago I complained about the lack of anonymous arrays of length zero. Like this; [1,2] @=> int fine; [1] @=> int still_fine; [] @=> int fails; It turns out that we actually can. but need to do it like this; new int[0]; This can be handy when returning from functions. Yours, Kas.
On 10 Dec 2009, at 00:18, Kassen wrote:
So isn't this what you want?
Hmmm, this is a tricky case, I see what you mean now. You are talking about callig overloaded functions using anonymous arrays, as a example of determining the type of these arrays, right?
Yes, that is it how it appeared in my program. I post a note about it here soon.
I see no real harm in your plan but mainly I think that this sounds quite dangerous as a practice and should probably be considered bad- ish form anyway. I don't have a strong opinion on this, right now.
Yes, one must think carefully as to not have bad rules - the risk is that some unexpected functions may be called.
I thought you were talking about assigning a anonymous array to a named one at instantiation, like this;
[1, 1.1, 1.2] @=> float foo[]; //this won't fly
That's one case where I think it's perfectly clear what is meant and that the "1"(int) can safely be cast to float, as it can here;
1 => float bar; //this is fine
Yes, and that is the first rule I want for arguments as well.
This may be as bit of a exception because here we can determine very clearly what was meant, like we can when returning arrays from functions, but those are also the cases where I get annoyed by my own typos most. In the general case it does seem a bit odd indeed, though at least the behaviour is consistent and predictable.
As a side note; some time ago I complained about the lack of anonymous arrays of length zero. Like this;
[1,2] @=> int fine; [1] @=> int still_fine; [] @=> int fails;
It turns out that we actually can. but need to do it like this;
new int[0];
This can be handy when returning from functions.
For consistency, [] should work as you suggest - that is how it is in Haskell, for example. It would be the normal thing. Hans
Hans; Yes, that is it how it appeared in my program. I post a note about it here
soon.
It's a interesting case, I hadn't considered it yet. I do feel that the current behavior does make some sense. It's simple and predictable. Your suggestion does have the advantage of being less punishing on what I feel is rather sensible shorthand typing. I think that might make sense.
Yes, one must think carefully as to not have bad rules - the risk is that some unexpected functions may be called.
Indeed. I wouldn't do this, I think, but I agree that it's interesting to contemplate what proper behavior should be. maybe we could use some sort of way of forcing the type of anonymous arrays?
Yes, and that is the first rule I want for arguments as well.
I think that one would be fine under your proposal, yes.
For consistency, [] should work as you suggest - that is how it is in Haskell, for example.
It would be the normal thing.
I think so, and I seem to remember Ge agreed back when I reported the issue. At least now I know how to get around it without defining separate length 0 arrays. Yours, Kas.
On 10 Dec 2009, at 00:52, Kassen wrote:
Yes, that is it how it appeared in my program. I post a note about it here soon.
It's a interesting case, I hadn't considered it yet. I do feel that the current behavior does make some sense. It's simple and predictable. Your suggestion does have the advantage of being less punishing on what I feel is rather sensible shorthand typing. I think that might make sense.
I just made the program available. So you can try it. If you have some cents values from some source, you can try pasting it into the program. Then one does not want to fiddle around with the data, especially if one has many tunings..
Yes, one must think carefully as to not have bad rules - the risk is that some unexpected functions may be called.
Indeed. I wouldn't do this, I think, but I agree that it's interesting to contemplate what proper behavior should be. maybe we could use some sort of way of forcing the type of anonymous arrays?
The next step would be to have 'chuck' reading and parse it from a text file. But I like haviong it all into one file - easier to distribute. Hans
participants (2)
-
Hans Aberg -
Kassen