I've updated the library so tuples behave like vectors, rather than lists.
The macros have gotten kind of elephantine, but since I've already added
every conceivable Clojure interface at least they won't get any bigger. If
there are any lingering gaps, though, please let me know.
Zach
On Sa
looking at clj-tuple a call to (nth some-tuple 0) turns in to a case
dispatch
(case idx
0 e0
...)
or something.
if you have a Tuple protocol with a function like get0 you can avoid the
overhead of the case there, and the jvm has a better change of inlining
the rest away.
for hotspot to opti
I'm not sure I understand the motivation behind what you're suggesting.
Why not just (nth tuple 0)?
On Mon, Aug 26, 2013 at 10:38 AM, Kevin Downey wrote:
> A Tuple protocol that defines get0 get1 get3 etc for fast element access
> that doesn't tie you to using field names might be a good idea.
No, Asim is right, and the majority of LOC is macro code (which expands to
a deftype expression).
On Mon, Aug 26, 2013 at 11:51 AM, Jim - FooBar(); wrote:
> I had a quick look at clj-tuple and I don't remember seeing any macros...
>
> Jim
>
>
>
> On 26/08/13 19:02, Asim Jalis wrote:
>
>> I belie
I had a quick look at clj-tuple and I don't remember seeing any macros...
Jim
On 26/08/13 19:02, Asim Jalis wrote:
I believe this is what clj-tuple is doing under the hood with macros.
On Aug 26, 2013, at 10:38 AM, Kevin Downey wrote:
A Tuple protocol that defines get0 get1 get3 etc for fa
I believe this is what clj-tuple is doing under the hood with macros.
On Aug 26, 2013, at 10:38 AM, Kevin Downey wrote:
> A Tuple protocol that defines get0 get1 get3 etc for fast element access
> that doesn't tie you to using field names might be a good idea.
>
> On 8/25/13 9:35 AM, Zach Tellm
A Tuple protocol that defines get0 get1 get3 etc for fast element access
that doesn't tie you to using field names might be a good idea.
On 8/25/13 9:35 AM, Zach Tellman wrote:
> I don't think so, even the existence of all the Tuple* types are an
> implementation detail, and you'd need to hint it
Good stuff Zach - I've certainly wanted something like this on various
occasions.
Some comments:
- core.matrix will also work with clj-tuple (because they support ISeq)
- If you made the tuples support IPersistentVector I think they would be
even more useful: it's helpful I think to see tuples
in my microbenchmarks I've found it to be consistently faster to unroll a
fixed number of elements rather than iterate over them. The difference
might not be large enough to matter for many people's use cases, but the
stated goal is to make a fast collection, so it's worthwhile to use the
best
I don't think so, even the existence of all the Tuple* types are an
implementation detail, and you'd need to hint it as the right one to get
sane performance. (nth t n) has good performance, you should prefer that.
On Saturday, August 24, 2013 8:15:40 PM UTC-7, Ben wrote:
>
> Are the element na
wow! very interesting stuff as always Zach...quick question:
I don't see Tuple implementing clojure.lang.Associative, so 'get' won't
work right?
Jim
ps: I've got a project where I 'm working with a lot of 2-element
vectors...I can't wait to try this out :)
On 25/08/13 03:38, Zach Tellman w
Hi,
I've did something similar for CLJS, see
http://dev.clojure.org/jira/browse/CLJS-453 and
https://groups.google.com/forum/#!searchin/clojure/arrayvector/clojure/yDvTRP0gYLA/Tb5MJC8Z0K8J
In CLJS, it is comparable in performance to use array instead of
specialized type for each arity. Did you ch
Are the element names .e0, .e1 etc. considered part of the public interface
of tuple objects?
On Sat, Aug 24, 2013 at 7:38 PM, Zach Tellman wrote:
> I just pulled some code I wrote while trying to optimize 'memoize' into
> its own library: https://github.com/ztellman/clj-tuple. It only has the
13 matches
Mail list logo
