Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Deliver yesterday, code today, think tomorrow.


devel / comp.lang.python / Re: xor operator (DEPRECATED)

SubjectAuthor
o Re: xor operator (DEPRECATED)Dom Grigonis

1
Re: xor operator (DEPRECATED)

<mailman.244.1699942763.3828.python-list@python.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=24464&group=comp.lang.python#24464

  copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!not-for-mail
From: dom.grig...@gmail.com (Dom Grigonis)
Newsgroups: comp.lang.python
Subject: Re: xor operator (DEPRECATED)
Date: Tue, 14 Nov 2023 08:19:19 +0200
Lines: 181
Message-ID: <mailman.244.1699942763.3828.python-list@python.org>
References: <2624DD04-097A-48B1-9F05-C6EF30F4C82D@gmail.com>
<6552a859.020a0220.8cb14.012f@mx.google.com>
<78B43ECD-2EFC-4CDF-99C4-DC310F0B26DE@gmail.com>
<6552bcca.050a0220.216c3.01b1@mx.google.com>
<BC709B8F-F154-4FE3-9C18-E167A78A02FA@gmail.com>
<6552cb0e.020a0220.4a172.0253@mx.google.com>
<00f301da16a2$16313e90$4293bbb0$@gmail.com>
<5F698B60-6387-44FF-83B2-853601F11177@gmail.com>
<010c01da16b5$3b303e40$b190bac0$@gmail.com>
<c829a5a0-e1b6-4943-be1b-ece97d0f8c64@tompassin.net>
<86188759-8055-41C8-8C26-EE77F2CB79A0@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Trace: news.uni-berlin.de Ok1H6SFR2CimYcahIYaeBAX12GN2WxVr0+MlIIwufeoQ==
Cancel-Lock: sha1:dh+37FglKt96zYXELiFVNNNQaCY= sha256:3cV6pSAR6bHp8R2HUe/lbwJiKjsO3srD7p1VoLbs9RM=
Return-Path: <dom.grigonis@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=gmail.com header.i=@gmail.com header.b=inQZaVE+;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: OK 0.000
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; '(which': 0.04; 'fairly':
0.05; '2023': 0.07; 'class="">': 0.07; 'couldn\xe2\x80\x99t':
0.07; 'cpu': 0.07; 'reason:': 0.07; 'that?': 0.07; '!important;"':
0.09; 'approaches': 0.09; 'cc:addr:python-list': 0.09;
'effectively': 0.09; 'fails': 0.09; 'numpy': 0.09; 'rarely': 0.09;
'shot': 0.09; 'skip:_ 20': 0.09; 'values.': 0.09; 'cc:no real
name:2**0': 0.14; 'url:mailman': 0.15; 'that.': 0.15; '"in': 0.16;
'"useful"': 0.16; '&gt;=': 0.16; '11:44': 0.16; '>>>>': 0.16;
'>>>>>': 0.16; 'arguments': 0.16; 'augmented': 0.16; 'avi': 0.16;
'bits': 0.16; 'builtin': 0.16; 'c++': 0.16; 'class="">it': 0.16;
'customized': 0.16; 'extensions,': 0.16; 'false.': 0.16;
'functions.': 0.16; 'gross': 0.16; 'hardware.': 0.16; 'involving':
0.16; 'iterable': 0.16; 'iterate': 0.16; 'jit': 0.16; 'line"':
0.16; 'low-level': 0.16; 'odd': 0.16; 'optimal': 0.16; 'outer':
0.16; 'prime': 0.16; 'primes': 0.16; 'reason.': 0.16;
'received:apple': 0.16; 'received:smtpclient.apple': 0.16;
'seen.': 0.16; 'sounds': 0.16; 'thats': 0.16; 'unsigned': 0.16;
'useful.': 0.16; 'values,': 0.16; 'want,': 0.16;
'wouldn\xe2\x80\x99t': 0.16; 'wrote:<span': 0.16; 'wrote:': 0.16;
'python': 0.16; 'values': 0.17; 'grant': 0.17; 'probably': 0.17;
'message-id:@gmail.com': 0.18; 'solve': 0.19; 'figure': 0.19;
'hardware': 0.19; 'helvetica;': 0.19; 'implement': 0.19; 'pm,':
0.19; 'cc:addr:python.org': 0.20; 'option': 0.20; 'issue': 0.21;
'language': 0.21; 'languages': 0.22; 'maybe': 0.22; 'returns':
0.22; 'version': 0.23; 'code': 0.23; 'lines': 0.23; 'run': 0.23;
'anything': 0.25; 'skip:- 10': 0.25; 'url-ip:188.166.95.178/32':
0.25; 'url-ip:188.166.95/24': 0.25; 'extension': 0.25;
'url:listinfo': 0.25; 'cc:2**0': 0.25; 'programming': 0.25; 'url-
ip:188.166/16': 0.25; 'seems': 0.26; 'do,': 0.26; 'perform': 0.26;
'bit': 0.27; 'function': 0.27; '>>>': 0.28; 'email
addr:python.org&gt;': 0.28; 'ideas': 0.28; 'environment': 0.29;
'asked': 0.29; 'approach': 0.31; 'url-ip:188/8': 0.31;
'interpreted': 0.69; 'none;"': 0.69; 'repeatedly': 0.69; 'vast':
0.69; 'times': 0.69; 'solutions': 0.70; 'front': 0.70; 'you.':
0.71; 'ignore': 0.71; 'speed': 0.71; 'float:': 0.74; 'features':
0.75; 'finds': 0.76; 'implemented': 0.76; 'mode,': 0.76; 'sent:':
0.78; 'effective': 0.78; 'spent': 0.81; 'unusual': 0.81; 'left':
0.83; 'href=""': 0.84; 'happens': 0.84; 'absolutely': 0.84;
'calls.': 0.84; 'decent': 0.84; 'dom': 0.84; 'dozen': 0.84; 'email
name:&lt;python-list': 0.84; 'inclined': 0.84; 'jury': 0.84;
'maintains': 0.84; 'merely': 0.84; 'minds': 0.84; 'phase.': 0.84;
'qualify': 0.84; 'received:88': 0.84; 'say,': 0.84; 'target,':
0.84; 'want.': 0.84; 'flexible': 0.91; 'return.': 0.91; 'stays':
0.91; 'storage': 0.95
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1699942761; x=1700547561; darn=python.org;
h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
:from:from:to:cc:subject:date:message-id:reply-to;
bh=dDRQHaOgUIw71EfMBjBZMmbzSoJ5hpaYJWjGeWL3FDw=;
b=inQZaVE+XS5XU3KlnzaKyXQkufNHnkGYs6uo3eBdQ7JeuH7ioNdtYe9PtJqAz9uOzI
zGmElpSFMldfxE+pIxRGf4EwpuCf0P55k+CsLy3gYPnk1eT8i+2PjcnSPeYzv5hVk6Gu
cFlLhj2+lHQCdFwsvENq//iZMdsYq6Pnxy6EHbmvl9yDI7PoXB+uR03R2tnFTlpYmI0+
k/kyvzS/wYakXSC1Sjd8AI2TPLrQL8LIv4ZRjjmKfxFKEhJahbrTjNPyId5+W5A4I52S
qdakUf5/pqjsHJzP0PVY6pLdCNKQFMQthKum+rCLv44R7Wqrw54aPa53ihfmATvE1ne5
yEsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1699942761; x=1700547561;
h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=dDRQHaOgUIw71EfMBjBZMmbzSoJ5hpaYJWjGeWL3FDw=;
b=pWvrrOY0LGASs9ZuVG9vri7k1ovUlsF4p1EVQd67jgHalD2PfWAtwNFgSbPFFGbDo+
GWAZ53bUTschLajUQGFXUj835cnCVV6xTLX7FFa7VTptT+GWQKt/y3xAsXMdopHVOU1g
0oEAjb3jeWLrAz2OGl6Uh/FhEG6A0qAAHB+uJs9dT5EGrehjc5w+ZxJ9j2JRSss3KX6f
S54YnjPe3z2BSftk/LNJvs7zhKdPrq8YgmmdQihFrkwRLtnL++1WfQEvy2qhTeyLQuGh
A4XvK7JROySrnSz1qlResDuZ7x4k417IatlB5GGzC8WJdBbY1zFiK2me+lzNqQTTa4i6
pgXg==
X-Gm-Message-State: AOJu0Yz4bd6//vC8G6shMwxBVRcBm6YsjwGFnPe9NYlILPJh0RGf+mIa
P3bQJzTuOB1svw7JRlAAK76lC1Dmwg471g==
X-Google-Smtp-Source: AGHT+IHslD+XrzEDsXfaW4qduEoH6wmg74HDeAUsVb+/dRzz20K96x2n13KMujoLYQclkt+ruTfoow==
X-Received: by 2002:ac2:4c9a:0:b0:500:7fc1:414b with SMTP id
d26-20020ac24c9a000000b005007fc1414bmr5590619lfl.25.1699942760706;
Mon, 13 Nov 2023 22:19:20 -0800 (PST)
In-Reply-To: <c829a5a0-e1b6-4943-be1b-ece97d0f8c64@tompassin.net>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
X-Content-Filtered-By: Mailman/MimeDel 2.1.39
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General discussion list for the Python programming language
<python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>,
<mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <https://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID: <86188759-8055-41C8-8C26-EE77F2CB79A0@gmail.com>
X-Mailman-Original-References: <2624DD04-097A-48B1-9F05-C6EF30F4C82D@gmail.com>
<6552a859.020a0220.8cb14.012f@mx.google.com>
<78B43ECD-2EFC-4CDF-99C4-DC310F0B26DE@gmail.com>
<6552bcca.050a0220.216c3.01b1@mx.google.com>
<BC709B8F-F154-4FE3-9C18-E167A78A02FA@gmail.com>
<6552cb0e.020a0220.4a172.0253@mx.google.com>
<00f301da16a2$16313e90$4293bbb0$@gmail.com>
<5F698B60-6387-44FF-83B2-853601F11177@gmail.com>
<010c01da16b5$3b303e40$b190bac0$@gmail.com>
<c829a5a0-e1b6-4943-be1b-ece97d0f8c64@tompassin.net>
 by: Dom Grigonis - Tue, 14 Nov 2023 06:19 UTC

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 <python-list@python.org> 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 <dom.grigonis@gmail.com>
>> Sent: Monday, November 13, 2023 10:12 PM
>> To: avi.e.gross@gmail.com
>> Cc: Grant Edwards <grant.b.edwards@gmail.com>; Python <python-list@python.org>
>> 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 <python-list@python.org> 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 <python-list-bounces+avi.e.gross=gmail.com@python.org> 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 <python-list@python.org> 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 <https://mail.python.org/mailman/listinfo/python-list>

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor