Re: Set equality bug?

[Michael Gardner]

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 that Clojure users will get bitten by this once in a while and 
> hours will be wasted.
> 
> It is also very disturbing to realise that "(= a b)" doesn't always imply "(= 
> (hash a) (hash b))" or "(= #{a} #{b})" as you would think.

(inc)

This is fundamentally broken behavior. Telling people to just learn to avoid it 
is not good, IMO. If the hashes must be unequal, then = should return false.

As for backwards compatibility, note that if such a change were made to =, it 
wouldn't affect anyone who was already following Andy's advice to avoid mixing 
doubles and floats. IOW, it should only affect those who are doing something 
you're not "supposed" to do anyway.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Luc Prefontaine]

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.

- Never mix different representations in computations

- Convert representations as early as possible to a common format

These are the rules to follow to avoid running into trouble.

Now if you think you can overcome this persistent (ah ! ah !) problem with some 
David Copperfield trick, fine.

But that's a trick nothing else. The problem will resurface in some form in 
another. Better cope with reality...

Luc P.


> 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 that Clojure users will get bitten by this once in a while 
> > and hours will be wasted.
> > 
> > It is also very disturbing to realise that "(= a b)" doesn't always imply 
> > "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
> 
> (inc)
> 
> This is fundamentally broken behavior. Telling people to just learn to avoid 
> it is not good, IMO. If the hashes must be unequal, then = should return 
> false.
> 
> As for backwards compatibility, note that if such a change were made to =, it 
> wouldn't affect anyone who was already following Andy's advice to avoid 
> mixing doubles and floats. IOW, it should only affect those who are doing 
> something you're not "supposed" to do anyway.
> 
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Mark Engelberg]

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's really no question when you're working with a
mixture of floats and doubles.  In Clojure, it's much easier for this kind
of thing to slip into your program unnoticed.  Call a couple of external
libraries that produce floats or doubles -- Clojure will happily hide the
difference from you and then you get burned.

As I frequently find myself explaining to newcomers to Clojure, one of
Clojure's biggest weaknesses is that it goes to great pains to hide type
details (floats vs doubles, boxed vs unboxed, hash sets vs array sets,
etc.) and every once in a while it really matters -- a lot -- what the
types actually are and there aren't many tools for discovering the flow of
types through your code.

So I wouldn't necessarily go blaming this on Java.

Furthermore, I'm not so sure it is broken in Java:

=> (.equals (float 2) (double 2))
false

=> (.compareTo (float 2) (double 2))
ClassCastException Cannot cast java.lang.Double to java.lang.Float
java.lang.Class.cast (Class.java:3258)

So Java doesn't appear to transparently treat floats and doubles as equal
(which is consistent with the fact that Java's hashes of floats and doubles
can be different).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

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 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.
> 
> - Never mix different representations in computations
> 
> - Convert representations as early as possible to a common format
> 
> These are the rules to follow to avoid running into trouble.
> 
> Now if you think you can overcome this persistent (ah ! ah !) problem with 
> some David Copperfield trick, fine.
> 
> But that's a trick nothing else. The problem will resurface in some form in 
> another. Better cope with reality...
> 
> Luc P.
> 
> 
>> 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 that Clojure users will get bitten by this once in a while 
>>> and hours will be wasted.
>>> 
>>> It is also very disturbing to realise that "(= a b)" doesn't always imply 
>>> "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
>> 
>> (inc)
>> 
>> This is fundamentally broken behavior. Telling people to just learn to avoid 
>> it is not good, IMO. If the hashes must be unequal, then = should return 
>> false.
>> 
>> As for backwards compatibility, note that if such a change were made to =, 
>> it wouldn't affect anyone who was already following Andy's advice to avoid 
>> mixing doubles and floats. IOW, it should only affect those who are doing 
>> something you're not "supposed" to do anyway.
>> 
>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 
> --
> Luc Prefontaine sent by ibisMail!
> 
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Satisfies? seems strangely slow

[Phillip Lord]

Tassilo Horn  writes:
>> I don't think satisfies? is worth optimizing as using ton of it seems
>> antithetical to protocols. It signals to me that a caller does in fact
>> care about the implementation, whereas protocols are about not
>> caring. Like your PR, if you want to ensure a protocol's coverage, you
>> can also extend a protocol to Object and/or nil. Not sure what a valid
>> use case would be for calling satisfies? on a hot path would be.
>
> I use satisfies? for optional features, e.g., if some data structure
> satisfies some protocol, then that optional feature is enabled, else
> it's disabled.  But that's not really on a hot path so I don't care much
> about satisfies? performance.


Have you tried just implementing the protocol over Object to do
nothing? Then putting use an alternative implementation of the protocol
where you want.

I did this to avoid lots of

(when (satisfies? AProc o)
   (do-method o))

and just have

(do-method o)

instead. But if I understand how protocols are implemented (which I
don't), I think this also avoids the type look up.

Phil
 

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Luc Préfontaine]

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 interest me. Hiding odd behaviors when consistency can be 
guaranteed,
I have no problem with that. Here to me its very clear that there is no 
failsafe approach.

Clojure is hosted on a platform that does not provide the kind if consistency 
you want.
Anything you can build to hide this in Clojure is like building a tower on 
moving sand.

Mark has a valid point about type safety which helps a bit in Java but you can 
dig
with google and you will find people that got bitten in Java by float/double 
mixing
even with type 'safety'. So long for type systems, it cannot help you with 
values that
'look' the same superficially but are internally different.

For some values, floats and doubles are equal because their internal 
representations are the 
same. For many other values it's not working.

I suggest some readings;

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
http://floating-point-gui.de/errors/comparison/

Then maybe we can bring this thread to an end.


> 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 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.
> > 
> > - Never mix different representations in computations
> > 
> > - Convert representations as early as possible to a common format
> > 
> > These are the rules to follow to avoid running into trouble.
> > 
> > Now if you think you can overcome this persistent (ah ! ah !) problem with 
> > some David Copperfield trick, fine.
> > 
> > But that's a trick nothing else. The problem will resurface in some form in 
> > another. Better cope with reality...
> > 
> > Luc P.
> > 
> > 
> >> 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 that Clojure users will get bitten by this once in a 
> >>> while and hours will be wasted.
> >>> 
> >>> It is also very disturbing to realise that "(= a b)" doesn't always imply 
> >>> "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
> >> 
> >> (inc)
> >> 
> >> This is fundamentally broken behavior. Telling people to just learn to 
> >> avoid it is not good, IMO. If the hashes must be unequal, then = should 
> >> return false.
> >> 
> >> As for backwards compatibility, note that if such a change were made to =, 
> >> it wouldn't affect anyone who was already following Andy's advice to avoid 
> >> mixing doubles and floats. IOW, it should only affect those who are doing 
> >> something you're not "supposed" to do anyway.
> >> 
> >> -- 
> >> 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 unsubscribe from this group and stop receiving emails from it, send an 
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >> 
> > --
> > Luc Prefontaine sent by ibisMail!
> > 
> > -- 
> > 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 unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, vi

[ANN] bouncer 0.3.2

[Leonardo Borges]

bouncer is a validation library for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

The main change with 0.3.2 is that bouncer now works with Clojurescript! -
thanks Robin(@Skinney)!

New validators have also been added. You can read more about the changes in
the CHANGELOG:
https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md

Enjoy! :)

Leonardo Borges
www.leonardoborges.com

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Luc Prefontaine]

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 = 3.2f;
System.out.println(String.format("dd2 vs ff2 == %b", dd2==ff2));
}
}

REPL output:
=> (idem.core.TestClass/equality)
nil

Console output:

nREPL server started on port 38698 on host 127.0.0.1 - nrepl://127.0.0.1:38698
dd vs ff == true
dd2 vs ff2 == false

We are talking about values as primitive types, not boxed values as objects:

The equals method for class Object implements the most discriminating possible 
equivalence relation on objects; that is, for any non-null reference values x 
and y, this method returns true if and only if x and y refer to the same object 
(x == y has the value true). 

=> (class (float 3.2))
java.lang.Float
=> (class (double 3.2))
java.lang.Double

Oupse... :)

Luc P.


On Fri, 23 Jan 2015 01:31:31 -0800
Mark Engelberg  wrote:

> 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's really no question when
> you're working with a mixture of floats and doubles.  In Clojure,
> it's much easier for this kind of thing to slip into your program
> unnoticed.  Call a couple of external libraries that produce floats
> or doubles -- Clojure will happily hide the difference from you and
> then you get burned.
> 
> As I frequently find myself explaining to newcomers to Clojure, one of
> Clojure's biggest weaknesses is that it goes to great pains to hide
> type details (floats vs doubles, boxed vs unboxed, hash sets vs array
> sets, etc.) and every once in a while it really matters -- a lot --
> what the types actually are and there aren't many tools for
> discovering the flow of types through your code.
> 
> So I wouldn't necessarily go blaming this on Java.
> 
> Furthermore, I'm not so sure it is broken in Java:
> 
> => (.equals (float 2) (double 2))
> false
> 
> => (.compareTo (float 2) (double 2))
> ClassCastException Cannot cast java.lang.Double to java.lang.Float
> java.lang.Class.cast (Class.java:3258)
> 
> So Java doesn't appear to transparently treat floats and doubles as
> equal (which is consistent with the fact that Java's hashes of floats
> and doubles can be different).
> 



-- 
Luc Préfontaine

SoftAddicts inc.
Québec, Canada
Mobil: (514) 993-0320
Fax: (514) 800-2017

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

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 objects can be equal only if their 
hashes are equal" is a fundamental one that should not be violated under any 
circumstances. Whether that means modifying Clojure's hashing algorithm or its 
implementation of = doesn't much matter to me, so long as that property is 
maintained.

> On Jan 23, 2015, at 5:06 AM, Luc Préfontaine  
> wrote:
> 
> 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 interest me. Hiding odd behaviors when consistency can be 
> guaranteed,
> I have no problem with that. Here to me its very clear that there is no 
> failsafe approach.
> 
> Clojure is hosted on a platform that does not provide the kind if consistency 
> you want.
> Anything you can build to hide this in Clojure is like building a tower on 
> moving sand.
> 
> Mark has a valid point about type safety which helps a bit in Java but you 
> can dig
> with google and you will find people that got bitten in Java by float/double 
> mixing
> even with type 'safety'. So long for type systems, it cannot help you with 
> values that
> 'look' the same superficially but are internally different.
> 
> For some values, floats and doubles are equal because their internal 
> representations are the 
> same. For many other values it's not working.
> 
> I suggest some readings;
> 
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
> http://floating-point-gui.de/errors/comparison/
> 
> Then maybe we can bring this thread to an end.
> 
> 
>> 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 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.
>>> 
>>> - Never mix different representations in computations
>>> 
>>> - Convert representations as early as possible to a common format
>>> 
>>> These are the rules to follow to avoid running into trouble.
>>> 
>>> Now if you think you can overcome this persistent (ah ! ah !) problem with 
>>> some David Copperfield trick, fine.
>>> 
>>> But that's a trick nothing else. The problem will resurface in some form in 
>>> another. Better cope with reality...
>>> 
>>> Luc P.
>>> 
>>> 
 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 that Clojure users will get bitten by this once in a 
> while and hours will be wasted.
> 
> It is also very disturbing to realise that "(= a b)" doesn't always imply 
> "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
 
 (inc)
 
 This is fundamentally broken behavior. Telling people to just learn to 
 avoid it is not good, IMO. If the hashes must be unequal, then = should 
 return false.
 
 As for backwards compatibility, note that if such a change were made to =, 
 it wouldn't affect anyone who was already following Andy's advice to avoid 
 mixing doubles and floats. IOW, it should only affect those who are doing 
 something you're not "supposed" to do anyway.
 
 -- 
 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 unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
>>> --
>>> Luc Prefontaine sent by ibisMail!
>>> 

Re: Set equality bug?

[Andy Fingerhut]

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.  Without
some new convincing argument in favor of (2), it seems unlikely to change.

Another alternative might be an option to throw an exception if any floats
creep into Clojure territory from Java, if that boundary line is even
drawable.

Andy

On Fri, Jan 23, 2015 at 4:45 AM, Michael Gardner 
wrote:

> 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 objects can be equal only if their
> hashes are equal" is a fundamental one that should not be violated under
> any circumstances. Whether that means modifying Clojure's hashing algorithm
> or its implementation of = doesn't much matter to me, so long as that
> property is maintained.
>
> > On Jan 23, 2015, at 5:06 AM, Luc Préfontaine <
> lprefonta...@softaddicts.ca> wrote:
> >
> > 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 interest me. Hiding odd behaviors when consistency can
> be guaranteed,
> > I have no problem with that. Here to me its very clear that there is no
> failsafe approach.
> >
> > Clojure is hosted on a platform that does not provide the kind if
> consistency you want.
> > Anything you can build to hide this in Clojure is like building a tower
> on moving sand.
> >
> > Mark has a valid point about type safety which helps a bit in Java but
> you can dig
> > with google and you will find people that got bitten in Java by
> float/double mixing
> > even with type 'safety'. So long for type systems, it cannot help you
> with values that
> > 'look' the same superficially but are internally different.
> >
> > For some values, floats and doubles are equal because their internal
> representations are the
> > same. For many other values it's not working.
> >
> > I suggest some readings;
> >
> > http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
> > http://floating-point-gui.de/errors/comparison/
> >
> > Then maybe we can bring this thread to an end.
> >
> >
> >> 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 <
> lprefonta...@softaddicts.ca> wrote:
> >>>
> >>> 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.
> >>>
> >>> - Never mix different representations in computations
> >>>
> >>> - Convert representations as early as possible to a common format
> >>>
> >>> These are the rules to follow to avoid running into trouble.
> >>>
> >>> Now if you think you can overcome this persistent (ah ! ah !) problem
> with some David Copperfield trick, fine.
> >>>
> >>> But that's a trick nothing else. The problem will resurface in some
> form in another. Better cope with reality...
> >>>
> >>> Luc P.
> >>>
> >>>
>  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 that Clojure users will get bitten by this once in a while
> and hours will be wasted.
> >
> > It is also very disturbing to realise that "(= a b)" doesn't always
> imply "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
> 
>  (inc)
> 
>  This is fundamentally broken behavior. Telling people to just learn
> to avoid it is not good, IMO. If the hashes must be unequal, then = should
> return false.
> 
>  As for backwards compatibility, note that if such a change were made
> to =, it wouldn't affect anyone who was already following Andy's advice to
> avoid mixing doubles and floats. IOW, it should only affect those who are
> doing something you're not "supposed" to do anyway.
> 
>  --
>  You received this message because you are subscribed to the Google
>  Groups "Clojure" group.
>  To post t

Re: [ANN] bouncer 0.3.2

[Plínio Balduino]

This is awesome, Leonardo

On Fri, Jan 23, 2015 at 9:39 AM, Leonardo Borges <
leonardoborges...@gmail.com> wrote:

> bouncer is a validation library for Clojure apps
>
> Github: https://github.com/leonardoborges/bouncer
> Clojars: https://clojars.org/bouncer
>
> The main change with 0.3.2 is that bouncer now works with Clojurescript! -
> thanks Robin(@Skinney)!
>
> New validators have also been added. You can read more about the changes
> in the CHANGELOG:
> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md
>
> Enjoy! :)
>
> Leonardo Borges
> www.leonardoborges.com
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] bouncer 0.3.2

[Andrey Antukh]

Great library! I don't know about it! Thanks!

2015-01-23 15:54 GMT+01:00 Plínio Balduino :

> This is awesome, Leonardo
>
> On Fri, Jan 23, 2015 at 9:39 AM, Leonardo Borges <
> leonardoborges...@gmail.com> wrote:
>
>> bouncer is a validation library for Clojure apps
>>
>> Github: https://github.com/leonardoborges/bouncer
>> Clojars: https://clojars.org/bouncer
>>
>> The main change with 0.3.2 is that bouncer now works with Clojurescript!
>> - thanks Robin(@Skinney)!
>>
>> New validators have also been added. You can read more about the changes
>> in the CHANGELOG:
>> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md
>>
>> Enjoy! :)
>>
>> Leonardo Borges
>> www.leonardoborges.com
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

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
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[job] Write Clojure/ClojureScript with us in Boston

[Isaac Cambron]

Hi everyone,

Zensight is an all-Clojure/ClojureScript startup in Cambridge, MA, and 
we're hiring full-stack engineers. We're solving some interesting data 
processing, machine learning, and information retrieval problems, as part 
of a product to help sales people be more effective at communicating with 
their prospects. We're looking for people with > 8 years software 
development experience, a desire to contribute to all levels of the process 
from code to architecture to product decisions, and a passion for the craft 
of building software. Being an experienced with Clojure/ClojureScript is 
not a requirement, but some sort FP experience is a big plus.

Here's our company page  with our team on 
it and a more complete description of the job. For some more context, 
here's an interview 
 
about how we approach building a product from scratch. If you're 
interested, please email me at is...@zensight.co and I'll be happy to tell 
you all about it.

-Isaac

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] bouncer 0.3.2

[Laurens Van Houtven]

Looks awesome! I’m currently using prismatic/schema for what seems like exactly 
the same thing; could you enlighten me how the two libraries are different?


thanks
lvh


> On Jan 23, 2015, at 3:39 AM, Leonardo Borges  
> wrote:
> 
> bouncer is a validation library for Clojure apps
> 
> Github: https://github.com/leonardoborges/bouncer 
> 
> Clojars: https://clojars.org/bouncer 
> 
> The main change with 0.3.2 is that bouncer now works with Clojurescript! - 
> thanks Robin(@Skinney)!
> 
> New validators have also been added. You can read more about the changes in 
> the CHANGELOG: 
> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md 
> 
> 
> Enjoy! :)
> 
> Leonardo Borges
> www.leonardoborges.com 
> 
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Set equality bug?

[Andy Fingerhut]

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.5))
true
user=> (>= (float 1.5) (double 1.5))
true
user=> (= (float 1.5) (double 1.5))
false

That certainly flies in the face of what most people learned in math class.

Andy

On Fri, Jan 23, 2015 at 9:29 AM, Michael Gardner 
wrote:

> 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
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

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=> (>= (float 1.5) (double 1.5))
> true
> user=> (= (float 1.5) (double 1.5))
> false

I'd argue you should be using == if you care about that particular property. 
And note that this can already happen with BigDecimals:

user=> (>= 10M 10)
true
user=> (<= 10M 10)
true
user=> (= 10M 10)
false

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Mark Engelberg]

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 like the
logical outcome of this line of thinking.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Luc Prefontaine]

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 in the context of heavy 
computations. Testing against a range is often preferred.

Money related apps use specific types to deal with rounding/truncating.
This is why packed decimal was used  intensively. You would always end up with 
two decimals. W/o having to care for the intermediate computation steps too 
much.

Danger comes from ignorance.

What you with it afterward is another story :)

I would find it odd to see some operators throw such errors in a typeless 
language.

> 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 like the
> logical outcome of this line of thinking.
> 
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Satisfies? seems strangely slow

[Tassilo Horn]

phillip.l...@newcastle.ac.uk (Phillip Lord) writes:

>> I use satisfies? for optional features, e.g., if some data structure
>> satisfies some protocol, then that optional feature is enabled, else
>> it's disabled.  But that's not really on a hot path so I don't care
>> much about satisfies? performance.
>
> Have you tried just implementing the protocol over Object to do
> nothing? Then putting use an alternative implementation of the
> protocol where you want.

I really use it for optional features for which no alternative
implementation exists.  Concretely, I have a library that can work with
several graph data structures in a uniform way.  Some of them have
first-class edges, others only have references.  For example, my lib has
a code generation facility where there's some code like

  (when (satisfies? IEdges type-graph)
(generate-edge-access-fns ...))

But for other stuff I do extend protocols to Object (and nil) providing
a default implementation.

Bye,
Tassilo

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Fluid Dynamics]

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 
> silent about other operators. 
>
> Testing equality with floats is seldom used in the context of heavy 
> computations. Testing against a range is often preferred. 
>

Often, but there can be exceptions. When floats appear as part of objects 
put in a set or used as map keys is one of them.

Not long ago I had something doing numeric work where calculations produced 
double values and certain runs of inputs would produce identical output, 
down to the last decimal place. Detecting such runs was as simple as using 
a map with double keys and checking whether it already had an entry for a 
value, then dispatching some other code based on the value found, as inputs 
that produced one value needed one sort of additional processing, and 
another value another sort.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Fluid Dynamics]

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 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Satisfies? seems strangely slow

[Fluid Dynamics]

On Friday, January 23, 2015 at 3:13:08 PM UTC-5, Tassilo Horn wrote:
>
> philli...@newcastle.ac.uk  (Phillip Lord) writes: 
>
> >> I use satisfies? for optional features, e.g., if some data structure 
> >> satisfies some protocol, then that optional feature is enabled, else 
> >> it's disabled.  But that's not really on a hot path so I don't care 
> >> much about satisfies? performance. 
> > 
> > Have you tried just implementing the protocol over Object to do 
> > nothing? Then putting use an alternative implementation of the 
> > protocol where you want. 
>
> I really use it for optional features for which no alternative 
> implementation exists.  Concretely, I have a library that can work with 
> several graph data structures in a uniform way.  Some of them have 
> first-class edges, others only have references.  For example, my lib has 
> a code generation facility where there's some code like 
>
>   (when (satisfies? IEdges type-graph) 
> (generate-edge-access-fns ...)) 
>
> But for other stuff I do extend protocols to Object (and nil) providing 
> a default implementation. 
>
> Bye, 
> Tassilo 
>

One approach is to have a first-class-edges? method in the mother graph 
protocol. Another is to have such a method in IEdges and extend that to 
Object with first-class-edges? returning false and the other 
IEdges-specific methods throwing IllegalStateExceptions, as well as to 
"true" IEdges subtypes with the first returning true and the rest doing 
whatever they should do.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Luc Prefontaine]

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 of language

Clojure 'type system' embraces the platform it runs on with the exception
of its own persistent data structures.

It's not the other way around.


On Fri, 23 Jan 2015 14:23:34 -0800 (PST)
Fluid Dynamics  wrote:

> And this is not a typeless language, it is a strongly dynamically
> typed language.
> 



-- 
Luc Préfontaine

SoftAddicts inc.
Québec, Canada
Mobil: (514) 993-0320
Fax: (514) 800-2017

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vectorz, "Unable to find implementation", uberjar, excluding source

[Michael Blume]

If you want to keep jar size down and avoid class loader problems, instead
of excluding source I'd avoid aot and only ship source. If you need the JVM
to find your main class you can write a shim and only aot-compile that.

On Wed Jan 21 2015 at 12:36:03 PM Brian Craft  wrote:

> Fixed it by adding :aot [mikera.vectorz.core] to the uberjar profile.
>
>
> On Wednesday, January 21, 2015 at 11:26:47 AM UTC-8, Brian Craft wrote:
>>
>> I'm excluding source when building uberjar, due to jar size and class
>> loader problems at run time. However I now get "Unable to find
>> implementation :vectorz" errors at run time. Is there some way to work
>> around 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: aot resolve question

[Michael Blume]

Not sure what to tell you. If you can post code we can use to reproduce the
problem, that would help. Alternately, put some println statements into
load-sym so you can be sure it's getting the values you think it is?

On Tue Jan 20 2015 at 11:45:34 PM bob  wrote:

> Hi,
>
> I have a function
>
> (defn load-sym
>   [s]
>   (require (symbol (namespace s)))
>   (resolve s))
>
>
> There is no problem if not using the uberjar. when using the uberjar,
>
> (common/load-sym 'web/app-routes) // it can work
>
>
> {:route web/app-routes} //an edn file
>
> I read the edn file and put  the value of :route to the common/load-sym, it 
> return nil. quite wired, I have used this approach for many place, only one 
> has this problem.
>
>
> Thanks at advanced.
>
>
>
>  --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] bouncer 0.3.2

[Sam Ritchie]

We're using Validateur for this: 
https://github.com/michaelklishin/validateur Not sure if you've seen 
that one either.


Schema is more of a type-system-lite - it's not very good out of the box 
at allowing you to validate form data and return nice error messages in 
a way that's easy for some form library to consume.



Laurens Van Houtven 
January 23, 2015 at 10:43 AM
Looks awesome! I’m currently using prismatic/schema for what seems 
like exactly the same thing; could you enlighten me how the two 
libraries are different?



thanks
lvh



--
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 unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.
Leonardo Borges 
January 23, 2015 at 4:39 AM
bouncer is a validation library for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

The main change with 0.3.2 is that bouncer now works with 
Clojurescript! - thanks Robin(@Skinney)!


New validators have also been added. You can read more about the 
changes in the CHANGELOG: 
https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md


Enjoy! :)

Leonardo Borges
www.leonardoborges.com 
--
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 unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: core.async chan ex-handler

[coltnz]

On Friday, January 23, 2015 at 12:59:40 AM UTC+13, Derek Troy-West wrote:
>
> From the documentation:
>
> (chan buf-or-n xform ex-handler)
>
> "If a transducer is supplied a
> buffer must be specified. ex-handler must be a fn of one argument -
> if an exception occurs during transformation it will be called with
> the Throwable as an argument"
>
>
> Is there a reason the ex-handler fn doesn't have a second arity which also 
> takes the val which caused the transformation error?
>
>
>
No reason I can see. Seems worthy of a ticket on the async project to me.

You could construct your own ManyToManyChannel as a workaround for now. 
Copy chan's 3rd arity and call your own handle fn taking buf.

Colin 

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.