Re: problem with multiwayMerge and chunkBy
On Sunday, 5 November 2017 at 22:47:10 UTC, Nicholas Wilson wrote: f.multiwayMerge.chunks(128).joiner.chunkBy!(pred).writeln; since it seems to be the iteration that stuff things up and this changes it. If that doesn't work you could try rolling your own version of chunk with `take` and a static array.
Re: problem with multiwayMerge and chunkBy
On Sunday, 5 November 2017 at 13:32:57 UTC, Matthew Gamble wrote:
On Sunday, 5 November 2017 at 03:21:06 UTC, Nicholas Wilson
wrote:
On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble
wrote:
[...]
It should, this looks like a bug somewhere, please file one at
issues.dlang.org/ .
in the mean time
struct Replicate(T)
{
Tuple!(T, uint) e;
@property bool empty() { return e[1] == 0 ; }
@property auto front() {return e[0]; }
void popFront() { --e[1]; }
}
Replicate!T replicate(T)(Tuple!(T, uint) e)
{
return typeof(return)(e);
}
f.multiwayMerge.group!"a == b".map!(replicate).writeln;
Does the same thing provided your predicate is "a == b".
Thanks Nicholas.
I posted the bug as you suggested. My predicate is not quite a
== b, otherwise I would never have needed chunkBy in the first
place. But thanks, I'm pursuing a workaround.
Matt
One thing you might try is instead of using .array to eagerly
evaluate the whole range, eagerly evaluate only a part (say 128
elements) and .joiner them.
import std.range : chunks;
f.multiwayMerge.chunks(128).joiner.chunkBy!(pred).writeln;
since it seems to be the iteration that stuff things up and this
changes it.
Re: problem with multiwayMerge and chunkBy
On Sunday, 5 November 2017 at 03:21:06 UTC, Nicholas Wilson wrote:
On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble
wrote:
[...]
It should, this looks like a bug somewhere, please file one at
issues.dlang.org/ .
in the mean time
struct Replicate(T)
{
Tuple!(T, uint) e;
@property bool empty() { return e[1] == 0 ; }
@property auto front() {return e[0]; }
void popFront() { --e[1]; }
}
Replicate!T replicate(T)(Tuple!(T, uint) e)
{
return typeof(return)(e);
}
f.multiwayMerge.group!"a == b".map!(replicate).writeln;
Does the same thing provided your predicate is "a == b".
Thanks Nicholas.
I posted the bug as you suggested. My predicate is not quite a ==
b, otherwise I would never have needed chunkBy in the first
place. But thanks, I'm pursuing a workaround.
Matt
Re: problem with multiwayMerge and chunkBy
On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble
wrote:
Dear most helpful and appreciated D community,
I'm a non-pro academic biologist trying to code a modeler of
transcription in D. I've run into a small roadblock. Any help
would be greatly appreciated. I'm hoping someone can tell me
why I get the following run-time error from this code. I've
reduced it to something simple:
import std.algorithm;
import std.range;
auto d =[2,4,6,8];
auto e =[1,2,3,5,7];
auto f =[d,e];
writeln(f.multiwayMerge.chunkBy!"a == b");//error happens
writeln(f.multiwayMerge.array.chunkBy!"a == b");//no
error, but there must be a better way!
My understanding is that chunkBy should be able to take an
input range. Is that not true? I'm trying to get a merged
sorted view of two sorted ranges followed by merging records
based on a predicate without allocating memory or swapping the
underlying values. Speed will be very important at the end of
the day and sticking the ".array" in the middle kills me, given
the size of the actual ranges.
It should, this looks like a bug somewhere, please file one at
issues.dlang.org/ .
in the mean time
struct Replicate(T)
{
Tuple!(T, uint) e;
@property bool empty() { return e[1] == 0 ; }
@property auto front() {return e[0]; }
void popFront() { --e[1]; }
}
Replicate!T replicate(T)(Tuple!(T, uint) e)
{
return typeof(return)(e);
}
f.multiwayMerge.group!"a == b".map!(replicate).writeln;
Does the same thing provided your predicate is "a == b".
