Re: Enhanced primitive support - redux

[Garth Sheldon-Coulson]

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.0 5.0M) ;no contagion
20.0
user=> (* 4.0M 5.0M)
20.00M
user=> (* 4.0 5.001M) ;not even when it's needed
20.0
user=> (* 4.0M 5.001M)
20.0040M

2) Will the same reasoning that produced BigInt give us a BigDec with a
better hashCode() than that of BigDecimal?

user=> (hash 4343434343)
48467046
user=> (hash (BigInteger. "4343434343")) ;not very nice
48467078
user=> (hash 4343434343N) ;nice as of equiv branch
48467046

but

user=> (hash 4343.4343)
1861754824
user=> (hash 4343.4343M) ;not very nice
1346464637

user=> (defn -hashCode [this]
  (let [dv (.doubleValue this)]
(if (== this dv)
  (.hashCode dv)
  (.hashCode this
#'user/-hashCode

user=> (hash 4343.4343)
1861754824
user=> (-hashCode 4343.4343M) ;nicer
1861754824

Garth


On Fri, Jun 25, 2010 at 3: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 to better support contagion. I think contagion is the best
> way to continue to support polymorphic numeric code, something I consider
> important.
>
> Contagion has several issues. First and foremost, it means that it it will
> be possible for 42 and 42N to be produced in the course of normal
> operations, so strict type-specific equality is not a good match. The equiv
> branch brings back equivalence-based =, with a slightly tighter notion of =,
> supporting only similar categories of numbers, so (= 42 42.0) => false, but
> (= 42 42N) => true. == is still available.
>
> The second problem is the use of numbers (and collections of numbers) as
> keys in hash maps and members of hash sets. We already had an issue here, as
> there wasn't completely uniform boxing, and there will always be the
> possibility of numbers from the outside. The equal branch tried to use
> consistent boxing and type-specific =, but it was still open to mismatch
> with numbers from outside. The equiv branch extends = to keys and set
> members when used from Clojure, i.e. Clojure get and contains will use =
> logic, while the Java get and containsKey will use .equals(). I.e. we will
> still satisfy the semantics of Java when used through the Java APIs, but
> nothing said the Clojure API must match those semantics. When combined with
> the new BigInt class (see below), this will allow you to look up (and find!)
> the integer 42 with either 42 or 42N.
>
> The equiv branch also has a new BigInt type. This is strictly necessary for
> this scheme, as Java's BigIntegers and Longs can produce different hashCodes
> for the same values. In addition to matching hashCode support, the BigInt
> class opens the door to better performance when used with numbers
> long-or-smaller. These performance enhancements have not yet been made.
>
> More details have been added to the top here:
>
>
> https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support
>
> Code is here:
>
> http://github.com/richhickey/clojure/commits/equiv
>
>
> Feedback welcome,
>
> Rich
>
> --
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Nicolas Oury]

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 to better support contagion. I think contagion is the best
> way to continue to support polymorphic numeric code, something I consider
> important.
>
> Contagion has several issues. First and foremost, it means that it it will
> be possible for 42 and 42N to be produced in the course of normal
> operations, so strict type-specific equality is not a good match. The equiv
> branch brings back equivalence-based =, with a slightly tighter notion of =,
> supporting only similar categories of numbers, so (= 42 42.0) => false, but
> (= 42 42N) => true. == is still available.
>
> The second problem is the use of numbers (and collections of numbers) as
> keys in hash maps and members of hash sets. We already had an issue here, as
> there wasn't completely uniform boxing, and there will always be the
> possibility of numbers from the outside. The equal branch tried to use
> consistent boxing and type-specific =, but it was still open to mismatch
> with numbers from outside. The equiv branch extends = to keys and set
> members when used from Clojure, i.e. Clojure get and contains will use =
> logic, while the Java get and containsKey will use .equals(). I.e. we will
> still satisfy the semantics of Java when used through the Java APIs, but
> nothing said the Clojure API must match those semantics. When combined with
> the new BigInt class (see below), this will allow you to look up (and find!)
> the integer 42 with either 42 or 42N.
>
> The equiv branch also has a new BigInt type. This is strictly necessary for
> this scheme, as Java's BigIntegers and Longs can produce different hashCodes
> for the same values. In addition to matching hashCode support, the BigInt
> class opens the door to better performance when used with numbers
> long-or-smaller. These performance enhancements have not yet been made.
>
> More details have been added to the top here:
>
>
> https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support
>
> Code is here:
>
> http://github.com/richhickey/clojure/commits/equiv
>
>
> Feedback welcome,
>
> Rich
>
> --
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Garth Sheldon-Coulson]

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.0M) ;BigDecimal works this way, apparently
false
user=> (= 434343.00M 434343.0M) ;odd, however
false
user=> (= 434343.00M 434343.0)
false
user=> (== 434343.00M 434343.0) ;even odder, in my opinion, given the above
true
user=> (= (.stripTrailingZeros 434343.00M) (.stripTrailingZeros 434343.0M))
;shouldn't = default to this?
true

Garth

On Fri, Jun 25, 2010 at 4:18 PM, Garth Sheldon-Coulson  wrote:

> 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.0 5.0M) ;no contagion
> 20.0
> user=> (* 4.0M 5.0M)
> 20.00M
> user=> (* 4.0 5.001M) ;not even when it's needed
> 20.0
> user=> (* 4.0M 5.001M)
> 20.0040M
>
> 2) Will the same reasoning that produced BigInt give us a BigDec with a
> better hashCode() than that of BigDecimal?
>
> user=> (hash 4343434343)
> 48467046
> user=> (hash (BigInteger. "4343434343")) ;not very nice
> 48467078
> user=> (hash 4343434343N) ;nice as of equiv branch
> 48467046
>
> but
>
> user=> (hash 4343.4343)
> 1861754824
> user=> (hash 4343.4343M) ;not very nice
> 1346464637
>
> user=> (defn -hashCode [this]
>   (let [dv (.doubleValue this)]
> (if (== this dv)
>   (.hashCode dv)
>   (.hashCode this
> #'user/-hashCode
>
> user=> (hash 4343.4343)
> 1861754824
> user=> (-hashCode 4343.4343M) ;nicer
> 1861754824
>
> Garth
>
>
>
> On Fri, Jun 25, 2010 at 3: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 to better support contagion. I think contagion is the best
>> way to continue to support polymorphic numeric code, something I consider
>> important.
>>
>> Contagion has several issues. First and foremost, it means that it it will
>> be possible for 42 and 42N to be produced in the course of normal
>> operations, so strict type-specific equality is not a good match. The equiv
>> branch brings back equivalence-based =, with a slightly tighter notion of =,
>> supporting only similar categories of numbers, so (= 42 42.0) => false, but
>> (= 42 42N) => true. == is still available.
>>
>> The second problem is the use of numbers (and collections of numbers) as
>> keys in hash maps and members of hash sets. We already had an issue here, as
>> there wasn't completely uniform boxing, and there will always be the
>> possibility of numbers from the outside. The equal branch tried to use
>> consistent boxing and type-specific =, but it was still open to mismatch
>> with numbers from outside. The equiv branch extends = to keys and set
>> members when used from Clojure, i.e. Clojure get and contains will use =
>> logic, while the Java get and containsKey will use .equals(). I.e. we will
>> still satisfy the semantics of Java when used through the Java APIs, but
>> nothing said the Clojure API must match those semantics. When combined with
>> the new BigInt class (see below), this will allow you to look up (and find!)
>> the integer 42 with either 42 or 42N.
>>
>> The equiv branch also has a new BigInt type. This is strictly necessary
>> for this scheme, as Java's BigIntegers and Longs can produce different
>> hashCodes for the same values. In addition to matching hashCode support, the
>> BigInt class opens the door to better performance when used with numbers
>> long-or-smaller. These performance enhancements have not yet been made.
>>
>> More details have been added to the top here:
>>
>>
>> https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support
>>
>> Code is here:
>>
>> http://github.com/richhickey/clojure/commits/equiv
>>
>>
>> Feedback welcome,
>>
>> Rich
>>
>> --
>> 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
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from thi

Re: Enhanced primitive support - redux

[Mark Engelberg]

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-Coulson  wrote:
> 1) If there is going to be BigInt contagion, why not BigDecimal contagion?

doubles contaminate bigdecimals, not the other way around.  That's how
it should be.

> 2) Will the same reasoning that produced BigInt give us a BigDec with a
> better hashCode() than that of BigDecimal?

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.

Now, one interesting question is whether the hashCode of 40.0M should
match the hashCode for 40N, because they are two exact numbers that
represent the same value.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Mark Engelberg]

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

>
> Now, one interesting question is whether the hashCode of 40.0M should
> match the hashCode for 40N, because they are two exact numbers that
> represent the same value.
>

The more I think about it, the more I think that big decimals are sort
of their own universe and we really wouldn't want the hashCodes of an
integral bigdecimal to match the integer hashcode.  I mean, if 40.0M
and 40.00M are considered different by Java, it seems fruitless to try
to unify these with their integer counterparts.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Garth Sheldon-Coulson]

> 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 enough. I would merely like to have floating point hash codes
that match floating point equality.

In other words, if we were to stick with the status quo where (= 0.3 0.3M)
=> true and (= 3/10 0.3) => true, then it would be nice to get BigDec hash
codes that match Double hash codes.

But you're right that Rich's message suggests we're moving to a world where
(= 0.3 0.3M) => false. I hadn't realized the (good) consequences for
floating point equality. In that world, you're right about hash codes. I
also see what you mean about contagion.

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
particular reason to have Clojure = work exactly like Java .equals(). I
think all it would take is a call to .stripTrailingZeros() on each =
comparison of a BigDecimal.

Garth

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Mark Engelberg]

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
> particular reason to have Clojure = work exactly like Java .equals(). I
> think all it would take is a call to .stripTrailingZeros() on each =
> comparison of a BigDecimal.

Yeah, if it's technically feasible, this definitely makes the most
mathematical sense.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Mike Meyer]

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 I know that fast algorithms in combinatorics and crypto
tend to make use of them.

 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Andrzej]

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 prone.

I don't think there is a nice and clean solution to the numeric
problem (Clojure is not the first language tackling it) but there are
two possibilities that could produce an acceptable trade off:
- using boxed math everywhere and optimizing performance by storing
preallocated Integers in a cache,
- using both boxed and primitive math but keeping the boundary between
them as explicit as possible (different operators, no automatic
conversion etc.). Existing operators should default to boxed math (for
runtime safety and compatibility).

Andrzej

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[B Smith-Mannschott]

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 and make
> programming in Clojure more difficult and error prone.
>
> I don't think there is a nice and clean solution to the numeric
> problem (Clojure is not the first language tackling it) but there are
> two possibilities that could produce an acceptable trade off:
> - using boxed math everywhere and optimizing performance by storing
> preallocated Integers in a cache,

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/3956cdee6712/src/share/classes/java/lang/Integer.java

And for Long as well (line 543):

http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/3956cdee6712/src/share/classes/java/lang/Long.java


> - using both boxed and primitive math but keeping the boundary between
> them as explicit as possible (different operators, no automatic
> conversion etc.). Existing operators should default to boxed math (for
> runtime safety and compatibility).
>
> Andrzej
>
> --
> 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
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Stefan Kamphausen]

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
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Nicolas Oury]

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 out that *Java already does this*.
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Mike Meyer]

[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 them as well. Yes, all the boxes will point 
to the cache, but you still have different boxes, and allocating those is the 
problem.

>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.
-- 
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 "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Andrzej]

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/3956cdee6712/src/share/classes/java/lang/Integer.java

Thank you. I wasn't aware of it.

It is not exactly what I meant, though. The above Java code
preallocates some low Integers, that are likely to be encountered in
actual programs. It obviously doesn't help at all when you happen to
use other numbers.

What I'd rather like to have is an array of N preallocated objects
waiting to be assigned values and used. This way an allocation cycle
could be triggered every N Integer constructor calls and all boxes
used in a single procedure would be gathered in one place.

Andrzej

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Nicolas Oury]

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-googlegroups.620...@mired.org> wrote:

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

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Nicolas Oury]

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
> 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-googlegroups.620...@mired.org> wrote:
>
>>
>> >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.
>
>
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[David Powell]

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 objects might do some harm to performance because
it prevents the JIT from being able to do inlining and escape
analysis.

http://www.infoq.com/presentations/click-fast-bytecodes-funny-languages


-- 
Dave

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Daniel]

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.0M 3.00M) => true would be nice. As Rich said, there's no
> > particular reason to have Clojure = work exactly like Java .equals(). I
> > think all it would take is a call to .stripTrailingZeros() on each =
> > comparison of a BigDecimal.
>
> Yeah, if it's technically feasible, this definitely makes the most
> mathematical sense.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Enhanced primitive support - redux

[Daniel]

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
> will find its way into Clojure?
>
> Andrzej

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en