Just curious, what is the status of this? Are there plans to implement
this change in Clojure?
Also curious if there's an existing lib that can be used now (I didn't come
across one for Clojure but there is a Scala lib from the authors of the
paper)...
Rob
On Fri, Nov 18, 2011 at 2:35 PM, logan
Are there currently any plans to eventually replace PersistentVector?
Looking at the code, the upper limit for the number of elements that can be
stored in PersistentVector is 32^6, which is quite a lot but still might
become a real limitation in the near future.
--
You received this message
On 15/11/2011, at 19.13, Justin Balthrop wrote:
> It wouldn't change the performance profile of existing programs because
> currently there isn't a way to concat two vectors and get a new vector. I
> don't envision changing the behavior of clojure.core/concat, that should
> still return a seq.
It wouldn't change the performance profile of existing programs because
currently there isn't a way to concat two vectors and get a new vector. I don't
envision changing the behavior of clojure.core/concat, that should still return
a seq. It seems better to create a new function like 'joinvec' t
On Tuesday, November 15, 2011, Justin Balthrop
wrote:
> My understanding from the talk was that RRB-Trees have performance
> identical to PersistentVector as long as you don't concat or split
> them. So why not just replace the PersistentVector implementation with
> an RRB-Tree?
I guess that cou
> This would be awesome. From his talk it sounds like it shouldn't replace
> PersistentVector at all, in fact you should be able to share structure with
> PersistentVector right?
My understanding from the talk was that RRB-Trees have performance
identical to PersistentVector as long as you don't c
Yeah, I found that one. I'll still go for the Java implementation to start with
(also makes it easier to put in clj-ds). Then gvec as a starting point for a
Clojure version (if I ever get there :). One thing I was wondering about: there
would be quite a bit of code I could reuse verbatim from g
You should definitely look at gvec.clj. It's a PersistentVector
implementation in Clojure but for the various primitive types.
David
On Sun, Nov 13, 2011 at 12:38 PM, Karl Krukow wrote:
>
> On 13/11/2011, at 18.14, David Nolen wrote:
>
> This would be awesome. From his talk it sounds like it sh
On 13/11/2011, at 18.14, David Nolen wrote:
> This would be awesome. From his talk it sounds like it shouldn't replace
> PersistentVector at all, in fact you should be able to share structure with
> PersistentVector right?
>
> David
>
Yes, I think so. If I understand correctly, one cool thin
This would be awesome. From his talk it sounds like it shouldn't replace
PersistentVector at all, in fact you should be able to share structure with
PersistentVector right?
David
On Sun, Nov 13, 2011 at 10:02 AM, Krukow wrote:
> By the way, I don''t see it as a replacement for PersistentVector,
By the way, I don''t see it as a replacement for PersistentVector, but
rather as an additional data structure, that could perhaps be put
somewhere in contrib if it turns out well.
/Karl
On Nov 13, 9:54 am, Karl Krukow wrote:
> Hi,
> Yes, Phil Bagwell presented that at the Conj.
>
> I'm really in
Hi,
Yes, Phil Bagwell presented that at the Conj.
I'm really interested in this stuff, so as an exercise in Clojure, I've started
thinking about how to implement it. At first I'll try and do it without looking
at Scala - if I get stuck I might peek a bit :)
If you're interested, I'll put it on
hi,
I just stumbled upon a paper on en enhanced immutable data structure
[0] that could be useful for Clojure implementation.
Could it enable batter parallel programming semantics as discussed by
Guy Steel in this presentation [1] ?
I'd have to look deeper into it, but I'd be very interested in
On Thu, Jul 16, 2009 at 1:52 AM, John Harrop wrote:
> On Wed, Jul 15, 2009 at 12:58 PM, Mark Engelberg
> wrote:
>>
>> It looks like stack-rot is going to be the bottleneck in your app
>> since it requires traversing the whole vector to build the new one,
>> but I think the list-based implementati
On Wed, Jul 15, 2009 at 12:58 PM, Mark Engelberg
wrote:
>
> It looks like stack-rot is going to be the bottleneck in your app
> since it requires traversing the whole vector to build the new one,
> but I think the list-based implementation would be a bit worse, so I
> think your choice to use vecto
On Wed, Jul 15, 2009 at 6:00 PM, Mark Engelberg wrote:
>
> On Wed, Jul 15, 2009 at 9:58 AM, Mark Engelberg
> wrote:
>> The problem with subvec is that it doesn't really create a "new"
>> vector, it just adds a level of indirection off of the original
>> vector. So for example, if you look up, sa
On Wed, Jul 15, 2009 at 9:58 AM, Mark Engelberg wrote:
> The problem with subvec is that it doesn't really create a "new"
> vector, it just adds a level of indirection off of the original
> vector. So for example, if you look up, say, index 2 in the subvec,
> it knows to go look up index 5 in the
On Wed, Jul 15, 2009 at 3:51 AM, Jan Rychter wrote:
> I am not sure what you mean about subvecs, though -- I currently use
> them for dropn and rot operations, and I don't know how to avoid using
> them:
The problem with subvec is that it doesn't really create a "new"
vector, it just adds a level
Thanks to everyone who replied in this thread. I am impressed by the
signal-to-noise ration on this list and by the quality of replies. I
will try to reply to everyone in a single post, trying to summarize.
> On Jul 13, 11:15 am, Jan Rychter wrote:
>> I've been trying to implement stacks using v
Hi
Instead of:
(conj (drop-last 1 [1 2 3]) 4)
You could use into []:
(conj (into [] (drop-last 1 [1 2 3])) 4)
[1 2 4]
Stephane _/)
On Jul 13, 11:15 am, Jan Rychter wrote:
> I've been trying to implement stacks using vectors in Clojure. In case
> you wonder why, it's because I need stacks w
On Jul 13, 11:15 am, Jan Rychter wrote:
> I've been trying to implement stacks using vectors in Clojure. In case
> you wonder why, it's because I need stacks with a fast item count
> operation.
If that's the only reason, you don't have to use vectors. The
following page says that 'count' for
On Mon, Jul 13, 2009 at 11:15 AM, Jan Rychter wrote:
>
> However, after reading "Programming Clojure" (page 114) I expected to be
> able to use sequence functions, such as drop-last, without my vectors
> changing representation. It seems this is not the case, as after calling
> drop-last (or indee
On Mon, Jul 13, 2009 at 8:15 AM, Jan Rychter wrote:
> And while we're on the subject -- any hints for implementing a stack
> with a fast item count? (apart from a list with a separate counter)
Using conj and pop on vectors for stack operations should work just
fine. Don't use subvec though; nest
the sequence functions operate on sequences. if you pass in something
that is not a sequence, like a vector, they call seq on it internally.
so what you get back from filter or map is a sequence. conj has
consistent behavior across types, you just get a different type out of
map/filter/etc then wh
I've been trying to implement stacks using vectors in Clojure. In case
you wonder why, it's because I need stacks with a fast item count
operation. While experimenting I discovered some vector properties which
were unexpected.
conj adds at the end of the vector as expected:
user> (conj [1 2 3] 4
25 matches
Mail list logo
