Re: [ANN] clojure-echonest-api

[Ulises]

> I am unsure about the atom of api-key, in theory i won't need to change my
> api-key, but idk... You can get a lot of api-key gratis which are a little
> limited or just one payed api-key that can do everything...

My point was that once you've declared api-key {:dynamic true} (which
by the way is not necessary if you define your api key as an atom) you
can then either bind it to a different value in a particular thread
with (binding ...) or in a particular context with (with-redef ...)[1]

This approach works fine when you regularly change your api key
depending on the context, however I'm not entirely sure how things
would work if you want to set your api-key once for an entire session.

U

[1] http://clojure.org/vars

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

Re: [ANN] clojure-echonest-api

[Simone Mosciatti]

Yep, i changed it in futures...

I am unsure about the atom of api-key, in theory i won't need to change my 
api-key, but idk... You can get a lot of api-key gratis which are a little 
limited or just one payed api-key that can do everything...

Il giorno giovedì 24 maggio 2012 00:56:25 UTC-5, Ulises ha scritto:
>
> > Looking the code again I believe that I should use a future and not an 
> > agent... 
> > I am right ??? 
>
> I would think so. AFAIK, the advice has always been "if you need to do 
> some computation on another thread don't (ab)use agents, use futures". 
>
> Additionally, you have[1]: 
>
> (def #^{:dynamic true} *api-key* (atom "N6E4NIOVYMTHNDM8J")) 
>
> unless you're planning on setting the key to different values in 
> different threads (unlikely?) you don't need to use an atom there. 
>
> All I've said above could be completely wrong so be warned :) 
>
> U 
>
> [1] 
> https://github.com/siscia/echonest-clojure-api/blob/master/src/echonest_api/with-doc-core.clj#L16
>  
>

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

Re: maths, functions and solvers

[Zack Maril]

Off topic:
How hard would it be to build on 
core.logicto do math 
functions? 
-Zack

On Thursday, May 24, 2012 9:30:12 PM UTC-2, Stephen Compall wrote:
>
> On May 24, 2012 8:42 AM, "jlk"  wrote:
> > However the only way I can think of converting the argument list and the 
> function into a function of one argument is with an intermediate function.
>
> Apply is the standard way to listify a function's arguments.  Where f is a 
> function taking n args, (partial apply f) is a function taking (among other 
> disjoint possibilities) one arg being a list of n values.
>
> > (defn -cat
> >   "example math function"
> >   [{:keys [E A alpha t2 t1 W1 W2 g L T1 T2]}]
> >   (- (+ (* E A alpha (- t2 t1)) (/ (* (sq W1) (sq g) (sq L) E A) (* 24.0 
> (sq T1))) T2) T1 (/ (* (sq W2) (sq g) (sq L) E A) (* 24.0 (sq T2)
>
> Take a look at (meta #'-cat) in this example; you may find it of use.
>
> > As a side note, being able to define functions in infix would also be 
> nice, but I don't feel up to creating a maths parser and dealing with ASTs, 
> although I can visualise how I might manage the variables using this 
> approach.
>
> If you parse Clojure lists, this reduces to a problem of grouping and 
> flipping back to prefix.
>
> Traversable functors and the writer monad are good choices for collecting 
> vars as you are grouping and flipping, though you perhaps have something 
> else in mind.  The real trouble is discriminating between bound and free 
> vars.
>
> -- 
> Stephen Compall
> Greetings from sunny Appleton!
>

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

Re: maths, functions and solvers

[Stephen Compall]

On May 24, 2012 8:42 AM, "jlk"  wrote:
> However the only way I can think of converting the argument list and the
function into a function of one argument is with an intermediate function.

Apply is the standard way to listify a function's arguments.  Where f is a
function taking n args, (partial apply f) is a function taking (among other
disjoint possibilities) one arg being a list of n values.

> (defn -cat
>   "example math function"
>   [{:keys [E A alpha t2 t1 W1 W2 g L T1 T2]}]
>   (- (+ (* E A alpha (- t2 t1)) (/ (* (sq W1) (sq g) (sq L) E A) (* 24.0
(sq T1))) T2) T1 (/ (* (sq W2) (sq g) (sq L) E A) (* 24.0 (sq T2)

Take a look at (meta #'-cat) in this example; you may find it of use.

> As a side note, being able to define functions in infix would also be
nice, but I don't feel up to creating a maths parser and dealing with ASTs,
although I can visualise how I might manage the variables using this
approach.

If you parse Clojure lists, this reduces to a problem of grouping and
flipping back to prefix.

Traversable functors and the writer monad are good choices for collecting
vars as you are grouping and flipping, though you perhaps have something
else in mind.  The real trouble is discriminating between bound and free
vars.

-- 
Stephen Compall
Greetings from sunny Appleton!

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

Re: Clojure and the Anti-If Campaign

[Raoul Duke]

On Thu, May 24, 2012 at 2:41 PM, Mimmo Cosenza  wrote:
> forgot Copernicus vs Ptolemy. But its not without mental efforts to find the
> right earth/sun to swap. I'll read your post in few minutes

yeah, they were all still wrong about mercury, no? :-)

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

Re: Clojure and the Anti-If Campaign

[Mimmo Cosenza]

Whatever model I choose to understand a piece (big or small at your 
preferences) of the world, when I need more than few conceptual if, there 
is something wrong in my understanding of that piece. I never 
forgot Copernicus vs Ptolemy. But its not without mental efforts to find 
the right earth/sun to swap. I'll read your post in few minutes

mimmo
 

On Thursday, May 24, 2012 11:57:47 AM UTC+2, Dominikus wrote:
>
> Three weeks ago I stumbled across the Anti-If Campaign (
> http://www.antiifcampaign.com/).
>
> An instant later I realized that one could easily re-implement "if" in 
> Clojure with maps. More interestingly, polymorphic functions can be easily 
> motivated with the help of maps. And this naturally leads to multimethods.
>
> If you like, enjoy reading my blogpost on "The root of polymorphism: The 
> Anti-If Campaign". It might be an interesting read for Clojure enthusiasts.
>
>
> http://denkspuren.blogspot.de/2012/05/root-of-polymorphism-anti-if-campaign.html
>  
>
> Cheers,
>
> Dominikus
>
>
>

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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[Armando Blancas]

>
> I saw that you wrote it in the style of a repl interaction, which 
> could have been pasted or could have been synthesized by hand. 
>
>
Aw! Dude, I'd never bullshit you like that. Honest. But I was sloppy and 
rude; sorry.
 

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

Re: Parallel doseq?

[Cedric Greevey]

Sorry. *Something* is apparently messing with my outbound messages.
I'm not sure what, why, or how. Characters are moved or substituted at
random times, sometimes with unfortunate results.

Meanwhile, I had tried using pcalls as well but was getting spurious
behavior. I wound up with:

(defmacro pdoseq
  "Bindings as for for, but parallel execution as per pmap, pcalls,
pvalues; returns
   nil."
  [seq-exprs & body]
  `(let [procs# (+ 2 (.availableProcessors (Runtime/getRuntime)))
 calls# (for ~seq-exprs (fn [] ~@body))
 threads# (for [i# (range procs#)]
(Thread.
  #(doall
 (map (fn [x#] (x#))
   (take-nth procs#
  (drop i# calls#))]
 (doseq [t# threads#]
   (.start t#))
 (doseq [t# threads#]
   (.join t#

The body is wrapped in a function so realizing an element of the seq
doesn't immediately execute it. Threads are created that will skip to
every nth element and invoke the function there, each starting offset
from the others. The threads are then all started, and then all joined
so the pdoseq call doesn't return until the job's done, just as plain
doseq has a synchronous return.

One potential issue is that if one thread gets well ahead of the
others a big chunk of the for seq is held onto while the others catch
up. So it's suitable for up to thousands of items that are
individually expensive. If you had millions of individually cheap
items you'd need another strategy. A nested iteration like (doseq [x
s1 y s2] foo) could be split into (pdoseq [x s1] (doseq [y s2] foo))
so that whole inner loops are the granularity of the parallel jobs
(diluting each anonymous function call overhead over a larger portion
of the total work) and the size of the potentially-held-onto seq is
only the size of the outer loop (e.g. the maximum size of held-onto
seq would be 1024 instead of 786432 if you are looping over a 1024x768
array, easily possible with some image manipulation jobs, and there
wouldn't be an added function call overhead once every pixel but only
once every row.)

An interesting question is why something like this isn't already in
the standard library. The supplied parallel functions (pmap, pcalls,
pvalues) don't have for bindings and don't seem to be adaptable to use
them.

Another thing that I thought could be handy is a lazy vector -- each
element is realized only when retrieved. Backed by a vector of delays,
of course. And super-lazy seqs and vectors built on a "weak delay":
something like delay, except that it uses a WeakReference to cache its
value. If it goes away the code that computed it will run again (so it
better not have side effects) if it's needed again. Lazy vectors could
even be backed by a function with a single integer argument -- it
seems unlikely you could define one in another way than as some sort
of mapping from index to value-to-produce anyway. There'd need to be
some kind of tree to hold the cache as well, perhaps one suited to
represent sparse vectors for good performance and low memory use when
few elements were realized. The usual 32^n trees, but with some
branches omitted with nils, might do the job; as it filled in when
elements were realized it would turn into a normal vector as far as
memory use was concerned. In the super-lazy case a (mutable!) map with
weak values (there's one in the Apache Commons) might be preferable to
a tree holding individual weak delays.

How are lazy vectors and super-lazy things relevant to this thread?
Well, the above already implements something like a super-lazy seq in
that a compact closure stands in for each realized item and must be
called repeatedly to produce the true seq element. The only thing
missing is the weak caching. And a super-lazy vector would be
especially easy to use in parallelized manner because it's random
access. The above code that produces offsets i# and stepsizes procs#
would, instead of being fed to (take-nth procs# (drop i# aseq)) to get
functions to invoke, would be fed to (map lvec (range i# (count lvec)
procs#)) to get the actual elements.

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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[Cedric Greevey]

On Thu, May 24, 2012 at 10:34 AM, Armando Blancas  wrote:
> Didn't you see that I pasted my sample from the repl?

I saw that you wrote it in the style of a repl interaction, which
could have been pasted or could have been synthesized by hand. Given
that in the former case it should have been easy for you to see if it
avoided any reflection warnings first before posting it, I naturally
supposed the latter.

> Here it goes again; pay attention:

How rude.

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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[Cedric Greevey]

On Thu, May 24, 2012 at 6:16 AM, John Szakmeister  wrote:
> On Wed, May 23, 2012 at 7:58 PM, Cedric Greevey  wrote:
>> (defn f [^java.awt.image.BufferedImage bi x]
>>  (.setSample (.getRaster bi) 0 0 0 (double x)))
>> #> matching method found: setSample, compiling:(NO_SOURCE_PATH:1)>
>>
>> The only way I was able to find to fix this is
>>
>> (defn f [^java.awt.image.BufferedImage bi]
>>  (.setSample (.getRaster bi) 0 0 0 ^Double (double x)))
>
> I'm entirely not sure what's going on, but this seems to be good in the repl:
>
>    (defn f [^java.awt.image.BufferedImage bi x]
>        (.setSample (.getRaster bi) (int 0) (int 0) (int 0) ^double x))
>
> I tried creating an object and running it through the function as well
> with no warnings.

I don't get it. The setSample methods aren't disambiguated by the
types of the coordinate arguments -- there's just int int int int, int
int int float, and int int int double overloads, so the exact right
one should be inferrable if the final argument is known to be a double
(and the WritableRaster itself is hinted). It being a primitive local
double really ought to suffice, and certainly specifying that the
middle arguments are ints shouldn't logically have any effect. Well,
except to add a bit of overhead with three additional calls to
RT.intCast that really ought to be avoidable.

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

Re: Clojure and the Anti-If Campaign

[Raoul Duke]

hi!

On Thu, May 24, 2012 at 4:42 AM, Rostislav Svoboda
 wrote:
> After seeing [1] from Rich Hickey I wondered what he means with
> "replace if statements with polymorphic functions"? Why and how
> exactly should I do it? Your blogpost opened my eyes. Thanks a lot
> Dominikus

interesting thread. are there folks coming to clojure who aren't
steeped in OO? the whole dynamic dispatch thing is in some sense about
avoiding if's, and is a pretty common clear rule of thumb for oo: if
you have an if, you are probably doing it wrong.

(whereas in functional languages, you should use pattern matching.
which ends up just being sugar for if statements, probably :-)

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

Re: Parallel doseq?

[Sean Corfield]

On Thu, May 24, 2012 at 5:02 AM, John Szakmeister  wrote:
> On Thu, May 24, 2012 at 7:46 AM, Chris Perkins  
> wrote:
> [snip]
>> Also, pmap is not broken; the problem with the code you pasted is simply an
>> errant closing paren. You had (do (doall (pmap ...) nil)), where you meant
>> (do (doall (pmap ...)) nil). Apparently doall has a two-arg version, which
>> is news to me :)
>
> I think you answered my question as well.  Thanks for the nice explanation!

Right, my point was Cedric's code had a bug, not pmap - I was
suggesting a test that would have highlighted that.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Do you leave a Swank / nREPL in your production servers?

[Sean Corfield]

On Thu, May 24, 2012 at 9:07 AM, blais  wrote:
> Is it common for people deploying Clojure servers in a production
> environment to leave a swank or nrepl server running for making live bug
> fixes? Do you guys do this?  Would you advise against it?

We've recently added swank server to our production machines - we
generally start/stop it as needed via an admin console - mostly for
live in-process debugging but we have, very occasionally, applied live
fixes. As Jay and Phil said, not for the faint of heart and not as a
replacement for your normal release process. The in-process debugging
has proved incredibly valuable for us as we've gone thru a massive
data migration and this allows us to easily repro and analyze
unexpected behavior that arises from bad/legacy data that have slipped
thru our automated and manual QA processes. Most fixes that we've
applied live have actually been scripts to clean up anomalies in the
legacy data rather than live code updates.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Do you leave a Swank / nREPL in your production servers?

[Phil Hagelberg]

On Thu, May 24, 2012 at 9:07 AM, blais  wrote:
> Is it common for people deploying Clojure servers in a production
> environment to leave a swank or nrepl server running for making live bug
> fixes? Do you guys do this?  Would you advise against it?

I would recommend having it available for debugging, but using it for
nontrivial live bug fixes is a bit sketchy. Use your judgement; don't
let it replace a real fix.

-Phil

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

Re: Do you leave a Swank / nREPL in your production servers?

[Jay Fields]

Martin,
We have a web-repl that we use for live code updates. Dangerous stuff, not
for the faint of heart.

On Thu, May 24, 2012 at 11:07 AM, blais  wrote:

> Hi,
> Just curious...
> Is it common for people deploying Clojure servers in a production
> environment to leave a swank or nrepl server running for making live bug
> fixes? Do you guys do this?  Would you advise against it?
> 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 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

Do you leave a Swank / nREPL in your production servers?

[blais]

Hi,
Just curious...
Is it common for people deploying Clojure servers in a production 
environment to leave a swank or nrepl server running for making live bug 
fixes? Do you guys do this?  Would you advise against it?
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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[Armando Blancas]

Didn't you see that I pasted my sample from the repl?

Here it goes again; pay attention:

Last login: Thu May 24 07:21:38 on console
~ $ clj
Clojure 1.4.0
user=> (defn f [^java.awt.image.BufferedImage bi x] 
>   (.setData (.getRaster bi) 0 0 0 ^double x)) 
#'user/f
user=> 
~ $ 



On Wednesday, May 23, 2012 10:53:15 PM UTC-7, Cedric Greevey wrote:
>
> On Wed, May 23, 2012 at 10:21 PM, Armando Blancas  
> wrote: 
> > Is this any better? 
> > 
> > user=> (defn f [^java.awt.image.BufferedImage bi x] 
> >   (.setData (.getRaster bi) 0 0 0 ^double x)) 
> > #'user/f 
>
> Didn't have a repl handy? It's quick to check that it produces: 
>
> Reflection warning, NO_SOURCE_PATH:2 - call to setData can't be resolved. 
>

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

Re: Clojure and the Anti-If Campaign

[Ambrose Bonnaire-Sergeant]

I really enjoyed that, thanks Dominikus :)

Ambrose

On Thu, May 24, 2012 at 5:57 PM, Dominikus wrote:

> Three weeks ago I stumbled across the Anti-If Campaign (
> http://www.antiifcampaign.com/).
>
> An instant later I realized that one could easily re-implement "if" in
> Clojure with maps. More interestingly, polymorphic functions can be easily
> motivated with the help of maps. And this naturally leads to multimethods.
>
> If you like, enjoy reading my blogpost on "The root of polymorphism: The
> Anti-If Campaign". It might be an interesting read for Clojure enthusiasts.
>
>
> http://denkspuren.blogspot.de/2012/05/root-of-polymorphism-anti-if-campaign.html
>
>
> Cheers,
>
> Dominikus
>
>
>  --
> 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 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

maths, functions and solvers

[jlk]

Hello

I've got a problem I'm stuck with and would value some extra input...

Basically I'd like to be able to define a maths function with a large 
number of variables, then pass this and a map of arguments to a solve 
function which solves for whatever is not defined in the map.

Now the solve function works well, using Apache Commons Math, but it 
expects a function of one argument.  However the only way I can think of 
converting the argument list and the function into a function of one 
argument is with an intermediate function.  However approach is pretty 
messy as I need to define two functions for each maths function and list 
out the arguments twice.

Ideally I could pass the body of the maths function and a map of arguments 
directly to the solve function without having to define a function 
explicitly, and it would also work for multiple variables, but I might be 
asking a lot.

Here is what I have:-

(defn -cat
  "example math function"
  [{:keys [E A alpha t2 t1 W1 W2 g L T1 T2]}]
  (- (+ (* E A alpha (- t2 t1)) (/ (* (sq W1) (sq g) (sq L) E A) (* 24.0 
(sq T1))) T2) T1 (/ (* (sq W2) (sq g) (sq L) E A) (* 24.0 (sq T2)

(defn cat
  [m]
  (let [v (difference #{:E :A :alpha :t2 :t1 :W1 :W2 :g :L :T1 :T2}
  (keys m))]
(if-not (= (count v) 1)
  (exception "incorrect number of variables"))
(fn [x] (-cat (assoc m (first v) x)

(solve (cat {:E 65000 :A 209.3 :alpha 0.23 :t1 15 :t2 5 :W1 0.576 :W2 
0.576 :g 9.81 :L 45 :T1 1595})
 :start 1
 :min 0
 :max 10
 :max-eval 1000)

and the solver code is on github:  
https://github.com/taprisiot/jlk.math/blob/master/src/jlk/math/optimization.clj


Now there has to be a better way of doing this but I'm stumped.  Any ideas?

As a side note, being able to define functions in infix would also be nice, 
but I don't feel up to creating a maths parser and dealing with ASTs, 
although I can visualise how I might manage the variables using this 
approach.

Thanks for any help!


- Lachlan

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

The http://clojure.org/libraries page

[Shantanu Kumar]

Hi,

The http://clojure.org/libraries page does not seem to be very up to
date. Would be be a good idea to put references to external links
there that maintain lists of Clojure libraries?

[1] http://www.clojure-toolbox.com/
[2] http://clojure-libraries.appspot.com/
[3] http://clojurewerkz.org
[4] http://clojuresphere.herokuapp.com

Shantanu

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

Re: ANN Welle, a Clojure client for Riak with batteries included

[Michael Klishin]

Krukow:

> I've been using sumo for some time, and that has been working out fine for 
> the simple use cases I have.
> 
> Would you mind giving your opinion on how these libraries compare (tradeoffs)

They are similar in many ways. Welle uses implicit connection var while with 
Sumo you always have to pass it around.
Welle separates unrelated features between namespaces, Sumo uses sumo.client 
(if I remember correctly) for all kinds
of things.

Welle has several features Sumo does not:

* Links and lin walking support
* Serialization and deserialization to/from gzipped JSON
* core.cache implementation
* ring session store implementation
* Welle reuses more building blocks in the Riak Java client

I've talked to the Sumo author and the "batteries included client" approach is 
not what he wants Sumo to be.

And maybe the most important aspect, Welle also has many more tests, complete 
documentation guides and is used in real systems transferring many gigabytes of 
data per day. Sumo is a side project with very little documentation and
(if you ask me) pretty incomplete coverage.

That said, Welle's README mentions Sumo in the first paragraph so it's not like 
I am trying to claim that Sumo
is irrelevant.

MK


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

Re: Parallel doseq?

[John Szakmeister]

On Thu, May 24, 2012 at 7:46 AM, Chris Perkins  wrote:
[snip]
> Also, pmap is not broken; the problem with the code you pasted is simply an
> errant closing paren. You had (do (doall (pmap ...) nil)), where you meant
> (do (doall (pmap ...)) nil). Apparently doall has a two-arg version, which
> is news to me :)

I think you answered my question as well.  Thanks for the nice explanation!

-John

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

Re: Parallel doseq?

[Chris Perkins]

On Thursday, May 24, 2012 3:17:56 AM UTC-4, Cedric Greevey wrote:
>
> On Thu, May 24, 2012 at 3:00 AM, Sean Corfield wrote: 
> > On Wed, May 23, 2012 at 11:37 PM, Cedric Greevey wrote: 
> >> Replacing (range 10) with (take 10 (iterate inc 0)) didn't change 
> >> anything. It's still not parallelizing. 
> > 
> > My point was that when you replace (range 10) with (range 100) in your 
> > code, it prints numbers up to 31 and no more. You didn't try that, I 
> > presume? 
>
> Sounds like pmap is *really* broken. (doall (pmap identity x)) should 
> realize every element of x, surely, just like (doall x)? 
>
>  
Unfortunately (pmap identity ...) won't do what you want. The only 
computation that will be parallelized is the call to identity.

To pmap, the for-expression is a black box - just a seq - it cannot reach 
into it and parallelize its insides. It can only consume it sequentially.

The meat of pmap is this: (map #(future (f %)) coll)
That must produce each element of coll (in this case, the for-loop), in 
order, *before* passing it to future.


Also, pmap is not broken; the problem with the code you pasted is simply an 
errant closing paren. You had (do (doall (pmap ...) nil)), where you meant 
(do (doall (pmap ...)) nil). Apparently doall has a two-arg version, which 
is news to me :)


- Chris Perkins
 
 

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

Re: Clojure and the Anti-If Campaign

[Rostislav Svoboda]

After seeing [1] from Rich Hickey I wondered what he means with
"replace if statements with polymorphic functions"? Why and how
exactly should I do it? Your blogpost opened my eyes. Thanks a lot
Dominikus

Bost

[1] http://www.infoq.com/presentations/Simple-Made-Easy

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

Re: Parallel doseq?

[John Szakmeister]

On Thu, May 24, 2012 at 2:15 AM, Sean Corfield  wrote:
> First off, the code you posted can't actually be right: you have
> (println n) but the for binding was for i.
>
> Second, given your macro, try (range 100) instead of (range 10) and
> see what you get...

Can you explain that a little more Sean?  I know of some issues with
chunked sequences, but I expected this to work as well with the doall
in there.

Thanks!

-John

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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[John Szakmeister]

On Wed, May 23, 2012 at 7:58 PM, Cedric Greevey  wrote:
> (defn f [^java.awt.image.BufferedImage bi x]
>  (.setSample (.getRaster bi) 0 0 0 (double x)))
> # matching method found: setSample, compiling:(NO_SOURCE_PATH:1)>
>
> The only way I was able to find to fix this is
>
> (defn f [^java.awt.image.BufferedImage bi]
>  (.setSample (.getRaster bi) 0 0 0 ^Double (double x)))

I'm entirely not sure what's going on, but this seems to be good in the repl:

(defn f [^java.awt.image.BufferedImage bi x]
(.setSample (.getRaster bi) (int 0) (int 0) (int 0) ^double x))

I tried creating an object and running it through the function as well
with no warnings.

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

Clojure and the Anti-If Campaign

[Dominikus]

Three weeks ago I stumbled across the Anti-If Campaign (
http://www.antiifcampaign.com/).

An instant later I realized that one could easily re-implement "if" in 
Clojure with maps. More interestingly, polymorphic functions can be easily 
motivated with the help of maps. And this naturally leads to multimethods.

If you like, enjoy reading my blogpost on "The root of polymorphism: The 
Anti-If Campaign". It might be an interesting read for Clojure enthusiasts.

http://denkspuren.blogspot.de/2012/05/root-of-polymorphism-anti-if-campaign.html
 

Cheers,

Dominikus


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

Re: ANN Welle, a Clojure client for Riak with batteries included

[Krukow]

Thanks. I'm quite interested in this.

I've been using sumo for some time, and that has been working out fine for 
the simple use cases I have.

Would you mind giving your opinion on how these libraries compare 
(tradeoffs)


On Wednesday, May 16, 2012 4:23:16 PM UTC+2, Michael Klishin wrote:
>
> I am happy to announce Welle [1], a Clojure client for Riak with batteries 
> included. 
>
> Welle supports almost all Riak 1.x features: 
>
>  * K/V operations 
>  * Bucket operations 
>  * Secondary indexes 
>  * Map/reduce queries 
>  * Links, link walking 
>  * HTTP and Protocol Buffers transports 
>
> and also provides some additional or Clojure-specific things: 
>
>  * Transparent serialization and deserialization of stored values for 
> common formats (JSON, Clojure reader, text, gzipped JSON) 
>  * core.cache protocol implementation on top of Riak 
>  * Ring session store implementation on top of Riak 
>  * Unit testing helpers 
>
> Welle is licensed under the EPL and targets Clojure 1.3+ from the ground 
> up. 
>
> Documentation guides at http://clojureriak.info are pretty complete and 
> API is stable. To get started, please 
> visit http://clojureriak.info/articles/getting_started.html. New releases 
> and important updates are 
> announced on Twitter @ClojureWerkz. 
>
> We also have a mailing list [3] and use travis-ci.org for continuous 
> integration [4] against 3 Clojure versions 
> (1.3, 1.4 and 1.5 master snapshots). 
>
> 1. http://clojureriak.info 
> 2. https://github.com/michaelklishin/welle 
> 3. http://groups.google.com/group/clojure-riak 
> 4. http://travis-ci.org/#!/michaelklishin/welle 
>
> MK 
>
>

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

Re: [ANN] Carmine, a new Redis client for Clojure

[Peter Taoussanis]

Thanks Baishampayan, appreciate it.

Just shout if you run into any problems or have any requests!

- Peter Taoussanis

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

Re: Parallel doseq?

[Cedric Greevey]

On Thu, May 24, 2012 at 3:00 AM, Sean Corfield  wrote:
> On Wed, May 23, 2012 at 11:37 PM, Cedric Greevey  wrote:
>> Replacing (range 10) with (take 10 (iterate inc 0)) didn't change
>> anything. It's still not parallelizing.
>
> My point was that when you replace (range 10) with (range 100) in your
> code, it prints numbers up to 31 and no more. You didn't try that, I
> presume?

Sounds like pmap is *really* broken. (doall (pmap identity x)) should
realize every element of x, surely, just like (doall x)?

In any event I have a working workaround now, one that uses an
explicit thread pool. It's ugly but it works.

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

Re: Midje 1.4 released

[CA]

Yeah!

On May 24, 12:29 am, Brian Marick  wrote:
> Midje is a test framework for Clojure. It supports top-down as well as 
> bottom-up testing, encourages readable tests, provides a smooth migration 
> path from clojure.test, and supports a balance between abstraction and 
> concreteness.
>
> Special thanks to Alex Baranosky for all his work on this version.
>
> Changes:https://github.com/marick/Midje/wiki/New-in-1.4
> User documentation:https://github.com/marick/Midje/wiki
> Repo:https://github.com/marick/Midje
>
> -
> Brian Marick, Artisanal Labrador
> Contract programming in Ruby and Clojure
> Occasional consulting on Agilewww.exampler.com,www.twitter.com/marick

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

Re: Parallel doseq?

[Sean Corfield]

On Wed, May 23, 2012 at 11:37 PM, Cedric Greevey  wrote:
> Replacing (range 10) with (take 10 (iterate inc 0)) didn't change
> anything. It's still not parallelizing.

My point was that when you replace (range 10) with (range 100) in your
code, it prints numbers up to 31 and no more. You didn't try that, I
presume?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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