On Fri, 14 Jan 2011 01:48:43 -0800 (PST)
Meikel Brandmeyer m...@kotka.de wrote:
Or:
(defmethod foo (clojure.lang.RT/classForName [[F)
...)
But isn't this too dependent on the actual implementation? I would
think that [[F is an implementation detail of the JVM.
regards,
Marek
--
You
On Jan 15, 2:40 am, Armando Blancas armando_blan...@yahoo.com wrote:
They used to give you compile switches for that kind of stuff, not
hope and wholesome wishes. Seems like every performance improvements
makes the language more complex, uglier or both.
I don't feel strongly about integer
It's in the Java spec.
http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.8
--
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
I'm going to re-organise this a bit…
On Jan 14, 2:40 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote:
Debatable it is, endlessly. ;) So Clojure committers made a choice.
Hopefully, they have made a choice that has:
I agree that they've made a choice, and I really don't want to be too
Hi,
just for the record: from what I have done in the past I wholeheartedly
agree with Bob. Of course the developers of Clojure have the final say on
this. It's just my 2ct.
Kind regards,
Stefan
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Bob Hutchison said:
In other words, I'd be very
annoyed, and I'd expect others to be annoyed too, if a numerical
error was introduced to one of my programs because of an unexpected, silent,
compiler optimisation.
Just to be clear, Clojure 1.3-alpha does not introduce numerical
errors,
On Jan 15, 2011, at 8:29 AM, Saul Hazledine wrote:
It would help people like me understand the debate if some mainstream
examples of applications requiring (seamless) BigInteger support could
be identified.
I doubt that many will consider this mainstream, but I evolve programs using
Sharing my first useful Clojure program. Feedback welcome.
http://bit.ly/clojure-rotten-tomatoes
--
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
I think this is looking at the situation backwards. I don't want
BigInts, why should I want *them*? Nor longs or whatever for that
matter. What I want is a numerical tower and a language that can
handle it correctly, without blowing up, and if possible with clean
code. I can type
Guy Steele recently gave a talk about thinking about parallel programming.
For those of us who are looking at Clojure in a parallel setting (e.g.
MPI, Hadoop)
this might be of interest:
http://www.infoq.com/presentations/Thinking-Parallel-Programming
--
You received this message because you
On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
We have thought about this quite a bit, and an argument from one axis only
(e.g safe/unsafe) that doesn't even mention some of the other axes is not
likely to be persuasive. Would be more interesting to see a
On Sat, Jan 15, 2011 at 9:40 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
We have thought about this quite a bit, and an argument from one axis only
(e.g safe/unsafe) that doesn't even mention some of the
On Jan 15, 2011, at 4:04 PM, Stuart Halloway wrote:
I'll make a documentation update higher priority; hopefully that will help.
This should help. I feel like the discussion is going in circles because
there's no single, official source that summarizes exactly what is happening
with numerics
(a) unsafe/incorrect value on overflow/fastest/unifiable* vs.
(b) safe/error on overflow/fast/unifiable vs.
(c) safe/promoting on overflow/slow/not-unifiable
If I understand correctly, the issue with auto-promotion is that we
have to box the output of an operation even if it turns out to fit
In the Hacker News discussion about that talk, someone posted a link
to another talk by Guy Steele on the same topic:
http://vimeo.com/6624203
... where he covers the material in somewhat greater depth (the
downside being that by the 30-minute mark, I was struggling to keep up
with the flow of
15 matches
Mail list logo
