Re: Presentation about Clojure

[Bruno Kim Medeiros Cesar]

I've given the following presentation in 30 minutes: 
https://github.com/brunokim/learning-clojure. I've used LightTable to 
change and evaluate code live, mutating from the code in short-preso/ to 
the one in notes/. It's probably not well annotated, I intended to make a 
video with that but didn't :P

The public was composed of developers acquainted with concurrency problems 
and a bit of functional languages, so I didn't need to "sell" immutable 
data structures, for example. The presentation covers:

   - Basic syntax
   - Immutable data structures
   - Functional idioms (filter, map, reduce)
   - JVM integration
   - Concurrency features (atoms and core.async)

I refrained from using syntax sugar such as #(...) in favor of (fn [] ...), 
and also didn't include destructuring, arrows, etc. As you have 45 minutes 
you may try to include macros, but I find it a bit risky. I'd prefer 
showing some Clojurescript instead, specially if your audience is composed 
of Web developers.

I received three questions: 

   - Q: What is the best place to start from zero? A: Check out the 
   references.md file at the repo :)
   - Q: Who uses Clojure? A: Mostly JVM shops, that is, people who also use 
   Java, Scala, etc.; among big players, we can cite Netflix, Twitter, 
   Soundcloud; and we see lots of job offers of financial institutions 
   floating around.
   - Q: Can it be used to create mobile apps? A: Yes and no, there is Neko 
   but it's not stable yet.

If you wish any pointers on how to use it, or better yet, if you know of 
some more references to include, please let me know!

Em quinta-feira, 21 de agosto de 2014 07h06min29s UTC-3, Cecil Westerhof 
escreveu:


I am far from an expert on Clojure, but I am thinking about giving a talk 
> about it on an Open Source event.
>
> Any tips about what to treat and what not to treat?
>
> I will have about 45 minutes.
>
> -- 
> Cecil Westerhof 
>

-- 
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.

Transposing a map and back again

[Bruno Kim Medeiros Cesar]

 

Is there a standard/library function to transpose a map from key-value to 
value-keys?

I've met this task many times before, and I'm sure others have too. Here is the 
code I'm using, mildly highlighted by Google 
Groups. I used to copy-paste from Pygments.org 
, but it seems to no longer work.

(defn transpose
  "Transposes a map of the form k_i -> v_i into v_j -> #{k_j1 k_j2 ...}"
  [m]
  (reduce (fn [acc [k v]]
(assoc acc v 
  (conj (get acc v #{}) k)))
  {} m))

(transpose {:a 1 :b 1 :c 2 :d 4 :e 2 :f 1}) ;=> {4 #{:d}, 2 #{:c :e}, 1 
#{:a :b :f}}

(defn inverse-transpose
  "Transposes back a map of the form v_i -> #{k_i1 k_12 ...} into k_j -> 
v_j"
  [m]
  (into {} (mapcat (fn [[v ks]] 
 (map #(vector %1 %2) ks (repeat v))) 
   m)))

(inverse-transpose (transpose {:a 1 :b 1 :c 2 :d 4 :e 2 :f 1})) ;=> {:d 4, :c 
2, :e 2, :a 1, :b 1, :f 1}

(let [m {:a 1 :b 1 :c 2 :d 4 :e 2 :f 1}]
  (= m (inverse-transpose (transpose m ;=> true
 

-- 
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: Name for this pattern: side-effect from swap!

[Bruno Kim Medeiros Cesar]

Why aren't watches adequate? You could test inside them if you really wish 
to create the side-effect based on your context.

On Tuesday, April 8, 2014 12:41:50 PM UTC-3, John Hume wrote:
>
> I sometimes find that after mutating an atom, I want to create some 
> side-effect that depends on the old and new state as well as the context in 
> which the change was made. Because of the dependence on context, a watch 
> doesn't work (unless there's something I'm not thinking of). So I add 
> things to the new atom state (returned by swap!) purely to tell the calling 
> code what side-effect to have (or give it the data it needs to decide what 
> side-effect to have). That additional state isn't used anywhere other than 
> the fn that called swap!.
>
> One gotcha to this approach is that one must be careful not to leave some 
> old side-effect causing state in place to cause another side-effect based 
> on stale data.
>
> Is there a name for this pattern? A standard way of implementing it? A 
> better alternative?
>
> One alternative I'm aware of is using mutable locals (provided by 
> https://github.com/ztellman/proteus) as a side-channel of communication 
> from swap!. Both approaches strike me as messy, though a let-mutable 
> probably makes it more obvious that something funny is going on, and it 
> doesn't pollute the atom.
>
> Thanks.
> -hume.
>

-- 
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: Looking for advice to fine tune a simple function

[Bruno Kim Medeiros Cesar]

I can't claim to be an experienced Clojure developer, specially so 
regarding maintainability as I'm the only reader of what I write. Andy 
provided a great piece of code, although I scratched my head for a second 
or two unwrapping the last two lines. You'll be surprised how often 
(partition * 1) comes up, as it provides a sliding window through a 
sequence.

(BTW, Andy, how do you format your code so prettily?)

Regarding your question about expecting a sorted input: why don't you 
ensure it? These are the (very similar) options to enforce a precondition 
that I know of:










*(defn hr-zone [bpm [zone-1 zone-2 zone-3 zone-4 :as zones]]  {:pre [(< 
zone-1 zone-2 zone-3 zone-4)]} ...) ; I don't see this very often, but it's 
simple(defn hr-zone [bpm [zone-1 zone-2 zone-3 zone-4 :as zones]]  (assert 
(< zone-1 zone-2 zone-3 zone-4)} "Not sorted!") ...) ; throws an error just 
as the above one, but with a provided message(defn hr-zone [bpm [zone-1 
zone-2 zone-3 zone-4 :as zones]]  (when-not (< zone-1 zone-2 zone-3 
zone-4)} (throw (Exception. "Not sorted!"))) ...) ; If you want to be able 
to catch the error, you may throw an exception*sorted? does not do what you 
may expect: it tests whether the data structure implements Sorted, such as 
sorted-set and sorted-map. You may get the same behaviour with (apply <= 
coll) or (apply < coll) for numeric collections.

For me, the simplest option is




*(defn hr-zone [bpm zones]  (let [[zone-1 zone-2 zone-3 zone-4] (sort 
zones)]...)*
which never fails, although may not be what you need (for example, you'd 
like to be alerted if you input [174 178 128 186] when you wanted [174 178 
182 186]).

Hope that helps a bit,

Bruno Kim.

On Sunday, February 16, 2014 7:31:46 PM UTC-3, Laurent Droin wrote:
>
> Hi,
>
> Disclaimer - I am completely new to Clojure. I just implemented my very 
> first (simple) program, letting me find out, from a GPX file, how much time 
> is spent in the various heart rate zones. Now that it's working, I'm 
> reviewing the code and trying to use best practices. From what I have read 
> so far, there are many ways in Clojure to do the same thing and for a 
> newbie, it's not always obvious to get a good grasp on what is the best way 
> to  code a feature.
> As a developer, and even though I love how concise Clojure programs can 
> be, I am very concerned with readability and ease of maintenance so I would 
> like to keep functions as short and tight as possible, but not to the point 
> where it becomes hard to understand what it does.
>
> Here is a function that I came up with that takes  a bpm (heart beats per 
> minute) value, as well as a sequence of 4 values that represent the 
> boundaries defining the 5 different heart rate zones for a particular 
> person.
> The function needs to finds out in what heart zone the bpm value falls 
> into and return that zone (as a keyword - I later use that keyword in a 
> map).
>
> If you're an experienced Clojure developer, what would you have done 
> differently (and why) ?
>
> *(defn hr-zone*
> *  "Return the HR zone as a keyword according to the bpm value."*
> *  [bpm [max-zone-1 max-zone-2 max-zone-3 max-zone-4]] *
> *  (cond *
> *(<= bpm max-zone-1) :hr-zone-1*
> *(and (< max-zone-1 bpm) (>= max-zone-2 bpm)) :hr-zone-2 *
> *(and (< max-zone-2 bpm) (>= max-zone-3 bpm)) :hr-zone-3 *
> *(and (< max-zone-3 bpm) (>= max-zone-4 bpm)) :hr-zone-4 *
> *(< max-zone-4 bpm) :hr-zone-5))*
>
> FYI, here is how I call this function in the REPL:
> (def my-hr-zones-defs [120 150 165 180])
>
> (hr-zone 115 my-hr-zones-defs)
> (hr-zone 133 my-hr-zones-defs)
> (hr-zone 161 my-hr-zones-defs)
> (hr-zone 175 my-hr-zones-defs)
> (hr-zone 192 my-hr-zones-refs)
>
> Questions I have:
> Would that make sense to consider (and maybe enforce) that the sequence 
> received as parameter is sorted? If this was the case, I would assume I 
> could avoid the "and" calls- assuming that all the conditions in the cone 
> form are evaluated in order. 
> Assuming that I need to test bpm against the two boundaries of each range, 
> would there be a better way to do this:
> *(and (< max-zone-1 bpm) (>= max-zone-2 bpm))*
> ?
> Maybe this would work, but is it preferable?
> *(< max-zone-1 bpm (dec **max-zone-2**))*
>
> *Thanks in advance for the advice.*
>
> *Laurent. *
>
>

-- 
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, vis

Re: Confused by Clojure floating-point differences (compared to other languages)

[Bruno Kim Medeiros Cesar]

Also, I've made a test for this function for all float values in 
C: https://gist.github.com/brunokim/8843039

Unfortunetely it doesn't work in my system, as it does not have other 
rounding modes available besides the default. If anyone suceeds in running 
it, please report.

On Thursday, February 6, 2014 10:07:40 AM UTC-2, Bruno Kim Medeiros Cesar 
wrote:
>
> Just to add a bit to the thread: the Java compiler treats java.lang.Math 
> differently when more efficient alternatives are available. StrictMath is 
> used only as a fallback.
>
> From the java.lang.Math 
> javadoc<http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html>
> :
>
>> By default many of the Math methods simply call the equivalent method in 
>> StrictMath for their implementation. Code generators are encouraged to 
>> use platform-specific native libraries or microprocessor instructions, 
>> where available, to provide higher-performance implementations of Math 
>> methods. 
>> Such higher-performance implementations still must conform to the 
>> specification for Math.
>
>
> Also, check this StackOverflow 
> question<http://stackoverflow.com/q/4232231/946814>
> .
>
> As most probably all your versions use the same native libraries or 
> hardware instructions, the differences must rely either on float 
> configuration parameters, like rounding modes, or the order of operations.
>
> On Wednesday, February 5, 2014 1:58:45 PM UTC-2, Glen Fraser wrote:
>>
>> Thanks for the tip.  After reading your comment, I looked and discovered 
>> the Java library called StrictMath, and tried it (replacing Math/cos and 
>> Math/sin by the StrictMath versions).  I did indeed get different results 
>> than with the regular library, but unfortunately still not the same answer 
>> as in other languages.  I guess the Java implementation(s) are indeed 
>> different.  It's not a big deal for me, just something I found confusing, 
>> wondering if I'd done something wrong.
>>
>> Thanks,
>> Glen.
>>
>> On Wednesday, February 5, 2014 4:06:31 PM UTC+1, Jon Harrop wrote:
>>>
>>>  
>>>
>>> IIRC, Java provides unusual trigonometric functions which, I’m guessing, 
>>> Clojure is using. I think the Java ones are actually more accurate (and 
>>> slower) so you may well find the answer obtained on the JVM is more precise 
>>> than the others.
>>>
>>>  
>>>
>>> Cheers,
>>>
>>> Jon.
>>>
>>>  
>>>
>>> *From:* clo...@googlegroups.com [mailto:clo...@googlegroups.com] *On 
>>> Behalf Of *Glen Fraser
>>> *Sent:* 05 February 2014 13:17
>>> *To:* clo...@googlegroups.com
>>> *Subject:* Confused by Clojure floating-point differences (compared to 
>>> other languages)
>>>
>>>  
>>>
>>> (sorry if you received an earlier mail from me that was half-formed, I 
>>> hit send by accident)
>>>
>>>  
>>>
>>> Hi there, I'm quite new to Clojure, and was trying to do some very 
>>> simple benchmarking with other languages.  I was surprised by the 
>>> floating-point results I got, which differed (for the same calculation, 
>>> using doubles) compared to the other languages I tried (including C++, 
>>> SuperCollider, Lua, Python).
>>>
>>>  
>>>
>>> My benchmark iteratively runs a function 100M times: g(x) <-- sin(2.3x) 
>>> + cos(3.7x), starting with x of 0.
>>>
>>>  
>>>
>>> In the other languages, I always got the result *0.0541718*..., but in 
>>> Clojure I get *0.24788989*  I realize this is a contrived case, but 
>>> -- doing an identical sequence of 64-bit floating-point operations on the 
>>> same machine should give the same answer.   Note that if you only run the 
>>> function for about ~110 iterations, you get the same answer in Clojure (or 
>>> very close), but then it diverges.
>>>
>>>  
>>>
>>> I assume my confusion is due to my ignorance of Clojure and/or Java's 
>>> math library.  I don't think I'm using 32-bit floats or the "BigDecimal" 
>>> type (I even explicitly converted to double, but got the same results, and 
>>> if I evaluate the *type* it tells me *java.lang.Double*, which seems 
>>> right).  Maybe Clojure's answer is "better", but I do find it strange that 
>>> it's different.  Can someone explain this to me?
>>>
>>>  
>>>
>>> Here are some

Re: Confused by Clojure floating-point differences (compared to other languages)

[Bruno Kim Medeiros Cesar]

Just to add a bit to the thread: the Java compiler treats java.lang.Math 
differently when more efficient alternatives are available. StrictMath is 
used only as a fallback.

>From the java.lang.Math 
>javadoc
:

> By default many of the Math methods simply call the equivalent method in 
> StrictMath for their implementation. Code generators are encouraged to 
> use platform-specific native libraries or microprocessor instructions, 
> where available, to provide higher-performance implementations of Math 
> methods. 
> Such higher-performance implementations still must conform to the 
> specification for Math.


Also, check this StackOverflow 
question
.

As most probably all your versions use the same native libraries or 
hardware instructions, the differences must rely either on float 
configuration parameters, like rounding modes, or the order of operations.

On Wednesday, February 5, 2014 1:58:45 PM UTC-2, Glen Fraser wrote:
>
> Thanks for the tip.  After reading your comment, I looked and discovered 
> the Java library called StrictMath, and tried it (replacing Math/cos and 
> Math/sin by the StrictMath versions).  I did indeed get different results 
> than with the regular library, but unfortunately still not the same answer 
> as in other languages.  I guess the Java implementation(s) are indeed 
> different.  It's not a big deal for me, just something I found confusing, 
> wondering if I'd done something wrong.
>
> Thanks,
> Glen.
>
> On Wednesday, February 5, 2014 4:06:31 PM UTC+1, Jon Harrop wrote:
>>
>>  
>>
>> IIRC, Java provides unusual trigonometric functions which, I’m guessing, 
>> Clojure is using. I think the Java ones are actually more accurate (and 
>> slower) so you may well find the answer obtained on the JVM is more precise 
>> than the others.
>>
>>  
>>
>> Cheers,
>>
>> Jon.
>>
>>  
>>
>> *From:* clo...@googlegroups.com [mailto:clo...@googlegroups.com] *On 
>> Behalf Of *Glen Fraser
>> *Sent:* 05 February 2014 13:17
>> *To:* clo...@googlegroups.com
>> *Subject:* Confused by Clojure floating-point differences (compared to 
>> other languages)
>>
>>  
>>
>> (sorry if you received an earlier mail from me that was half-formed, I 
>> hit send by accident)
>>
>>  
>>
>> Hi there, I'm quite new to Clojure, and was trying to do some very simple 
>> benchmarking with other languages.  I was surprised by the floating-point 
>> results I got, which differed (for the same calculation, using doubles) 
>> compared to the other languages I tried (including C++, SuperCollider, Lua, 
>> Python).
>>
>>  
>>
>> My benchmark iteratively runs a function 100M times: g(x) <-- sin(2.3x) + 
>> cos(3.7x), starting with x of 0.
>>
>>  
>>
>> In the other languages, I always got the result *0.0541718*..., but in 
>> Clojure I get *0.24788989*  I realize this is a contrived case, but 
>> -- doing an identical sequence of 64-bit floating-point operations on the 
>> same machine should give the same answer.   Note that if you only run the 
>> function for about ~110 iterations, you get the same answer in Clojure (or 
>> very close), but then it diverges.
>>
>>  
>>
>> I assume my confusion is due to my ignorance of Clojure and/or Java's 
>> math library.  I don't think I'm using 32-bit floats or the "BigDecimal" 
>> type (I even explicitly converted to double, but got the same results, and 
>> if I evaluate the *type* it tells me *java.lang.Double*, which seems 
>> right).  Maybe Clojure's answer is "better", but I do find it strange that 
>> it's different.  Can someone explain this to me?
>>
>>  
>>
>> Here are some results:
>>
>>  
>>
>> *Clojure: ~23 seconds*
>>
>> (defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
>>
>> (loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
>>
>> ;; final x: *0.24788989279493556 **(???)*
>>
>>  
>>
>> *C++ (g++ -O2): ~4 seconds*
>>
>> double g(double x) {
>>
>> return std::sin(2.3*x) + std::cos(3.7*x);
>>
>> }
>>
>> int main() {
>>
>> double x = 0;
>>
>> for (int i = 0; i < 1; ++i) {
>>
>>  x = g(x);
>>
>> }
>>
>> std::cout << "final x: " << x << std::endl;
>>
>> return 0;
>>
>> }
>>
>> // final x: *0.0541718*
>>
>>  
>>
>> *Lua: ~39 seconds*
>>
>> g = function(x)
>>
>> return math.sin(2.3*x) + math.cos(3.7*x)
>>
>> end
>>
>>  
>>
>> x = 0; for i = 1, 1 do x = g(x) end
>>
>> -- Final x: *0.054171801051906*
>>
>>  
>>
>> *Python: ~72 seconds*
>>
>> def g(x):
>>
>> return math.sin(2.3*x) + math.cos(3.7*x)
>>
>>  
>>
>> x = 0
>>
>> for i in xrange(1):
>>
>> x = g(x)
>>
>>  
>>
>> # Final x: *0.05417180105190572*
>>
>>  
>>
>> *SClang: ~26 seconds*
>>
>> g = { |x| sin(2.3*x) + cos(3.7*x) };
>>
>> f = { |x| 1.do{ x = g.(x) }; x};
>>
>> bench{ f.(0).postln };
>>
>> // final x: *0.054171801051906* (same as C++, Lua, Python; different 
>> from Clojure)
>>
>>  
>>
>> Thanks,
>>
>> Glen

Re: Confused by Clojure floating-point differences (compared to other languages)

[Bruno Kim Medeiros Cesar]

Just to add a bit to the thread: the Java compiler treats java.lang.Math 
differently when more efficient alternatives are available. StrictMath is 
used only as a fallback.

>From the java.lang.Math 
>javadoc
:

> By default many of the Math methods simply call the equivalent method in 
> StrictMath for their implementation. Code generators are encouraged to 
> use platform-specific native libraries or microprocessor instructions, 
> where available, to provide higher-performance implementations of Math 
> methods. 
> Such higher-performance implementations still must conform to the 
> specification for Math.


Also, check this StackOverflow 
question
.

As most probably all your versions use the same native libraries or 
hardware instructions, the differences must rely either on float 
configuration parameters, like rounding modes, or the other of operations.

On Wednesday, February 5, 2014 1:58:45 PM UTC-2, Glen Fraser wrote:

> Thanks for the tip.  After reading your comment, I looked and discovered 
> the Java library called StrictMath, and tried it (replacing Math/cos and 
> Math/sin by the StrictMath versions).  I did indeed get different results 
> than with the regular library, but unfortunately still not the same answer 
> as in other languages.  I guess the Java implementation(s) are indeed 
> different.  It's not a big deal for me, just something I found confusing, 
> wondering if I'd done something wrong.
>
> Thanks,
> Glen.
>
> On Wednesday, February 5, 2014 4:06:31 PM UTC+1, Jon Harrop wrote:
>>
>>  
>>
>> IIRC, Java provides unusual trigonometric functions which, I’m guessing, 
>> Clojure is using. I think the Java ones are actually more accurate (and 
>> slower) so you may well find the answer obtained on the JVM is more precise 
>> than the others.
>>
>>  
>>
>> Cheers,
>>
>> Jon.
>>
>>  
>>
>> *From:* clo...@googlegroups.com [mailto:clo...@googlegroups.com] *On 
>> Behalf Of *Glen Fraser
>> *Sent:* 05 February 2014 13:17
>> *To:* clo...@googlegroups.com
>> *Subject:* Confused by Clojure floating-point differences (compared to 
>> other languages)
>>
>>  
>>
>> (sorry if you received an earlier mail from me that was half-formed, I 
>> hit send by accident)
>>
>>  
>>
>> Hi there, I'm quite new to Clojure, and was trying to do some very simple 
>> benchmarking with other languages.  I was surprised by the floating-point 
>> results I got, which differed (for the same calculation, using doubles) 
>> compared to the other languages I tried (including C++, SuperCollider, Lua, 
>> Python).
>>
>>  
>>
>> My benchmark iteratively runs a function 100M times: g(x) <-- sin(2.3x) + 
>> cos(3.7x), starting with x of 0.
>>
>>  
>>
>> In the other languages, I always got the result *0.0541718*..., but in 
>> Clojure I get *0.24788989*  I realize this is a contrived case, but 
>> -- doing an identical sequence of 64-bit floating-point operations on the 
>> same machine should give the same answer.   Note that if you only run the 
>> function for about ~110 iterations, you get the same answer in Clojure (or 
>> very close), but then it diverges.
>>
>>  
>>
>> I assume my confusion is due to my ignorance of Clojure and/or Java's 
>> math library.  I don't think I'm using 32-bit floats or the "BigDecimal" 
>> type (I even explicitly converted to double, but got the same results, and 
>> if I evaluate the *type* it tells me *java.lang.Double*, which seems 
>> right).  Maybe Clojure's answer is "better", but I do find it strange that 
>> it's different.  Can someone explain this to me?
>>
>>  
>>
>> Here are some results:
>>
>>  
>>
>> *Clojure: ~23 seconds*
>>
>> (defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
>>
>> (loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
>>
>> ;; final x: *0.24788989279493556 **(???)*
>>
>>  
>>
>> *C++ (g++ -O2): ~4 seconds*
>>
>> double g(double x) {
>>
>> return std::sin(2.3*x) + std::cos(3.7*x);
>>
>> }
>>
>> int main() {
>>
>> double x = 0;
>>
>> for (int i = 0; i < 1; ++i) {
>>
>>  x = g(x);
>>
>> }
>>
>> std::cout << "final x: " << x << std::endl;
>>
>> return 0;
>>
>> }
>>
>> // final x: *0.0541718*
>>
>>  
>>
>> *Lua: ~39 seconds*
>>
>> g = function(x)
>>
>> return math.sin(2.3*x) + math.cos(3.7*x)
>>
>> end
>>
>>  
>>
>> x = 0; for i = 1, 1 do x = g(x) end
>>
>> -- Final x: *0.054171801051906*
>>
>>  
>>
>> *Python: ~72 seconds*
>>
>> def g(x):
>>
>> return math.sin(2.3*x) + math.cos(3.7*x)
>>
>>  
>>
>> x = 0
>>
>> for i in xrange(1):
>>
>> x = g(x)
>>
>>  
>>
>> # Final x: *0.05417180105190572*
>>
>>  
>>
>> *SClang: ~26 seconds*
>>
>> g = { |x| sin(2.3*x) + cos(3.7*x) };
>>
>> f = { |x| 1.do{ x = g.(x) }; x};
>>
>> bench{ f.(0).postln };
>>
>> // final x: *0.054171801051906* (same as C++, Lua, Python; different 
>> from Clojure)
>>
>>  
>>
>> Thanks,
>>
>> Glen.

Re: Akka-like framework in Clojure ?

[Bruno Kim Medeiros Cesar]

I haven't dabbled yet on actor-based concurrency, can someone point out (a 
blog post about) a comparison between Akka actors, Clojure agents and other 
solutions?

On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I recently 
> spent some time learning functionnal programming, starting with Scala. I 
> had the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there 
> was some clojure based framework available which could implement rather 
> similar features to Akka. 
>
> In particular, I would be interested in an implementation of the Actor 
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model
>  

-- 
-- 
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.

Re: Who is "doing something worthwhile" in Clojure?

[Bruno Kim Medeiros Cesar]

Being acquired by Monsanto does not invalidate "The Climate Corporation"'s 
work, which I find extremely exciting and valuable. In fact, why would 
their work be "worthwhile" by your worthiness definition? They are just 
insurance sellers, after all.

Clojure itself is the ultimate worthwhile project. Even if it fails, by 
some measure of failure, the world is better with a sufficiently-functional 
language, an inspiration for future Lisp users, and a target for future JVM 
languages to aim.

On Thursday, December 19, 2013 2:49:37 AM UTC-2, Rich Morin wrote:
>
> I found Doug Selph's talk at Clojure/conj to be quite inspiring, in 
> that he is clearly (IMHO) doing something that is of great potential 
> value to humanity.  I used to have similar feelings about The Climate 
> Corporation, but their recent acquisition by Monsanto troubles me. 
>
> This makes me wonder about the number of Clojure-driven projects that 
> meet Tim O'Reilly's notions of "doing something worthwhile": 
>
>   “Pursue something so important that even if you fail, 
>the world is better off with you having tried.” 
>
> Full disclojure: I'd love to find a Clojure-related position that meets 
> this test.  More generally, however, I'd like to know about any projects 
> that do so.  Suggestions, anyone? 
>
> -r 
>
>  -- 
> http://www.cfcl.com/rdm   Rich Morin   
> r...@cfcl.com 
> http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA   +1 650-873-7841 
>
> Software system design, development, and documentation 
>
>
>

-- 
-- 
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.

Re: graphs library?

[Bruno Kim Medeiros Cesar]

Maybe late to the thread, but I'm currently implementing some complex 
networks analysis tools in https://github.com/brunokim/loom (specifically, 
loom.metrics) that may be merged back to the main library.

For what you described, Aysylu's Loom https://github.com/aysylu/loom fits 
well.

Bruno Kim.

On Monday, December 2, 2013 12:01:12 PM UTC-2, Paweł Rozynek wrote:
>
> hello
>
> quick question: is there any good graphs related library? the one that 
> implements data structures and search/traverse or some other algorithms in 
> a nice fashion. googling found me nothing useful for my simple needs, neo4j 
> client libs at best.
>
> thanks for responses
> 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
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.

Why not automatically generate classes?

[Bruno Kim Medeiros Cesar]

I was reading on Erjang implementation, and in an 
article 
about how 
it handles recursion, the author says this about multi-arity functions:

   - Every function is compiled to a class *F* with one method named 
*body**(EProc 
   proc, EObject arg1, ... EObject argN)*.  The function takes the EProc (a 
   reference to the light-weight process) and the N arguments. The class *F* is 
   marked final.  This function contains the result of compiling an Erlang 
   function into Java.
   - If the function takes *2* arguments then *F* is a subclass of class 
   EFun*2*, a class provided by Erjang.  *Erjang has a class loader that 
   triggers when such a class is missing and generates EFun**N classes on 
   the fly.*
   - From the generated superclass, class *F* inherits the virtual methods 
*invoke(EProc 
   proc, EObject arg1, ... EObject argN)* and *go(EProc proc)*.  
   
Recently there was a great discussion on how Clojure could better handle 
primitive types, and it was noticed that combinatorial explosion is a major 
limitation do to primitive interfaces 
declaration,
 
and that this could only be solved by ClojureInClojure. Why can't we use a 
custom ClassLoader that generates the needed interface when asked?

I noticed that Clojure goes until 20 arguments, and then expects Object... 
for the 21st invoke. Does this solve the limitation? Scala is limited to 22 
arguments per function, but I didn't understand the 
explanationabout
 two customly generated classes being of different types. Couldn't 
these problems be solved by a custom ClassLoader as well?

(Of course, I don't think anybody should write a 20+ argument function, but 
you know, we're a bunch of misfits that enjoy having the freedom to do as 
we please...)

Thanks for your attention,

Bruno Kim.

-- 
-- 
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.

Re: Improving a nested if, or How to use multimethods the right way.

[Bruno Kim Medeiros Cesar]

Thanks, Alex, I was going down an over-engineering rabbit hole. Your 
solution just lacks a not before multi? and looped?.

On Thursday, September 5, 2013 6:24:13 PM UTC-3, Alex Baranosky wrote:
>
> ;; Better yet...
>
> (if (or (and (multi? graph) (not= 2 (count edge))) 
> (and (looped? graph) (not (distinct? edge
> graph
> (let [e (if (directed? edge) (vec edge) (set edge))]
>   (update-in graph [:edges] conj e
>
>
> On Thu, Sep 5, 2013 at 2:22 PM, Alex Baranosky 
> 
> > wrote:
>
>> I'd just use a cond to flatten a nested if. That's usually all you need, 
>> imo.
>>
>>
>> On Thu, Sep 5, 2013 at 1:07 PM, Bruno Kim Medeiros Cesar <
>> bruno...@gmail.com > wrote:
>>
>>> Thanks for your suggestion, didn't know about that! One of the things 
>>> that made someone say that "Clojure looks like a language from the near 
>>> future". However, I'm having a hard time using it with its full power. 
>>> Could you recommend any other resource, besides the overview page on 
>>> github, to learn pattern matching? Maybe a project that uses them?
>>>
>>> For the record, my code uses a simple truth table now:
>>>
>>>
>>> (defn add-edge
>>>   ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
>>>([g edge]
>>>(let [two? (= 2 (count edge))
>>>  dist? (apply distinct? edge)
>>>  e (match [(hyper? g) (looped? g)] ; e will be nil if edge is 
>>> invalid for this graph
>>>  [false false] (when (and two? dist?) edge)
>>>  [false true ] (when two?  edge)
>>>  [true  false] (when dist? edge)
>>>      [true  true ] edge]
>>>  (if e
>>>(update-in g [:edges] conj (if (directed? g) (vec e) (set e)))
>>>g
>>>
>>> On Wednesday, September 4, 2013 7:07:06 PM UTC-3, Leonardo Borges wrote:
>>>
>>>> You could use pattern matching with core.match 
>>>> On 05/09/2013 6:57 AM, "Bruno Kim Medeiros Cesar"  
>>>> wrote:
>>>>
>>>>>  I'm writing (another) basic graph library, and would like to treat 
>>>>> inputs depending on the type of the graph. A graph can be
>>>>>
>>>>>- Directed, in which case edges are vectors. Otherwise, edges are 
>>>>>sets; 
>>>>>- Looped, allowing edges from a node to itself; 
>>>>>- Pseudo (or multi), allowing multiples edges between the same 
>>>>>endpoints; and
>>>>>- Hyper, allowing edges with more than two vertices.
>>>>>
>>>>> To illustrate better these characteristics you can think of a 
>>>>> scientific publication network as a directed, looped, pseudo-hypergraph. 
>>>>> Vertices are authors, and edges are articles containing multiple 
>>>>> researchers (hyper) who can publish alone (looped). There are multiple 
>>>>> articles between the same researchers (pseudo) and in some contexts 
>>>>> author 
>>>>> order matters (directed). 
>>>>>
>>>>> Now, I've created a flowchart <http://imgur.com/IdgsGFG> to decide if 
>>>>> an edge should be conjed in a graph :edges entry, that leads to the 
>>>>> following straightforward function:
>>>>>  (defn add-edge 
>>>>>   ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
>>>>>   ([graph edge]
>>>>>   (if (and (multi? graph) (not= 2 (count edge))) 
>>>>> graph
>>>>> (if (and (looped? graph) (not (distinct? edge)))
>>>>>   graph
>>>>>   (let [e (if (directed? edge) (vec edge) (set edge))]
>>>>> (update-in graph [:edges] conj e))
>>>>>
>>>>> That looks ugly and a pattern that could propagate in a codebase. So I 
>>>>> tried to factor out multimethods from it, and ended with the following:
>>>>>
>>>>> (defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
>>>>> (defmulti ^:private add-edge1 (fn [g e] (looped? g)))
>>>>> (defmulti ^:private add-edge2 (fn [g e] (directed? g)))
>>>>> (defn ^:private add-edge3 [g e]
>>>>>   (update-in g [:edges] conj e))
>>>>>
>>>>> (defmethod add-edge0 :hyper [g e] (add-edge1 g e))
>>>>> (defmethod add-edge0 :default [g e] 

Re: Clojure for the Brave and True, an online book for beginners

[Bruno Kim Medeiros Cesar]

I would like to add to Roberto's request, a thorough treatment of ns would 
be great. It has its specific syntax that takes some time to understand, 
but that you don't use enough to imprint in your brain. It differs between 
the REPL and the file source, and is a showstopper when you want to try 
something new and get it wrong. The threads some days ago about 
:useand
 a proposal 
to simplify 
nsmay
 be of interest in detailing their problems.

On Thursday, September 5, 2013 4:32:20 PM UTC-3, Roberto Guerra wrote:
>
> Sorry if my comment came across the wrong way. I wasn't meaning you 
> specifically, just the general clojure community in general. Keep up the 
> good work. BTW, something that confuses me a lot in clojure is 'require' vs 
> 'import'. There seem to be different ways of 'importing' or 'requiring' a 
> package, I never know when to use what or if it even matters.
>
> On Thursday, September 5, 2013 1:25:04 PM UTC-6, Daniel Higginbotham wrote:
>>
>> Thanks for all the feedback. I didn't expect there to be such polar 
>> opposite reactions to the Emacs content!
>>
>> Roberto - did you notice the links to vim, CCW, and sublime text 2 
>> materials? They are at the bottom of this page: 
>> http://www.braveclojure.com/getting-started/ . I'm also curious about 
>> your impression that the book implies that anything but Emacs is wrong. My 
>> goal is to provide a rationale for using Emacs and offer great instructions 
>> on how to use it, not to say that people shouldn't use other editors.
>>
>> My approach is that I want to reduce barriers to learning Clojure as much 
>> as possible. I want people to have an environment where they feel confident 
>> about writing and running Clojure. What I'm trying to say is "here are 
>> resources for other editors, here is an emacs tutorial, but whatever you do 
>> please take the time to set up your environment" - does that come across?
>>
>> Thanks!
>> Daniel
>>
>

-- 
-- 
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.

Re: Improving a nested if, or How to use multimethods the right way.

[Bruno Kim Medeiros Cesar]

Thanks for your suggestion, didn't know about that! One of the things that 
made someone say that "Clojure looks like a language from the near future". 
However, I'm having a hard time using it with its full power. Could you 
recommend any other resource, besides the overview page on github, to learn 
pattern matching? Maybe a project that uses them?

For the record, my code uses a simple truth table now:

(defn add-edge
  ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
  ([g edge]
   (let [two? (= 2 (count edge))
 dist? (apply distinct? edge)
 e (match [(hyper? g) (looped? g)] ; e will be nil if edge is 
invalid for this graph
 [false false] (when (and two? dist?) edge)
 [false true ] (when two?  edge)
 [true  false] (when dist? edge)
 [true  true ] edge]
 (if e
   (update-in g [:edges] conj (if (directed? g) (vec e) (set e)))
   g

On Wednesday, September 4, 2013 7:07:06 PM UTC-3, Leonardo Borges wrote:
>
> You could use pattern matching with core.match 
> On 05/09/2013 6:57 AM, "Bruno Kim Medeiros Cesar" 
> > 
> wrote:
>
>> I'm writing (another) basic graph library, and would like to treat inputs 
>> depending on the type of the graph. A graph can be
>>
>>- Directed, in which case edges are vectors. Otherwise, edges are 
>>sets; 
>>- Looped, allowing edges from a node to itself; 
>>- Pseudo (or multi), allowing multiples edges between the same 
>>endpoints; and
>>- Hyper, allowing edges with more than two vertices.
>>
>> To illustrate better these characteristics you can think of a scientific 
>> publication network as a directed, looped, pseudo-hypergraph. Vertices are 
>> authors, and edges are articles containing multiple researchers (hyper) who 
>> can publish alone (looped). There are multiple articles between the same 
>> researchers (pseudo) and in some contexts author order matters (directed). 
>>
>> Now, I've created a flowchart <http://imgur.com/IdgsGFG> to decide if an 
>> edge should be conjed in a graph :edges entry, that leads to the following 
>> straightforward function:
>>  (defn add-edge 
>>   ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
>>   ([graph edge]
>>   (if (and (multi? graph) (not= 2 (count edge))) 
>> graph
>> (if (and (looped? graph) (not (distinct? edge)))
>>   graph
>>   (let [e (if (directed? edge) (vec edge) (set edge))]
>> (update-in graph [:edges] conj e))
>>
>> That looks ugly and a pattern that could propagate in a codebase. So I 
>> tried to factor out multimethods from it, and ended with the following:
>>
>> (defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
>> (defmulti ^:private add-edge1 (fn [g e] (looped? g)))
>> (defmulti ^:private add-edge2 (fn [g e] (directed? g)))
>> (defn ^:private add-edge3 [g e]
>>   (update-in g [:edges] conj e))
>>
>> (defmethod add-edge0 :hyper [g e] (add-edge1 g e))
>> (defmethod add-edge0 :default [g e] (if (= 2 (count e))
>>   (add-edge1 g e)
>>   g))
>> (defmethod add-edge1 :looped  [g e] (add-edge2 g e))
>> (defmethod add-edge1 :default [g e] (if (distinct? e)
>>   (add-edge2 g e)
>>g))
>> (defmethod add-edge2 :directed [g e] (add-edge3 g (vec e)))
>> (defmethod add-edge2 :default  [g e] (add-edge3 g (set e)))
>>
>> (defn add-edge
>>   ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
>>   ([g edge]   (add-edge0 g edge)))
>>
>> That doesn't look much better, as the amount of boilerplate increased, 
>> but at least the concerns for each type are separated.
>>
>> Do you have any suggestions on how to improve this design? Thanks for any 
>> consideration!
>>
>> Bruno Kim Medeiros Cesar
>> Engenheiro de Computação
>> Pesquisador em Redes Complexas
>> www.brunokim.com.br
>>  
>> -- 
>> -- 
>> 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 Gr

Improving a nested if, or How to use multimethods the right way.

[Bruno Kim Medeiros Cesar]

I'm writing (another) basic graph library, and would like to treat inputs
depending on the type of the graph. A graph can be

   - Directed, in which case edges are vectors. Otherwise, edges are sets;
   - Looped, allowing edges from a node to itself;
   - Pseudo (or multi), allowing multiples edges between the same
   endpoints; and
   - Hyper, allowing edges with more than two vertices.

To illustrate better these characteristics you can think of a scientific
publication network as a directed, looped, pseudo-hypergraph. Vertices are
authors, and edges are articles containing multiple researchers (hyper) who
can publish alone (looped). There are multiple articles between the same
researchers (pseudo) and in some contexts author order matters (directed).

Now, I've created a flowchart <http://imgur.com/IdgsGFG> to decide if an
edge should be conjed in a graph :edges entry, that leads to the following
straightforward function:
(defn add-edge
  ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
  ([graph edge]
  (if (and (multi? graph) (not= 2 (count edge)))
graph
(if (and (looped? graph) (not (distinct? edge)))
  graph
  (let [e (if (directed? edge) (vec edge) (set edge))]
(update-in graph [:edges] conj e))

That looks ugly and a pattern that could propagate in a codebase. So I
tried to factor out multimethods from it, and ended with the following:

(defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
(defmulti ^:private add-edge1 (fn [g e] (looped? g)))
(defmulti ^:private add-edge2 (fn [g e] (directed? g)))
(defn ^:private add-edge3 [g e]
  (update-in g [:edges] conj e))

(defmethod add-edge0 :hyper [g e] (add-edge1 g e))
(defmethod add-edge0 :default [g e] (if (= 2 (count e))
  (add-edge1 g e)
  g))
(defmethod add-edge1 :looped  [g e] (add-edge2 g e))
(defmethod add-edge1 :default [g e] (if (distinct? e)
  (add-edge2 g e)
   g))
(defmethod add-edge2 :directed [g e] (add-edge3 g (vec e)))
(defmethod add-edge2 :default  [g e] (add-edge3 g (set e)))

(defn add-edge
  ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
  ([g edge]   (add-edge0 g edge)))

That doesn't look much better, as the amount of boilerplate increased, but
at least the concerns for each type are separated.

Do you have any suggestions on how to improve this design? Thanks for any
consideration!

Bruno Kim Medeiros Cesar
Engenheiro de Computação
Pesquisador em Redes Complexas
www.brunokim.com.br

-- 
-- 
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.

Re: too circular?

[Bruno Kim Medeiros Cesar]

This exact use case is covered by letfn, which creates a named fn 
accessible to all function definitions and the body. That even allows 
mutual recursive definitions without declare. Your example would be

 (defn fib-n [n]
   (letfn [(fib [a b]
(cons a (lazy-seq (fib b (+ b a)]
 (take n (fib 1 1

Note that its grammar is 

(letfn [fnspecs*] exprs*)
fnspec ==> (fname [params*] exprs)

That is, don't forget to surround a function definition with parentheses as 
above, and not as 

(letfn [fib [a b] ...])
CompilerException java.lang.IllegalArgumentException: Don't know how to 
create ISeq from: clojure.lang.Symbol

The reason is that letfn accepts multiple definitions, and as each function 
can have multiple expressions as in a do form, you can't just partition the 
vector as you do in let. 

On Thursday, August 29, 2013 4:32:00 PM UTC-3, Jim foo.bar wrote:
>
> On 29/08/13 20:23, JvJ wrote: 
> > I wonder if the somewhat counterintuitive concept of a "named 
> > anonymous function" eludes some people, or isn't properly conveyed in 
> > tutorials. 
>
> I only consider #(...) as an anonymous function. The longer form (fn [] 
> (...)) has the potential of being perfectly named, it's just you who 
> doesn't give it a name usually... 
>
> 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
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.

Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata

[Bruno Kim Medeiros Cesar]

Thanks for that link, I loved this tutorial!

On Saturday, August 10, 2013 3:13:52 PM UTC-3, Jacob Goodson wrote:
>
> Here is where I started... 
> http://www.lisperati.com/clojure-spels/casting.html
>
> I personally disagree about being so timid with macros, however, I do not 
> code Clojure with a team of other people =P.
>
> The one thing you will find about Clojure is that it slaps a limit on the 
> types of macros you can do.  This limit does not necessarily stop you from 
> creating amazing things with macros but it is there.  So of the macros that 
> you will find in these LISP SPEL books will not be easily recreated in the 
> hampered(pampered?) Clojure language.  Clojure was meant to be a more 
> corporate friendly, pragmatic language; thus, no reader macros.
>
> On Friday, August 9, 2013 6:21:02 PM UTC-4, Jace Bennett wrote:
>>
>> Thanks everyone. Good stuff.
>>
>> I have Let over Lambda, but I didn't glean what I wanted from it (or 
>> probably even what it wanted from me). I'll pick up On Lisp. I didn't 
>> realize it was focused on macros.
>>
>> Also, I think Luca has given me a clue. I used code gen techniques long 
>> before I started using reflection based techniques. Macros are more like 
>> code gen, so I'll think back to those techniques, and search for analogues 
>> and maybe even epiphanies. I think I had the ideas of dynamism and DRY 
>> complected (sorry, had to). The dynamism will obviously require state. The 
>> DRY shouldn't. But in C# I've usually gone dynamic to get dry.
>>
>> Out of curiousity, where do the defs go? Could one iterate over all the 
>> vars in the runtime environment? Would I just get pointers to native code?
>>
>>
>> On Fri, Aug 9, 2013 at 1:04 PM, Andrew Stine wrote:
>>
>>> The difficulty with On Lisp when applied to Clojure is that the specific 
>>> macros On Lisp demonstrates either depend on state, which Clojure avoids, 
>>> or are already present in Clojure core. (if-let is a big one in my book.) 
>>> Some of them also run into conflicts with Clojure implicit gensyming. I 
>>> don't suggest it for the specific macros it demonstrates, but because it 
>>> demonstrates very clearly what they are for, why and where you would use 
>>> them, and how, in general, they are used. I also don't write macro much 
>>> anymore in Clojure but that's mostly because Clojure has a few macros 
>>> already which handle most of the things I would do with them in Common Lisp.
>>>
>>>
>>> On Friday, August 9, 2013 11:13:44 AM UTC-4, Lee wrote:


 On Aug 9, 2013, at 11:01 AM, Andrew Stine wrote: 

 > For a pretty decent cover of when and how to use macros, On Lisp[1] 
 is a pretty good book. It's written mainly for Common Lisp but most of it 
 translates to Clojure well enough. I find that for common code, writing 
 macros isn't so useful as most of the goods ones are already part of 
 clojure.core. But if you ever find yourself in the position where you'd 
 really like to have a control structure just for your program, or 
 introduce 
 a compile-time code generator, or subtly add a new paradigm to the 
 language, a macro is your ticket. 
 > 
 > 1. http://code.google.com/p/**onlisp/ 

 I think that On Lisp is completely awesome -- one of the best technical 
 books of any kind that I've ever read. 

 However, my recollection is that the macro stuff, in particular, 
 doesn't translate so well to Clojure because the differences between 
 Common 
 Lisp and Clojure macros are pretty fundamental. Or at least that has been 
 my impression and I mostly stopped writing macros when I switched from 
 Common Lisp to Clojure because I found the differences confusing. Your 
 experience may be different but I thought that a warning might be in 
 order. 

  -Lee 



  -- 
>>> -- 
>>> 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/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+uns

Re: Parallelizing tasks

[Bruno Kim Medeiros Cesar]

On Thursday, April 11, 2013 10:03:51 AM UTC-3, Gary Verhaegen wrote:
>
> The way the f function is written, there is no way to run it in 
> parallel, since it needs the previous answer. The best you can hope 
> for is to use two cores, one for a and one for b. 
>

That was my goal at first, but your comment made me think that there _is_ a 
way to compute the sequence in parallel: Substituting the expression in 
itself I can compute x_{n+2} from x_n; this way I can compute the even and 
odd terms in parallel for each sequence. This can be extended to compute 
x_{n+4} from x_n, allowing to compute 4 terms in parallel for each 
sequence, thus occupying 8 cores. The calculation complexity will rise for 
each term, though, so some performance analysis is needed to find the best 
approach.
 

> What you can do if you want to make it parallel is use the closed 
> form, and create a lazy list of that closed form for each iteration. 
> Something along the lines of (doall (pmap #(- (f a %) (f b %)) 
> (range))), where (f a n) yields the value for the nth iteration with a 
> starting value of a, using the closed form. If you know in advance how 
> many steps you want, you could have even more parallelism with a 
> reducer-based map on a vector of n's. 
>
> Unfortunately, I personally do not know of an arbitrary-precision 
> implementation of sin, asin and sqrt (though I suppose they would not 
> be *that* hard to implement). 
>

It's impossible to implement such functions using rational arithmetic, it 
would be necessary some serious symbolic packages à la Mathematica.
 

> On 11 April 2013 09:27, Michael Gardner > 
> wrote: 
> > On Apr 10, 2013, at 21:46 , Ulises > 
> wrote: 
> > 
> >> Have you tried replacing all your calls to map for pmap yet? 
> > 
> > That will not work. He'll need to rearrange his algorithm to something 
> like this before pmap will help: 
> > 
> > (defn iterated-difference [f a b] 
> > "Yields a lazy seq of the differences between (iterate f a) and 
> (iterate f b)." 
> > (cons (doto (double (- b a)) println) 
> > (lazy-seq (apply iterated-difference f (pmap f [a b]) 
> > 
> > Might need to wrap this in a (doall …) or such to see progressive output 
> from the println. 
>

Both suggestions seems to kind-of have worked, but for the most part just 
one core is used. The problem is that the calculation for a is much faster 
than the calculation for b, and the iteration hangs on that. Also, the time 
complexity seems to be exponential!

(defn test-f [n x] (double (last (take n (iterate f x)
(doall (for [n (range 10 18)] [n (time (test-f n a)]))
;"Elapsed time: 1.550121 msecs"
;"Elapsed time: 1.081994 msecs"
;"Elapsed time: 3.278447 msecs"
;"Elapsed time: 11.228025 msecs"
;"Elapsed time: 22.27068 msecs"
;"Elapsed time: 90.175714 msecs"
;"Elapsed time: 305.631558 msecs"
;"Elapsed time: 1196.748514 msecs"
;(...)

(doall (for [n (range 10 18)] [n (time (test-f n b))]))
;"Elapsed time: 197.777474 msecs"
;"Elapsed time: 769.693374 msecs"
;"Elapsed time: 3038.191752 msecs"
;"Elapsed time: 12228.269874 msecs"
;"Elapsed time: 49325.26163 msecs"
;"Elapsed time: 197819.804965 msecs"
;^C (life is too short)

This is just to be expected as the denominator doubles every step, although 
the exponent seems close to 4... I guess I'll need plenty of time to reach 
100 steps.

Thanks for your suggestions, if I ever get some results I'll post it here.

-- 
-- 
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.