Re: xor operator

[Dom Grigonis via Python-list]

In case someone is actually going to execute the code, there is a bug:

`set` need to be wrapped in `len` for criteria args.

> On 15 Nov 2023, at 20:13, Dom Grigonis  wrote:
> 
> 
> The specific situation was related to truth values and following out of that 
> my considerations regarding equivalent of all and any for counting `truths`.
> 
> So one of the specific examples:
> class Publisher:
> def __init__(self):
> self.subscribers = dict()
> 
> def subscribe(self, sub, criteria, agg=all):
> self.subscribers[sub] = (criteria, agg)
> 
> def publish(self, msg):
> for sub, criteria in self.subscribers.items():
> if criteria(msg):
> sub.handle(msg)
> 
> p = Publisher()
> p.subscribe(sub, lambda x: all(r > 3 for r in x.ratings))
> 
> # So what I needed is:
> p.subscribe(sub, lambda x: set(r > 3 for r in x.ratings) > 50)
> # Note, that elements might not necessarily be bool.
> # E.g. at least 51 non-empty pages
> p.subscribe(sub, lambda x: set(bool(p) for p in x.pages) > 50)
> # So the function:
> p.subscribe(sub, lambda x: xor_more_than(x.pages, 50)
> # would ideally deal with truth values too.
> The question is: can you construct a function? which:
> a) performs: lambda x: set(bool(el) for el in iterable) > n
> b) is in line with performance of python’s `all`
> 
> Then, as I said the case where one would need `set() == n` is hard to think 
> of, but it seems fairly probable to need `set() > n` and `set() < n`.
> 
> Regards,
> DG
> 
>> On 15 Nov 2023, at 19:16, Peter J. Holzer via Python-list 
>> mailto:python-list@python.org>> wrote:
>> 
>> On 2023-11-15 12:26:32 +0200, Dom Grigonis wrote:
>>> 
>>> Thank you,
>>> 
>>> 
>>> test2 = [True] * 100 + [False] * 2
>>> test2i = list(range(100))
>>> 
>>> %timeit len(set(test2i)) == 1   # 1.6 µs ± 63.6 ns per loop (mean ± std. 
>>> dev. of 7 runs, 1,000,000 loops each)
>>> %timeit all(test2)  # 386 ns ± 9.58 ns per loop (mean ± std. 
>>> dev. of 7 runs, 1,000,000 loops each)
>>> 
>>> test2s = set(test2i)
>>> %timeit len(test2s) == 1# 46.1 ns ± 1.65 ns per loop (mean ± std. 
>>> dev. of 7 runs, 10,000,000 loops each)
>>> 
>>> If you pre-convert to set it is obviously faster. However, set
>>> operation is most likely going to be part of the procedure. In which
>>> case it ends up to be significantly slower.
>> 
>> Obviously, if you convert a list to a set just to count the elements
>> it's going to be slow. My suggestion was to use the set *instead* of the
>> list. I don't know whether that's possible in your situation, because
>> you haven't told us anything about it. All I'm suggesting is taking a
>> step back and reconsider your choice of data structure.
>> 
>>hp
>> -- 
>>   _  | Peter J. Holzer| Story must make more sense than reality.
>> |_|_) ||
>> | |   | h...@hjp.at  |-- Charles Stross, 
>> "Creative writing
>> __/   | http://www.hjp.at/  |   challenge!"
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list 
>> 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

The specific situation was related to truth values and following out of that my 
considerations regarding equivalent of all and any for counting `truths`.

So one of the specific examples:
class Publisher:
def __init__(self):
self.subscribers = dict()

def subscribe(self, sub, criteria, agg=all):
self.subscribers[sub] = (criteria, agg)

def publish(self, msg):
for sub, criteria in self.subscribers.items():
if criteria(msg):
sub.handle(msg)

p = Publisher()
p.subscribe(sub, lambda x: all(r > 3 for r in x.ratings))

# So what I needed is:
p.subscribe(sub, lambda x: set(r > 3 for r in x.ratings) > 50)
# Note, that elements might not necessarily be bool.
# E.g. at least 51 non-empty pages
p.subscribe(sub, lambda x: set(bool(p) for p in x.pages) > 50)
# So the function:
p.subscribe(sub, lambda x: xor_more_than(x.pages, 50)
# would ideally deal with truth values too.
The question is: can you construct a function? which:
a) performs: lambda x: set(bool(el) for el in iterable) > n
b) is in line with performance of python’s `all`

Then, as I said the case where one would need `set() == n` is hard to think of, 
but it seems fairly probable to need `set() > n` and `set() < n`.

Regards,
DG

> On 15 Nov 2023, at 19:16, Peter J. Holzer via Python-list 
>  wrote:
> 
> On 2023-11-15 12:26:32 +0200, Dom Grigonis wrote:
>> 
>> Thank you,
>> 
>> 
>> test2 = [True] * 100 + [False] * 2
>> test2i = list(range(100))
>> 
>> %timeit len(set(test2i)) == 1   # 1.6 µs ± 63.6 ns per loop (mean ± std. 
>> dev. of 7 runs, 1,000,000 loops each)
>> %timeit all(test2)  # 386 ns ± 9.58 ns per loop (mean ± std. 
>> dev. of 7 runs, 1,000,000 loops each)
>> 
>> test2s = set(test2i)
>> %timeit len(test2s) == 1# 46.1 ns ± 1.65 ns per loop (mean ± std. 
>> dev. of 7 runs, 10,000,000 loops each)
>> 
>> If you pre-convert to set it is obviously faster. However, set
>> operation is most likely going to be part of the procedure. In which
>> case it ends up to be significantly slower.
> 
> Obviously, if you convert a list to a set just to count the elements
> it's going to be slow. My suggestion was to use the set *instead* of the
> list. I don't know whether that's possible in your situation, because
> you haven't told us anything about it. All I'm suggesting is taking a
> step back and reconsider your choice of data structure.
> 
>hp
> -- 
>   _  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Peter J. Holzer via Python-list]

On 2023-11-15 12:26:32 +0200, Dom Grigonis wrote:
> 
> Thank you,
> 
> 
> test2 = [True] * 100 + [False] * 2
> test2i = list(range(100))
> 
> %timeit len(set(test2i)) == 1   # 1.6 µs ± 63.6 ns per loop (mean ± std. dev. 
> of 7 runs, 1,000,000 loops each)
> %timeit all(test2)  # 386 ns ± 9.58 ns per loop (mean ± std. dev. 
> of 7 runs, 1,000,000 loops each)
> 
> test2s = set(test2i)
> %timeit len(test2s) == 1# 46.1 ns ± 1.65 ns per loop (mean ± std. 
> dev. of 7 runs, 10,000,000 loops each)
> 
> If you pre-convert to set it is obviously faster. However, set
> operation is most likely going to be part of the procedure. In which
> case it ends up to be significantly slower.

Obviously, if you convert a list to a set just to count the elements
it's going to be slow. My suggestion was to use the set *instead* of the
list. I don't know whether that's possible in your situation, because
you haven't told us anything about it. All I'm suggesting is taking a
step back and reconsider your choice of data structure.

hp
-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

Thank you,

test2 = [True] * 100 + [False] * 2
test2i = list(range(100))

%timeit len(set(test2i)) == 1   # 1.6 µs ± 63.6 ns per loop (mean ± std. dev. 
of 7 runs, 1,000,000 loops each)
%timeit all(test2)  # 386 ns ± 9.58 ns per loop (mean ± std. dev. 
of 7 runs, 1,000,000 loops each)

test2s = set(test2i)
%timeit len(test2s) == 1# 46.1 ns ± 1.65 ns per loop (mean ± std. dev. 
of 7 runs, 10,000,000 loops each)
If you pre-convert to set it is obviously faster. However, set operation is 
most likely going to be part of the procedure. In which case it ends up to be 
significantly slower.

Regards,
DG


> On 15 Nov 2023, at 02:34, Peter J. Holzer via Python-list 
>  wrote:
> 
> On 2023-11-14 00:11:30 +0200, Dom Grigonis via Python-list wrote:
>> Benchmarks:
>> test1 = [False] * 100 + [True] * 2
>> test2 = [True] * 100 + [False] * 2
>> 
>> TIMER.repeat([
>>lambda: xor(test1), # 0.0168
>>lambda: xor(test2), # 0.0172
>>lambda: xor_ss(test1),  # 0.1392
>>lambda: xor_ss(test2),  # 0.0084
>>lambda: xor_new(test1), # 0.0116
>>lambda: xor_new(test2), # 0.0074
>>lambda: all(test1), # 0.0016
>>lambda: all(test2)  # 0.0046
>> ])
>> Your first function is fairly slow.
>> Second one deals with short-circuiting, but is super slow on full search.
>> 
>> `xor_new` is the best what I could achieve using python builtins.
>> 
>> But builtin `all` has the best performance.
> 
> One question worth asking is if a list of bool is the best data
> structure for the job. This is essentially a bitmap, and a bitmap is
> equivalent to a set of integers. len(s) == 1 is also a fairly quick
> operation if s is small. On my system, len(test1s) == 1 (where test1s is
> {100, 101}) is about as fast as all(test1) and len(test2s) == 1 (where
> test2s is set(range(100))) is about twice as fast as all(test2).
> 
> If you are willing to stray from the standard library, you could e.g.
> use pyroaring instead of sets: This is about as fast as all(test1)
> whether there are two bits set or a hundred.
> 
>hp
> 
> -- 
>   _  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at  |-- Charles Stross, 
> "Creative writing
> __/   | http://www.hjp.at/  |   challenge!"
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Peter J. Holzer via Python-list]

On 2023-11-14 00:11:30 +0200, Dom Grigonis via Python-list wrote:
> Benchmarks:
> test1 = [False] * 100 + [True] * 2
> test2 = [True] * 100 + [False] * 2
> 
> TIMER.repeat([
> lambda: xor(test1), # 0.0168
> lambda: xor(test2), # 0.0172
> lambda: xor_ss(test1),  # 0.1392
> lambda: xor_ss(test2),  # 0.0084
> lambda: xor_new(test1), # 0.0116
> lambda: xor_new(test2), # 0.0074
> lambda: all(test1), # 0.0016
> lambda: all(test2)  # 0.0046
> ])
> Your first function is fairly slow.
> Second one deals with short-circuiting, but is super slow on full search.
> 
> `xor_new` is the best what I could achieve using python builtins.
> 
> But builtin `all` has the best performance.

One question worth asking is if a list of bool is the best data
structure for the job. This is essentially a bitmap, and a bitmap is
equivalent to a set of integers. len(s) == 1 is also a fairly quick
operation if s is small. On my system, len(test1s) == 1 (where test1s is
{100, 101}) is about as fast as all(test1) and len(test2s) == 1 (where
test2s is set(range(100))) is about twice as fast as all(test2).

If you are willing to stray from the standard library, you could e.g.
use pyroaring instead of sets: This is about as fast as all(test1)
whether there are two bits set or a hundred.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator (DEPRECATED)

[Dom Grigonis via Python-list]

Thank you, I have spent a fair bit of time on these and found optimal solutions 
(at least I think so), but they are still multiple times slower than python 
builtin function.

I am currently out of ideas, maybe will dig something out in time.

> On 14 Nov 2023, at 07:23, Thomas Passin via Python-list 
>  wrote:
> 
> On 11/13/2023 11:44 PM, AVI GROSS via Python-list wrote:
>> Dom,
>> I hear you.
>> As you say, writing your own extension in something like C++ may not appeal 
>> to you even if it is faster.
>> I was wondering if using a generator or something similar in R might make 
>> sense.
>> I mean what happens if you write a function that includes a "yield" or two 
>> and does a part of what you want. It maintains some internal state between 
>> invocations. So you can call it once to setup things then call it repeatedly 
>> to keep processing the next item. You stop calling it when you get a result 
>> you want, such as that it has seen what you want N times.
>> Since the code stays in memory, it may effectively run faster than some 
>> other kinds of functions calls. It can keep things in internal storage such 
>> as not just how many N you want but how many it has seen.
> 
> I'm inclined to just turn the iterable into a set to get the values, then 
> iterate through those values calling count() on a listified version of the 
> iterable. If the count >= target, return.
> 
> It may not be the fastest one could do but it's simple and probably pretty 
> fast for many uses.  I suppose that for some iterables it would be better not 
> to turn them into lists, but one could figure out about that after working 
> out more carefully what cases need to be covered.
> 
>> Your outer function can maintain a list of the items you want to XOR or 
>> generate a new one dynamically as needed. It can use functional programming 
>> techniques to create a new customized version of the iterator, such as with 
>> a value of N built in. You would then call the outer function and let it use 
>> the inner function till the result is available or until the data in the 
>> iterator runs out or perhaps other tweaks involving two way communication of 
>> sorts between the functions.
>> I am NOT suggesting this approach is optimal or fast but merely wondering if 
>> something along these lines is worth trying that might speed things up even 
>> if not very fast. Such approaches can be even more effective if what you are 
>> working on need not all be instantiated up front but can be dynamically 
>> calculated or incrementally read from files. With care, you can make 
>> multiple instantiations that each iterate over their own sets of data 
>> without interference.
>> Just a thought. In a sense, this can be a slightly decent substitute for the 
>> non-standard evaluation in R where you can arrange for lots of your data to 
>> not be interpreted till absolutely needed.
>> -Original Message-
>> From: Dom Grigonis 
>> Sent: Monday, November 13, 2023 10:12 PM
>> To: avi.e.gr...@gmail.com
>> Cc: Grant Edwards ; Python 
>> 
>> Subject: Re: xor operator (DEPRECATED)
>> Fair point. However, I gave it a shot for the following reason:
>> I couldn’t find a way to make such performant function. Using python builtin 
>> components still ends up several times slower than builtin `all`. Cython or 
>> numba or similar is not an option as they do not support `truth` values. Or 
>> if they do, it ends up slower than pure python variant.
>> So all what is left is writing a proper extension. Which I would prefer not 
>> to do for 1 function. I thought maybe `xor`, as in logical XOR functionality 
>> in its vanilla case could be compelling. And after doing a bit of search I 
>> see that very very few languages have that and it seems for a good reason.
>> Some that do: R, thats all I could find. Although some (if not many) went 
>> through the proposal phase. And yes, none of them have a function that I am 
>> proposing.
>> So yes, you are right, not a good proposal.
>> But there still seems to be the need for short-circuiting performant 
>> implementations in python space. The issue is that there are many variants 
>> of what might be needed while there is no efficient solution to sourcing 
>> predicates from python to lower level implementations. Someone mentioned 
>> that numpy experimented with such implementations in C, but they did not get 
>> anywhere with it.
>> The best I could come up with is cached numba for numpy problems, which does 
>> perform very well and more than worth it if function is re-used. It even 
>&g

Re: xor operator (DEPRECATED)

[Thomas Passin via Python-list]

On 11/13/2023 11:44 PM, AVI GROSS via Python-list wrote:

Dom,

I hear you.

As you say, writing your own extension in something like C++ may not appeal to 
you even if it is faster.

I was wondering if using a generator or something similar in R might make sense.

I mean what happens if you write a function that includes a "yield" or two and 
does a part of what you want. It maintains some internal state between invocations. So 
you can call it once to setup things then call it repeatedly to keep processing the next 
item. You stop calling it when you get a result you want, such as that it has seen what 
you want N times.

Since the code stays in memory, it may effectively run faster than some other 
kinds of functions calls. It can keep things in internal storage such as not 
just how many N you want but how many it has seen.


I'm inclined to just turn the iterable into a set to get the values, 
then iterate through those values calling count() on a listified version 
of the iterable. If the count >= target, return.


It may not be the fastest one could do but it's simple and probably 
pretty fast for many uses.  I suppose that for some iterables it would 
be better not to turn them into lists, but one could figure out about 
that after working out more carefully what cases need to be covered.



Your outer function can maintain a list of the items you want to XOR or 
generate a new one dynamically as needed. It can use functional programming 
techniques to create a new customized version of the iterator, such as with a 
value of N built in. You would then call the outer function and let it use the 
inner function till the result is available or until the data in the iterator 
runs out or perhaps other tweaks involving two way communication of sorts 
between the functions.

I am NOT suggesting this approach is optimal or fast but merely wondering if 
something along these lines is worth trying that might speed things up even if 
not very fast. Such approaches can be even more effective if what you are 
working on need not all be instantiated up front but can be dynamically 
calculated or incrementally read from files. With care, you can make multiple 
instantiations that each iterate over their own sets of data without 
interference.

Just a thought. In a sense, this can be a slightly decent substitute for the 
non-standard evaluation in R where you can arrange for lots of your data to not 
be interpreted till absolutely needed.



-Original Message-
From: Dom Grigonis 
Sent: Monday, November 13, 2023 10:12 PM
To: avi.e.gr...@gmail.com
Cc: Grant Edwards ; Python 
Subject: Re: xor operator (DEPRECATED)

Fair point. However, I gave it a shot for the following reason:

I couldn’t find a way to make such performant function. Using python builtin 
components still ends up several times slower than builtin `all`. Cython or 
numba or similar is not an option as they do not support `truth` values. Or if 
they do, it ends up slower than pure python variant.

So all what is left is writing a proper extension. Which I would prefer not to 
do for 1 function. I thought maybe `xor`, as in logical XOR functionality in 
its vanilla case could be compelling. And after doing a bit of search I see 
that very very few languages have that and it seems for a good reason.

Some that do: R, thats all I could find. Although some (if not many) went 
through the proposal phase. And yes, none of them have a function that I am 
proposing.

So yes, you are right, not a good proposal.

But there still seems to be the need for short-circuiting performant 
implementations in python space. The issue is that there are many variants of 
what might be needed while there is no efficient solution to sourcing 
predicates from python to lower level implementations. Someone mentioned that 
numpy experimented with such implementations in C, but they did not get 
anywhere with it.

The best I could come up with is cached numba for numpy problems, which does 
perform very well and more than worth it if function is re-used. It even ends 
up faster than cython or cffi extensions, however can’t have many of those due 
to JIT and AOT is currently being deprecated (which wouldn’t solve anything 
anyway). However, as I mentioned earlier it does not apply to this case.

So it’s either:
a) Something very clever and flexible implemented that covers most of such 
needs and doesn’t require predicates.
b) I welcome any thoughts on this.

DG


On 14 Nov 2023, at 04:27, AVI GROSS via Python-list  
wrote:

I was going to ask a dumb question. Has any other language you know of made
something available that does what is being asked for and included it in the
main program environment rather than an add-on?

A secondary mention here has been whether short-circuiting functions like
"any" and "all" have been augmented with something like "has_n" that
evaluates arguments till it has found n or perhaps n+1 of 

RE: xor operator (DEPRECATED)

[AVI GROSS via Python-list]

Dom,

I hear you.

As you say, writing your own extension in something like C++ may not appeal to 
you even if it is faster.

I was wondering if using a generator or something similar in R might make sense.

I mean what happens if you write a function that includes a "yield" or two and 
does a part of what you want. It maintains some internal state between 
invocations. So you can call it once to setup things then call it repeatedly to 
keep processing the next item. You stop calling it when you get a result you 
want, such as that it has seen what you want N times.

Since the code stays in memory, it may effectively run faster than some other 
kinds of functions calls. It can keep things in internal storage such as not 
just how many N you want but how many it has seen.

Your outer function can maintain a list of the items you want to XOR or 
generate a new one dynamically as needed. It can use functional programming 
techniques to create a new customized version of the iterator, such as with a 
value of N built in. You would then call the outer function and let it use the 
inner function till the result is available or until the data in the iterator 
runs out or perhaps other tweaks involving two way communication of sorts 
between the functions.

I am NOT suggesting this approach is optimal or fast but merely wondering if 
something along these lines is worth trying that might speed things up even if 
not very fast. Such approaches can be even more effective if what you are 
working on need not all be instantiated up front but can be dynamically 
calculated or incrementally read from files. With care, you can make multiple 
instantiations that each iterate over their own sets of data without 
interference.

Just a thought. In a sense, this can be a slightly decent substitute for the 
non-standard evaluation in R where you can arrange for lots of your data to not 
be interpreted till absolutely needed.



-Original Message-
From: Dom Grigonis  
Sent: Monday, November 13, 2023 10:12 PM
To: avi.e.gr...@gmail.com
Cc: Grant Edwards ; Python 
Subject: Re: xor operator (DEPRECATED)

Fair point. However, I gave it a shot for the following reason:

I couldn’t find a way to make such performant function. Using python builtin 
components still ends up several times slower than builtin `all`. Cython or 
numba or similar is not an option as they do not support `truth` values. Or if 
they do, it ends up slower than pure python variant.

So all what is left is writing a proper extension. Which I would prefer not to 
do for 1 function. I thought maybe `xor`, as in logical XOR functionality in 
its vanilla case could be compelling. And after doing a bit of search I see 
that very very few languages have that and it seems for a good reason.

Some that do: R, thats all I could find. Although some (if not many) went 
through the proposal phase. And yes, none of them have a function that I am 
proposing.

So yes, you are right, not a good proposal.

But there still seems to be the need for short-circuiting performant 
implementations in python space. The issue is that there are many variants of 
what might be needed while there is no efficient solution to sourcing 
predicates from python to lower level implementations. Someone mentioned that 
numpy experimented with such implementations in C, but they did not get 
anywhere with it.

The best I could come up with is cached numba for numpy problems, which does 
perform very well and more than worth it if function is re-used. It even ends 
up faster than cython or cffi extensions, however can’t have many of those due 
to JIT and AOT is currently being deprecated (which wouldn’t solve anything 
anyway). However, as I mentioned earlier it does not apply to this case.

So it’s either:
a) Something very clever and flexible implemented that covers most of such 
needs and doesn’t require predicates.
b) I welcome any thoughts on this.

DG

> On 14 Nov 2023, at 04:27, AVI GROSS via Python-list  
> wrote:
> 
> I was going to ask a dumb question. Has any other language you know of made
> something available that does what is being asked for and included it in the
> main program environment rather than an add-on?
> 
> A secondary mention here has been whether short-circuiting functions like
> "any" and "all" have been augmented with something like "has_n" that
> evaluates arguments till it has found n or perhaps n+1 of what it wants then
> skips the rest. Does any language supply something like that? What would
> such a function return and does it have an "any" or an "all" side?
> 
> It sounds like if I asked if a list of integers has at least n prime numbers
> in "any" mode, it should ignore any that are not primes till it finds n
> primes or fails and returns true or false. If in "all" mode, I assume it
> would have to be the first n items without

Re: xor operator (DEPRECATED)

[Dom Grigonis via Python-list]

Fair point. However, I gave it a shot for the following reason:

I couldn’t find a way to make such performant function. Using python builtin 
components still ends up several times slower than builtin `all`. Cython or 
numba or similar is not an option as they do not support `truth` values. Or if 
they do, it ends up slower than pure python variant.

So all what is left is writing a proper extension. Which I would prefer not to 
do for 1 function. I thought maybe `xor`, as in logical XOR functionality in 
its vanilla case could be compelling. And after doing a bit of search I see 
that very very few languages have that and it seems for a good reason.

Some that do: R, thats all I could find. Although some (if not many) went 
through the proposal phase. And yes, none of them have a function that I am 
proposing.

So yes, you are right, not a good proposal.

But there still seems to be the need for short-circuiting performant 
implementations in python space. The issue is that there are many variants of 
what might be needed while there is no efficient solution to sourcing 
predicates from python to lower level implementations. Someone mentioned that 
numpy experimented with such implementations in C, but they did not get 
anywhere with it.

The best I could come up with is cached numba for numpy problems, which does 
perform very well and more than worth it if function is re-used. It even ends 
up faster than cython or cffi extensions, however can’t have many of those due 
to JIT and AOT is currently being deprecated (which wouldn’t solve anything 
anyway). However, as I mentioned earlier it does not apply to this case.

So it’s either:
a) Something very clever and flexible implemented that covers most of such 
needs and doesn’t require predicates.
b) I welcome any thoughts on this.

DG

> On 14 Nov 2023, at 04:27, AVI GROSS via Python-list  
> wrote:
> 
> I was going to ask a dumb question. Has any other language you know of made
> something available that does what is being asked for and included it in the
> main program environment rather than an add-on?
> 
> A secondary mention here has been whether short-circuiting functions like
> "any" and "all" have been augmented with something like "has_n" that
> evaluates arguments till it has found n or perhaps n+1 of what it wants then
> skips the rest. Does any language supply something like that? What would
> such a function return and does it have an "any" or an "all" side?
> 
> It sounds like if I asked if a list of integers has at least n prime numbers
> in "any" mode, it should ignore any that are not primes till it finds n
> primes or fails and returns true or false. If in "all" mode, I assume it
> would have to be the first n items without a failure.
> 
> Fine, but then someone may want to know WHERE you stopped or for you to
> return the sublist of the ones that made the match, or even return
> everything that was skipped so you can later process that. Consider a long
> list of jurors you process to place a dozen that qualify on a jury and then
> later you want to choose from among the rest for another jury.
> 
> Human minds can come up with an amazing number of ideas including for
> "useful" functions or features but I find the vast majority would rarely be
> used as nobody remembers it is available and some fairly simple method using
> other functions can easily be cobbled together.
> 
> -Original Message-
> From: Python-list  On
> Behalf Of Grant Edwards via Python-list
> Sent: Monday, November 13, 2023 8:19 PM
> To: python-list@python.org
> Subject: Re: xor operator
> 
> On 2023-11-14, Dom Grigonis via Python-list  wrote:
>> 
>>> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
>>> or and and applided to many bits. To do something "in line" with that
>>> using the 'xor' operator would return True for an odd number of True
>>> values and False for an even Number of True values.
>> 
>> Fair point.
>> 
>> Have you ever encountered the need for xor for many bits (the one
>> that I am NOT referring to)? Would be interested in what sort of
>> case it could be useful.
> 
> Yes, it's used all the time in low-level communications protocols,
> where it's often implemented in hardware. But, it is also not at all
> unusual to implement it in software.
> 
> It's also not that unusual for the "count-ones" part of the function
> you're asking for to be implemented in hardware by a CPU having an
> instruction that counts the number of 1 bits in a register.
> 
> GCC has a low-level builtins called __builtin_popcount() and
> __builtin-popcountl() that counts the number of 1's in an unsigned
> (long) int.
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: xor operator

[AVI GROSS via Python-list]

I was going to ask a dumb question. Has any other language you know of made
something available that does what is being asked for and included it in the
main program environment rather than an add-on?

A secondary mention here has been whether short-circuiting functions like
"any" and "all" have been augmented with something like "has_n" that
evaluates arguments till it has found n or perhaps n+1 of what it wants then
skips the rest. Does any language supply something like that? What would
such a function return and does it have an "any" or an "all" side?

It sounds like if I asked if a list of integers has at least n prime numbers
in "any" mode, it should ignore any that are not primes till it finds n
primes or fails and returns true or false. If in "all" mode, I assume it
would have to be the first n items without a failure.

Fine, but then someone may want to know WHERE you stopped or for you to
return the sublist of the ones that made the match, or even return
everything that was skipped so you can later process that. Consider a long
list of jurors you process to place a dozen that qualify on a jury and then
later you want to choose from among the rest for another jury.

Human minds can come up with an amazing number of ideas including for
"useful" functions or features but I find the vast majority would rarely be
used as nobody remembers it is available and some fairly simple method using
other functions can easily be cobbled together.

-Original Message-
From: Python-list  On
Behalf Of Grant Edwards via Python-list
Sent: Monday, November 13, 2023 8:19 PM
To: python-list@python.org
Subject: Re: xor operator

On 2023-11-14, Dom Grigonis via Python-list  wrote:
>
>> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
>> or and and applided to many bits. To do something "in line" with that
>> using the 'xor' operator would return True for an odd number of True
>> values and False for an even Number of True values.
>
> Fair point.
>
> Have you ever encountered the need for xor for many bits (the one
> that I am NOT referring to)? Would be interested in what sort of
> case it could be useful.

Yes, it's used all the time in low-level communications protocols,
where it's often implemented in hardware. But, it is also not at all
unusual to implement it in software.

It's also not that unusual for the "count-ones" part of the function
you're asking for to be implemented in hardware by a CPU having an
instruction that counts the number of 1 bits in a register.

GCC has a low-level builtins called __builtin_popcount() and
__builtin-popcountl() that counts the number of 1's in an unsigned
(long) int.


-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Grant Edwards via Python-list]

On 2023-11-14, Dom Grigonis via Python-list  wrote:
>
>> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
>> or and and applided to many bits. To do something "in line" with that
>> using the 'xor' operator would return True for an odd number of True
>> values and False for an even Number of True values.
>
> Fair point.
>
> Have you ever encountered the need for xor for many bits (the one
> that I am NOT referring to)? Would be interested in what sort of
> case it could be useful.

Yes, it's used all the time in low-level communications protocols,
where it's often implemented in hardware. But, it is also not at all
unusual to implement it in software.

It's also not that unusual for the "count-ones" part of the function
you're asking for to be implemented in hardware by a CPU having an
instruction that counts the number of 1 bits in a register.

GCC has a low-level builtins called __builtin_popcount() and
__builtin-popcountl() that counts the number of 1's in an unsigned
(long) int.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Chris Angelico via Python-list]

On Tue, 14 Nov 2023 at 11:40, Chris Angelico  wrote:
> Here's a couple of excellent videos on error correction, and you'll
> see XOR showing up as a crucial feature:
>
> https://www.youtube.com/watch?v=X8jsijhllIA
> https://www.youtube.com/watch?v=h0jloehRKas
>

I just flipped through that 3blue1brown video again, and as it turns
out, the actual part where he talks about multi-argument XOR happens
in part two (it's barely touched on at the very end as he's
introducing part two).

https://www.youtube.com/watch?v=b3NxrZOu_CE

Honestly though, the full video is well worth watching. More modern
error correction systems are slightly different, but will still be
built on many of the same principles.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Alan Gauld via Python-list]

On 14/11/2023 00:33, Mats Wichmann via Python-list wrote:
> Hardware and software people may have somewhat different views of xor

I've come at it from both sides. I started life as a telecomms
technician and we learned about xor in the context of switching
and relays and xor was a wiring configuration for scenarios where
you wanted any single change of switch state to toggle the
entire system (think a stairwell with switches on every
landing).

Later, I got into software engineering and we studied Boolean
algebra and xor was an odd number of Truth values, used in
parity tests (and in encryption).

But from both perspectives xor is pretty clearly defined
in how it operates and not, I suspect, what the OP really
wants in this case.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Chris Angelico via Python-list]

On Tue, 14 Nov 2023 at 12:02, Dom Grigonis via Python-list
 wrote:
> As I am here, I will dare to ask if there is no way that `sign` function is 
> going to be added to `math` or `builtins`.
>

https://docs.python.org/3/library/math.html#math.copysign

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

I agree, from perspective of standard `all` and `any` use cases this does not 
seem very useful.

However, in my experience it has its usages. E.g.:
* If sum(map(bool, iterable) [> | <] n can be useful. Counting dead processes 
and similar, optimisation problems where need to re-initialise if less than 
certain number of nodes reached certain threshold.
* If sum(map(bool, iterable) [== | !=] n is an edge case. Can’t even think of 
an example
* Finally, it would be a convenient shorthand for `bool(a) ^ bool(b)`

I sometimes think that there is also a case when certain function is not in 
one’s mind he doesn’t see the usefulness, but sometimes the sheer knowledge of 
its existence can twist certain situations in a positive manner.

What about an alternative, which does seem more useful:

def count_compare(iterable, n):
return np.sign(sum(map(bool, iterable)) - n)

print(count_compare([False, False, False], 1))
As I am here, I will dare to ask if there is no way that `sign` function is 
going to be added to `math` or `builtins`. `np.sign` does the trick, but it is 
very slow to be used on a single number. And yes, I know that `copysign` 
exists, it just doesn’t do the same thing.

DG

> On 14 Nov 2023, at 02:33, Mats Wichmann via Python-list 
>  wrote:
> 
> On 11/13/23 16:24, Dom Grigonis via Python-list wrote:
>> I am not arguing that it is a generalised xor.
>> I don’t want anything, I am just gauging if it is specialised or if there is 
>> a need for it. So just thought could suggest it as I have encountered such 
>> need several times already.
>> It is fairly clear by now that it is not a common one given it took some 
>> time to even convey what I mean. Bad naming didn’t help ofc, but if it was 
>> something that is needed I think it would have clicked much faster.
> 
> There are things that If You Need Them You Know, and If You Do Not You Do Not 
> Understand - and you seem to have found one.  The problem is that forums like 
> this are not a statistically great sampling mechanism - a few dozen people, 
> perhaps, chime in on many topics; there are millions of people using Python. 
> Still, the folks here like to think they're at least somewhat representative 
> :)
> 
> Hardware and software people may have somewhat different views of xor, so 
> *maybe* the topic title added a bit to the muddle.  To me (one of those 
> millions), any/all falsy, any/all truthy have some interest, and Python does 
> provide those. Once you get into How Many True question - whether that's the 
> odd-is-true, even-is-false model, or the bail-after-X-truthy-values model, 
> it's not terribly interesting to me: once it gets more complex than an 
> all/any decision, I need to check for particular combinations specifically. 
> Two-of-six means nothing to me until I know which combination of two it is.
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Chris Angelico via Python-list]

On Tue, 14 Nov 2023 at 11:29, Dom Grigonis via Python-list
 wrote:
>
>
> > Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
> > or and and applided to many bits. To do something "in line" with that
> > using the 'xor' operator would return True for an odd number of True
> > values and False for an even Number of True values.
>
> Fair point.
>
> Have you ever encountered the need for xor for many bits (the one that I am 
> NOT referring to)? Would be interested in what sort of case it could be 
> useful.

Yes, parity checking. That's why I namedropped that in my prior
response - it's an easy thing to search the web for if you want to
know more about it.

Here's a couple of excellent videos on error correction, and you'll
see XOR showing up as a crucial feature:

https://www.youtube.com/watch?v=X8jsijhllIA
https://www.youtube.com/watch?v=h0jloehRKas

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Michael Speer via Python-list]

>AFAICT, it's not nothing at all to do with 'xor' in any sense.

As much as I agree that the function needn't be in the base of python, I
can easily follow the OP's logic on the function name.

With two items in the iterator, it is a standard binary exclusive or.

It is true if one of but not both of the items is true.

OP then generalized this to is exclusively one of any number of these
options are true, which is different than the repetitious binary operator
application, certainly, but is still very much an 'or' that excludes the
case of other options being true.

OP then generalized this from exclusively one truth in the set of variables
to some other specific number of truths that need be.

I expect the OP could then generalize this to a range of truthiness for the
set with a minimum and maximum allowable truthiness, and probably a key
function to extract some facet from the iterable for consideration.

I understand why you find it disagreeable, but I cannot find it necessarily
illogical, and it is easy, I think, to see what it has to do with xor.

A better name for OP's generalization, however, could likely be 'aut', from
the Latin exclusive or.


On Mon, Nov 13, 2023 at 7:20 PM Grant Edwards via Python-list <
python-list@python.org> wrote:

> On 2023-11-13, Dom Grigonis via Python-list 
> wrote:
>
> > I am not asking. Just inquiring if the function that I described
> > could be useful for more people.
> >
> > Which is: a function with API that of `all` and `any` and returns
> > `True` if specified number of elements is True.
>
> I've got no objection to a function that counts True objects returned
> by an iterator and returns True IFF count == .
>
> I've got no objection to a function that counts True objects returned
> by an iterator and returns True IFF count >= .
>
> I've got no objection if that latter function short-circuits by
> stopping the iteration and returning True when it has seen  true
> objects.
>
> I don't recall ever having a need for such a function in the 25 years
> I've been writing Python code, but I'm not going to claim that nobody
> else has a need for such a function.
>
> I would object to that being called 'xor', and would fight to the
> death (yes, I'm being hyperbolic) the addition of a builtin with the
> name 'xor' that does what you describe.
>
> > It is not a generalised `xor` in strict programatic space.
>
> AFAICT, it's not nothing at all to do with 'xor' in any sense.
>
> > I.e. NOT bitwise xor applied to many bits.  This is more in line
> > with cases that `any` and `all` builtins are used.
>
> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
> or and and applided to many bits. To do something "in line" with that
> using the 'xor' operator would return True for an odd number of True
> values and False for an even Number of True values.
>
> --
> Grant
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Mats Wichmann via Python-list]

On 11/13/23 16:24, Dom Grigonis via Python-list wrote:

I am not arguing that it is a generalised xor.

I don’t want anything, I am just gauging if it is specialised or if there is a 
need for it. So just thought could suggest it as I have encountered such need 
several times already.

It is fairly clear by now that it is not a common one given it took some time 
to even convey what I mean. Bad naming didn’t help ofc, but if it was something 
that is needed I think it would have clicked much faster.


There are things that If You Need Them You Know, and If You Do Not You 
Do Not Understand - and you seem to have found one.  The problem is that 
forums like this are not a statistically great sampling mechanism - a 
few dozen people, perhaps, chime in on many topics; there are millions 
of people using Python. Still, the folks here like to think they're at 
least somewhat representative :)


Hardware and software people may have somewhat different views of xor, 
so *maybe* the topic title added a bit to the muddle.  To me (one of 
those millions), any/all falsy, any/all truthy have some interest, and 
Python does provide those. Once you get into How Many True question - 
whether that's the odd-is-true, even-is-false model, or the 
bail-after-X-truthy-values model, it's not terribly interesting to me: 
once it gets more complex than an all/any decision, I need to check for 
particular combinations specifically. Two-of-six means nothing to me 
until I know which combination of two it is.



--
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
> or and and applided to many bits. To do something "in line" with that
> using the 'xor' operator would return True for an odd number of True
> values and False for an even Number of True values.

Fair point.

Have you ever encountered the need for xor for many bits (the one that I am NOT 
referring to)? Would be interested in what sort of case it could be useful.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Grant Edwards via Python-list]

On 2023-11-13, Dom Grigonis via Python-list  wrote:

> I am not asking. Just inquiring if the function that I described
> could be useful for more people.
>
> Which is: a function with API that of `all` and `any` and returns
> `True` if specified number of elements is True.

I've got no objection to a function that counts True objects returned
by an iterator and returns True IFF count == .

I've got no objection to a function that counts True objects returned
by an iterator and returns True IFF count >= .

I've got no objection if that latter function short-circuits by
stopping the iteration and returning True when it has seen  true
objects.

I don't recall ever having a need for such a function in the 25 years
I've been writing Python code, but I'm not going to claim that nobody
else has a need for such a function.

I would object to that being called 'xor', and would fight to the
death (yes, I'm being hyperbolic) the addition of a builtin with the
name 'xor' that does what you describe.

> It is not a generalised `xor` in strict programatic space.

AFAICT, it's not nothing at all to do with 'xor' in any sense.

> I.e. NOT bitwise xor applied to many bits.  This is more in line
> with cases that `any` and `all` builtins are used.

Except the 'any' and 'all' builtins are _exactly_ the same as bitwise
or and and applided to many bits. To do something "in line" with that
using the 'xor' operator would return True for an odd number of True
values and False for an even Number of True values.

--
Grant
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

I am not arguing that it is a generalised xor.

I don’t want anything, I am just gauging if it is specialised or if there is a 
need for it. So just thought could suggest it as I have encountered such need 
several times already.

It is fairly clear by now that it is not a common one given it took some time 
to even convey what I mean. Bad naming didn’t help ofc, but if it was something 
that is needed I think it would have clicked much faster.

Thanks,
DG

> On 14 Nov 2023, at 01:12, Chris Angelico via Python-list 
>  wrote:
> 
> On Tue, 14 Nov 2023 at 10:00, Dom Grigonis via Python-list
>  wrote:
>> 
>> I am not asking. Just inquiring if the function that I described could be 
>> useful for more people.
>> 
>> Which is: a function with API that of `all` and `any` and returns `True` if 
>> specified number of elements is True.
>> 
>> It is not a generalised `xor` in strict programatic space. I.e. NOT bitwise 
>> xor applied to many bits.
>> This is more in line with cases that `any` and `all` builtins are used.
>> 
> 
> A generalization of XOR is exactly what Grant and I said, though: a
> parity check. See for example:
> 
> https://en.wikipedia.org/wiki/Exclusive_or
> https://reference.wolfram.com/language/ref/Xor.html
> 
> It tells you whether you have an odd or even number of true values.
> 
> Now, if you want something that short-circuits a counting function,
> that's definitely doable, but it's a sum-and-compare, not xor. Also,
> it's quite specialized so it's unlikely to end up in the stdlib.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Chris Angelico via Python-list]

On Tue, 14 Nov 2023 at 10:00, Dom Grigonis via Python-list
 wrote:
>
> I am not asking. Just inquiring if the function that I described could be 
> useful for more people.
>
> Which is: a function with API that of `all` and `any` and returns `True` if 
> specified number of elements is True.
>
> It is not a generalised `xor` in strict programatic space. I.e. NOT bitwise 
> xor applied to many bits.
> This is more in line with cases that `any` and `all` builtins are used.
>

A generalization of XOR is exactly what Grant and I said, though: a
parity check. See for example:

https://en.wikipedia.org/wiki/Exclusive_or
https://reference.wolfram.com/language/ref/Xor.html

It tells you whether you have an odd or even number of true values.

Now, if you want something that short-circuits a counting function,
that's definitely doable, but it's a sum-and-compare, not xor. Also,
it's quite specialized so it's unlikely to end up in the stdlib.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

I am not asking. Just inquiring if the function that I described could be 
useful for more people.

Which is: a function with API that of `all` and `any` and returns `True` if 
specified number of elements is True.

It is not a generalised `xor` in strict programatic space. I.e. NOT bitwise xor 
applied to many bits.
This is more in line with cases that `any` and `all` builtins are used.

> On 14 Nov 2023, at 00:51, Grant Edwards via Python-list 
>  wrote:
> 
> On 2023-11-13, Dom Grigonis via Python-list  wrote:
>> Hi All,
>> 
>> I think it could be useful to have `xor` builtin, which has API similar to 
>> the one of `any` and `all`.
>> 
>> * Also, it could have optional second argument `n=1`, which
>> * indicates how many positives indicates `True` return.  For
>> * complete flexibility 3rd argument could indicate if `the number`
>> * is equal, greater, less, ... than `n`
> 
> I would expect "xor" to return true if there are an odd number of
> trues, and false if there are an even number of trues.  It's not clear
> to me what you're asking for.
> 
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Grant Edwards via Python-list]

On 2023-11-13, Dom Grigonis via Python-list  wrote:
> Hi All,
>
> I think it could be useful to have `xor` builtin, which has API similar to 
> the one of `any` and `all`.
>
> * Also, it could have optional second argument `n=1`, which
> * indicates how many positives indicates `True` return.  For
> * complete flexibility 3rd argument could indicate if `the number`
> * is equal, greater, less, ... than `n`

I would expect "xor" to return true if there are an odd number of
trues, and false if there are an even number of trues.  It's not clear
to me what you're asking for.



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

Benchmarks:
test1 = [False] * 100 + [True] * 2
test2 = [True] * 100 + [False] * 2

TIMER.repeat([
lambda: xor(test1), # 0.0168
lambda: xor(test2), # 0.0172
lambda: xor_ss(test1),  # 0.1392
lambda: xor_ss(test2),  # 0.0084
lambda: xor_new(test1), # 0.0116
lambda: xor_new(test2), # 0.0074
lambda: all(test1), # 0.0016
lambda: all(test2)  # 0.0046
])
Your first function is fairly slow.
Second one deals with short-circuiting, but is super slow on full search.

`xor_new` is the best what I could achieve using python builtins.

But builtin `all` has the best performance.

DG

> On 13 Nov 2023, at 23:20, Michael Speer  wrote:
> 
> I don't think an exclusive-or/truthy-entries-count-checker needs to be a 
> builtin by any stretch.
> 
> >>> def xor( iterable, n = 1 ):
> ... return sum( map( bool, iterable ) ) == n
> 
> Or if you insist on short circuiting:
> 
> >>> def xor_ss( iterable, n = 1 ):
> ...   for intermediate in itertools.accumulate( iterable, (lambda x, y: x + 
> bool(y)), initial = 0 ):
> ... if intermediate > n:
> ...   return False
> ...   return intermediate == n
> 
> 
> 
> On Mon, Nov 13, 2023 at 4:05 PM Barry via Python-list  > wrote:
> 
> 
> > On 13 Nov 2023, at 17:48, Dom Grigonis  > > wrote:
> > 
> > Short circuiting happens, when:
> > xor([True, True, False, False], n=1)
> > At index 1 it is clear that the answer is false.
> 
> Can you share an example with 4 values that is true?
> And explain why it is xor.
> 
> Barry
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Chris Angelico via Python-list]

On Tue, 14 Nov 2023 at 08:57, Axel Reichert via Python-list
 wrote:
>
> Barry  writes:
>
> > I do not understand how xor(iterator) works.
> > I thought xor takes exactly 2 args.
>
> See
>
>   https://mathworld.wolfram.com/XOR.html
>
> for some background (I was not aware of any generalizations for more
> than 2 arguments either).
>

Generalization to more arguments usually means calculating parity -
that is, it tells you whether you have an odd or even number of true
results. Which means that short-circuiting is nonsensical.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Axel Reichert via Python-list]

Barry  writes:

> I do not understand how xor(iterator) works.
> I thought xor takes exactly 2 args.

See

  https://mathworld.wolfram.com/XOR.html

for some background (I was not aware of any generalizations for more
than 2 arguments either).

> I also do not understand how xor can be short circuited.

Me neither, but that could be related to the meaning of n (which I did
not get) in the OP's question. Maybe he can clarify.

Best regards

Axel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

xor([True, False, False, False], n=1)
xor([False, False, False, True], n=1)
Both of the above would evaluate to true.

Well, it depends how you interpret it.
In binary case it reads: “exclusively one positive bit or the other, but not 
both”
In this case one could read: “exclusively one positive set of certain length, 
but not more than one such set at the same time" 

But I completely see how one could argue, that “exclusive” refers to slightly 
different thing. And multivariate `xor` is a function which defines fixed 
subsets out of which only one is true, but not the others, but this is 
theoretical, as in practice each set would need to always have all values 
switched on or off, which boils down to my proposed `xor` with `n=1`.

But the point is if there is a need for such function or I am the only one who 
happens to use it.

DG

> On 13 Nov 2023, at 23:03, Barry  wrote:
> 
> 
> 
>> On 13 Nov 2023, at 17:48, Dom Grigonis  wrote:
>> 
>> Short circuiting happens, when:
>> xor([True, True, False, False], n=1)
>> At index 1 it is clear that the answer is false.
> 
> Can you share an example with 4 values that is true?
> And explain why it is xor.
> 
> Barry
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[MRAB via Python-list]

On 2023-11-13 21:03, Barry via Python-list wrote:




On 13 Nov 2023, at 17:48, Dom Grigonis  wrote:

Short circuiting happens, when:
xor([True, True, False, False], n=1)
At index 1 it is clear that the answer is false.


Can you share an example with 4 values that is true?
And explain why it is xor.

I think what the OP wants is something that stops after finding n true 
items.


It's a more general form of what 'any' and 'all' do - 'any' stops when 
it finds 1 true item and 'all' stops when it finds 1 false item.


In general, you might want to stop when you find n true items or n false 
items, or whatever.


--
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Michael Speer via Python-list]

I don't think an exclusive-or/truthy-entries-count-checker needs to be a
builtin by any stretch.

>>> def xor( iterable, n = 1 ):
... return sum( map( bool, iterable ) ) == n

Or if you insist on short circuiting:

>>> def xor_ss( iterable, n = 1 ):
...   for intermediate in itertools.accumulate( iterable, (lambda x, y: x +
bool(y)), initial = 0 ):
... if intermediate > n:
...   return False
...   return intermediate == n



On Mon, Nov 13, 2023 at 4:05 PM Barry via Python-list <
python-list@python.org> wrote:

>
>
> > On 13 Nov 2023, at 17:48, Dom Grigonis  wrote:
> >
> > Short circuiting happens, when:
> > xor([True, True, False, False], n=1)
> > At index 1 it is clear that the answer is false.
>
> Can you share an example with 4 values that is true?
> And explain why it is xor.
>
> Barry
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Barry via Python-list]

> On 13 Nov 2023, at 17:48, Dom Grigonis  wrote:
> 
> Short circuiting happens, when:
> xor([True, True, False, False], n=1)
> At index 1 it is clear that the answer is false.

Can you share an example with 4 values that is true?
And explain why it is xor.

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Dom Grigonis via Python-list]

Well yes, I don’t think naming is very accurate. If iterable has 2 elements, 
then it is `xor`, otherwise it is something else - it checks the number of 
truth values in iterable.

Short circuiting happens, when:
xor([True, True, False, False], n=1)
At index 1 it is clear that the answer is false.

Regards,
DG

> On 13 Nov 2023, at 19:42, Barry  wrote:
> 
> 
> 
>> On 13 Nov 2023, at 15:16, Dom Grigonis via Python-list 
>>  wrote:
>> 
>> I think it could be useful to have `xor` builtin, which has API similar to 
>> the one of `any` and `all`.
> 
> I do not understand how xor(iterator) works.
> I thought xor takes exactly 2 args.
> 
> I also do not understand how xor can be short circuited.
> For AND or OR only looking at the first arg works.
> But that does not work for xor right?
> 
> Barry
> 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xor operator

[Barry via Python-list]

> On 13 Nov 2023, at 15:16, Dom Grigonis via Python-list 
>  wrote:
> 
> I think it could be useful to have `xor` builtin, which has API similar to 
> the one of `any` and `all`.

I do not understand how xor(iterator) works.
I thought xor takes exactly 2 args.

I also do not understand how xor can be short circuited.
For AND or OR only looking at the first arg works.
But that does not work for xor right?

Barry


-- 
https://mail.python.org/mailman/listinfo/python-list

xor operator

[Dom Grigonis via Python-list]

Hi All,

I think it could be useful to have `xor` builtin, which has API similar to the 
one of `any` and `all`.

* Also, it could have optional second argument `n=1`, which indicates how many 
positives indicates `True` return.
* For complete flexibility 3rd argument could indicate if `the number` is 
equal, greater, less, ... than `n`

I find I sometimes need it when dealing with pub-sub filters and multiple 
predicates in general.

What is the current situation that led me to writing this e-mail?
Dealing with circular import in low level component space: library builtins 
depend on validation utilities, while validation utilities want to use xor from 
library builtins.

Not a big issue, but seen there are fairly large threads in stack everyone 
inventing their own `xor`. And surprisingly there aren’t many good solutions. 
Almost none of them deal with short-circuiting well. And those that do contain 
loops that result in very poor performance.


Regards,
DG
-- 
https://mail.python.org/mailman/listinfo/python-list