www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3661] New: opPow not supported in array operations.

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2009-12-31
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #1 from Don <clugdbug yahoo.com.au> 2009-12-31 23:08:16 PST ---
(In reply to comment #0)
 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 31 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


--- Comment #2 from Stewart Gordon <smjg iname.com> 2010-01-03 07:44:54 PST ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #3 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-01-31
09:58:12 PST ---
(In reply to comment #1)
 (In reply to comment #0)
 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.
Yes, it works correctly. Also when exponent is int or uint. Very good.
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com


--- Comment #4 from Andrei Alexandrescu <andrei metalanguage.com> 2010-01-31
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #5 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-01-31
10:30:51 PST ---
(In reply to comment #4)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #6 from Andrei Alexandrescu <andrei metalanguage.com> 2010-01-31
10:33:45 PST ---
(In reply to comment #5)
 (In reply to comment #4)
 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).
-1.0^^0.5 has complex type.
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #7 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-01-31
10:36:41 PST ---
(In reply to comment #6)
 (In reply to comment #5)
 (In reply to comment #4)
 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).
-1.0^^0.5 has complex type.
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: -------
Jan 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #8 from Don <clugdbug yahoo.com.au> 2010-01-31 11:27:59 PST ---
(In reply to comment #3)
 (In reply to comment #1)
 (In reply to comment #0)
 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.
Yes, it works correctly. Also when exponent is int or uint. Very good.
 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.
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.
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #9 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-11-21
18:04:00 PST ---
 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.
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: -------
Nov 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661


Iain Buclaw <ibuclaw ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw ubuntu.com


--- Comment #10 from Iain Buclaw <ibuclaw ubuntu.com> 2011-08-21 03:26:20 PDT
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661


Iain Buclaw <ibuclaw ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #11 from Iain Buclaw <ibuclaw ubuntu.com> 2011-08-21 03:28:23 PDT
---
*** 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #12 from Walter Bright <bugzilla digitalmars.com> 2011-08-23
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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #13 from bearophile_hugs eml.cc 2011-08-24 03:05:42 PDT ---
See bug 6548

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 24 2011