[Issue 6345] A different kind of vector operation
https://issues.dlang.org/show_bug.cgi?id=6345 --- Comment #6 from Nick Treleaven --- A less drastic change would be this syntax, which also solves the ambiguities: float*[] CBuffers = buffers[#].ptr; m[#][1] = 1.0; c[#] = a[#] < b[#]; // issue #5636 Note: issue #5636 was fixed by simply documenting that comparisons, equality, etc make the operation not a vector op, just an array comparison. --
[Issue 6345] A different kind of vector operation
https://issues.dlang.org/show_bug.cgi?id=6345 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #5 from Nick Treleaven --- List comprehensions would cover these and avoid any ambiguity. They are also more expressive and composable than vector ops: >auto foos = new Foo[100]; >foos[].y += 10; // [e.y += 10 for e in foos]; Note this doesn't need to allocate an array as the result is not used. > cdouble[100] foos; > foos[].re = 5.0; [e.re = 5.0 for e in foos]; > auto foos = new Foo[100]; > auto ints = new int[100] > ints = foos[].y; ints = [e.y for e in foos]; > float[] buffers = malloc...; > float*[] CBuffers = buffers[].ptr; float*[] cBuffers = [e.ptr for e in buffers]; Also, type inference could be used `auto cBuffers = ` because the RHS is no longer ambiguous with `float*`. (This would also solve Issue #2548). > auto M = new double[][](10, 20); > M[][1] = 1.0; [e[1] = 1.0 for e in m]; And indexes mean they can cover vector ops too: > a[] = b[] / c[]; a = [b[i] / e for i, e in c]; A benefit is that `b.length` can be larger than `c.length`. Also we can use the index variable e.g. to index b in reverse order. The key benefit however is that we can use expressions not supported by vector ops such as function calls, comparisons and the conditional operator - see issue #5636. --
[Issue 6345] A different kind of vector operation
https://issues.dlang.org/show_bug.cgi?id=6345 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 6345] A different kind of vector operation
https://issues.dlang.org/show_bug.cgi?id=6345 Andrei Alexandrescu changed: What|Removed |Added Version|unspecified |D2 --
[Issue 6345] A different kind of vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=6345 --- Comment #4 from bearophile_h...@eml.cc 2011-07-28 05:15:59 PDT --- (In reply to comment #3) > All these operations require the use of strided slices, which would be a huge > amount of work to implement. Also, there are a plethora of corner cases. I see. Those corner cases are bad. If you think this is too much work for the gain I'll close this enhancement request, to leave similar functionalities to matrix libraries. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6345] A different kind of vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=6345 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don 2011-07-28 00:36:12 PDT --- All these operations require the use of strided slices, which would be a huge amount of work to implement. Also, there are a plethora of corner cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6345] A different kind of vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=6345 --- Comment #2 from bearophile_h...@eml.cc 2011-07-27 13:56:06 PDT --- Another possible purpose. Given this matrix: auto M = new double[][](10, 20); This: M[][1] = 1.0; Means: foreach (row; p) row[1] = 1.0; This replaces some usages of std.range.transversal(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6345] A different kind of vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=6345
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #1 from kenn...@gmail.com 2011-07-18 12:44:34 PDT ---
What if I define
ref int y(Foo[] f) {
return f[0].x;
}
?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
