On 08.06.2010 23:41, Simen kjaeraas wrote:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and thus
check std.container.
Law of Least Astonishment. Never forget.
FeepingCreature wrote:
On 08.06.2010 23:41, Simen kjaeraas wrote:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and thus
check std.container.
Law of Least Astonishment. Never forget.
I made BinaryHeap a
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Instead of assuming that I'm simultaneously retard(ed) and stubborn
I'm sorry, that was not my intention.
I wrote BinaryHeap out of necessity. The necessity was to solve the
selection problem (see topN, topNIndex in std.algorithm)
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and thus
check std.container. If it was not there, I would use the search function
to
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and thus
check std.container. If it was
On 06/09/2010 06:20 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
It's a good point. I agree it would make sense to define a binary heap
container in addition to a binary heap range. I'm only weary that they
don't have very clean means to reuse code, so
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
The problem is that operating on a range as a heap is not just one
operation (i.e. heapify), it's a handful of them. STL took the approach
of providing make_heap, push_heap, pop_heap, sort_heap, and is_heap.
Their use is quite
On 06/09/2010 10:13 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
The problem is that operating on a range as a heap is not just one
operation (i.e. heapify), it's a handful of them. STL took the
approach of providing make_heap, push_heap, pop_heap,
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and
thus
On 2010-06-09 11:37:38 -0400, Don nos...@nospam.com said:
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and
thus
On 06/09/2010 02:48 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I
Andrei Alexandrescu wrote:
I wanted to do that but with the singular:
public import std.container.binaryheap;
So if someone imports std.container then they get them all, if someone
imports std.container.something then they only get something.
Having a module and a package with the same name
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Having a module and a package with the same name does not currently
work, and I don't think there's a good rationale for that limitation.
//
module a;
public import a.b;
struct b {
static int c;
}
//
Michel Fortin wrote:
Personally I'd draw the line like this: a module should contain
functions and types which are either tied in their implementation or
which their use are correlated (if you use this thing you'll likely
need this other one).
For instance, a tree set and a tree map are
Andrei Alexandrescu, el 9 de junio a las 14:59 me escribiste:
On 06/09/2010 02:48 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, Simen kjaeraas simen.kja...@gmail.com
said:
Now, my favorite way of dealing with
On 2010-06-09 15:44:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 06/09/2010 02:34 PM, Michel Fortin wrote:
Beside the size of the module, there is also the issue of namespace
pollution. If you import std.container and you end up with a dozen of
different containers
I finalized BinaryHeap. It's pretty cool - it builds a forward range on
top of a random-access range - typically T[] - or a random-access
container - typically Array!T.
The difference is simple - if you build on top of a range the heap can't
grow beyond the size of that range. Building on top
On Tue, 08 Jun 2010 10:47:33 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I finalized BinaryHeap. It's pretty cool - it builds a forward range on
top of a random-access range - typically T[] - or a random-access
container - typically Array!T.
The difference is simple -
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
I finalized BinaryHeap. It's pretty cool - it builds a forward range on
top of a random-access range - typically T[] - or a random-access
container - typically Array!T.
The difference is simple - if you build on top of a range the
On 06/08/2010 10:00 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
I finalized BinaryHeap. It's pretty cool - it builds a forward range
on top of a random-access range - typically T[] - or a random-access
container - typically Array!T.
The difference is
On 06/08/2010 10:04 AM, Steven Schveighoffer wrote:
On Tue, 08 Jun 2010 10:47:33 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I finalized BinaryHeap. It's pretty cool - it builds a forward range
on top of a random-access range - typically T[] - or a random-access
container -
On Tue, 08 Jun 2010 11:12:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 06/08/2010 10:04 AM, Steven Schveighoffer wrote:
On Tue, 08 Jun 2010 10:47:33 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I finalized BinaryHeap. It's pretty cool - it builds
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Let me be more specific: BinaryHeap does not work like a range. It _is_
a range. It implements all of a forward range's primitives with the
required semantics.
Is not anything that works like a range automatically a range?
But where
On Tue, 08 Jun 2010 11:53:06 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
I hold that a range is a view that does not change the underlying data,
and does not store all its data.
That makes an array a container, which I feel is correct. It may still
have range functionality, and thus
On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Let me be more specific: BinaryHeap does not work like a range. It
_is_ a range. It implements all of a forward range's primitives with
the required semantics.
Is not anything that works
On Tue, 08 Jun 2010 12:26:19 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I agree that a BinaryHeap built on top of a container may ultimately
affect the topology of the container, which makes it unlike e.g. Take or
Chain. I could choose to disallow that and simply
Steven Schveighoffer Wrote:
You might say the same about
an array, but an array is special in that if I append to one array, it
does not affect the other.
I don't know where it belongs. To me, a range is a type that in itself
cannot affect the topology of the data structure. It's like
On 2010-06-08 11:09:44 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
But where should I put it then? I thought it would be even more
confusing if I put something in std.container that wait a minute, is
not a container.
import std.binheap;
--
Michel Fortin
On 06/08/2010 12:29 PM, jlquinn wrote:
Steven Schveighoffer Wrote:
You might say the same about an array, but an array is special
in that if I append to one array, it does not affect the
other.
I don't know where it belongs. To me, a range is a type that in
itself cannot affect the topology of
On 06/08/2010 12:26 PM, Andrei Alexandrescu wrote:
On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
I hold that a range is a view that does not change the underlying data,
and does not store all its data.
That makes an array a container, which I feel is correct. It may still
have range
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
But where should I put it then? I thought it would be even more
confusing if I put something in std.container that wait a minute,
On Jun 9, 10 02:02, Michel Fortin wrote:
On 2010-06-08 11:09:44 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
But where should I put it then? I thought it would be even more
confusing if I put something in std.container that wait a minute, is
not a container.
import
On 06/08/2010 04:41 PM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
But where should I put it then? I thought it would be even more
confusing if I put
34 matches
Mail list logo
