On this last question, most (maybe all) Clojure immutable collections store
their hash value after it has been calculated once, so it need not be
calculated again.
Even the first time a collection's hash is calculated, it is a function of
the hash of its elements (set elements, or map keys & value
One more thing, is it cheap to hash immutable maps vs mutable ones?
On Saturday, June 27, 2015 at 10:44:44 AM UTC-4, Jacob Goodson wrote:
>
> Thanks.
>
> What about the perf of something like this...
>
> ({{:x 1 :y 2} :point} {:x 1 :y 2})
>
> vs
>
> ({1 2} 1)
>
> and what if the map was mutable as
Thanks.
What about the perf of something like this...
({{:x 1 :y 2} :point} {:x 1 :y 2})
vs
({1 2} 1)
and what if the map was mutable as a key?
On Saturday, June 27, 2015 at 10:08:19 AM UTC-4, Andy Fingerhut wrote:
>
> (let [foo {:x 1}]
> (= foo foo))
>
> is fast, because they are identical
(let [foo {:x 1}]
(= foo foo))
is fast, because they are identical, and = is fast for things that are
identical.
In general, two maps that are = are often not identical.
If two maps have different numbers of elements, = should quickly return
false because of the way equiv() is implemented for
for comparing floatingpoint-numbers esp. in testcode this is useful:
(defn- square [n]
(* n n))
(defn close-to
([a b d]
(< (square(- a b)) d))
([a b]
(close-to a b 0.01)))
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
T
Seems to me that BigDecimal, being essentially a BigInteger numerator and a
power-of-ten denominator, could have been accommodated in Category 1 given
that Ratio could.
On Mon, Jan 27, 2014 at 10:26 AM, Andy Fingerhut
wrote:
> As Jim already mentioned, you can use == to compare numbers for equal
As Jim already mentioned, you can use == to compare numbers for equality,
but you must be cautious with equality for floating point numbers, as the
tiniest bit of roundoff error will cause = and == to be false for such
comparisons.
For =, there are effectively 3 'categories' of numeric values in C
Use `==` instead:
user=> (== 42 42.0)
true
user=> (== 42 42M)
true
Jim
On 27/01/14 13:41, Dennis Haupt wrote:
one does not simply compare floating point numbers for equality
2014-01-27 Eric Le Goff mailto:eleg...@gmail.com>>
Newbie question :
user=> (= 42 42)
true
user=> (
one does not simply compare floating point numbers for equality
2014-01-27 Eric Le Goff
> Newbie question :
>
> user=> (= 42 42)
> true
> user=> (= 42 42.0)
> false
>
> I did not expect last result.
>
> I understand that underlying classes are not the same
> i.e
> user=> (class 42)
> java.lang.
Yes, the Clojure 1.3 doc is wrong. As a new Clojure user, I was pretty
confused for a while.
But after reading this thread I still don't understand why the map behavior
(where 3 and 3.0 are considered different map keys) wasn't considered
incorrect, rather than the = behavior.
http://clojure.
core.clj currently contains two definitions of =, one of which is commented
out. The active one has this docstring:
"Equality. Returns true if x equals y, false if not. Same as
Java x.equals(y) except it also works for nil, and compares
numbers and collections in a type-independent manner.
In practice, in most languages, it's uncertain to test for equality between
floating point values.
This is mainly a side effect of internal representations.
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
It's probably safer to keep things that way. Ints (or longs) are
Ok, I follow you now. That makes sense. Sort-of :)
On the other hand, it's only inconsistent if you consider clojure's = to map
to java's .equals method, but it does not:
user=> (clojure-version)
"1.2.1"
user=> (= 3 3.0)
true
user=> (.equals 3 3.0)
false
So it doesn't really violate the contr
What I meant is that (= 3 3.0) is the erroneous behavior.
Either it's equal every where (including as keys in maps) or not.
You cannot have both semantics coexists. It's all or nothing.
Look at this the other way around (1.2):
user=> {3 :a 3 :b}
java.lang.IllegalArgumentException: Duplicate ke
I think he's saying that it boiled down to consistency ie it's
inconsistent to allow maps where 3 != 3.0, but make 3 = 3.0 fit
clojure equality semantics. I don't know if that's satisfying, but
it's fair.
On Oct 2, 3:31 pm, Chris Perkins wrote:
> Luc,
>
> I think you are mistaken.
>
> user=> (cl
Luc,
I think you are mistaken.
user=> (clojure-version)
"1.2.1"
user=> (def m {3.0 :a 3 :b})
#'user/m
user=> (get m 3.0)
:a
user=> (get m 3)
:b
user=> (= 3 3.0)
true
user=>
Do you have another example?
- Chris
--
You received this message because you are subscribed to the Google
Groups "Cloj
Right. I didn't see this earlier (http://dev.clojure.org/display/doc/
Documentation+for+1.3+Numerics). We're all on the same page now. (=
> If the doc string is confusing, please propose alternate language.
Updating the '=' docstring to match that page sounds appropriate ie
adding "...,but not
user=> (def m { 3.0 :a 3 :b})
#'user/a
user=> a
{3.0 :a, 3 :b}
user=> (get m 3.0 )
:a
user=> (get m 3 )
:b
user=>
if 3.0 and 3 were to be considered equals, you could not represent the above
map,
the second entry would squash the first.
Now if we want to allow such maps, then we cannot conside
Follow-up question: Can someone explain the rationale behind the change to =
semantics between integers and floating-point numbers? I have read the
design page (
http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics), but all
it seems to have is this somewhat cryptic description:
"
> Stuart,
>
> The documentation is clear (to me) about comparing numbers directly - that
> part is fine. My question was about whether there is an equivalent of the new
> == comparison that works on containers with floating-point numbers inside.
>
> I had guessed that == would recursively compa
Stuart,
The documentation is clear (to me) about comparing numbers directly - that
part is fine. My question was about whether there is an equivalent of the
new == comparison that works on containers with floating-point numbers
inside.
I had guessed that == would recursively compare the conten
> user=> (= 23.0 23)
> false
> user=> (= 23 23)
> true
This is the correct behavior. If the doc string is confusing, please propose
alternate language.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" gr
On Sat, Oct 1, 2011 at 9:52 PM, Daniel wrote:
> user=> (= 23.0 23)
> false
With every language I've ever worked in, I've always been told that
comparing floating point numbers for equality is a bad idea so I'm
actually glad to see that the above comparison is false...
--
Sean A Corfield -- (904)
user=> (= 23.0 23)
false
user=> (= 23 23)
true
"compares numbers and collections in a type-independent manner"
This kind of breakage was probably to be expected with the numerics
changes in 1.3. I am also interested in this.
On Oct 1, 4:34 pm, Chris Perkins wrote:
> I am trying to upgrade so
false, of course. :-)
What would the post-patch result be of that operation?
On Feb 20, 10:25 am, Stuart Halloway
wrote:
Current results vary based on arg order:
(def xes (iterate #(str % "x") "x"))
=> #'user/xes
; infinite first ok
(= xes ["x" "xx"])
=> false
; finite first boom
(= ["x" "
What would the post-patch result be of that operation?
On Feb 20, 10:25 am, Stuart Halloway
wrote:
> Current results vary based on arg order:
>
> (def xes (iterate #(str % "x") "x"))
> => #'user/xes
>
> ; infinite first ok
> (= xes ["x" "xx"])
> => false
>
> ; finite first boom
> (= ["x" "xx"] xe
On 7 Oct 2008, at 21:00, Brian Doyle wrote:
> [...] I've created a defstruct for a place type object like:
>
> (defstruct place :id :name :street :city :state :zip)
>
> I want to write a function that would take a list of places and remove
> the duplicates. Duplicates are defined by places havi
Hello,
Am 07.10.2008 um 23:32 schrieb Brian Doyle:
Yes, I was just being somewhat lazy with this. If I define 10
attributes
for a given struct and wanted to use all of those plus 3 more in a new
struct I didn't want to have to write out those original 10
attributes again.
I'm not sure, t
On Tue, Oct 7, 2008 at 2:32 PM, Stuart Halloway
<[EMAIL PROTECTED]>wrote:
>
> Hi Brian,
>
> (1) What does it mean to be equal on id and not equal on the other
> fields? If two fields claim the same id but a different name, how
> would you know which one to keep?
I guess it could depend on the si
Hi Brian,
(1) What does it mean to be equal on id and not equal on the other
fields? If two fields claim the same id but a different name, how
would you know which one to keep?
(2) Given some answer to #1, why not store the structs in a map under
id?
(3) For the geocoded place struct, I w
30 matches
Mail list logo
