7 ms·

"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a t

"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a terrible shame.

peregrine 16y ago
This is only true if you use the annotations, at least that is my understanding.
- herdrick 16y ago
  Really? That'd be fantastic. Did I misunderstand this?
  - peregrine 16y ago
    Yes the annotations are purely optional.
    - herdrick 16y ago
      Right, but the initial quote seemed to say that promoting to BigNums would no longer be automatic. But I may have misunderstood.
      - richhickey 16y ago
        Correct, promotion will no longer be automatic because the semantics of primitive and auto-promoting arithmetic can't be unified (on the JVM with no fixnums, the return types are disjoint). However, missing from the blog post and discussion here is the fact that, should there be overflow, an exception will be thrown. We are not adopting the silent error strategy of C/Java etc.
prospero 16y ago
I was at the talk in question. Some more context: Bignums "contaminate" surrounding operations. Adding a long and a bignum yields a bignum. Seeding an equation with a single bignum (42N is a bignum representation of 42) will prevent overflow. No one has come forward with a single real-world scenario where they're using bignums in Clojure. Choosing a default that is only theoretically useful rather than a 10x performance improvement seems a bit silly. In any situation where the compiler cannot be sure you're using primitives everywhere, it will emit non-overflowing bytecode. By my measure, there's nothing premature about this optimization. In Rich Hickey's words, Clojure is a replacement for Java, not Ruby. Giving up Java-like performance makes the language quantitatively less useful.
- herdrick 16y ago
  That Clojure's target is to replace slow old Ruby (actually that never happens, rather a successful language gains dominance in some niche and spreads from there) is only more evidence that it isn't worth breaking the abstraction called "numbers" to get merely an order of magnitude better performance. Seriously, I almost can't believe this is still an open issue in 2010. And Rich Hickey, who has designed such a great language otherwise, is on the wrong side of it? I'm boggled. EDIT: If peregrine's comment is right, then we're arguing about something that isn't happening. I hope so.
  - prospero 16y ago
    Clojure's target is to replace slow old Ruby That is very clearly the opposite of what I wrote.
    - herdrick 16y ago
      Oh, sorry! I transposed the words.
swannodette 16y ago
Premature? No people have been complaining (or just getting very confused) about Clojure's numeric performance without oodles of invasive type-hinting for two years now. More importantly with these changes it's now possible to reimplement Clojure's core datastructures in Clojure without sacrificing performance. The majority of people who care about BigInts are solving Project Euler problems, not writing Clojure libraries or deploying apps into production.
- herdrick 16y ago
  2^63 numbers ought to be enough for anyone, huh?
  - silentbicycle 16y ago
    The situations that deal with numbers that large are usually a bit nuanced. (i.e., "it's 1 in 2^63 of the time that I need bignums for day-to-day programming"). I agree that losing accuracy needlessly sucks (and I've been burned by floating-point), but 64 bit ints are usually good enough. I'm thirsty for counterexamples.

"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a terrible shame.

peregrine 16y ago

This is only true if you use the annotations, at least that is my understanding.

herdrick 16y ago
Really? That'd be fantastic. Did I misunderstand this?
- peregrine 16y ago
  Yes the annotations are purely optional.
  - herdrick 16y ago
    Right, but the initial quote seemed to say that promoting to BigNums would no longer be automatic. But I may have misunderstood.
    - richhickey 16y ago
      Correct, promotion will no longer be automatic because the semantics of primitive and auto-promoting arithmetic can't be unified (on the JVM with no fixnums, the return types are disjoint). However, missing from the blog post and discussion here is the fact that, should there be overflow, an exception will be thrown. We are not adopting the silent error strategy of C/Java etc.

prospero 16y ago

I was at the talk in question. Some more context: Bignums "contaminate" surrounding operations. Adding a long and a bignum yields a bignum. Seeding an equation with a single bignum (42N is a bignum representation of 42) will prevent overflow. No one has come forward with a single real-world scenario where they're using bignums in Clojure. Choosing a default that is only theoretically useful rather than a 10x performance improvement seems a bit silly. In any situation where the compiler cannot be sure you're using primitives everywhere, it will emit non-overflowing bytecode. By my measure, there's nothing premature about this optimization. In Rich Hickey's words, Clojure is a replacement for Java, not Ruby. Giving up Java-like performance makes the language quantitatively less useful.

herdrick 16y ago
That Clojure's target is to replace slow old Ruby (actually that never happens, rather a successful language gains dominance in some niche and spreads from there) is only more evidence that it isn't worth breaking the abstraction called "numbers" to get merely an order of magnitude better performance. Seriously, I almost can't believe this is still an open issue in 2010. And Rich Hickey, who has designed such a great language otherwise, is on the wrong side of it? I'm boggled. EDIT: If peregrine's comment is right, then we're arguing about something that isn't happening. I hope so.
- prospero 16y ago
  Clojure's target is to replace slow old Ruby That is very clearly the opposite of what I wrote.
  - herdrick 16y ago
    Oh, sorry! I transposed the words.

swannodette 16y ago

Premature? No people have been complaining (or just getting very confused) about Clojure's numeric performance without oodles of invasive type-hinting for two years now. More importantly with these changes it's now possible to reimplement Clojure's core datastructures in Clojure without sacrificing performance. The majority of people who care about BigInts are solving Project Euler problems, not writing Clojure libraries or deploying apps into production.

herdrick 16y ago
2^63 numbers ought to be enough for anyone, huh?
- silentbicycle 16y ago
  The situations that deal with numbers that large are usually a bit nuanced. (i.e., "it's 1 in 2^63 of the time that I need bignums for day-to-day programming"). I agree that losing accuracy needlessly sucks (and I've been burned by floating-point), but 64 bit ints are usually good enough. I'm thirsty for counterexamples.