Yes, very important difference that. Clojure will *not* return incorrect
results on overflow (Java will) but it might throw an exception.
--
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
On Mon, Jan 17, 2011 at 3:10 AM, chris cnuern...@gmail.com wrote:
Is it insane to suggest that perhaps clojure should work with scala
such that we can write both languages in the same file?
A lot of reasons for which it is not possible:
- it would mean coordinating two
Yeah yeah!
http://www.google.com/search?q=lisp+type+inference
Chris
On Jan 17, 5:55 am, nicolas.o...@gmail.com nicolas.o...@gmail.com
wrote:
On Mon, Jan 17, 2011 at 3:10 AM, chris cnuern...@gmail.com wrote:
Is it insane to suggest that perhaps clojure should work with scala
such that we
Hi Stuart,
On 2011-01-15, at 4:06 PM, Stuart Halloway wrote:
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.
On Jan 16, 6:18 pm, Sean Corfield seancorfi...@gmail.com wrote:
On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe ja...@w01fe.com wrote:
Moreover, we do not need to redefine the class at run-time. A simple
way to do this: when you compile a function with arithmetic
operations, concatenate
On Mon, Jan 17, 2011 at 1:05 PM, Bob Hutchison hutch-li...@recursive.ca wrote:
Numerical correctness, for some of us, is an overwhelming issue. This is
purely from experience... bad experience... 30+ years of bad experience in my
case :-) From my point of view, the approach Clojure is taking
On Jan 17, 3:17 pm, Jason Wolfe ja...@w01fe.com wrote:
I think you can. Let me elaborate on my simplistic example. Compile
the code for a function twice -- once where everything works within
primitives, and once where everything works with Objects -- and
concatenate the bytecode together.
On Jan 17, 3:24 pm, Brian Goslinga quickbasicg...@gmail.com wrote:
On Jan 17, 3:17 pm, Jason Wolfe ja...@w01fe.com wrote: I think you can.
Let me elaborate on my simplistic example. Compile
the code for a function twice -- once where everything works within
primitives, and once where
I'll also add that type inference wouldn't solve the problem, it would
just move the pain the the design of the type system and details
relating to it. The type system would probably be at least as complex
as Java generics to be something worthwhile if you do the type
inferencing for perf
On 16 January 2011 05:35, Jason Wolfe ja...@w01fe.com wrote:
(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
Then again, how often do you write code that might be
doing maths with numbers that big and not realise it? For that
matter, how often do you write code that might be doing maths with
numbers that big and not spend time thinking carefully about its
performance anyway?
This reminds me of a
(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
On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe ja...@w01fe.com wrote:
Moreover, we do not need to redefine the class at run-time. A simple
way to do this: when you compile a function with arithmetic
operations, concatenate bytecode for two versions: essentially, one
with the unprimed
Is it insane to suggest that perhaps clojure should work with scala
such that we can write both languages in the same file?
Use scala to do you strongly typed work and things where you are
really concerned that auto-promotion. Let the language made for
helping a programmer lots of information
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
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
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
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
Debatable it is, endlessly. ;) So Clojure committers made a choice.
Hopefully, they have made a choice that has:
* a small positive effect (better performance with less effort) on a
majority of users
* a small negative effect (worse performance, extra effort) on a minority
-S
--
You
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.
On Jan 14, 2:40 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote:
Debatable it is, endlessly. ;) So Clojure
Hi all,
I've been reading about the changes to Clojure that are occurring with
regards to improving performance of arithmetic operations. For
example, + no longer auto promotes and +' has been introduced as an
auto-promoting addition operator.
The idea of introducing additional syntax is a bit
The goal of primitive math is better performance in the common case. The
implementation makes the assumptions that Java long is big enough for nearly
all cases, and that auto-promotion to BigInteger (and the resulting
performance hit) is rarely desirable.
The + function still promotes, it just
On Thu, Jan 13, 2011 at 7:28 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
The goal of primitive math is better performance in the common case.
Of course, this better performance is not needed in the common case,
IMO, but only in hotspots that do number crunching, where people
already
29 matches
Mail list logo
