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)
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
Hi,
Am 20.06.2010 um 01:10 schrieb Michał Marczyk:
(defn fact [n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Maybe I'm spoiled by OCaml, but why can't things be inferred?
n - We don't know.
1 - primitive
r - primitive
zero? - We don't know because of n.
dec -
On Jun 19, 9:02 pm, Aaron Cohen aa...@assonance.org wrote:
On Sat, Jun 19, 2010 at 11:22 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
Rob Lachlan robertlach...@gmail.com wrote:
Actually, Mike, your two functions work just fine. (Equal branch).
Mind you I checked that
It seems to me that there is mainly 2 categories in this thread:
- people that are worried about the difficulty to understand and to code
with the throw-on-overflow semantic. They worry about untested cases
showing in production code and the steeper learning curve of the language.
(I am not of
On Jun 19, 2010, at 15:58 , Rich Hickey wrote:
I am telling you though, if you continue with these show stopper, will
keep people from using Clojure sky-is-falling histrionics, I will stop
reading your messages.
My apologies here, simple reason is I love clojure and it is one of the best
David Nolen dnolen.li...@gmail.com writes:
Using loop/recur is already the beginning of code smell for anything
that is not performance sensitive.
[...]
In your arity-overloaded example, is there any runtime cost to figure
out which of the two overloads to choose each time `recur' evaluates?
On Sun, Jun 20, 2010 at 2:34 PM, Heinz N. Gies he...@licenser.net wrote:
To 3)
To the third thing and in my eyes this is the most challenging and
problematic issue. loop in current clojure is not statically typing (of
cause it is but it tosses objects in any field so you can pass whatever
On Jun 20, 2010, at 17:57 , Nicolas Oury wrote:
With what I think is 1.2-MASTER, a few weeks old (I start to be a bit lost
with many clojure.jar):
user= (loop [i (long 1)] (recur :a))
#CompilerException java.lang.RuntimeException:
java.lang.IllegalArgumentException: recur arg for
A flag like *warn-on-boxing* can help to identify these spots. These works
for all kind of things. Not only for contrived fact and fib exampls.
+1.
I think something like *warn-on-boxing* would be helpful. I'd use it.
--
You received this message because you are subscribed to the Google
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 on Clojure. It's a short book. That's because Clojure
is
On Sun, Jun 20, 2010 at 12:57 PM, Luke VanderHart luke.vanderh...@gmail.com
wrote:
anything that would mean I'd have to explain the intricacies of
primitives, boxing, hinting and casting in an Intro to Clojure
course. As much as humanely possible, that should be reserved for the
Performance
2010/6/20 David Nolen dnolen.li...@gmail.com:
This begs the question: Is loop/recur an advanced / performance coding
topic?
(defn fact [n]
(reduce *' (range 1 n)))
no
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send
Like Luke, I have been reading this thread with interest. For what it's
worth, I'm in basic agreement with him.
I might take it a step further. I don't think anyone should have to think
about boxing and primitives when writing standard idiomatic code -- code
that uses +, *, loop, and recur. The
As Rich has mentioned a couple times, though, let's be careful not to
conflate bounded integers with unsafe integers. In the proposed
system, an overflowing number would throw an exception. Presumably the
documentation would make it very clear what the behavior of numbers
is. That's not unsafe or
Every code is prone to produce runtime exceptions on some input (mainly
StackOverflow or OutOfMemory).
That's just one more reason to produce.
I agree that it is one harder to grasp for a non computer scientist, but it
is quite a simple one to manage for the more advanced user.
There is a
I find these compromises quite
acceptable. Tuning code has always
been a last step in most dev. projects
I worked on except a few and I worked
on many resource constraint
platforms.
All languages I encountered had a
default integer/float implementation
and getting away from it rarely
occured but
On Sun, Jun 20, 2010 at 11:30 AM, Nicolas Oury nicolas.o...@gmail.com wrote:
I don't believe overflow exception is hard for a beginner. (They know how an
integer is stored in a computer), but they should not need to write any
annotations.
I agree with Nicolas. An overflow says you did math
I agree with Nicolas. An overflow says you did math that doesn't work
with basic numbers and pretty much everybody coming to computers via
any path may encounter that from time to time. It's basic stuff.
There's a distinction between knowing that something can occur, and
expecting to have to
Actually, that's worst. Most language we grew up with, and most languages I
taught, had fact( someLargeNumber ) = 0 very fastly.
(Which is harder to explain, but explainable)
At least, throw on overflow is safe!
On Sun, Jun 20, 2010 at 8:04 PM, Sean Corfield seancorfi...@gmail.comwrote:
That's
On Sun, Jun 20, 2010 at 8:46 PM, Richard Newman holyg...@gmail.com wrote:
The question here is whether Clojure is a primitive language, where
numbers are machine numbers by default, or a modern language, where
getting primitive math might require input from the programmer, but by
default all
On Jun 20, 2010, at 22:03 , Nicolas Oury wrote:
primitive vs modern might not be the right terminology.
The main issue I see is not that primitives vs boxed I think when it is done
right both will be accepted by the community, the main issue I see is the
consequences primitives cause when it
This is interesting.
One set of folks considers non-machine-number performance to be surprising,
and wants to avoid it.
Another set of folks considers the possibility of arithmetic exceptions for
certain combinations of input to be surprising, and wants to avoid them.
Nobody likes
On Sun, 20 Jun 2010 13:27:01 -0400
David Nolen dnolen.li...@gmail.com wrote:
On Sun, Jun 20, 2010 at 12:57 PM, Luke VanderHart luke.vanderh...@gmail.com
wrote:
anything that would mean I'd have to explain the intricacies of
primitives, boxing, hinting and casting in an Intro to Clojure
The arguments seem to be winding down, so I thought this would be a
good time to summarize my thoughts.
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
I would expect a library to internaly
work with whatever is the best
implementation and provide an API
to allow callers using another implementation to use it.
I also expect a library to complain
about a potential overflow
and maybe some precision loss.
That's not different from what you can
On Sun, Jun 20, 2010 at 8:19 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
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
David Nolen dnolen.li...@gmail.com wrote:
On Sun, Jun 20, 2010 at 8:19 PM, Mark Engelberg
mark.engelb...@gmail.comwrote:
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
On Jun 21, 2010, at 2:19 , Mark Engelberg wrote:
The arguments seem to be winding down, so I thought this would be a
good time to summarize my thoughts.
My favorite option of those proposed is:
+, *, -, inc, dec auto-promote.
loop/recur is changed so that primitive bindings are boxed.
I'm confused. In the latest scheme, what is the eventual plan for
handling a recur to a loop element that was initialized with a
primitive? Are boxed numbers automatically coerced to the primitive?
Would a long be coerced to a double, or double to long? Under what
scenarios will you get a
On 18.06.2010, at 15:20, Rich Hickey wrote:
Which then begs the questions:
- how will someone 'protect' themselves from libraries written using fastmath?
Using fastmath or not would be part of the library specification. Or, in
general, of the documentation for each individual function. It
On 18.06.2010, at 15:31, Nicolas Oury wrote:
In this situation, I would rather have some kind of toggle
*use-bigints-by-default* (defaulted to false) used by the compiler.
Then, if someone needs big integers, he can switch the toggle and recompile
everything.
You wouldn't have to change
On Sat, Jun 19, 2010 at 3:12 AM, Rich Hickey richhic...@gmail.com wrote:
I have to say I'm in the 'pay for what you use' camp - you need a box, you
ask for one. If I don't (and neither do any of those loops), why should I
have to do extra work to avoid it?
Rich
+1.
It is often very easy
Nicolas Oury nicolas.o...@gmail.com wrote:
On the other hand, having boxed by default is a very significant slowdown
(10% on the strange program I tried, that had already a lot of annotations,
probably 20% or more on most programs), that can never be addressed : you
can't write annotations on
I tried it on my program. Very few arithmetic, most of it with annotation.
10%.
On an arithmetic benchmark, it would be in te *10/*20 range.
This 10% is orthogonal to what profiling shows. It just makes a lot of
little improvements spread everywhere.
That's why it couldn't be solved with
Nicolas Oury nicolas.o...@gmail.com wrote:
I tried it on my program. Very few arithmetic, most of it with annotation.
10%
Can we see the source?
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
You received this message because you are subscribed to the Google
Groups
yes, when it will be released :-b.
I can describe it though:
it applied a stochastically a set of rewriting rules on trees (represented
by records of records).
To speed up, the activity of the rules in each subtree is cached in a Java
weak hash table from one step to another.
There is a bit of
I know nothing about the JVM, but I do know that on x86 you can handle
fixnum - bignum promotion fairly cheaply. You compile two versions of
the code: one for bignums and one for fixnums. After an arithmetic
instruction in the fixnum code you check if it overflowed, and if it
did you switch to the
On Jun 19, 2010, at 4:12 , Rich Hickey wrote:
I have to say I'm in the 'pay for what you use' camp - you need a box, you
ask for one. If I don't (and neither do any of those loops), why should I
have to do extra work to avoid it?
- 42
I totally and wholeheartedly disagree, as long as there
On 19 June 2010 03:33, Rich Hickey richhic...@gmail.com wrote:
Turnabout is fair play, so I've produced a version that swaps the
defaults, still in the 'equal' branch:
The issue of which behaviour should be the default aside, I think that
I'd expect the *, + etc. ops to go with unannotated
Personally, I have no real interest in bigints, but I'm glad that they
are there, and that arithmetic code supports them polymorphically.
I'm not sure what I think regarding non-promoting numeric operators.
They are ok, but they seem to add complexity to the language, and they
don't look very
On Jun 19, 2010, at 14:18 , David Powell wrote:
(loop [^int n 1 r 1](if (zero? n) r (recur (dec n) (* r 0.2
Numeric literals would still produce primitives where possible, but
would get auto-boxed in loop initialisers.
I think this option wouldn't have any nasty surprises.
+41
I think if we had them, promoting ops
should be the primed ones, and they would mostly be used in library
Oops, I had meant the non-primed ops should support promotion. But
tbh, I have mixed feelings about promotion.
I haven't required bitint promotion myself, but having statically
typed
common need?
From the wiki page Enhanced Primitive Support: * Note: this means
that locals initialized with literals will have primitive type, e.g.
(let [x 42] …), and especially: (loop [x 42] …). If you intend to
recur with a non-primitive, init like this, (loop [x (num 42)] …)
I'd like
On Jun 19, 2010, at 6:39 AM, Jules wrote:
I know nothing about the JVM, but I do know that on x86 you can handle
fixnum - bignum promotion fairly cheaply. You compile two versions of
the code: one for bignums and one for fixnums. After an arithmetic
instruction in the fixnum code you check if
On Jun 19, 2010, at 6:41 AM, Heinz N. Gies wrote:
On Jun 19, 2010, at 4:12 , Rich Hickey wrote:
I have to say I'm in the 'pay for what you use' camp - you need a
box, you ask for one. If I don't (and neither do any of those
loops), why should I have to do extra work to avoid it?
- 42
I
Maybe it's only because I'm coming from Ruby, in which number
promotion is automatic and everything is slow, but if I have to choose
between correctness and performance as a *default*, I'll choose
correctness every time. I think there's a good reason that GCC, for
instance, makes you push the
On Sat, Jun 19, 2010 at 5:13 AM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
Were those real world programs, or arithmetic benchmarks? Most real world
programs I see spend so little of their time doing arithmetic that making
the math an order of magnitude slower wouldn't make
I definitely would like to see more people trying their code with primitive
by default and talk about unexpected bugs and performance improvements.
On Sat, Jun 19, 2010 at 3:43 PM, David Nolen dnolen.li...@gmail.com wrote:
Most real world programs. You mean like Clojure itself?
--
You
The hard error has been restored:
http://github.com/richhickey/clojure/commit/25165a9ccd1001fa7c4725a8219c4108803ae834
Rich
On Jun 19, 2010, at 2:03 AM, Mark Engelberg wrote:
I'm confused. In the latest scheme, what is the eventual plan for
handling a recur to a loop element that was
Checked out the new prim branch to repeat some tests.
user= (defn ^:static fib ^long [^long n]
(if (= n 1)
1
(+ (fib (dec n)) (fib (- n 2)
#'user/fib
user= (time (fib 38))
Elapsed time: 4383.127343 msecs
63245986
That's certainly not what I expected
user= (defn fact [n]
On Jun 19, 2010, at 4:25 AM, Daniel wrote:
Checked out the new prim branch to repeat some tests.
user= (defn ^:static fib ^long [^long n]
(if (= n 1)
1
(+ (fib (dec n)) (fib (- n 2)
#'user/fib
user= (time (fib 38))
Elapsed time: 4383.127343 msecs
63245986
That's certainly not
(proclaim (speed 3) (safety 0))
is verbose? Telling the compiler in one place that you care
about boxing speed, such as (declare (x unboxed)) seems to
me to be a very direct way to tell the compiler to choose
+' vs + everywhere that 'x' occurs.
This means that it just works code does not need
On Jun 19, 2010, at 1:05 PM, Tim Daly wrote:
(proclaim (speed 3) (safety 0))
is verbose? Telling the compiler in one place that you care
about boxing speed, such as (declare (x unboxed)) seems to
me to be a very direct way to tell the compiler to choose
+' vs + everywhere that 'x' occurs.
On Jun 19, 11:45 am, Rich Hickey richhic...@gmail.com wrote:
On Jun 19, 2010, at 4:25 AM, Daniel wrote:
Checked out the new prim branch to repeat some tests.
user= (defn ^:static fib ^long [^long n]
(if (= n 1)
1
(+ (fib (dec n)) (fib (- n 2)
#'user/fib
user= (time
On Sat, Jun 19, 2010 at 6:32 AM, Rich Hickey richhic...@gmail.com wrote:
Really? It seems tedious to me. Don't you get tired of saying int i = 42 in
Java, when you know full well the compiler knows 42 is an int? I do, and
Clojure is competing with languages that infer the right types without
Not ordinary code. 10^19 is big.
On Sat, Jun 19, 2010 at 8:08 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
Agreed, but with a default of boxing, it is possible to write all code
without ever using an annotation -- it will just be a bit slower than
it could be. With a default of
On Jun 19, 3:53 pm, Rich Hickey richhic...@gmail.com wrote:
On Jun 19, 2010, at 6:39 AM, Jules wrote:
I know nothing about the JVM, but I do know that on x86 you can handle
fixnum - bignum promotion fairly cheaply. You compile two versions of
the code: one for bignums and one for
On Sat, Jun 19, 2010 at 12:20 PM, Nicolas Oury nicolas.o...@gmail.com wrote:
Not ordinary code. 10^19 is big.
Nicolas, I think you misunderstand my point. I'm talking about
loop/recur behavior. If you initialize a loop with the literal 1, and
then recur with a number 2 that's pulled from a
On Jun 19, 2:24 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
On Sat, Jun 19, 2010 at 12:20 PM, Nicolas Oury nicolas.o...@gmail.com wrote:
Not ordinary code. 10^19 is big.
Nicolas, I think you misunderstand my point. I'm talking about
loop/recur behavior. If you initialize a loop with
On Sat, 19 Jun 2010 11:00:39 +0100
Nicolas Oury nicolas.o...@gmail.com wrote:
There is a bit of arithmetic involved everywhere, and around 2-3 double
operations per function in the part choosing the instance of rule to apply.
That still sounds arithmetic-heavy to me. In looking through my
On Sat, 19 Jun 2010 10:43:36 -0400
David Nolen dnolen.li...@gmail.com wrote:
On Sat, Jun 19, 2010 at 5:13 AM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
Were those real world programs, or arithmetic benchmarks? Most real world
programs I see spend so little of their
While I generally favor correct over fast (worrying about fast before
you're correct is a good sign that you're engaged in premature
optimization), I'm still trying to figure out the tradeoffs
here. Especially since most LISPs other dynamic languages don't seem
to run into this issue - or at
On Sat, 19 Jun 2010 20:20:48 +0100
Nicolas Oury nicolas.o...@gmail.com wrote:
Not ordinary code. 10^19 is big.
No, Aleph-2 is big. Any non-infinite number you can name in your
lifetime is small ;-).
Pretty much any time I really need integer speed, I also deal with
numbers that can get much
On Sat, Jun 19, 2010 at 10:15 PM, Mike Meyer m...@mired.org wrote:
Pretty much any time I really need integer speed, I also deal with
numbers that can get much larger than 10^19th, because I tend to be
doing combinatorics or cryptography.
But you would agree that for this kind of domain,
On 19 June 2010 16:43, David Nolen dnolen.li...@gmail.com wrote:
Most real world programs. You mean like Clojure itself?
Please look over the implementation of gvec before making statements like
this:
Surely Clojure's internals are a *very* special case though... I
wouldn't find it
On 19 June 2010 23:51, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
In any case, I don't think 10% is enough gain to justify narrowing the
range for which naive programs are correct. An order of magnitude
would be. A factor of two is a maybe.
QFT!
Have a look at this:
(defn
On Sat, Jun 19, 2010 at 4:10 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
(defn fact [n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Thanks for posting this surprisingly simple example of something that
looks like it should work, but wouldn't under the
On Sat, Jun 19, 2010 at 4:10 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
(defn fact [n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Huh? That doesn't look like it's going to work at all.
1) 1 is primitive, we know that, accept it
2) we don't know the type
Where can I get jar files of the various branches so I can test for
myself without having to deploy whatever infrastructure is needed to
build clojure these days? Or am I likely to be able to build them with
tools found in the BSD ports tree?
It still seems to build with 'ant' like it always
On Sat, Jun 19, 2010 at 5:13 PM, David Nolen dnolen.li...@gmail.com wrote:
Huh? That doesn't look like it's going to work at all.
1) 1 is primitive, we know that, accept it
2) we don't know the type of n, what will (* r n) be?
3) BOOM!
Yes David, if you have a deep understanding of how
On Sat, 19 Jun 2010 20:13:07 -0400
David Nolen dnolen.li...@gmail.com wrote:
On Sat, Jun 19, 2010 at 4:10 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
(defn fact [n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Huh? That doesn't look like it's
The main example for recur on the special forms page (http://
clojure.org/special_forms#Special%20Forms--(recur%20exprs*)) is:
(def factorial
(fn [n]
(loop [cnt n acc 1]
(if (zero? cnt)
acc
(recur (dec cnt) (* acc cnt))
I may not be be clojure jedi, but
Mark and Mike you fail to address my deeper question. I've been using
many different Clojure libraries all day long with the latest equals
branch. Guess
what?
No loop/recur bugs.
When you guys start postIng your broken code that has this problem
then people can start believing it is an issue for
On Sat, 19 Jun 2010 20:40:13 -0400
David Nolen dnolen.li...@gmail.com wrote:
Mark and Mike you fail to address my deeper question.
Maybe because you've failed to ask in your hurry to claim code is
non-idiomatic or calling our example rhetoric.
I've been using
many different Clojure libraries
On 20 June 2010 02:13, David Nolen dnolen.li...@gmail.com wrote:
On Sat, Jun 19, 2010 at 4:10 PM, Michał Marczyk
michal.marc...@gmail.com wrote:
(defn fact [n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Huh? That doesn't look like it's going to work at all.
Actually, Mike, your two functions work just fine. (Equal branch).
Mind you I checked that out over two hours ago, so this information
might be out of date.
Rob
On Jun 19, 6:59 pm, Mike Meyer mwm-keyword-googlegroups.
620...@mired.org wrote:
On Sat, 19 Jun 2010 20:40:13 -0400
David Nolen
On 20 June 2010 03:59, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
So here's some new
examples, pulled in sequence from some of my combinatorics code:
This works fine as far as arithmetic ops are concerned, though I
suppose it might suffer from issues of = vs. == now (which is a
I don't think my computer has enough memory to test that. But, you're
right, I might have spoken hastily.
Rob
On Jun 19, 7:26 pm, Aaron Cohen aa...@assonance.org wrote:
I actually believe it will throw an overflow exception if col contains
more than Integer.MAX_VALUE elements. Hard to confirm
Rob Lachlan robertlach...@gmail.com wrote:
Actually, Mike, your two functions work just fine. (Equal branch).
Mind you I checked that out over two hours ago, so this information
might be out of date.
Rob
On Jun 19, 6:59 pm, Mike Meyer mwm-keyword-googlegroups.
Ok, why does this work but the
Because the compiler is upset that it doesn't know what n is. r is a
long, but n is ???. The following works:
(defn ^:static fact [^long n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Or see Dnolen's version above. But yeah, I wish that it still worked,
Rob Lachlan robertlach...@gmail.com wrote:
Because the compiler is upset that it doesn't know what n is. r is a
long, but n is ???. The following works:
(defn ^:static fact [^long n]
(loop [n n r 1]
(if (zero? n)
r
(recur (dec n) (* r n)
Or see Dnolen's version above.
On Sat, Jun 19, 2010 at 11:22 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
Rob Lachlan robertlach...@gmail.com wrote:
Actually, Mike, your two functions work just fine. (Equal branch).
Mind you I checked that out over two hours ago, so this information
might be out of date.
On Fri, Jun 18, 2010 at 1:44 AM, Antony Blakey antony.bla...@gmail.comwrote:
On Fri, Jun 18, 2010 at 12:24 AM, Antony Blakey antony.bla...@gmail.com
wrote:
This proposal is IMO a very bad idea.
Why do you need know? You're assumption is built on someone writing a
writing a bad library (one
On Thu, Jun 17, 2010 at 11:01 PM, David Nolen dnolen.li...@gmail.com wrote:
What's the problem?
David
It's a composability issue.
Elaborating on Anthony's explanation, let's say you call (fact (foo n)).
Do you know what values of n, when passed to foo, produce a value
large enough that fact
On Fri, Jun 18, 2010 at 2:10 AM, Mark Engelberg mark.engelb...@gmail.comwrote:
Elaborating on Anthony's explanation, let's say you call (fact (foo n)).
This imposes too high a burden on any programmer who cares about safety.
Don't buy it. That's the whole point of BigInt contagion. If
This imposes too high a burden on any programmer who cares about
safety.
Don't buy it. That's the whole point of BigInt contagion. If fact
and foo are correctly written this will work.
It only takes one library to screw up, and the whole stack falls down.
Screwing up can occur because of
On 18/06/2010, at 4:28 PM, Richard Newman wrote:
This imposes too high a burden on any programmer who cares about safety.
Don't buy it. That's the whole point of BigInt contagion. If fact and foo
are correctly written this will work.
It only takes one library to screw up, and the whole
Richard Newman holyg...@gmail.com writes:
Having digested Rich's notes, pretty much the only thing that I
disagree with is the lack of automatic bignum promotion/demotion. It
seems like too much of a bad tradeoff,
This nicely summarizes my thoughts. The other parts of Rich's notes
seem very
Dear all,
just finished to read the proposals.
- prim is great and would allow to keep performance in more idiomatic code
- I am pro-num.
It allows to get read of plenty of annotations or java methods.
Annotations are difficult for beginners, makes code hard to read, maintain
and modify, even
On a totally different point:
is there a way of having he equivalent of #^final/#^static for defs?
Sometimes, you know a def won't be dynamically bound/redefined.
Would there be a benefit for the JITed code (less memory barriers or more
asm reordering) to give a way to pass this information
to
On Fri, Jun 18, 2010 at 8:58 AM, Richard Newman holyg...@gmail.com wrote:
It only takes one library to screw up, and the whole stack falls down.
Screwing up can occur because of omission (fact being written with a 1,
not 1N, and not being tested with large inputs), or by design.
It can already
On 18 June 2010 05:57, Mark Engelberg mark.engelb...@gmail.com wrote:
I assume that most Clojure users really like its dynamic nature. If
this is true, then for most of us, the common case is to NOT annotate
our code with types. Certainly I like the idea of making it as easy
as possible to
Just tried out num branch and I really like how easy it is to be
fast! However...
Consider:
(defn fact [n] (if (zero? n) 1 (* n (fact (dec n)
(defn twice-fact [n] (fact (fact n)))
(defn bad-twice-fact [n] (fact (- n fact range last inc)))
user= (fact (fact 5))
On Fri, Jun 18, 2010 at 11:47 AM, Carson c.sci.b...@gmail.com wrote:
Don't buy it. That's the whole point of BigInt contagion. If fact and foo
are correctly written this will work.
BigInt contagion doesn't help if in some convoluted manner a BigInt's
value is used to construct a primitive
On Jun 18, 2:44 am, Christophe Grand christo...@cgrand.net wrote:
With contagious bigints (let's nick name them safeints and assume
they are not BigInteger but something à la kawa) a single N on
literals or having all your inputs going through a safeint conversion
would trigger safe
On Jun 18, 4:22 am, Nicolas Oury nicolas.o...@gmail.com wrote:
On Fri, Jun 18, 2010 at 11:47 AM, Carson c.sci.b...@gmail.com wrote:
Don't buy it. That's the whole point of BigInt contagion. If fact and foo
are correctly written this will work.
BigInt contagion doesn't help if in some
I'm no expert in this field.
What I would like to avoid, is having to become expert in the field to
expect the prevention of more :
* nightmare debug sessions because of my own code or third party
libraries code
* crash in production code
which might derive from the choices.
I tend to
2010/6/18 Carson c.sci.b...@gmail.com:
And *still*, I'm in favour of fast by default, with an *easy* way to
make things safe as an option. The key is to make the safe option
*easy*.
The solution is easy: write java code by default, and clojure code
when you want to be safe :-p
--
You
I too think that correct by default is a much better idea than fast by
default.
One way I think about this is that the meaning of +, for example, is the sum of
its numeric arguments. The performance characteristics are not part of this
core meaning, although of course everyone will be
101 - 200 of 264 matches
Mail list logo
