[Issue 3661] ^^ not supported in array operations.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Jan 31 11:28:04 PST 2010


http://d.puremagic.com/issues/show_bug.cgi?id=3661



--- Comment #8 from Don <clugdbug at 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: -------


More information about the Digitalmars-d-bugs mailing list