Stuff
Actually now I realise what the conflict is between the two, a +
b * b would give the wrong answer when applied to the whole array
in the manner I was thinking by doing a + a * a for the first
value.
Without optimization the range and algorithm method takes about
10 times as long as the simple code below it, with no array
bounds checking and optimization it takes six times as long. Why
is the difference so huge? I'd expect a moderate overhead but
that's a big difference.
module main;
On Tuesday, 2 October 2012 at 20:48:31 UTC, ixid wrote:
Without optimization the range and algorithm method takes about
10 times as long as the simple code below it, with no array
bounds checking and optimization it takes six times as long.
Why is the difference so huge? I'd expect a moderate
On 10/02/2012 10:48 PM, ixid wrote:
Without optimization the range and algorithm method takes about 10 times
as long as the simple code below it, with no array bounds checking and
optimization it takes six times as long. Why is the difference so huge?
I'd expect a moderate overhead but that's a
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 = MAX.iota.map!(x = x * x).reduce!a + b;
sw.stop;
On Tuesday, 2 October 2012 at 22:13:10 UTC, Timon Gehr wrote:
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 =
On Tuesday, 2 October 2012 at 22:13:10 UTC, Timon Gehr wrote:
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 =
On Wednesday, 3 October 2012 at 01:21:38 UTC, ixid wrote:
If it were (range, seed) then there would be no problem:
[1,1,1].reduce!a + b + 2(0).writeln; // == 9
My thoughts exactly.
While fiddling with this I came across something that seems odd
in the behaviour of reduce and wondered if it's intended. It
rather limits the usefulness of reduce with UFCS to a + b and
a - b.
Reduce works correctly when provided with a seed argument:
reduce!a + b + 2(0, [1,1,1]).writeln;
A typical use case is to find the maximum of a range (there is
an example of this in the documentation at
http://dlang.org/phobos/std_algorithm.html#reduce). If you don't
know the highest possible value of elements, then you couldn't
come up with an appropriate seed for this case.
Fixing
10 matches
Mail list logo
