Hi David,
On 21/06/13 14:51, David Nolen wrote:
The problem is the reversing of the list if you want to convert back
to a list. You can avoid this but you have to use a custom mapping
operation, continuation passing style, and a trampoline - it won't be
fast.
Another option is to realize that concrete types simply don't matter.
What you're trying to avoid is getting stuck with a ISeq vs. a
IPersistentList (note you shouldn't care about having a PersistentList
as none of the Clojure fns target that).
Yes, but what about java interop? Why not being able to send data over
from Java to that namespace? The protocol is also extended to Lists,
Vectors, arrays etc. One is able to send his ArrayLists for
normalisation to that namespace and get the same type back or a similar
one (conforming to a common interface). I'll admit that sending
PersistentLists from Java is extremely unlikely but it's been bugging me
since this is the one extension-point where uniformity breaks. I will
consider removing the extension-point to IPersistenList. If such a type
is passed in, the extension-point for IPersistentCollection should catch
it, which happens to return a vector.
One bit of cleverness you could do is to create a new type that
satisfies all the interfaces of IPersistentList and return that
instead (under the hood you can hide the lazy sequence or whatever you
like generated by the mapping operation). A bit more work but probably
accomplishes what you want.
that does sound more work but I'll look into it anyway...:)
David
thanks a lot,
Jim
On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); <jimpil1...@gmail.com
<mailto:jimpil1...@gmail.com>> wrote:
On 21/06/13 14:08, Philip Potter wrote:
Your logic here is incorrect. To say "transients == fast, persistents
== slow" is to grossly oversimplify things.
Yes, I am indeed oversimplifying things but that doesn't change
the fact that 'into' will be *slower* for collections that don't
have transient cousins than the ones that have. It will also be
slower if you don't use the 'transient-capabilities' than when
you use them. I didn't mean to say that persistents==slow but
rather that filling up a transient will always be faster (for more
than 5-6 elements I') than filling up a persistent.
The default data structures are**fast**. Transients are offered, where
they make sense, as optimization to make things go**faster**. Note that
this does not change the big-O complexity.
I did not imply otherwise did I?
There is no analogous case in lists. Every conj operation necessarly
allocates a new cons cell; there is no scope for saving time by
bashing in place. Therefore, there is no transient for lists.
The fact that no transient optimization exists for lists does not mean
that lists are slow. This logic simply does not follow.
again, I never said that lists are slow but that with my current
implementation the extension-point for IPeristentList is
consistently slower than all the rest extensions. Even lazy-seqs
are faster (NOT the data-structure but the mapping operation).
Therefore I'd like to get it in-par with at least lazy-seqs.
If you're afraid of performing 2 passes, you could take advantage of
laziness:
(->> (rseq v)
(map f)
(into '()))
Since map is lazy, this will only perform one pass (though it appears
on first glance that it performs two).
I already tried that but cannot call 'rseq' on a PersistenList and
reverse would do an entire pass.
ClassCastException clojure.lang.PersistentList cannot be cast to
clojure.lang.Reversible clojure.core/rseq (core.clj:1497)
but I would be wary of your use of the word "fastest" at the top.
Normally on the JVM, the answer to a "what is the fastest way to..?"
question is "it depends". A much easier question to answer is "Is X
fast enough?"
I thought I was very careful to provide all the details for the
"what does it depend on?" question. Ok, the title just reads
"fastest way..." but in the message I explained all the
constraints of my problem. I carefully said "the fastest way to
produce a list from mapping" and since I explained that these are
all protocol extensions you can infer that I am extending it to
PersistenLIsts and I want to produce PersistentLists. The question
is much narrower now isn't it? in any case I apologise for
potentially causing confusion... this wasn't even a question about
performance...I don't care if the fastest way is fast enough. All
I care is that I find the fastest way...if that's not fast-enough
then the consumer can choose not to use it...but I do want to
offer the fastest way to do it by default (should the user choose
it)...much like 'conj' works polymorphically
regards,
Jim
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
