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
No
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 primarily
On Jan 17, 3:24 pm, Brian Goslinga wrote:
> On Jan 17, 3:17 pm, Jason Wolfe 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 -- an
On Jan 17, 3:17 pm, Jason Wolfe 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. Start by runn
On Mon, Jan 17, 2011 at 1:05 PM, Bob Hutchison 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 isn't
> persuasive, n
On Jan 16, 6:18 pm, Sean Corfield wrote:
> On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe 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: essenti
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/
Yeah yeah!
http://www.google.com/search?q=lisp+type+inference
Chris
On Jan 17, 5:55 am, "nicolas.o...@gmail.com"
wrote:
> On Mon, Jan 17, 2011 at 3:10 AM, chris wrote:
> > Is it insane to suggest that perhaps clojure should work with scala
> > such that we can write both languages in the same
On Mon, Jan 17, 2011 at 3:10 AM, chris 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 implementations/implementers.
- it would
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 abo
On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe 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 (exception-throwing) o
> >> (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
> 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
On 16 January 2011 05:35, Jason Wolfe 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 to box
> (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
> 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
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,
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
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 wrote:
> Debatable it is, endlessly. ;) So Clojure committers made a choice.
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 receiv
On Thu, Jan 13, 2011 at 7:28 PM, Stuart Sierra
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 optimize using primitive loc
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
I can't speak for Rich, but your suggestion would mean an additional
if statement being executed every time you call +. Not sure if
Hotspot (or other JVMs) would compile that away or not...
Colin
On Jan 13, 3:31 pm, RJ Nowling wrote:
> Hi all,
>
> I've been reading about the changes to Clojure
31 matches
Mail list logo
