In January Mark Engelberg brought up the subject of certain "missing"
math functions and provided some nice code to fix the situation. [1]
I'm still pretty new to Clojure, and I don't understand all of the
ins and outs of Mark's code, but I've come up with im
> but apply works very well for this use case: (apply < (range 10))
> and it stops as soon as it can:
Alright, I fold... thanks for clearing things up Christophe!
On Tue, Feb 3, 2009 at 3:13 PM, Christophe Grand wrote:
>
> Stu Hood a écrit :
> > I still think the
> > (< (range 10))
> > ... use c
Stu Hood a écrit :
> I still think the
> (< (range 10))
> ... use case is really worthwhile though, and I don't see a way to
> accomplish it with reduce.
reduce is not a good fit since you would want to short circuit the
computation at the first false.
but apply works very well for this use cas
> This is a common misconception: passing a seq to apply doesn't force its
> evaluation.
Ahh, is this because the [& more] portion is itself a lazy sequence? That's
very cool =)
Hmm, the (reduce + ...) approach works just fine, but if it is already
implemented as reduce, it seems like it would be
Hello,
stuhood a écrit :
> Functions like (+), (*), (-), (and probably more) should support
> sequences as parameters.
>
> The current way to accomplish this (without implementing your own sum
> using reduce) seems to be:
>
>> (apply + (map #(. Math pow 2 %) (range 10)))
>>
> ... which ha
Functions like (+), (*), (-), (and probably more) should support
sequences as parameters.
The current way to accomplish this (without implementing your own sum
using reduce) seems to be:
> (apply + (map #(. Math pow 2 %) (range 10)))
... which has to generate the sequence first.
Instead, you sho
On Jan 3, 2:48 pm, "Mark Engelberg" wrote:
> I've noticed that Clojure is missing several math functions that come
> standard with most programming languages, especially other
> Schemes/Lisps. Many of these functions are available in java's math
> library, but on
On Jan 3, 7:46 pm, vogelrn wrote:
> sqrt(a/b) should always be equal to sqrt(a)/sqrt(b) since (a/b)^m =
> a^m/b^m for b != 0. However, I'm unsure of whether it's the best
> option for ratios because unless both the numerator and the
> denominator are perfect squares, you're going to end up with
sqrt(a/b) should always be equal to sqrt(a)/sqrt(b) since (a/b)^m =
a^m/b^m for b != 0. However, I'm unsure of whether it's the best
option for ratios because unless both the numerator and the
denominator are perfect squares, you're going to end up with a float
anyway. This is trading an extra s
On Sat, Jan 3, 2009 at 7:06 PM, Mark H. wrote:
> Would you
> find a sqrt that returns complex numbers for negative inputs (it would
> be the appropriate branch of the sqrt function in order to make it
> single-valued) useful?
Ideally I'd also like that, but since complex numbers aren't part of
On Jan 3, 11:48 am, "Mark Engelberg" wrote:
> If you give it an exact number (i.e., not a floating point),
Floating-point numbers are exact -- it's their operations that may not
be. *ducks*
Seriously, handy code -- many thanks! I should check with someone
whether sqrt(a/b) -> sqrt(a)/sqrt(b)
I've noticed that Clojure is missing several math functions that come
standard with most programming languages, especially other
Schemes/Lisps. Many of these functions are available in java's math
library, but only for doubles.
I am attaching a file that tries to "do the r
12 matches
Mail list logo
