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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------