Re: [ANN] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth

['Jan-Paul Bultmann' via Clojure]

Very awesome :D!

Cheers, Jan

> On 09 Dec 2015, at 10:39, Michał Marczyk  wrote:
> 
> Hi,
> 
> I am pleased to announce the 0.0.13 release of data.avl, a Clojure
> Contrib library providing highly performant drop-in replacements for
> Clojure(Script)'s built-in sorted maps and sets with the following
> headline features:
> 
>  0. performance often superior to the built-ins (owing to the smaller
> height of AVL trees), see end of this email for some benchmarks
> 
>  1. logarithmic-time slicing and splits:
> 
> (avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1 2} 3 #{4 5 6}]
> 
> (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1} #{2 3 4 5}]
> 
> (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
> ;= #{2 3 4}
> 
> All returned collections are independent from the originals for GC
> purposes (no holding on to out-of-range keys present in the
> original collections), all operations run in O(log n) time in
> asymptotic terms, and actually fast in real-world terms.
> 
>  2. logarithmic-time access by rank and rank queries:
> 
> (nth (avl/sorted-set 0 1 2) 1)
> ;= 1
> 
> (avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
> ;= 2
> 
>  3. nearest-neighbour lookups:
> 
> (avl/nearest (avl/sorted-set 0 1 2) < 1)
> ;= 0
> 
> The complete clojure.core sorted collections API is also supported, as
> is the transient API. See the README for more detailed examples and
> feature descriptions.
> 
> Fixed in this release:
> 
>  1. IMeta and IFn implementations now use correct method names in the
> ClojureScript version.
> 
>  2. sorted-map/sorted-map-by now throw exceptions if no value is
> provided for the final key (in other words, if an odd number of
> arguments is passed in) – patch by Andy Fingerhut, thanks!
> 
> Changed in this release:
> 
>  1. Seqs over data.avl maps now use node objects themselves as map
> entries. This is in line with the behaviour of Clojure's built-in
> sorted maps. Previously seqs over data.avl maps used
> freshly-allocated map entry objects; this had the benefit of not
> holding on to subtrees in some scenarios, however not without some
> performance and GC pressure cost to regular traversals. Note that
> the new behaviour allows the user to rewrap key/value pairs as map
> entries if they so choose in a separate map step.
> 
>  2. Because of 1., AVL nodes now implement vector and map entry
> interfaces.
> 
> Cheers,
> Michał
> 
> 
> ;;; A handful of benchmarks
> 
> ; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)
> 
> user> (def ks (range 1))
> #'user/ks
> user> (def ksks (doall (interleave ks ks)))
> #'user/ksks
> user> (def m1 (apply sorted-map ksks))
> #'user/m1
> user> (def m2 (apply avl/sorted-map ksks))
> #'user/m2
> user> (.tree m1)
> [4095 4095]
> user> (.getTree m2)
> [4095 4095]
> user> (let []
> (prn :> 0)
> (c/quick-bench (get m1 0))
> (c/quick-bench (get m2 0))
> (prn :> 4095)
> (c/quick-bench (get m1 4095))
> (c/quick-bench (get m2 4095))
> (prn :> )
> (c/quick-bench (get m1 ))
> (c/quick-bench (get m2 )))
> :> 0
> WARNING: Final GC required 9.525315094951035 % of runtime
> WARNING: Final GC required 88.3127760569387 % of runtime
> Evaluation count : 2280474 in 6 samples of 380079 calls.
>  Execution time mean : 262.138936 ns
> Execution time std-deviation : 56.938518 ns
>Execution time lower quantile : 237.779848 ns ( 2.5%)
>Execution time upper quantile : 360.756510 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 64.2134 % Variance is severely inflated by outliers
> WARNING: Final GC required 78.56747149813818 % of runtime
> Evaluation count : 2280498 in 6 samples of 380083 calls.
>  Execution time mean : 261.626921 ns
> Execution time std-deviation : 42.454179 ns
>Execution time lower quantile : 241.444705 ns ( 2.5%)
>Execution time upper quantile : 335.120524 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 47.5275 % Variance is moderately inflated by 
> outliers
> :> 4095
> WARNING: Final GC required 168.0614206986717 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>  Execution time mean : 25.939625 ns
> Execution time std-deviation : 4.135726 ns
>Execution time lower quantile : 22.648015 ns ( 2.5%)
>Execution time upper quantile : 32.134865 ns (97.5%)
>Overhead used : 20.503990 ns
> WARNING: Final GC required 293.8046791844393 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>

Re: Awesome Clojure Engineer Opportunity

['Jan-Paul Bultmann' via Clojure]

Hey Rameen,

Cool, I didn’t know that Apple was using Clojure internally.

Cheers, Jan

> On 12 Oct 2015, at 22:00, Rameen Fattahi  wrote:
> 
> Hi Everyone,
> 
> My name is Rameen and I'm looking for a passionate Clojure engineer for a 
> very confidential project at one of the biggest companies in the world 
> (cannot name it here for privacy reasons).
> 
> This is a full time role on our Applied Machine Learning team. If you're 
> interested, please send me your resume and I'd be happy to chat with you.
> 
> Thanks a lot,
> Rameen Fattahi, Technical Recruiter
> 
> 
> -- 
> 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/d/optout 
> .

-- 
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/d/optout.

Re: rand-nth on empty collections

['Jan-Paul Bultmann' via Clojure]

Throwing an exception is probably the right thing to do if it's supposed to 
closely model the behavior of `nth`, but it wonder if it's the most usefull 
behavior in practice.
I would guess that it introduces `not-empty` checks everywhere, instead of only 
for the cases where you want to be shure that the nil returned is actually an 
element of the collection.

cheers Jan

> On 30 Sep 2015, at 20:18, Mark Engelberg  wrote:
> 
>> On Wed, Sep 30, 2015 at 12:14 PM, Mark Engelberg  
>> wrote:
>> I also think it makes perfect sense for rand-nth to throw an error on an 
>> empty collection.  That's because the first step is it needs to generate a 
>> random number between 0 and the length of the collection (0), which is 
>> impossible.  So it should throw an error.  Note that it is the *random 
>> generation of the index*, not the nth that conceptually is throwing the 
>> error.
> 
> To be clear, when I say that nth "conceptually is throwing the error", I just 
> mean that's how I rationalize Clojure's behavior.  That's not really what's 
> going on.  (rand-int 0) returns 0 (which it probably shouldn't, given that 
> the input is meant to be an exclusive upper bound).  So in fact, the error is 
> thrown by clojure.lang.RT.nthFrom, which is surprising.
> 
>  
> -- 
> 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/d/optout.

-- 
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/d/optout.

Re: Is this the good way to write get-percentage

[Jan-Paul Bultmann]

I really don't think that calculating percentages warrants a DSL.
(I'm not even sure if percent warrants a function ;} )

`(round (percent ...))
 (round-up (percent ...))
 (round-down (percent ...))`

Seems far more readable to me than having a function that does many things at 
once, be it higher order, keyword configured or pre `comp`ed.

Cheers Jan

-- 
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/d/optout.

Re: Architectural doubts

[Jan-Paul Bultmann]

Why not stream frames directly into the datomic db as they fall out of gloss?
This should be faster at query time anyhow due to indexes,
and let's datomic handle the memory management.

cheers Jan

 On 31 Jan 2015, at 11:39, Milton Silva milton...@gmail.com wrote:
 
 While using wireshark to analyse libpcap files (= 200 MB) I routinely think 
 that it would be great to preform relational queries but, wireshark only 
 supports search. 
 
 I thought I would decode the entire file, hold it in memory as clojure data 
 structures and use datomic's datalog.
 
 Besides relational queries, a requirement is for the file to be decoded 
 (libpcap, ethernet-II, IP, TCP, diameter) in less then a minute(for a 200MB) 
 and the typical queries should also be less than a minute.
 
 I thought the frames could be represented like this:
 
 {:frame-id 1
 :timestamp java's instant-object
 :src-mac string
 :dest-mac string
 :src-ip
 :dest-ip ...
 ...}
 
 {:frame-ids [1 3]
 :diameter-session-id ...}
 
 So, I started by using gloss to decode a 200MB file. Gloss is fantastic to 
 specify frames  but, it is not meeting the time requirements. It appear the 
 problem has to do with the creation of a lot of objects. Even with 3G of ram 
 for the heap, it still crawls to a halt.
 
 I could try to perform some experiments to determine approximate answers but, 
 I think it is better to talk with people with more experience in order to 
 avoid common pitfalls..
 My questions are:
 
 Will the JVM (with 3G) support a million hashmaps like the above?
 Is Buffy able to do something like what I want? 
 Will datomic be able to handle this use case? 
 What would you suggest to solve this(e.g. don't use clojure data structures.. 
 but then datomic's datalog is not available to query?)?
 -- 
 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/d/optout.

-- 
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/d/optout.

Re: if-not implementation

[Jan-Paul Bultmann]

Even with inlining the code is rather silly ;)

[x] (if x false true)

so you'd get,

   (if (if test false true) then else)

Which relies a bit too much on the JVM's JIT for my taste :D

I've always wondered what the reason for the original implementation is.
Keep closer to the implementation of not, so that no incompatibilities arise
should not become a protocol one day?

Cheers Jan


 On 22 Jan 2015, at 01:32, Mikera mike.r.anderson...@gmail.com wrote:
 
 Interesting -  there seems to be a very slight performance advantage to your 
 version on my machine (consistently about 25% faster for if-nots in a tight 
 loop).
 
 I think the problem is actually with not - which isn't getting inlined 
 currently. If I patch not so that it is inlined, the difference disappears.
 
 Worth a quick patch maybe?
 
 On Thursday, 22 January 2015 03:51:37 UTC+8, Leon Grapenthin wrote:
 I am surprised to find the two branch implementation of if-not as follows:
 
 
 ([test then else]
`(if (not ~test) ~then ~else))
 
 
 What I expected was:
 
 
 ([test then else]
`(if ~test ~else ~then))
 
 
 -- 
 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 
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
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/d/optout.

Re: DSL in RTL (Right to Left) languages.

[Jan-Paul Bultmann]

I would wrap everything in a tree walking macro that first reverses all lists 
and then starts evaluating other macros.

I'd love to see an Arabic clojure file btw :D
But non English source always makes me shudder a bit, one of the great things 
about programming is that everybody speaks English ;)

cheers Jan

 On 14 Jan 2015, at 05:52, clojure.u...@gmail.com wrote:
 
 Hi
 
 I need to write a dsl in Arabic which is a RTL. I am not sure how to get 
 started with such a dsl in clojure. Any pointers with be really appreciated.
 
 Thanks
 
 -- 
 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/d/optout.

-- 
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/d/optout.

Re: Author a Book on Clojure - Packt Publishing

[Jan-Paul Bultmann]

Just my 50 cent.

I was asked to do a technical review on a Clojure podcasts by packtpub once.

The storyboard they send me consisted of a word file containing a huge table 
with text and source code.

Why would anybody send a technical reviewer source code in a word document, yet 
alone in a table column that has a width of 50 characters which causes it to 
line-wrap everywhere?!

It feels to me that this publisher is just a book mill that goes for quantity 
and not quality.
I couldn't make it thought a single book I bought from them because reading 
them felt like a waste of time.

Of course things might have changed by now and your mileage may vary.
I'm just thinking that if somebody takes the time of writing a book on Clojure,
it should at least be worthwhile.

All the best, Jan

 On 20 Dec 2014, at 09:07, Tushar Gupta tos...@gmail.com wrote:
 
 I am Tushar Gupta, an Acquisition Editor at Packt Publishing. We specialise 
 in publishing books, eBooks, video tutorials and articles for IT developers, 
 administrators and users. 
 We are currently planning to develop a book on Clojure Data structures and 
 Algorithms. 
 
 We are looking for an expert to author this book and share their knowledge 
 and skills with our readers.
 
 For more information you can mail me on tush...@packtpub.com.
 
 Looking forward to have some legit responses. :)
 
 -- 
 Regards,
 Tushar Gupta
 Acquisition Editor
 Packt Publishing 
 www.packtpub.com http://www.packtpub.com/
 Skype: packt.tusharg x-msg://4/tush...@packtpub.com%3C
 
 
 
 
 
 
 
 -- 
 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 
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
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/d/optout.

Re: If code is data why do we use text editors?

[Jan-Paul Bultmann]

Yeah this would be awesome, but sadly representing Clojure code as data is as 
hard as representing Java.
All the reader macros make it a nightmare, and the closest thing you'll get is 
tools.analyzer AST nodes.

Session is certainly a step in the right direction, and I wish more people 
would embrace it,
but it works on text as well. Same pretty much goes for codeq, if that is not 
dead.

One could define a Clojure subset that is valid EDN though,
which would make everything from serialisable functions to a nano-pass compiler 
a lot easier.
This has to be the first step imho.

Cheers Jan

 On 14 Nov 2014, at 17:09, atucker agjf.tuc...@gmail.com wrote:
 re
 As I understand it, Session https://github.com/kovasb/session and codeq 
 https://github.com/Datomic/codeq are tools that somehow keep your code in a 
 database instead of plain text.
 
 On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote:
 Hi, here is an idea that has been in my mind for a while. I wonder what you 
 think about it.
 
 In Clojure code is data, right? But when we program we manipulate flat text 
 files, not the data directly.
 Imagine your source code where a data structure (in memory). And programming 
 is done by manipulating this data structure. No text editor and text files 
 involved. 
 Your editor directly manipulates the source data and later saves it on disk 
 (maybe as a text file). 
 
 These are the benefits I can think of:
  - It enables you to use any Clojure function to manipulate your source 
 „code“. Giving you hole new opportunities for refactoring.This functions can 
 be provides as library. 
 
 - Really nice auto complete. 
 
 - Visual programming. Source code can be represented in many different ways 
 (not just text) . The easiest example I can think of is color. It can be 
 represented as text of course (#23FF02)
 but that’s a quite bad interface for humans. Why not display the actual color 
 and provide a color picker? Or what about music notes? Or Math formulars? Or 
 what about a tree view to move and rename functions like files? 
 This could all be implemented in a way that every library can ship there own 
 „views“. I think this „views“ are basically macros that are not limited to 
 text. 
 
 - You don’t have to worry that you text files are in the same state as your 
 JVM (when developing interactive). You only work on your sourcedata and it 
 gets loaded into the JVM automatically.
 
 - Answer questions about your source code. What is the most called function? 
 Who depends on this namespace? Where is this function used? What is the 
 biggest function? Thinks like that become easy. Again you can ship this 
 queries as a library.
 
 
 
 The drawback is you can’t simply program using any text editor. You need a 
 special tool. But we have that anyway (syntax highlighting, paredit etc.). 
 Nobody programs using a bare text editor. 
 
 Maybe this idea is not new? What do you think?
 
 -- 
 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 
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
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/d/optout.

Re: better way to group consecutive numbers in a vector?

[Jan-Paul Bultmann]

I think what you want is `partition-between` as implemented by amalloys useful 
lib 
(https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224
 
https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224).

`(partition-between (fn [x y]
(not= (inc x) y))
   coll)`

Why this isn’t in the standard library is beyond me tbh,
as `partition-by` is a special case for `partition-between`.

`(def partition-by (partial partition-between not=))`

Maybe adding it to clojure.core should be considered?
Also I’d be intrigued to know the rationale behind `partition-by`.

Cheers, Jan

 On 07 Nov 2014, at 18:56, Alex Hammel ahamme...@gmail.com wrote:
 
 Here's my take on the 'add delimiters and split' approach. Bonus `congeal 
 function, which chunks collections on any condition you like:
 
 (defn- insert-gaps
   [coll pred gap-symbol]
   (reduce (fn [acc x]
 (if (pred (peek acc) x)
 (conj acc x)
 (conj acc gap-symbol x)))
   [(first coll)]
   (rest coll)))
 
 (defn split-coll
   [coll delimiter]
   (- coll
(partition-by (partial = delimiter))
(remove (partial = (list delimiter)
 
 (defn congeal
   [pred coll]
   (let [gap-symbol (gensym)]
 (- coll
 (insert-gaps pred gap-symbol)
 (split-coll gap-symbol
 
 (defn consecutive? [p q]
   (= (inc p) q))
 
 (println (congeal consecutive? [1 3 4 5 7 9 10 11 12]))
 #= ((1) (3 4 5) (7) (9 10 11 12))
 (println (congeal  [1 2 3 1 2 3 1 2 3]))
 #= ((1 2 3) (1 2 3) (1 2 3))
 (println (congeal not= [:foo :foo :bar :bar :foo :bar]))
 #= ((:foo) (:foo :bar) (:bar :foo :bar))
 
 
 
 
 On Fri, Nov 7, 2014 at 4:09 AM, Paweł Rozynek pro...@gmail.com 
 mailto:pro...@gmail.com wrote:
 (def data '(1 3 4 5 7 9 10 11 12))
 (map #(map last %) (partition-by #(apply - %) (map-indexed vector data))) = 
 ((1) (3 4 5) (7) (9 10 11 12))
 
 regards
 PR
 
 
 -- 
 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 
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
 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 
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
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/d/optout.

Re: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

Transducers build up transformation steps, with new generic operations like  
single arg `map` and `filter`, and then apply these transformations to a 
collection using an evaluation function.
This function decides if operations are done lazily, eagerly, or on a channel.

Note that while this makes the place where laziness occurs more obvious, it is 
not really new.
You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
While `mapv` or `filterv` are not.


On 11 Oct 2014, at 00:28, Mars0i marsh...@logical.net wrote:

 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 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/d/optout.

-- 
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/d/optout.

Re: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

I feel that there are some misconceptions here,
Clojure is not a language that has lazy evaluation,
but is instead completely eager.
Macros are the closest thing that come to laziness, but they are still 
different.
However, Clojure has a data structure, that also serves as an abstraction layer,
that implements laziness, called a sequence or seq.

Therefor turning of laziness makes no real sense. You could say disable the 
laziness of seqs,
but that doesn't really make sense either. It's like disabling the FIFO nature 
of a queue or a channel.
If you don't want the properties of a seq, then use another data structure, 
like a vector.


On 11 Oct 2014, at 18:14, Mars0i marsh...@logical.net wrote:

 Thanks Jan-Paul.  That's helpful.  I wonder whether, if all lazy functions 
 were rewritten in terms of transducers, it would then be easy to turn 
 laziness on and off.  (I am not suggesting that this should be done.  No 
 doubt it would entail a lot of work, and performance tradeoffs.  I'm quite 
 happy with Clojure as it is, despite anything negative I might say about 
 impacts of laziness in some circumstances.)
 
 On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote:
 Transducers build up transformation steps, with new generic operations like  
 single arg `map` and `filter`, and then apply these transformations to a 
 collection using an evaluation function.
 This function decides if operations are done lazily, eagerly, or on a channel.
 
 Note that while this makes the place where laziness occurs more obvious, it 
 is not really new.
 You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
 While `mapv` or `filterv` are not.
 
 
 On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote:
 
 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 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/d/optout.

-- 
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/d/optout.

Re: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

Yes you are right, currently a lot of stuff is seq only.
I think that reducers provide a lot of eager operations, but not everything.

So yeah, transducers are exactly what you are looking for.

If you call `sequence` with the transducer you get laziness, if you call `into` 
with a collection and a transducer, you get eagerness :).
No decision about the evaluation strategy has to be made up until that point, 
and afaik transducers implement most classical seq constructs.

On 11 Oct 2014, at 21:09, Mars0i marsh...@logical.net wrote:

 I don't think I have any misconceptions.  I probably haven't expressed myself 
 clearly.  Clojure has many very useful functions that return lazy sequences.  
 Analogous functions in other languages perform what are exactly the same 
 operations, except for the fact that what's returned is not a lazy sequence, 
 but instead is a different kind of sequential structure.  For example, Common 
 Lisp'smapcar is very much like Clojure's map, but mapcar returns a (non-lazy) 
 singly-linked list.  As you point out, there are also functions in Clojure 
 that return sequential structures that are not lazy.  Moreover, it's easy to 
 convert a lazy sequence into a non-lazy sequence through use of, for example, 
 doall or vec.
 
 However, writing code in Clojure that only used non-lazy sequences would be 
 unnatural and verbose, as Lee points out.  No one would bother doing that.  
 Part of what's great about Clojure is the convenience of its set of sequence 
 operations.  If you're not using those, you're not getting full benefit from 
 Clojure.  So as a practical matter, one must deal with laziness in Clojure.  
 
 However, almost the same language could be constructed without any laziness, 
 just by replacing lazy functions such as map with non-lazy analogues.  In 
 that case, you could do all of the same things in those situations that don't 
 require laziness.  (You couldn't use lazy infinite sequences, and you'd have 
 to worry about keeping large data structures in memory, etc.  But in many 
 situations, those features aren't needed.)  
 
 That's what I mean by turning off laziness: Replacing every function that 
 returns a lazy sequence with its closest non-lazy analogue.
 
 On Saturday, October 11, 2014 12:01:34 PM UTC-5, Jan-Paul Bultmann wrote:
 I feel that there are some misconceptions here,
 Clojure is not a language that has lazy evaluation,
 but is instead completely eager.
 Macros are the closest thing that come to laziness, but they are still 
 different.
 However, Clojure has a data structure, that also serves as an abstraction 
 layer,
 that implements laziness, called a sequence or seq.
 
 Therefor turning of laziness makes no real sense. You could say disable 
 the laziness of seqs,
 but that doesn't really make sense either. It's like disabling the FIFO 
 nature of a queue or a channel.
 If you don't want the properties of a seq, then use another data structure, 
 like a vector.
 
 
 On 11 Oct 2014, at 18:14, Mars0i mars...@logical.net wrote:
 
 Thanks Jan-Paul.  That's helpful.  I wonder whether, if all lazy functions 
 were rewritten in terms of transducers, it would then be easy to turn 
 laziness on and off.  (I am not suggesting that this should be done.  No 
 doubt it would entail a lot of work, and performance tradeoffs.  I'm quite 
 happy with Clojure as it is, despite anything negative I might say about 
 impacts of laziness in some circumstances.)
 
 On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote:
 Transducers build up transformation steps, with new generic operations like  
 single arg `map` and `filter`, and then apply these transformations to a 
 collection using an evaluation function.
 This function decides if operations are done lazily, eagerly, or on a 
 channel.
 
 Note that while this makes the place where laziness occurs more obvious, it 
 is not really new.
 You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
 While `mapv` or `filterv` are not.
 
 
 On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote:
 
 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from

Re: `as-` does not work with `recur`.

[Jan-Paul Bultmann]

Ah thanks, I did a JIRA search for `as-`  before but nothing had popped up.


On 05 Oct 2014, at 03:06, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote:

 This issue has been reported
 
 May be you should upvote this..
 
 http://dev.clojure.org/jira/browse/CLJ-1418
 
 
 
 On Sun, Oct 5, 2014 at 4:56 AM, Leon Grapenthin grapenthinl...@gmail.com 
 wrote:
 Thought:
 
 (defmacro as-
 [expr name  forms]
 `(let [~name ~expr
~@(interleave (repeat name) (butlast forms))]
~(last forms)))
 
 
 
 
 On Sunday, October 5, 2014 1:02:50 AM UTC+2, Jan-Paul Bultmann wrote:
 Hey, 
 I just noticed that while recur can be the last statement in most threading 
 macros, 
 it can't be used within an `as-` macro. 
 
   user= (macroexpand '(- x (recur))) 
   (recur x) 
 
   user= (macroexpand '(as- x % (recur %))) 
   (let* [% x % (recur %)] %) 
 
 This means that a recur within a `as-` will cause a CompilerException, 
 because it is not at the tail position. 
 
 Thoughts? 
 
 Cheers, 
 Jan-Paul
 
 -- 
 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/d/optout.
 
 
 -- 
 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/d/optout.

-- 
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/d/optout.

`as-` does not work with `recur`.

[Jan-Paul Bultmann]

Hey,
I just noticed that while recur can be the last statement in most threading 
macros,
it can't be used within an `as-` macro.

  user= (macroexpand '(- x (recur)))
  (recur x)

  user= (macroexpand '(as- x % (recur %)))
  (let* [% x % (recur %)] %)

This means that a recur within a `as-` will cause a CompilerException, because 
it is not at the tail position.

Thoughts?

Cheers,
Jan-Paul

-- 
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/d/optout.

Re: complex numbers in clojure

[Jan-Paul Bultmann]

I agree that Clojure could really use an imaginary number type.

The best place to start with this might be `clojure.math.numeric-tower` because 
it already provides a
`MathFunctions` protocol that defines a square root operation.

Cheers Jan

On 15 Aug 2014, at 19:54, Maik Schünemann maikschuenem...@gmail.com wrote:

 Hi,
 
 On Fri, Aug 15, 2014 at 7:00 PM, Reid McKenzie rmckenzi...@gmail.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 The best way to build a complex arithmetic package is probably to work atop 
 `clojure.algo.generic`. I've done a pair of libraries 
 (https://github.com/arrdem/imprecise, https://github.com/arrdem/meajure) 
 based around extending algo.generic with custom datatypes and they've both 
 worked out well
 I'll look at these. 
 Building complex arithmetic atop algo.generic wouldn't bring the desired 
 unification, because for example core.matrix doesn't use algo.generic ... 
 Clojure in general seems pretty loath to package traditional numerics 
 facilities... note that we don't even have a built in square root operator 
 and the common practice is to use java.lang.Math through interop so I 
 wouldn't go holding your breath over adding irrational numbers to the 
 language core. Also clojure.contrib is abandoned and deprecated in favor of 
 real community maintained standalone libraries. The most likely place for 
 an irrational type is probably either a user library like both of the above 
 or possibly algo.generic itself.
 Yeah, I meant 'as a contrib library' when I wrote clojure.contrib. Sorry for 
 the confusion. 
 As for the other part, let me elaborate a bit:
 As it is true that clojure doesn't have much numeric functions in core (like 
 the square root example), it doesn't eschew numeric /types/ like BigInt and 
 Rationals, and you obviously can't pass  to java.lang.Math via interop 
 already. 
 
 Take rationals as example. I really like them and use them often in my 
 clojure code because they give you exact arithmetic basically for free 
 because they are part of the core language and you can use them anywhere (in 
 pure clojure). They even have a convenient literal syntax (but that is not 
 that inportant). 
 
 We had a discussion a while ago on the clojure-numerics mailing list on how 
 we could open core.matrix for arbitrary scalar types, like complex numbers or 
 symbolic expressions. I'll link this here as it could be of interest: 
 https://groups.google.com/forum/#!topic/numerical-clojure/Ze7lNjXJeQc/discussion
 I think a reason that held the discussion back was missing standard types to 
 experiment with. 
 
 I don't argue that clojure should provide complex types as part of 
 clojure.core and can understand the reasons not to (while I think it would be 
 the same reason as including rationals in clojure.core) but as a clojure 
 contrib library that other clojure math libraries build ontop of (including 
 core.matrix and algo.generic).
 The tricky part would then be figuring out how to nicely interop with the 
 other clojure types without incuring too much overhead to be used in serious 
 scientific computing (I think algo.generic uses multimethods for dispatch, 
 which is definitly too slow in highly stressed inner loops of heavy matrix 
 manipulations for example).
 
 greetings
 Maik
 
 Reid
 
 
 On 08/15/2014 10:24 AM, Maik Schünemann wrote:
  Hi, 
 
is there a recommended way to do complex arithmetic in
   clojure ? 
 
I am interested to see clojure going forward for scientific
   computing purposes. 
 
There is already considerable effort going on with
   core.matrix, incanter, expresso etc.
 
But something thad is oddly lacking is support for complex
   numbers. For some areas, this is
 
a show stopper and it is very basic stuff in other languages
   and systems: 
 
- common-lisp, python etc all have a standard complex type as
   part of the language/standard library
 
- see language support here
   http://en.wikipedia.org/wiki/Complex_data_type
 
   
 
In Java, there are multiple incompatible complex number
   classes and I don't want that incompatibilities 
 
in clojure libraries that provide complex number
   manipulation. 
 
   
 
In my opinion we should strive as a community for a standard
   complex number datatype, that is agreed on by clojure libraries, 
 
and plays nicely with clojures other numeric types.
 
Ideally, this would be provided as part of clojure.contrib or
   even clojure itself - like rationals are!
 
   
 
   
 
   
 
   
 
-- 
 
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