Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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/

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

> >> (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

Re: Enhanced Primitive Support Syntax

> 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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

> (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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

> 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

Re: Enhanced Primitive Support Syntax

> 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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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,

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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.

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced Primitive Support Syntax

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

Re: Enhanced primitive support - redux

If there is some sort of new numeric tower on the plate, what would be some desirable properties? On Jun 25, 10:58 pm, Andrzej wrote: > On Sat, Jun 26, 2010 at 4:04 AM, Rich Hickey wrote: > > equiv, the revenge of num > > Has it already been decided that some sort of this new numeric tower > wil

Re: Enhanced primitive support - redux

Thirded. On Jun 25, 4:55 pm, Mark Engelberg wrote: > On Fri, Jun 25, 2010 at 2:39 PM, Garth Sheldon-Coulson wrote: > > Personally, I think (= 3 3M) => true and (= 3/10 0.3M) => true would be nice > > to have, given that (= 3 3N) => true. Both are currently false in equiv. I > > also think (= 3.0

Re: Enhanced primitive support - redux

Hi, Re: caching boxed ints: >>I think I pointed it out, and I reiterate it will probably not improve >>performance a lot (Except if you use always the 5 same numbers). > Reiteration won't make it true. At about 10m - 12m into this video, Cliff Click suggests that Java's caching of Integer obje

Re: Enhanced primitive support - redux

And, by the way, after having looked into the compiler source, the current Master already uses the valeOf function. On Sat, Jun 26, 2010 at 2:31 PM, Nicolas Oury wrote: > http://tech.puredanger.com/2007/02/01/valueof/ > > Apparently, a program that

Re: Enhanced primitive support - redux

http://tech.puredanger.com/2007/02/01/valueof/ Apparently, a program that only access 1 integer (0) is only twice as fast when caching. We are very far from the *10/20 that occurs. On Sat, Jun 26, 2010 at 2:04 PM, Mike Meyer < mwm-keyword-googlegrou

Re: Enhanced primitive support - redux

On Sat, Jun 26, 2010 at 3:59 PM, B Smith-Mannschott wrote: > > This was suggested on the previous thread on this topic as well, but > I don't think it was pointed out that *Java already does this*. > > See the inner class IntegerCache at line 608: > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/

Re: Enhanced primitive support - redux

[Format recovered from top posting.] "Nicolas Oury" wrote: >On Sat, Jun 26, 2010 at 7:59 AM, B Smith-Mannschott >wrote: > >> This was suggested on the previous thread on this topic as well, but >> I don't think it was pointed out that *Java already does this*. Doesn't matter if clojure is boxing

Re: Enhanced primitive support - redux

I think I pointed it out, and I reiterate it will probably not improve performance a lot (Except if you use always the 5 same numbers). On Sat, Jun 26, 2010 at 7:59 AM, B Smith-Mannschott wrote: > This was suggested on the previous thread on this topic as well, but > I don't think it was pointed

Re: Enhanced primitive support - redux

Hi, On 25 Jun., 21:04, Rich Hickey wrote: > equiv, the revenge of num [...] > Feedback welcome, sorry, no feedback, but one question which is rather important to me: will this make it into Clojure 1.2? Kind regards, Stefan -- You received this message because you are subscribed to the Google

Re: Enhanced primitive support - redux

On Sat, Jun 26, 2010 at 05:58, Andrzej wrote: > On Sat, Jun 26, 2010 at 4:04 AM, Rich Hickey wrote: >> equiv, the revenge of num > > Has it already been decided that some sort of this new numeric tower > will find its way into Clojure? > > Personally, I think this change will open a can of worms

Re: Enhanced primitive support - redux

On Sat, Jun 26, 2010 at 4:04 AM, Rich Hickey wrote: > equiv, the revenge of num Has it already been decided that some sort of this new numeric tower will find its way into Clojure? Personally, I think this change will open a can of worms and make programming in Clojure more difficult and error p

Re: Enhanced primitive support - redux

I'll reiterate a question I asked a while back, but was never answered: Are the bit-bashing operators (bit-*) going to get the same treatment as the arithmetic operators? I would expect that many of the fields that benefit if the latter to be fast would also benefit from the former being fast, and

Re: Enhanced primitive support - redux

On Fri, Jun 25, 2010 at 2:39 PM, Garth Sheldon-Coulson wrote: > Personally, I think (= 3 3M) => true and (= 3/10 0.3M) => true would be nice > to have, given that (= 3 3N) => true. Both are currently false in equiv. I > also think (= 3.0M 3.00M) => true would be nice. As Rich said, there's no > pa

Re: Enhanced primitive support - redux

> I should have said "they shouldn't be equal" based on Rich Hickey's > explanation that from now on (= 1 1.0) will return false. I think by > this logic (= 1.0M 1.0) should also be false. I have no idea what the > current branch actually does though -- haven't tried it yet. > > Ah, yeah, fair en

Re: Enhanced primitive support - redux

A couple points of clarification: On Fri, Jun 25, 2010 at 1:35 PM, Mark Engelberg wrote: > You don't want the hashCode of bigdecimal to match the corresponding > double.  They aren't equal, so they shouldn't have the same hashcode. > They aren't equal because one is exact and one is inexact. I s

Re: Enhanced primitive support - redux

floats and doubles are "inexact" numbers and ratios, ints, longs, bigints, and bigdecimals are "exact" numbers. The expected behavior is that inexact things contaminate exact things, because now the result is inexact. This is what Clojure does. On Fri, Jun 25, 2010 at 1:18 PM, Garth Sheldon-Couls

Re: Enhanced primitive support - redux

Following up, point (2) in my previous message would be helpful only if = were changed so that it looked at the stripTrailingZeros() value of BigDecimals. I would advocate this in any case, because the following behavior appears silly to me (is it useful to anyone?): user=> (== 434343.00M 434343.0

Re: Enhanced primitive support - redux

Amazingly good ideas. Will try it tomorrow. On Fri, Jun 25, 2010 at 8:04 PM, Rich Hickey wrote: > equiv, the revenge of num > > The latest revision of primitive support is in the equiv branch. It takes > the approach of num, with no auto-promotion, and bigint contagion, and adds > several things

Re: Enhanced primitive support - redux

This looks excellent. I'd like to re-raise a question I had a few days ago: Will this ultimately come to affect floats, too? In particular: 1) If there is going to be BigInt contagion, why not BigDecimal contagion? user=> (* 4 5) 20 user=> (* 4 5N) 20N but user=> (* 4.0 5.0) 20.0 user=> (* 4.

Re: Enhanced Primitive Support

[Not really about enhanced primitive support - more about optimization on the jvm.] On Tue, 22 Jun 2010 01:47:26 -0400 David Nolen wrote: > Yet consider this, If I'm writing OpenGL code in Penumbra I will have quite > a bit of code that amounts to the following: > > ; 630 msecs > (dotimes [_ 10

Re: Enhanced Primitive Support

Another thing I noticed, clojures array functions are using int's as index, so to get best performance from them you currently need to cast every counter you use to a int by hand so you have (loop [i (int 0)] ... since otherwise there will be a lot of type casting when accessing arrays. So a goo

Re: Enhanced Primitive Support

On Sat, Jun 19, 2010 at 5:41 AM, Heinz N. Gies wrote: > Lets get away from the argument already cast and bring a new one. It is an > impossible situation that the literal 1 in one place has a different meaning > and behavior then in another place. This is in fact a show stopper, I'm > serious, th

Re: Enhanced Primitive Support

Hmm yesterday Rick said that the new changes give clojure a chance to put down the 'scala is faster then clojure' argument. So I figured I give it a try and implemented some of the shootouts: fannkucken-redux and the regexdna example. I found some interesting things especially once I got carried

Re: Enhanced Primitive Support

Other math functions as max, min and so on should behave the same as +, - I think it is kind of confusing if you've a loop with a max and have to cast it to long by hand :) Regards, heinz. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to

Re: Enhanced Primitive Support

On Tue, 22 Jun 2010 21:07:39 -0400 Garth Sheldon-Coulson wrote: > I would, however, like to throw some support behind Mike Meyer's suggestion > that the arbitrary precision numeric tower use names like add, sub, mul, > div, inc, dec, while the "default" ops keep the symbolic names. I think it > w

Re: Enhanced Primitive Support

I'm just one voice on the side that's been advocating for auto-promotion by default. For what it's worth, I completely see where the other side is coming from, and if Rich sees primitive math by default as important to Clojure's future, then so be it. It sounds like he's given it a lot of though an

Re: Enhanced Primitive Support

On Jun 22, 1:27 pm, David Nolen wrote: > On Tue, Jun 22, 2010 at 6:04 AM, Heinz N. Gies wrote: > > > > > > Yes. With Rich's primitive work we can get to *1 billion arithmetic > > operations* in < 2/3 of a second on commodity hardware. > > > Which is absolutely great since I always wanted to do th

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 1:43 PM, Mike Meyer wrote: > Would it be Clojure if it didn't run on the JVM? Personally, I could > live without the JVM. And the more I learn about the JVM, the more I > could live without it! I just want to add my two cents here. I don't think we would've ever used cloju

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 10:43 AM, Mike Meyer wrote: > Would it be Clojure if it didn't run on the JVM? Personally, I could > live without the JVM. And the more I learn about the JVM, the more I > could live without it! For my work, languages are only useful if they run on the JVM *and* can intero

Re: Enhanced Primitive Support

On Tue, 22 Jun 2010 18:56:30 +0100 Nicolas Oury wrote: > On Tue, Jun 22, 2010 at 6:43 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > > > > Everyone has to realize the math you are advocating for the default, > > > on non-tagged architectures like the JVM and CLR, *mus

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 6:43 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > > > Everyone has to realize the math you are advocating for the default, > > on non-tagged architectures like the JVM and CLR, *must* do an > > allocation on every +/-/* etc operation. And such ops ar

Re: Enhanced Primitive Support

On Tue, 22 Jun 2010 10:46:05 -0400 Rich Hickey wrote: > --- > The claim that this primitive stuff is just for numeric-intensive > applications is outrageous and false, and ignores the implementation > of Clojure itself to an embarrassing degree. I've worked my tail off > to reduce th

Re: Enhanced Primitive Support

We could always take the FORTRAN approach and make identifiers that start with I through N default to contagious behavior :-) Rich Hickey wrote: On Jun 22, 2010, at 12:44 AM, Mark Engelberg wrote: The new uber-loop is fantastic. So I guess the main point still to be finalized is whether the

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 7:46 AM, Rich Hickey wrote: > It is precisely for these reasons that the first iteration was based upon > BigInteger contagion. Yeah, I still don't like BigInteger contagion, and I believe I would vastly prefer the current equals branch, even with its idiosyncrasies, versu

Re: Enhanced Primitive Support

On Mon, 21 Jun 2010 21:44:04 -0700 Mark Engelberg wrote: > The new uber-loop is fantastic. > > So I guess the main point still to be finalized is whether the default > arithmetic ops will auto-promote or error when long addition > overflows. I think calling them "default" gives the wrong idea h

Re: Enhanced Primitive Support

We always talk about auto promoting ops, is there a way, and I guess the answer will be no, to have auto demoting ops? as in they get (+ (num 1) (num 1)) and return (long 2) if the calling side desires so? As in the function promises to return a Number or better. I know this might die on the fa

Re: Enhanced Primitive Support

> Everyone has to realize the math you are advocating for the default, on > non-tagged architectures like the JVM and CLR, *must* do an allocation on > every +/-/* etc operation. And such ops are littered throughout non-numeric > data structure code, for indexes, offsets, bounds etc. Allocating on

Re: Enhanced Primitive Support

One of our reviewers made a fantastic comment on the book and I thought I would share it for public consumption: "I know that you Lisp guys are incredibly proud of arbitrary-precision arithmetic, but I can't help but think that it is entirely missing the point: infinite precision is infinitely slo

Re: Enhanced Primitive Support

There are places where "regular" folks can be helped (e.g. perhaps supporting contagious bigs for the normal/fast ops so that the potentially foreign op-prime notation can be ignored if that's desirable), but handicapping capability or semantics in any direction based on vague appeals to "a

Re: Enhanced Primitive Support

On Tue, 22 Jun 2010 14:34:44 +0100 Nicolas Oury wrote: > On Tue, Jun 22, 2010 at 2:00 PM, Daniel Gagnon wrote: > > > If we base the decision on the average guy not writing high performance > > numeric apps, then we should also base it on the fact that he does not need > > more than a long in 99

Re: Enhanced Primitive Support

As the implementor Rich, it's your call as I said :)) If auto promotion brings in chaos then lets drop it entirely. If people want to eat elephants they can still choose to use directly big number implementations. Luc P Sent from my iPod On 2010-06-22, at 10:46 AM, Rich Hickey wrote: --

Re: Enhanced Primitive Support

On Jun 22, 2010, at 12:44 AM, Mark Engelberg wrote: The new uber-loop is fantastic. So I guess the main point still to be finalized is whether the default arithmetic ops will auto-promote or error when long addition overflows. Playing around with the latest equals branch: user=> (def n 92233

Re: Enhanced Primitive Support

All of this talk about the "average guy" is ungrounded. Average over what set and how are you getting the data? It may (or may not) be true that that the average *programmer* understands that big numbers (how big?) are something special, but IMHO that (if true) would probably be because the ave

Re: Enhanced Primitive Support

I never said we should not provides ways to tune code and get higher throughput or arbitrary sized numbers. There has to be a path to satisfies those needs. The stuff that was proposed on this thread (specialized ops, ...) should allow people to tune their code if they require to do so. I said tha

Re: Enhanced Primitive Support

On Jun 22, 3:00 pm, Daniel Gagnon wrote: > > Lets just make things easy for the > > average guy.., > > If we base the decision on the average guy not writing high performance > numeric apps, then we should also base it on the fact that he does not need > more than a long in 99% of cases either as

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 2:00 PM, Daniel Gagnon wrote: > If we base the decision on the average guy not writing high performance > numeric apps, then we should also base it on the fact that he does not need > more than a long in 99% of cases either as Rich points out. And longs are a > much simple

Re: Enhanced Primitive Support

> > Lets just make things easy for the > average guy.., > If we base the decision on the average guy not writing high performance numeric apps, then we should also base it on the fact that he does not need more than a long in 99% of cases either as Rich points out. And longs are a much simpler con

Re: Enhanced Primitive Support

If the maintenance cost of keeping both options in the Clojure run time is reasonnable it's fine with me. Rich is the best person to answer this. Otherwise, auto promotion should be the winner... And the default ... The vast majority of apps these days are not gravitating around high performanc

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 6:04 AM, Heinz N. Gies wrote: > > > Yes. With Rich's primitive work we can get to *1 billion arithmetic > operations* in < 2/3 of a second on commodity hardware. > > Which is absolutely great since I always wanted to do that :P , > meaning the example is kind of far fetche

Re: Enhanced Primitive Support

Boxing and unboxing can be very confusing. The "rules" need to be clearly stated somewhere. It might help if we introduced an explicit syntax, which might compile away, such as: (box i) (unbox i) (with-unboxed [i 7] ...) etc. I know Rich doesn't like "syntactic overhead" but source languages a

Re: Enhanced Primitive Support

On Tue, Jun 22, 2010 at 12:45 PM, Luc Préfontaine < lprefonta...@softaddicts.ca> wrote: > > Data changes overtime and > discovering it in production with > an overflow exception is less than > elegant. > > Degraded performance is much more > acceptable in production than a crash > over an unhandle

Re: Enhanced Primitive Support

++1 for auto promotion, average code is complex enough, lets not add more incertainty with overflow exceptions. Data changes overtime and discovering it in production with an overflow exception is less than elegant. Degraded performance is much more acceptable in production than a crash over an

Re: Enhanced Primitive Support

I'd like to ask something, is there an (open source) project that really got a speed boost from the move to primitive +,- & Co. and is testable / benchmarkable fairly easy? I sadly don't have any of those :( to do it all on my own. I'm not asking to mock, what I'd like to do (for myself) is loo

Re: Enhanced Primitive Support

On Jun 22, 2010, at 7:47 , David Nolen wrote: > If you're going to give example of what the current branch is like, at least > write the code how a primitive Clojurian would write it: > ... I feel his examples were on purpose not given as a 'primitive' clojurian or a 'boxing' one would write th

Re: Enhanced Primitive Support

Hi, On Jun 22, 7:47 am, David Nolen wrote: > Clearly a range' is in order. Eh? Why? The following is probably completely hypothetical syntax, because I'm not familiar with the changes in the numeric branches. But I think, it's easy to get my point. (defn range ([^long lower ^long upper] work

Re: Enhanced Primitive Support

If you're going to give example of what the current branch is like, at least write the code how a primitive Clojurian would write it: (let [n (long 9223372036854775810)] (* (/ n 3) 3)) ; Value out of range for long: 9223372036854775810 (let [n (long 9223372036854775810)] (* (/ n 2) 2)) ; Valu

Re: Enhanced Primitive Support

To me, numbers are an abstraction, just as sequences are an abstraction. Because Clojure treats sequences as abstractions, I can say (partition 3 (set '(1 2 3 4 5 6))) without Clojure complaining that sets are not the kind of thing that can be efficiently partitioned. Sets are seqable, so they can

Re: Enhanced Primitive Support

user=> (defn fac [n] (loop [n n r 1] (if (= n 1) r (recur (dec' n) (*' r n) NO_SOURCE_FILE:5 recur arg for primitive local: r is not matching primitive, had: Object, needed: long Auto-boxing loop arg: r #'user/fac user=> (fac 40) 8159152832478977343456112695961158942720N Might I sugg

Re: Enhanced Primitive Support

The new uber-loop is fantastic. So I guess the main point still to be finalized is whether the default arithmetic ops will auto-promote or error when long addition overflows. Playing around with the latest equals branch: user=> (def n 9223372036854775810) #'user/n user=> (* (/ n 3) 3) 922337203

Re: Enhanced Primitive Support

user=> (set! *warn-on-reflection* true) true user=> (defn fac [n] (loop [n n r 1] (if (= n 1) r (recur (dec' n) (*' r n) NO_SOURCE_FILE:5 recur arg for primitive local: r is not matching primitive, had: Object, needed: long Auto-boxing loop arg: r #'user/fac user=> (fac 40) 81591528324789773434

Re: Enhanced Primitive Support

If this is half the genius it sounds like then bravo! :D On Jun 21, 9:52 am, Rich Hickey wrote: > I've added the speculative analysis required to detect when recur   > arguments fail to match the type of primitive loop locals, and   > recompile the loop with those loop args boxed. When *warn-on-

Re: Enhanced Primitive Support

On 21 June 2010 16:52, Rich Hickey wrote: > I've added the speculative analysis required to detect when recur arguments > fail to match the type of primitive loop locals, and recompile the loop with > those loop args boxed. When *warn-on-reflection* is true it will issue a > report that this is ha

Re: Enhanced Primitive Support

On Mon, Jun 21, 2010 at 10:52 AM, Rich Hickey wrote: > I've added the speculative analysis required to detect when recur arguments > fail to match the type of primitive loop locals, and recompile the loop with > those loop args boxed. When *warn-on-reflection* is true it will issue a > report tha

Re: Enhanced Primitive Support

> My favorite option of those proposed is: > +, *, -, inc, dec auto-promote. > loop/recur is changed so that primitive bindings are boxed. > +',*',-',inc',dec' give error upon overflow. > A new construct, loop', is introduced that doesn't box primitives and > enforces recur with primitive upon pena

Re: Enhanced Primitive Support

On Jun 21, 2010, at 16:52 , Rich Hickey wrote: > I've added the speculative analysis required to detect when recur arguments > fail to match the type of primitive loop locals, and recompile the loop with > those loop args boxed. When *warn-on-reflection* is true it will issue a > report that t

Re: Enhanced Primitive Support

On Jun 20, 2010, at 12:57 PM, Luke VanderHart wrote: I've been reading this thread, and there's good arguments being made both ways - I've just been reading with interest. But after seeing the factorial function that won't compile without hints/casts, I feel I have to speak up. I wrote a book

Re: Enhanced Primitive Support

Hi, On Jun 21, 4:04 pm, Lee Spector wrote: > I guess this a somewhat unrelated newbie question: aren't there often cases > like this where one wants to temporarily rebind something, but across all > children threads? Is there some straightforward way to do this that I've > missed? See: http

Re: Enhanced Primitive Support

On Jun 21, 2010, at 8:23 AM, Heinz N. Gies wrote: > it would be more or less trivial to make a macro that switches between non > promoting + primitive loop and promoting and boxed loop: > > (defmacro fast [body] > `(let [+# +, *# *, -# -, loop# loop ...] > (binding [+ +', * *', - -', loop

Re: Enhanced Primitive Support

On Mon, Jun 21, 2010 at 12:40 PM, Tim Daly wrote: > This debate happened many years ago for common lisp. > > The flag *use-primitive-as-default* is a big help for optimization. Most >> of the performance hits of boxing do not show in profiling. >> (It slows down a lot of functions, by memory acc

  1   2   3   >