/* This one was a doozey... it took me about 2 hours to figure out this one, as I had rewritten some code, not thinking this could be the trouble... Anyway, it would appear Chuck doesn't differentiate between floats and arrays of floats when finding the proper function to call. I would think that this code would produce an output with a call to the B1, but when run, it actually calls the E1. Does ChucK treat floats and arrays of float the same when making this function determination? Well, yes it does, but should it? I would think, that if object oriented is a goal, then floats and arrays of floats would be treated differently. */ class B1 { fun void f(float f[]) { <<< "in B1.f", "" >>>; } } class E1 extends B1 { fun void f(float x, float y, float z) { <<< "in E1.f", "" >>>; } } class B2 { fun void f(float x, float y, float z) { <<< "in B2.f", "" >>>; } } class E2 extends B2 { fun void f(float f[]) { <<< "in E2.f", "" >>>; } } B1 b1; B2 b2; E1 e1; E2 e2; [ 0.1, 0.3, 0.7 ] @=> float myArray[]; b1.f(myArray); // in B1.f - correct e1.f(myArray); // in E1.f - wrong - should this actually call B1.f(myArray) e1.f(0.7, .553, 77); // in E1.f - correct b2.f(0.7, .553, 77); // in B2.f - correct e2.f(0.7, .553, 77); // in E2.f - wrong - should this actually call B2.f(0.7, .553, 77) e2.f(myArray); // in E2.f - correct //******* The following Java program illustrates what I was thinking should happen. Will ChucK follow what Java is doing? class Base1 { public String f(double x[]) { return "Base1"; } } class Ext1 extends Base1 { public String f(double x, double y) { return "Ext1"; } } class Base2 { public String f(double x, double y) { return "Base2"; } } class Ext2 extends Base2 { public String f(double x[]) { return "Ext2"; } } public class doit { public static void main(String[] args) { Base1 b1 = new Base1(); Ext1 e1 = new Ext1(); Base2 b2 = new Base2(); Ext2 e2 = new Ext2(); double myArray[] = { 0.7, .533, 75 }; System.out.println("b1: " + b1.f(myArray)); // b1: Base1 System.out.println("e1: " + e1.f(myArray)); // e1: Base1 System.out.println("e1: " + e1.f(0, 1)); // e1: Ext1 System.out.println("b2: " + b2.f(0, 1)); // b2: Base2 System.out.println("e2: " + e2.f(0, 1)); // e2: Base2 System.out.println("e2: " + e2.f(myArray)); // e2: Ext2 } } Thanks, Mike
Hi Mike! This one was a doozey indeed. ChucK should definitely treat float and arrays of floats as different types. After further investigation, this is due to a bug in the type checker, which incorrectly handles the function calling when the overridden function (B1.f(float[])) is the first one (of the same overloaded name) declared in the class. It actually had nothing to do with misconstruing float and float arrays (which seems to be handled correctly). A doozey, as we said. This has been fixed and committed in CVS. It will be in 1.2.0.5. Your test program should now behave correctly. Thanks again for finding and reporting this! Best, Ge! On Tue, 7 Feb 2006, Mike McGonagle wrote:
/* This one was a doozey... it took me about 2 hours to figure out this one, as I had rewritten some code, not thinking this could be the trouble...
Anyway, it would appear Chuck doesn't differentiate between floats and arrays of floats when finding the proper function to call. I would think that this code would produce an output with a call to the B1, but when run, it actually calls the E1.
Does ChucK treat floats and arrays of float the same when making this function determination? Well, yes it does, but should it?
I would think, that if object oriented is a goal, then floats and arrays of floats would be treated differently. */ class B1 { fun void f(float f[]) { <<< "in B1.f", "" >>>; } }
class E1 extends B1 { fun void f(float x, float y, float z) { <<< "in E1.f", "" >>>; } }
class B2 { fun void f(float x, float y, float z) { <<< "in B2.f", "" >>>; } }
class E2 extends B2 { fun void f(float f[]) { <<< "in E2.f", "" >>>; } }
B1 b1; B2 b2; E1 e1; E2 e2;
[ 0.1, 0.3, 0.7 ] @=> float myArray[];
b1.f(myArray); // in B1.f - correct e1.f(myArray); // in E1.f - wrong - should this actually call B1.f(myArray) e1.f(0.7, .553, 77); // in E1.f - correct b2.f(0.7, .553, 77); // in B2.f - correct e2.f(0.7, .553, 77); // in E2.f - wrong - should this actually call B2.f(0.7, .553, 77) e2.f(myArray); // in E2.f - correct
//*******
The following Java program illustrates what I was thinking should happen. Will ChucK follow what Java is doing?
class Base1 { public String f(double x[]) { return "Base1"; } }
class Ext1 extends Base1 { public String f(double x, double y) { return "Ext1"; } }
class Base2 { public String f(double x, double y) { return "Base2"; } }
class Ext2 extends Base2 { public String f(double x[]) { return "Ext2"; } }
public class doit { public static void main(String[] args) { Base1 b1 = new Base1(); Ext1 e1 = new Ext1(); Base2 b2 = new Base2(); Ext2 e2 = new Ext2();
double myArray[] = { 0.7, .533, 75 };
System.out.println("b1: " + b1.f(myArray)); // b1: Base1 System.out.println("e1: " + e1.f(myArray)); // e1: Base1 System.out.println("e1: " + e1.f(0, 1)); // e1: Ext1 System.out.println("b2: " + b2.f(0, 1)); // b2: Base2 System.out.println("e2: " + e2.f(0, 1)); // e2: Base2 System.out.println("e2: " + e2.f(myArray)); // e2: Ext2
} }
Thanks, Mike _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 2/7/06, Ge Wang
Thanks again for finding and reporting this!
Thanks for sharing ChucK with the world at large. While it may not be "ready for prime time" just yet (or I could be wrong), it sure is nice to progress so far on my work. I have basically re-written some things that I used in PureData, and have actually expanded on them to make (at least I hope) easier. The first package is a Masking Suite, ala Xenakis. This is pretty much ready for release. My second package is a Strange Attractor Suite. It was while I was working on this that I found the inheritance bug. I was very pleased to note that while ChucK may not be as fast as it could be, it is very surprising how fast it is. It was only this morning that I was able to test the "searching" functions that are used to find another set of chaotic parameters for an Attractor, and I was very happy that all the code that I translated from C was pretty much all I needed. Now it is just a matter of adding some more subclasses of Strange Attractors (other varieties of equations). I hope that I can post these up on the WIKI this weekend. Thanks again for such a great program. Mike
participants (2)
-
Ge Wang
-
Mike McGonagle