Re: set return value is unordered, is that a bug or by design?

Sets are unordered data structures, so it's by design. - James On 31 May 2016 at 13:54, wrote: > I would expect the returned set to be > > #{1 2 3} but i get the following. Copied from repl > > > user=> (set [1 1 2 2 3 3]) > > #{1 3 2} > > > user=> (set '(1 1 2 3 2 4 5 5)) > > #{1 4 3 2 5} > >

Re: set return value is unordered, is that a bug or by design?

sets & maps make no guarantee about the order of their entries. In fact, they deliberately use hash functions to keep simple keys like 1,2,3 "spread out" in their hash-codes. This causes the "random" ordering when printed. If you want a set to print in order (often worth the trouble, I think), use

Re: set return value is unordered, is that a bug or by design?

I believe you may have meant sorted-set On Tue, May 31, 2016 at 6:10 AM, vandr0iy wrote: > You could use sorted-map, if you wish to have them ordered: > > https://clojuredocs.org/clojure.core/sorted-map > > there is also sorted-map-by, which lets

Re: set return value is unordered, is that a bug or by design?

You could use sorted-map, if you wish to have them ordered: https://clojuredocs.org/clojure.core/sorted-map there is also sorted-map-by, which lets you define the comparator based on which the values have to be sorted On 05/31/2016 02:54 PM, james.naad...@gmail.com wrote: > > I would expect the

Re: Set equality bug?

Obviously... user=> (= (byte 1) (short 1) (long 1) 1) true user=> http://clojure.org/rationale Language as platform vs. language + platform - Old way - each language defines its own runtime GC, bytecode, type system, libraries etc - New way (JVM, .Net) - Common runtime independent o

Re: Set equality bug?

And this is not a typeless language, it is a strongly dynamically typed language. -- 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

Re: Set equality bug?

On Friday, January 23, 2015 at 1:27:18 PM UTC-5, Luc wrote: > > Danger vs flexibility. > > < or > are safe. Should they throw an exception then ? > > Compiler in some older typed languages would warn you about testing > equality between two float numbers irrelevant of their types but would be >

Re: Set equality bug?

Danger vs flexibility. < or > are safe. Should they throw an exception then ? Compiler in some older typed languages would warn you about testing equality between two float numbers irrelevant of their types but would be silent about other operators. Testing equality with floats is seldom used

Re: Set equality bug?

If the underlying argument is that it is horribly dangerous to mix floats and doubles in your code, then maybe (<= (float 1.5) (double 1.5)) should have the semantics of (.compareTo (float 1.5) (double 1.5)), i.e., throw an error. I'm not certain that's a good idea for Clojure, but it does seem li

Re: Set equality bug?

On Jan 23, 2015, at 11:51 AM, Andy Fingerhut wrote: > Hash consistency is certainly nice, but if Clojure were changed such that (= > float-val double-val) were always false, and no other changes were made, it > would lead to this situation: > > user=> (<= (float 1.5) (double 1.5)) > true > user

Re: Set equality bug?

Not sure which properties you prefer to be true in programming languages you use. Hash consistency is certainly nice, but if Clojure were changed such that (= float-val double-val) were always false, and no other changes were made, it would lead to this situation: user=> (<= (float 1.5) (double 1

Re: Set equality bug?

On Jan 23, 2015, at 8:23 AM, Andy Fingerhut wrote: > You can try creating a JIRA ticket suggesting that Clojure's = should return > false when comparing floats and doubles to each other. CLJ-1649, for anyone interested. -- You received this message because you are subscribed to the Google Grou

Re: Set equality bug?

Michael: You can try creating a JIRA ticket suggesting that Clojure's = should return false when comparing floats and doubles to each other. I have no idea if it would go anywhere, but alternative (2) trying to get hashes to be equal between = float/doubles has been suggested and declined. Witho

Re: Set equality bug?

I'm sure we are all aware of the various issues with floating point math (particularly equality comparisons); however none of that is relevant to this discussion. The only issue here is an inconsistency between hashing and equality testing in Clojure. My claim is that the property "any two obje

Re: Set equality bug?

public class TestClass { public static void equality () { double dd = 3.5; float ff = 3.5f; System.out.println(String.format("dd vs ff == %b", dd==ff)); double dd2 = 3.2; float ff2 =

Re: Set equality bug?

Well if it breaks elsewhere than in your code because you mix representations and leak them to some library in Java that you do not control I see my comments as absolutely relevant. It's not technical, it's failsafe. But that might not be of any interest to your problem scope. However it does i

Re: Set equality bug?

If there's a technical reason why Clojure can't return false for all = comparisons between floats and doubles, I'd like to hear it. Otherwise, I don't see how your response is relevant. > On Jan 23, 2015, at 3:10 AM, Luc Prefontaine > wrote: > > Agree, it's broken... in java... > Has it has b

Re: Set equality bug?

On Fri, Jan 23, 2015 at 1:10 AM, Luc Prefontaine < lprefonta...@softaddicts.ca> wrote: > Agree, it's broken... in java... > I think it's more frustrating in Clojure than in Java, though, because in Java you have those big, ugly type annotations on every single variable, input and output, so there

Re: Set equality bug?

Agree, it's broken... in java... Has it has been broken in the past in several architectures... I understand your frustration but this is not something new. It's been a problem for at least 30 years. It is kind of a basic programming issue: - Never compare floats with different representations.

Re: Set equality bug?

On Jan 23, 2015, at 1:33 AM, Immo Heikkinen wrote: > > I actually ran into this while comparing nested data structures from two > different sources and spent a good part of my day figuring out what's > happening. While it is a good advice to avoid mixing floats and doubles, it > is inevitable

Re: Set equality bug?

I actually ran into this while comparing nested data structures from two different sources and spent a good part of my day figuring out what's happening. While it is a good advice to avoid mixing floats and doubles, it is inevitable that Clojure users will get bitten by this once in a while and hou

Re: Set equality bug?

Part of what you wish were true is already true: Using = to compare a double to a BigDecimal always returns false in Clojure, as does comparing a float to a BigDecimal. It is only (= float-value double-value) that can return true in Clojure, even though hash does not guarantee the usual hash consi

Re: Set equality bug?

On Thursday, January 22, 2015 at 2:12:52 PM UTC-5, Jozef Wagner wrote: > > As seen in CLJ-1372, this issue will probably cause some strong opinions. > I think this is an example of a leaky abstraction and the current approach > is to leave it as is, as there are some serious trade-offs and are th

Re: Set equality bug?

As seen in CLJ-1372, this issue will probably cause some strong opinions. I think this is an example of a leaky abstraction and the current approach is to leave it as is, as there are some serious trade-offs and are there is no rationale or real practical reason to fix this. Current implementation

Re: Set equality bug?

And how to you want to proceed knowing that floats and double can escape elsewhere in your app and create the same chaotic effect like for example, in some interop call to some obscure library ? The best ... consistency here seems to reflect what's occurring underneath instead of giving the false

Re: Set equality bug?

On the side of positive recommendations to avoid problems like this, here is some advice: + Don't mix floats and doubles in the same Clojure program. Given that Clojure uses double arithmetic by default, it is much easier to use doubles everywhere than it is to try to use floats everywhere. + Do

Re: Set equality bug?

My one cent: But I think (and it's just my humble opinion) is in the scope of Clojure keep its consistency, am I right? I mean, if doubles and floats are different, and they are, I think we should always get equality test as false. Or always as true, if they're nominally the same value. Regards

Re: Set equality bug?

"It is out of scope for Clojure to fix this for Java types Float/Double" -- comments in CLJ-1036: http://dev.clojure.org/jira/browse/CLJ-1036 Andy On Thu, Jan 22, 2015 at 5:53 AM, Nicola Mometto wrote: > > Not sure if this is intended behaviour: > user=> (= (float 1.6) (double 1.6)) > false >

Re: Set equality bug?

Not sure if this is intended behaviour: user=> (= (float 1.6) (double 1.6)) false user=> (= (float 1.5) (double 1.5)) true I.e. = (and ==) will return true when comparing floats with doubles IFF the float's .doubleValue roundtrips to the same double it's comparing to. user=> (.doubleValue (float

Re: Set equality bug?

More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036 On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto wrote: > > Looking at the PHM impl, this looks like it's caused by (float 0.5) and > (double 0.5) hashing differently. > > user=> (= (float 0.5) (double 0.5)) > true > user=> (map ha

Re: Set equality bug?

Looking at the PHM impl, this looks like it's caused by (float 0.5) and (double 0.5) hashing differently. user=> (= (float 0.5) (double 0.5)) true user=> (map hash [(float 0.5) (double 0.5)]) (1056964608 1071644672) Nicola Mometto writes: > Looks like it's a bug in PersistentHashMap: > user=> (

Re: Set equality bug?

Looks like it's a bug in PersistentHashMap: user=> (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)}) false user=> (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)}) true Immo Heikkinen writes: > (= (float 0.5) (double 0.5)) > => true > (= #{(float 0.5)} #{(double 0.5)}) > =>

Re: set vs hash-set

One takes a coll and the other a list of arguments user=> (set [1 1]) #{1} user=> (hash-set 1 1) #{1} On Thu, Feb 6, 2014 at 4:49 PM, Alan Thompson wrote: > OK, this one has me stumped. What is the difference between > clojure.core/set and clojure.core/hash-set ??? The source code is alm

Re: set!

OK, that answers my question. Thanks for the insights everyone! -- -- 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

Re: set!

The repl's thread binding for those vars is set here: https://github.com/clojure/clojure/blob/master/src/clj/clojure/main.clj#L267 using this macro: https://github.com/clojure/clojure/blob/master/src/clj/clojure/main.clj#L85 Users of your library would need to do something similar, possibly

Re: set!

2013/3/13 Mark Engelberg > Still, it would be nice to understand whether it's possible to achieve the > same effect as Clojure core's settable vars. > It is, because clojure doesn't do anything magic here (apart from the effects its set!-able vars have ;-). The catch is: The set of commonly set!

Re: set!

On Wednesday, March 13, 2013 2:46:06 PM UTC-7, puzzler wrote: > On Wed, Mar 13, 2013 at 2:06 PM, Marko Topolnik > > > wrote: > > >> As far as I understand it, *set!* modifies the *thread-local* binding, >> just like the *binding* macro, but doesn't delimit a definite scope of >> validity for t

Re: set!

Yes, I'd say there is no low-level magic about those vars except that they are well-supported in all the relevant contexts. However, the fact that they need such special support does make it hard to use one's own vars in the same way. On Wednesday, March 13, 2013 10:52:15 PM UTC+1, Cedric Greev

Re: set!

Again, those are already given bindings. Think of it as if somewhere there's (binding [*unchecked-math* false] (loop [] (do-repl-stuff!) (recur))). As for "intended for uses other than working at the REPL", they still tend to be compile/macroexpansion-time uses, and presumably dynamic bindings exi

Re: set!

On Wed, Mar 13, 2013 at 2:36 PM, Michael Klishin < michael.s.klis...@gmail.com> wrote: > alter-var-root works fine for that purpose, e.g. > > https://github.com/michaelklishin/monger/blob/master/src/clojure/monger/core.clj#L168-171 > Thanks. That's probably what I'll end up doing. Still, it wou

Re: set!

On Wed, Mar 13, 2013 at 2:06 PM, Marko Topolnik wrote: > As far as I understand it, *set!* modifies the *thread-local* binding, > just like the *binding* macro, but doesn't delimit a definite scope of > validity for the binding. You can *set!* any dynamic var with the same > semantics. > You can

Re: set!

On Wed, Mar 13, 2013 at 2:09 PM, Cedric Greevey wrote: > To expand on what Marko said, the set!able Vars that come with Clojure > just have thread-local bindings created already in the REPL thread. They're > really only meant to aid developers working at the REPL, rather than to be > set! as part

Re: set!

2013/3/14 Mark Engelberg > I believe one can mimic the functionality with alter-var-root! (I haven't > tried it though), but I'd rather imitate core's style of using set! for > those sorts of overall controlling variables. alter-var-root works fine for that purpose, e.g. https://github.com/mich

Re: set!

To expand on what Marko said, the set!able Vars that come with Clojure just have thread-local bindings created already in the REPL thread. They're really only meant to aid developers working at the REPL, rather than to be set! as part of normal running code. On Wed, Mar 13, 2013 at 5:06 PM, Marko

Re: set!

On Wednesday, March 13, 2013 9:35:42 PM UTC+1, puzzler wrote: > OK, thanks. The apparent "globalness" is not the piece I want to > imitate. I want to make a var available for users to set!, where the var > controls overall behavior of how the library operates. > > I understand that I can just

Re: set!

OK, thanks. The apparent "globalness" is not the piece I want to imitate. I want to make a var available for users to set!, where the var controls overall behavior of how the library operates. I understand that I can just declare the var dynamic, and then they can control it with the binding cons

Re: Set as function

On Apr 6, 12:16 am, Alex Osborne wrote: > Calling the set as if it is a fn is a short-hand for "get", that is > retrieving an element from the set. Why would you want to do this, when > to look it up you need to know what element is?  Sets are based on > value-equality not reference-equality.  T

Re: Set as function

B Smith-Mannschott writes: >> Calling the set as if it is a fn is a short-hand for "get", that is >> retrieving an element from the set. Why would you want to do this, when >> to look it up you need to know what element is? > > Since you asked: canonicalization. I've wanted this on occasion (in >

Re: Set as function

On Tue, Apr 6, 2010 at 07:16, Alex Osborne wrote: > Mark Engelberg writes: > >> filter works just as well with a function that returns true and false, >> so that's not a particularly good example. > > Calling the set as if it is a fn is a short-hand for "get", that is > retrieving an element from

Re: Set as function

Mark Engelberg writes: > filter works just as well with a function that returns true and false, > so that's not a particularly good example. Calling the set as if it is a fn is a short-hand for "get", that is retrieving an element from the set. Why would you want to do this, when to look it up y

Re: Set as function

On Apr 6, 2010, at 12:20 AM, Mark Engelberg wrote: On Mon, Apr 5, 2010 at 8:56 PM, Richard Newman wrote: Why this behavior? It's useful: e.g., you can use a set as a filter. user=> (filter #{2 3 4 5} (range 1 10)) (2 3 4 5) filter works just as well with a function that returns true

Re: Set as function

filter works just as well with a function that returns true and false, so that's not a particularly good example. Heh, that's true. Should have re-read :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@

Re: Set as function

On Mon, Apr 5, 2010 at 8:56 PM, Richard Newman wrote: > Why this behavior? >> > > It's useful: e.g., you can use a set as a filter. > > user=> (filter #{2 3 4 5} (range 1 10)) > (2 3 4 5) > > filter works just as well with a function that returns true and false, so that's not a particularly good

Re: Set as function

Why this behavior? It's useful: e.g., you can use a set as a filter. user=> (filter #{2 3 4 5} (range 1 10)) (2 3 4 5) If you want your alternative, use contains?: user=> (contains? #{true false} false) true -- You received this message because you are subscribed to the Google Groups "Clojur

Re: Set performance

On Apr 5, 3:06 pm, ineol wrote: > It has nothing to do with Clojure but your colleague can look at the > Google collection library that contains an > ImmutableSet.http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co... Yes, there is also Scalas data structures (he was using th

Re: Set performance

On Apr 2, 3:28 pm, Chas Emerick wrote: > As Clojure moves towards being self-hosted, fewer and fewer of the   > data structures will be implemented in Java, thereby ensuring   > dependence on the Clojure runtime.  Just FYI. Yes, I've realized that as well :-) I would have to maintain a Java "ba

Re: Set performance

I looked at the source code. ImmutableSet doesn't support adding adding or removing elements incrementally. You can make an ImmutableSet.Builder from an existing ImmutableSet of n elements and then make a batch of m updates from which it will construct a new ImmutableSet in O(n+m) time. It simply i

Re: Set performance

It has nothing to do with Clojure but your colleague can look at the Google collection library that contains an ImmutableSet. http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ImmutableSet.html -- You received this message because you are subscribed to the Google G

Re: Set performance

As Clojure moves towards being self-hosted, fewer and fewer of the data structures will be implemented in Java, thereby ensuring dependence on the Clojure runtime. Just FYI. - Chas On Mar 31, 2010, at 12:56 PM, Krukow wrote: It would be nice to have a version of the clojure data structure

Re: Set performance

Did you run the test with the -server jvm option? This command line argument is usually recommended when measuring performance. -Julien On Mar 31, 10:56 am, Krukow wrote: > On Mar 29, 10:21 pm, Krukow wrote:> Hello, > [snip..] > > What was surprising to me wasn't that "inserts" are slower - tha

Re: Set performance

On Mar 29, 10:21 pm, Krukow wrote: > Hello, [snip..] > What was surprising to me wasn't that "inserts" are slower - that is > ok and it could be improved with transients. The surprising thing was > that iterating through the entire set was significantly slower. [snip..] I've dug through the sou

Re: set/select vs. other set functions: argument order and ->

Well, I think you've exposed an inconsistency in the signature of clojure.set/select vis-a-vis the "collection first, sequence last" principles here: http://groups.google.com/group/clojure/msg/a8866d34b601ff43 It seems that the collection function clojure.set/select is patterned after the sequenc

Re: set/select vs. other set functions: argument order and ->

On Feb 4, 3:31 am, wlr wrote: > (-> #{{:a 1, :b 1, :c 1} >{:a 2, :b 2, :c 2} >{:a 3, :b 3, :c 3}} >(->> (select #(= (:a %) 1))) >(project [:b :c])) > > => #{{:c 1, :b 1}} Ahhh.. what a tricky language. ;) This saves me from writing reverse- args or select*,

Re: set/select vs. other set functions: argument order and ->

On Feb 3, 6:41 pm, Tayssir John Gabbour wrote: > ;; Works, but is ugly. > (let [xset  #{{:a 1, :b 1, :c 1} >               {:a 2, :b 2, :c 2} >               {:a 3, :b 3, :c 3}}] >   (project (select #(= (:a %) 1) xset) >            [:b :c])) > > So what I currently do is this: > > ;; Works, with

Re: set/select vs. other set functions: argument order and ->

On Feb 3, 10:41 pm, wlr wrote: > Can you somehow use ->> ? > > user> (->> #{1 2 3 4} (clojure.set/select even?)) > #{2 4} D'oh, I was terribly unclear. I want to do something neat and pretty like: ;; Doesn't work! (-> #{{:a 1, :b 1, :c 1} {:a 2, :b 2, :c 2} {:a 3, :b 3, :c 3}} (s

Re: set/select vs. other set functions: argument order and ->

Can you somehow use ->> ? user> (->> #{1 2 3 4} (clojure.set/select even?)) #{2 4} Walt -- 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 -

Re: Question/Problem re (set! *warn-on-reflection* true)

Thank you for your help. I have posted a message on the Enclojure group yesterday and I am still waiting for it to show up... On Jun 22, 5:46 am, "Stephen C. Gilardi" wrote: > On Jun 21, 2009, at 11:17 PM, arasoft wrote: > > > When I enter the following function into the REPL it compiles and > >

Re: Question/Problem re (set! *warn-on-reflection* true)

On Jun 21, 2009, at 11:17 PM, arasoft wrote: When I enter the following function into the REPL it compiles and works without problems: (defn harmonic-number [n prec] (reduce + (map #(with-precision prec (/ 1 (bigdec %))) (range 1 (inc n ) After (set! *warn-on-reflection* true), in

Question/Problem re (set! *warn-on-reflection* true)

When I enter the following function into the REPL it compiles and works without problems: (defn harmonic-number [n prec] (reduce + (map #(with-precision prec (/ 1 (bigdec %))) (range 1 (inc n ) After (set! *warn-on-reflection* true), in a normal REPL I get: Reflection warning, NO_SO

Re: set-system-properties

On Apr 9, 10:48 pm, Stuart Halloway wrote: > Yes to almost all of this (r662). I am not totally comfortable with   > the false/"false" conversion. Cool. I'm not crazy about false/"false" either, since it's not symmetric. -Stuart --~--~-~--~~~---~--~~ You received

Re: set-system-properties

Yes to almost all of this (r662). I am not totally comfortable with the false/"false" conversion. Stu > Hi Stuart H! Comment on: > > (defn set-system-properties > [settings] > "Set some system properties. Nil clears a property." > (doseq [[name val] settings] >(if val > (System/se

Re: Set bug?

On Mar 30, 2:54 pm, Mark Engelberg wrote: > On Mon, Mar 30, 2009 at 10:45 AM, Mark Engelberg > > wrote: > > I don't know whether this fix would be worth the performance penalty, > > though, but it's what would "feel right" to me. > > If it's not practical to always reduce integers when used as

Re: Set bug?

On Mar 30, 1:45 pm, Mark Engelberg wrote: > My own opinions: > I don't expect 1 to equal 1.0 (because I think of inexact numbers as > fundamentally different from exact numbers). I think of 1.0 as a > "number that's so close to 1 that we can't tell the difference, but it > still might not be 1

Re: Set bug?

On Mon, Mar 30, 2009 at 10:45 AM, Mark Engelberg wrote: > I don't know whether this fix would be worth the performance penalty, > though, but it's what would "feel right" to me. > If it's not practical to always reduce integers when used as keys, then I think it would be useful for a variation o

Re: Set bug?

My own opinions: I don't expect 1 to equal 1.0 (because I think of inexact numbers as fundamentally different from exact numbers). I think of 1.0 as a "number that's so close to 1 that we can't tell the difference, but it still might not be 1". I do expect 1 to equal 1/1, and I expect a long 1 to

Re: Set bug?

On Mar 30, 2009, at 14:51, Rich Hickey wrote: > Well, the community simply has to get together on what they want here, > variously: > > - Clojure sets and maps should implement java.util.Set and Map Not something I care much about, though I understand those who do. > - Clojure Numbers are the s

Re: Set bug?

On Mon, Mar 30, 2009 at 8:21 AM, Konrad Hinsen wrote: > > On Mar 30, 2009, at 12:36, Mark Engelberg wrote: > >> I'm aware that a and 123 have different types, but I was under the >> impression that the hash set implementation was supposed to just rely >> on hash codes and equality. Why does the

Re: Set bug?

On Mar 30, 2009, at 12:36, Mark Engelberg wrote: > I'm aware that a and 123 have different types, but I was under the > impression that the hash set implementation was supposed to just rely > on hash codes and equality. Why does the type come into play, and is > this really the desired behavior?