digitalmars.D.bugs - [Issue 3661] New: opPow not supported in array operations.
- d-bugmail puremagic.com (57/57) Dec 31 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (15/23) Dec 31 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (13/13) Jan 03 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (28/43) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (12/12) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (12/15) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (10/22) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (8/21) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (10/56) Jan 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (21/30) Nov 21 2010 Now I see. I had no idea that SSE do not have nacassary instructions for...
- d-bugmail puremagic.com (12/12) Aug 21 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (10/10) Aug 21 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (12/12) Aug 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3661
- d-bugmail puremagic.com (6/6) Aug 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3661
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Summary: opPow not supported in array operations. Product: D Version: 2.036 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: baryluk smp.if.uj.edu.pl 20:48:57 PST --- This is agains 2.037. void main() { float[2] a,b,c; a = [8.33, 7.11]; b = [2.1, 3.1]; double[2] d = [2.11, 3.11]; int[2] e = [4,5]; double[2] f; // this should work //c[] = a[] ^^ b[]; // Error: float[] ^^ float[] is not supported //f[] = d[] ^^ d[]; // Error: double[] ^^ double[] is not supported // just like c[] = a[] * c[]; // works // if possible this also //c[] = 2.0f ^^ b[]; // Error: float ^^ float[] is not supported //c[] = a[] ^^ 2.0f; // Error: float[] ^^ float is not supported //f[] = d[] ^^ 2.0; // Error: double[] ^^ double is not supported //f[] = 2.0 ^^ d[]; // Error: double ^^ double[] is not supported // and then this also (relevant opPow is working). //c[] = a[] ^^ e[]; // Error: float[] ^^ int[] is not supported //f[] = d[] ^^ e[]; // Error: double[] ^^ int[] is not supported //c[] = a[] ^^ 2; // Error: float[] ^^ int is not supported //f[] = d[] ^^ 2; // Error: double[] ^^ int is not supported // and eventually this also, but this part involves mixed types, // and there is no opPow(double,float) //c[] = 2.0 ^^ b[]; // Error: double ^^ float[] is not supported //f[] = d[] ^^ a[]; // Error: double[] ^^ float[] is not supported // or opPow(float,double), //f[] = a[] ^^ 2.0; // Error: float[] ^^ double is not supported //f[] = a[] ^^ d[]; // Error: float[] ^^ double[] is not supported // similary this doesnt work currently //c[] = a[] * d[]; // Error: incompatible types for ((a[]) * (e[])): 'float[]' and 'double[]' //c[] = a[] * e[]; // Error: incompatible types for ((a[]) * (e[])): 'float[]' and 'int[]' } btw. also this in opPow doesnt work float pi = 3.14; float x = pi ^^ 2.0; one needs explicitly write 2.0f (this is because std.math.pow have only one F template parameter, and compiler doesn't know which to infer). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 31 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.auThis is agains 2.037. btw. also this in opPow doesnt work float pi = 3.14; float x = pi ^^ 2.0; one needs explicitly write 2.0f (this is because std.math.pow have only one F template parameter, and compiler doesn't know which to infer).This works in 2.038. Please ignore opPow in 2.037, it wasn't intended to be complete. Perform all tests on 2.038. As for the other ones -- opPow for array operations, where the exponent is not a compile-time constant, will probably never be supported. We could manage things like z[] = x^^2 + y^^2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 31 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rejects-valid CC| |smjg iname.com Summary|opPow not supported in |^^ not supported in array |array operations. |operations. What, exactly, has opPow to do with anything? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 03 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 09:58:12 PST ---Yes, it works correctly. Also when exponent is int or uint. Very good.This is agains 2.037. btw. also this in opPow doesnt work float pi = 3.14; float x = pi ^^ 2.0; one needs explicitly write 2.0f (this is because std.math.pow have only one F template parameter, and compiler doesn't know which to infer).This works in 2.038. Please ignore opPow in 2.037, it wasn't intended to be complete. Perform all tests on 2.038.As for the other ones -- opPow for array operations, where the exponent is not a compile-time constant, will probably never be supported. We could manage things like z[] = x^^2 + y^^2.Definitly this would be move in good direction, especially if such expressions (with positive integer exponent) will be rewriten by compiler in optimal way (ie. in case of x^^4 only two multiplications per term than 3). But also float exponents are needed, thinks like z[] = x^^-2.5, are quite common in many fields. There are also few computational methods where exponents (floats) are variable in time. They are especially popular in case of optimalisation, adaptative ordinary differential equation solvers, and many others. Exponents are there slowly varied from one end to another (exponents are uniformly varied over whole array): e = 3.0 - (1.0*i)/N; z[] = x[]^^e There are also some methods where it is completly variable: z[] = x[]^^e[]; I don't know many methods which use them personally, but it doesn't mean that they shouldn't be provided. Actually any formula which have exponent (ie. Stirling's approximation) can be used to compute multiple values in parallel, so it should be possible to "vectorize" them easly. Having implementation with float expontents I don't see big obstacles to implement also variable exponents. Actually any limitation in compiler of this form can also limit people in using so expressive things like array operations. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Andrei Alexandrescu <andrei metalanguage.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei metalanguage.com 10:14:21 PST --- Floating-point exponents means the result type must be complex, which at least for the moment complicates migrating to a library-only implementation of complex numbers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 10:30:51 PST ---Floating-point exponents means the result type must be complex, which at least for the moment complicates migrating to a library-only implementation of complex numbers.No, it only means that some results will be NaN's. :) But yes, complex result should also be supported, this can be determined when left operand (base) is also complex (but then in many cases imaginary parts will be 0, which is waste). BTW. I don't see anything wrong with compiler implemntation of complex numbers. Actually i see them supperior to the library-only implemntation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 10:33:45 PST ----1.0^^0.5 has complex type.Floating-point exponents means the result type must be complex, which at least for the moment complicates migrating to a library-only implementation of complex numbers.No, it only means that some results will be NaN's. :) But yes, complex result should also be supported, this can be determined when left operand (base) is also complex (but then in many cases imaginary parts will be 0, which is waste).BTW. I don't see anything wrong with compiler implemntation of complex numbers. Actually i see them supperior to the library-only implemntation.In that case it would be great if you came forth with the appropriate arguments. We just convinced ourselves that superiority goes the other way around. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 10:36:41 PST ---pow(-1.0, 0.5) is of type real and have value NaN. http://www.digitalmars.com/d/2.0/phobos/std_math.html#pow -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: --------1.0^^0.5 has complex type.Floating-point exponents means the result type must be complex, which at least for the moment complicates migrating to a library-only implementation of complex numbers.No, it only means that some results will be NaN's. :) But yes, complex result should also be supported, this can be determined when left operand (base) is also complex (but then in many cases imaginary parts will be 0, which is waste).
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661The problem is that they're not going to be efficiently vectorized. It'd be possible to have x[] ^^ y[] become arrayPow(x, y); but array pow would just be a for-loop of calls to pow(). I guess what I'm saying is that there'd be no performance benefit.Yes, it works correctly. Also when exponent is int or uint. Very good.This is agains 2.037. btw. also this in opPow doesnt work float pi = 3.14; float x = pi ^^ 2.0; one needs explicitly write 2.0f (this is because std.math.pow have only one F template parameter, and compiler doesn't know which to infer).This works in 2.038. Please ignore opPow in 2.037, it wasn't intended to be complete. Perform all tests on 2.038.As for the other ones -- opPow for array operations, where the exponent is not a compile-time constant, will probably never be supported. We could manage things like z[] = x^^2 + y^^2.Definitly this would be move in good direction, especially if such expressions (with positive integer exponent) will be rewriten by compiler in optimal way (ie. in case of x^^4 only two multiplications per term than 3). But also float exponents are needed, thinks like z[] = x^^-2.5, are quite common in many fields. There are also few computational methods where exponents (floats) are variable in time. They are especially popular in case of optimalisation, adaptative ordinary differential equation solvers, and many others. Exponents are there slowly varied from one end to another (exponents are uniformly varied over whole array): e = 3.0 - (1.0*i)/N; z[] = x[]^^e There are also some methods where it is completly variable: z[] = x[]^^e[]; I don't know many methods which use them personally, but it doesn't mean that they shouldn't be provided. Actually any formula which have exponent (ie. Stirling's approximation) can be used to compute multiple values in parallel, so it should be possible to "vectorize" them easly.Having implementation with float expontents I don't see big obstacles to implement also variable exponents. Actually any limitation in compiler of this form can also limit people in using so expressive things like array operations.-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 18:04:00 PST ---Now I see. I had no idea that SSE do not have nacassary instructions for this (log,exp,pow). But this is limitation of hardware vector unit. Language should not make such limitations. It is possible that new hardware will support more transcendental functions. Acutely there are some simple vector libraries, which implements missing SSE/AVX/AltiVec functions (sin/cos/sincos/exp/log/pow), and can be found in approximated, precise or strict versions. And even then (with software emulation) they are faster than just using scalar unit 4 times (and even faster for AVX with 8 single precision float operands) - just benchmarked some code from http://gruntthepeon.free.fr/ssemath/ on Intel Core2. When talking about ^^ operation, it is known that x ^^ y == exp(y * log(x)), and this is how this operation is implemented most often. Additionally if x is constant (like few of my examples), log(x) can be precomputed in compile-time. I'm not only fighting here about performance, but about clear and orthogonal usage of syntax. It should just work. Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I don't know many methods which use them personally, but it doesn't mean that they shouldn't be provided. Actually any formula which have exponent (ie. Stirling's approximation) can be used to compute multiple values in parallel, so it should be possible to "vectorize" them easly.The problem is that they're not going to be efficiently vectorized. It'd be possible to have x[] ^^ y[] become arrayPow(x, y); but array pow would just be a for-loop of calls to pow(). I guess what I'm saying is that there'd be no performance benefit.
Nov 21 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Iain Buclaw <ibuclaw ubuntu.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ibuclaw ubuntu.com --- Have raised a pull request to get this code accepted by the compiler. https://github.com/D-Programming-Language/dmd/pull/325 I did not make pow expressions commutative, so '2 ^^ T[]' is still rejected. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 21 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Iain Buclaw <ibuclaw ubuntu.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc --- *** Issue 6136 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 21 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED 20:32:55 PDT --- https://github.com/D-Programming-Language/dmd/commit/e0a1ece820ffd415f884c2ad5081d00623a3b163 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3661 See bug 6548 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 24 2011