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 id
> (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
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 i
On Sat, Jan 15, 2011 at 9:40 PM, Mark Engelberg
wrote:
> On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway
> 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 persuasi
On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway
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 new axis we
> haven't t
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
> 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 92233720
> In my experience, errors are the problem and we should be avoiding them,
> almost at all costs.
This debate always starts by conflating three things into two, and then goes
downhill from there. :-( It isn't
(a) safe/slow vs.
(b) unsafe/fast.
It is
(a) unsafe/incorrect value on overflow
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 mode
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 922337203685477580
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
ge
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, u
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
I'm going to re-organise this a bit…
> On Jan 14, 2:40 pm, Stuart Sierra 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 critical
here. However,
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
On Jan 15, 2:40 am, Armando Blancas 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 limits at all and am alwa
On Sat, Jan 15, 2011 at 6:44 AM, David Powell wrote:
> Ken Wesson wrote:
>> Even then, couldn't the compiler generate the needed interfaces for a
>> specific Clojure project on the fly along with the appropriate calls?
>
> I don't see why it couldn't. Actually I just hacked the Clojure
> compiler
Ken Wesson wrote:
> The interfaces are needed only if the function is passed around as an
> object or dynamically rebound; if it's just called at a few fixed
> sites, those calls can be directly to a known class.
The class names of function implementations seem to be a Clojure
implementation det
On Sat, Jan 15, 2011 at 5:17 AM, Marek Kubica wrote:
> On Fri, 14 Jan 2011 01:48:43 -0800 (PST)
> Meikel Brandmeyer 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 i
On Fri, 14 Jan 2011 01:48:43 -0800 (PST)
Meikel Brandmeyer 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 received
20 matches
Mail list logo
