digitalmars.D - Why not extend array operations to full Fortran90 power ?
- Joachim Wuttke <j.wuttke fz-juelich.de> (12/12) Nov 16 2011 Compare
- Kagamin (3/19) Nov 16 2011 Hmm... well, yeah
- Timon Gehr (6/18) Nov 16 2011 I like it, but there is a problem:
- Xinok (3/15) Nov 16 2011 I think vector operations are designed to avoid turning them into loops....
- =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= (2/22) Nov 16 2011 Really? How would you do Y[] = X[] * X[] without a loop?
- Timon Gehr (11/33) Nov 16 2011 In the special case that the type of X and Y is eg. float[4], use SIMD :...
- Xinok (17/39) Nov 16 2011 That's not what I meant by it. Perhaps an example is in order:
- Robert Jacques (2/14) Nov 16 2011 Lack of developer man-hours. This has actually been discussed before and...
- Steve Teale (3/8) Nov 17 2011 Heard that line before Walter?
- Xinok (8/10) Nov 17 2011 I realized a problem with (2), it's actually not possible to rewrite it
- Timon Gehr (7/19) Nov 17 2011 zip is implemented in terms of core language features.
Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim
Nov 16 2011
Joachim Wuttke <j.wuttke fz-juelich.de> Wrote:Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimHmm... well, yeah http://d.puremagic.com/issues/show_bug.cgi?id=3395
Nov 16 2011
On 11/16/2011 08:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimI like it, but there is a problem: (2) is already valid code if you have these two overloads: float sin(float x); float[] sin(float[] x); So with your rule it would be ambiguous.
Nov 16 2011
On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimI think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin().
Nov 16 2011
On Wed, 16 Nov 2011 22:31:31 +0100, Xinok <xinok live.com> wrote:On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Really? How would you do Y[] = X[] * X[] without a loop?Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimI think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin().
Nov 16 2011
On 11/16/2011 10:48 PM, Simen Kjærås wrote:On Wed, 16 Nov 2011 22:31:31 +0100, Xinok <xinok live.com> wrote:In the special case that the type of X and Y is eg. float[4], use SIMD :o). Joachim's example points out an performance limitation of the current array vector operations: if we have Y[] = sin( X[] ); Then there is currently no way to implement an overload for sin such that it can benefit from RVO. It should be able to write the sinuses directly to Y, but it cannot. That is merely syntax though. copy(map!sin(X), Y); // good enough for me.On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Really? How would you do Y[] = X[] * X[] without a loop?Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimI think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin().
Nov 16 2011
On 11/16/2011 4:48 PM, Simen Kjærås wrote:On Wed, 16 Nov 2011 22:31:31 +0100, Xinok <xinok live.com> wrote:That's not what I meant by it. Perhaps an example is in order: void main(){ int rand(){ rndGen.popFront(); return rndGen.front; } int[5] a; int[5] b = [1000, 2000, 3000, 4000, 5000]; a[] = b[] + (rand() % 1000); writeln(a); } This is the result: [1299, 2299, 3299, 4299, 5299] It adds the same random value to each element, meaning it only calls rand() once. D doesn't treat vector operations like loops.On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Really? How would you do Y[] = X[] * X[] without a loop?Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimI think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin().
Nov 16 2011
On Wed, 16 Nov 2011 14:08:33 -0500, Joachim Wuttke <j.wuttke fz-juelich.de> <j.wuttke fz-juelich.de> wrote:Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimLack of developer man-hours. This has actually been discussed before and is on Don's bubble list, IIRC, but there are a lot of other bug to fix before it.
Nov 16 2011
The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - JoachimHeard that line before Walter? I still have the T shirt. Steve
Nov 17 2011
On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:(1) Y[] = X[]*X[]; (2) Y[] = sin( X[] );I realized a problem with (2), it's actually not possible to rewrite it using existing constructs because foreach doesn't support multiple iterators. You can use std.range.zip: foreach(i; zip(Y, X)) i[0] = sin(i[1]); But it's not a core language feature. Before we could extend array operations to support the example above, I think D would need native support for multiple iterators.
Nov 17 2011
On 11/17/2011 07:48 PM, Xinok wrote:On 11/16/2011 2:08 PM, Joachim Wuttke <j.wuttke fz-juelich.de> wrote:Yes it is. D is Turing Complete!(1) Y[] = X[]*X[]; (2) Y[] = sin( X[] );I realized a problem with (2), it's actually not possible to rewrite it using existing constructsbecause foreach doesn't support multiple iterators. You can use std.range.zip: foreach(i; zip(Y, X)) i[0] = sin(i[1]); But it's not a core language feature.zip is implemented in terms of core language features.Before we could extend array operations to support the example above, I think D would need native support for multiple iterators.foreach supports indexed iteration: assert(Y.length == X.length); foreach(i,x; X) Y[i] = sin(x); But there are infinitely many ways to rewrite it.
Nov 17 2011