JVMs has a strange limitation for the size of methods.
I don't know if there is a plan to solve that on the JVM side.
It is quite hard to solve that on the compiler side.
When I bumped inot this (once for an ICFP contest), I rewrote a macro
so that it emitted
smaller methods called from a big meth
On Sun, 14 Nov 2010 00:48:13 -0500
Robert McIntyre wrote:
> So my friend and I were screwing around, battling versions of LISP as
> nerds are wont to do, when I came across this:
>
> (eval `(clojure.core/+ ~@(take 1e4 (iterate inc 1
> Invalid method Code length 89884 in class file user$eval1
Math/abs won't accept ratios, so I assumed the Java Math functions
only took base number types but all the other methods I tried accept
ratios just fine.
user=> (Math/sin 1/2)
0.479425538604203
user=> (Math/sqrt 1/2)
0.7071067811865476
user=> (Math/pow 1/2 1/2)
0.7071067811865476
user=> (Math/abs
(map vector [1 2 3] [4 5 6] [7 8 9]) gives back ([1 4 7] [2 5 8] [3
6 9])
but if I have a function that returns the list:
'([1 2 3] [4 5 6] [7 8 9])
and call map vector with the list, then I no longer get ([1 4 7] [2 5
8] [3 6 9])
i.e.
(def x '([1 2 3] [4 5 6] [7 8 9]))
(map vector x)
==
> (apply (partial map vector) [[1 2 3] [4 5 6] [7 8 9]])
([1 4 7] [2 5 8] [3 6 9])
On Sun, Nov 14, 2010 at 2:16 PM, garf wrote:
> (map vector [1 2 3] [4 5 6] [7 8 9]) gives back ([1 4 7] [2 5 8] [3
> 6 9])
> but if I have a function that returns the list:
> '([1 2 3] [4 5 6] [7 8 9])
> and c
@Nicolas Oury
I'd normally agree that "you just shouldn't do that kind of thing,"
but this is not correct behaviour for something that I would consider
a basic thing. It feels dirty that our functions don't work for
"arbitrary arities" but instead for arities only between 0 and around
7000. Sinc
The use of "partial" is unnecessary because "apply" takes any number
of arguments and expands its last argument.
(apply map vector [[1 2 3] [4 5 6] [7 8 9]])
is equivalent to
(map vector [1 2 3] [4 5 6] [7 8 9])
and results in
([1 4 7] [2 5 8] [3 6 9])
On Sun, Nov 14, 2010 at 8:30 AM, Moritz
On 14 November 2010 15:43, Robert McIntyre wrote:
> @Nicolas Oury
> I'd normally agree that "you just shouldn't do that kind of thing,"
> but this is not correct behaviour for something that I would consider
> a basic thing. It feels dirty that our functions don't work for
> "arbitrary arities"
There are four separate methods called Math/abs, to handle the
following types: int, long, float, double. So when you use Math/abs on
a different Number type, it is not clear which of those methods it
should use.
The other examples you gave can only accept double. Maybe in that case
Clojure is aut
> I believe the underlying problem is a limit of the JVM. Maybe it
> would be possible for the Clojure compiler to work around the
> limitation, though.
It has a non trivial interaction with the lack of TCO.
The trivial transformation of going from a big method to a sequence of
small methods coul
How about just
user=> (vector [1 2 3] [4 5 6] [7 8 9])
[[1 2 3]
[4 5 6]
[7 8 9]]
user=>
--
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 - p
On Sun, 14 Nov 2010 08:43:11 -0500
Robert McIntyre wrote:
> @Mike Meyer
> Using apply is different than what I'm doing.
Yup.
> When I use eval I'm trying to evaluate a huge s-expression.
> When you use apply you're evaluating a s-expression with three
> elements. Same thing with the count form (
On Fri, Nov 12, 2010 at 4:25 PM, Scott Jaderholm wrote:
> I don't think there are any great new movies in the theater this weekend so
> if you're looking to kick back and relax and watch the tube a bit you might
> checkout the first few episodes of my new screencast series on Clojure,
> Emacs, Sli
In the API it is suggested to use `seq` to check if coll is empty.
I was working on some code recently found that my biggest performance
bottleneck was calling `seq` to check for emptiness. The calls to
`seq` were causing lots of object allocation and taking noticeable CPU
time. I switched to usin
On Sun, Nov 14, 2010 at 2:16 PM, Eric Kobrin wrote:
> In the API it is suggested to use `seq` to check if coll is empty.
>
> I was working on some code recently found that my biggest performance
> bottleneck was calling `seq` to check for emptiness. The calls to
> `seq` were causing lots of object
On Nov 14, 2010, at 2:16 PM, Eric Kobrin wrote:
> In the API it is suggested to use `seq` to check if coll is empty.
Your timing results raise some interesting questions, however, the API doesn't
suggest using 'seq' to check if a collection is empty. That's what 'empty?' is
for. The documentat
On Sun, Nov 14, 2010 at 2:42 PM, Ken Wesson wrote:
> user=> (let [iterations 1] (time (dotimes [_ iterations]
> (= [] (pop [3] (time (dotimes [_ iterations] (seq []
> "Elapsed time: 29994.93852 msecs"
> "Elapsed time: 2745.21924 msecs"
It occurred to me that the JIT might not be h
On Sat, Nov 13, 2010 at 11:33 PM, Eric Schulte wrote:
> I'm about to begin starting all of my clojure namespaces with
> (def o comp) ; o for cOmp, Haskell's (.) or Mathematical composition \circ
> (def p partial) ; p for partial
> Is there any support for including these function aliases for `com
Hi all,
When I ran some Clojure Dojo's in Dundee, we did a few group sessions
going through labrepl and its exercises; and I thought the format
worked well. I'm keen to do the same thing again, here in Manchester
(UK):
http://madlab.org.uk/content/kick-ass-coding-with-clojure/
Unfortunately the
In the particular bit of code I'm working on, I have a collection of
vectors. The last one is always [] and no others are empty. Using
`identical?` instead of `seq` to detect that last vector shaved quite
a bit of time in my loop.
This brought to mind the general case of detecting emptiness. The
c
Github is down at the moment unfortunately...
On Sun, Nov 14, 2010 at 3:27 PM, Rick Moynihan wrote:
> Hi all,
>
> When I ran some Clojure Dojo's in Dundee, we did a few group sessions
> going through labrepl and its exercises; and I thought the format
> worked well. I'm keen to do the same thing
That is not in fact an adequate workaround ---
(eval `(apply + ~@(take 9001 (iterate inc 1 ;; OVER 9000!!!
or, alternately
(eval (cons 'apply (cons '+ (take 9001 (iterate inc 1)
will fail just as in the addition examples.
It's not true that you can just use an apply in your auto gener
On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin wrote:
> In the particular bit of code I'm working on, I have a collection of
> vectors. The last one is always [] and no others are empty. Using
> `identical?` instead of `seq` to detect that last vector shaved quite
> a bit of time in my loop.
The
On Sun, Nov 14, 2010 at 4:33 PM, David Nolen wrote:
> On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin wrote:
>>
>> In the particular bit of code I'm working on, I have a collection of
>> vectors. The last one is always [] and no others are empty. Using
>> `identical?` instead of `seq` to detect that
On Nov 14, 2010, at 4:04 PM, Ken Wesson wrote:
> Interestingly, (= (count v) 0) is relatively fast (900 msec); (seq v)
> is slower (2s); (empty? v) is even slower (3s); and (= v []) is
> slowest (16s).
Strange. Here are the timings I get for 1e8 iterations:
(zero? (count v)): ~3600 msecs
(seq v)
Am 14.11.2010 07:33, schrieb Eric Schulte:
Hi,
I find myself frequently using the `comp' and `partial' functions and
while I really enjoy being able to program in a point free style, the
length (in characters) of these command names often has the effect of
causing what should be a brief statemen
It might be interesting to add a Clojure frontend to Nengo. Having
said that, Nengo is very "opinionated" in the sense that you have to
buy in to the kind of neural simulation Eliasmith is doing (and the
way he's doing it), which Eric may not be interested in doing. There
are many other kinds of
On Nov 14, 2010, at 4:21 PM, Robert McIntyre wrote:
> It's not true that you can just use an apply in your auto generated
> code, you would instead have to do something like a tree of function
> calls, so It may be worth increasing the limit for for the sake of
> enabling machine generated code.
>
On Sun, Nov 14, 2010 at 4:21 PM, Robert McIntyre wrote:
> That is not in fact an adequate workaround ---
>
> (eval `(apply + ~@(take 9001 (iterate inc 1 ;; OVER 9000!!!
>
> or, alternately
>
> (eval (cons 'apply (cons '+ (take 9001 (iterate inc 1)
>
> will fail just as in the addition ex
Some more String-specific timings, modified to avoid inlining
differences between alternatives:
(let [iterations 1e8] (time (dotimes [_ iterations] (= 0 (.length
(.substring "x" 1) (time (dotimes [_ iterations] (seq (.substring
"x" 1)
"Elapsed time: 3125.125 msecs"
"Elapsed time: 8198.331
Hi,
I think a better usage for max-key would be
(max-key f someseq)
rather than passing the values as args.
I used
(defn max-key-seq [f someseq]
(apply max-key (into [f] someseq)))
to make it do what I wanted
Is there a better way?
Cheers,
Tom
--
You received this message because you are s
On 15 November 2010 14:17, Tom Hall wrote:
> Hi,
>
> I think a better usage for max-key would be
> (max-key f someseq)
> rather than passing the values as args.
>
> I used
> (defn max-key-seq [f someseq]
> (apply max-key (into [f] someseq)))
> to make it do what I wanted
>
> Is there a better wa
32 matches
Mail list logo
