On 6 Sep, 2011, at 12:43 , Sam Aaron wrote:
>> I have added a plain function not= to clojure.algo.generic.comparison as a
>> convenience, it is just the negation of generic =.
>
> Would this still allow the overriding of not= to do somethign different to
> the negation of generic =. If not, how
On 6 Sep 2011, at 11:33, Konrad Hinsen wrote:
>
> I must assume that nobody read that message, as there should have been loud
> complaints. There is obviously no difference in performance between = and
> not=, as the result of either one is known as soon as one can decide equality
> OR non-equ
On 1 Sep, 2011, at 14:51 , Konrad Hinsen wrote:
> On 1 Sep, 2011, at 10:35 , Alan Malloy wrote:
>
>> I don't see any reason for it to include !=, which can be implemented
>> as (not (= a b)). Conversely, <= could be implemented as (or (< a b)
>> (= a b)), but if either of those is expensive opera
A couple nitpicks:
> Right, and that's also the reason why there should be not=, with a default
> implementation that does (not (= ...)). It can be expensive to establish
> equality for a complex data structure, whereas inequality can be ascertained
> at the first difference encountered.
In th
On 1 Sep, 2011, at 10:35 , Alan Malloy wrote:
> I don't see any reason for it to include !=, which can be implemented
> as (not (= a b)). Conversely, <= could be implemented as (or (< a b)
> (= a b)), but if either of those is expensive operations he gives you
> a chance to do a more-optimized <=.
On 1 Sep 2011, at 09:35, Alan Malloy wrote:
> I don't see any reason for it to include !=, which can be implemented
> as (not (= a b)). Conversely, <= could be implemented as (or (< a b)
> (= a b)), but if either of those is expensive operations he gives you
> a chance to do a more-optimized <=. T
I don't see any reason for it to include !=, which can be implemented
as (not (= a b)). Conversely, <= could be implemented as (or (< a b)
(= a b)), but if either of those is expensive operations he gives you
a chance to do a more-optimized <=. There's not much point in forcing
people to implement
Hi Konrad,
that's great news :-)
Thanks for such a useful set of libraries. Oh, and whilst we're on the subject,
is there any reason why generic.comparison doesn't include !=
Sam
---
http://sam.aaron.name
On 1 Sep 2011, at 08:29, Konrad Hinsen wrote:
> On 31 août 11, at 17:04, Sam Aaron wrot
On 31 août 11, at 17:04, Sam Aaron wrote:
is anyone aware of any plans to move Konrad Hinsen's generic math,
comparator and arithmetic libraries to new separate 1.3 contrib libs?
* http://richhickey.github.com/clojure-contrib/generic.math-functions-api.html
* http://richhickey.github.com/cloj
Hi there,
is anyone aware of any plans to move Konrad Hinsen's generic math, comparator
and arithmetic libraries to new separate 1.3 contrib libs?
* http://richhickey.github.com/clojure-contrib/generic.math-functions-api.html
* http://richhickey.github.com/clojure-contrib/generic.arithmetic-api.
10 matches
Mail list logo
