David Mertz wrote:
> Set union, however, has a great deal in common with bitwise-or
On the contrary, in mathematics there's the concept of direct sum of sets, and
the categorical sum, aka disjoint union. They are not union operations, but
similar. They have not named them "direct or" and "catego
Chris Angelico wrote:
> > Mathematically, the operator is ⊂. "<" operator is used for comparison, and
> > it's vital for sorting. And sorting sets makes no sense.
> Once again, you assert this. Do you have proof that it absolutely
> makes NO SENSE in any context, or just that you don't see value in
So why only mean and not median, that's better for statistics? :D
Seriously, if you want it builtin, add it to PYTHONSTARTUP:
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONSTARTUP
from statistics import mean
___
Python-ideas mailing list
Stephen J. Turnbull wrote:
> > from statistics import mean
> > sum([1e16,1,1])/3 == 1e16/3# surprise!
> > True
> > mean([1e16,1,1]) == 1e16/3
> > False
> > Regards,
Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01)
[GCC 9.2.1 20190909] on linux
Type "help", "copyright"
Random832 wrote:
> But sets also support symmetric difference ^, and intersection &. All the
> bitwise operators mean the same thing that they do for an integer imagined as
> a set of bit
> values. The use of - for difference is the odd one out
and?
__
Well, some days ago i didn't know about `statistics` module, so I
wrote my own median implementation, that I improved with the help of a
private discussion:
```
import math
def median(it, member=False, sort_fn=sorted, **kwargs):
if sort is None:
# Don't sort. Coder must be carefull to
Andrew Barnert wrote:
> > the operator is ⊂. "<" operator is used for
> > comparison, and it's vital for sorting.
> Yes. It’s the defining operation for the partial order in a poset (partially
> ordered set). And when studying posets generically, you always spell the
> operation <.
Nope.
Usuall
Richard Damon wrote:
> Note, this functions still has issues with NaN values, unless you change
> to use a sort function different than sorted
Well, yes. Indeed I wrote you can change the `sort_fn` parameter.
Anyway IMHO the best part of this function is that you don't need anymore the
biased m
IMHO, another sorted function, slower than it, should be added.
I don't know exactly how timsort works, but I know that it requires only
`__lt__()`.
So probably it checks, element by element, if `elem_b < elem_a`, and probably
exchange them if this is `1`. If `0`, it does nothing.
(Yes, `0` an
Well, Barnert, maybe you didn't understood my irony, so I speak more seriously.
This is extremely interesting, but **completely** OT.
We are discussing about the operator that potentially could merge in a future
two `dict`s.
I think this is OT also for the mailing list... but I think you could
Andrew Barnert wrote:
> I didn’t want to get into that, because I assumed you weren’t going to argue
> that
> <= makes sense for sets but < doesn’t
So you're telling about **strict** partial ordering. I can spend thousand of
words, but I think Python can speak for me:
```
(venv) marco@buzz:~/s
David Mertz wrote:
> Here is an implementation that:
> A. Only relies on '<'
Well, no. There's an `==` check.
Can you please read this 2 posts of mine?
https://mail.python.org/archives/list/python-ideas@python.org/message/7255SH6LSC266HAGI4SRJGV4JTUMMI4J/
https://mail.python.org/archives/list/py
David Mertz wrote:
> NaN is an IEEE-854 value, everything you
> mention is precisely identical of floats.
> Is your argument that we need to stop using the '<' operator for floats
> also?!
Nope, but I simply ignored in this case IEEE 754-2019 (that supersedes IEEE
854) and I raised an exception,
Andrew Barnert wrote:
> On Dec 26, 2019, at 12:19, Marco Sulla via Python-ideas
> python-ideas@python.org wrote:
> you can get the behavior of your algorithm below:
> @functools.cmp_to_key
> def flip_incomparables_key(a, b):
> if a < b: return -1
> if b <
Nope. flip_incomparables_key does not work, and neither my key. This one works:
```
import functools
@functools.cmp_to_key
def iliadSort(a, b):
if a < b:
res = -1
elif not b == b:
res = -1
else:
res = 0
return res
x = float("nan")
y = float("nan")
p
Andrew Barnert wrote:
> if you’re going to be a pedant, the floats in
> whatever Python you’re using right now are probably 854/754-1985 doubles, not
> 754-2019
> binary64s.
Mr. Andrew Barnet,
if pedant means adhere to the standard, yes, I'm a pedant.
> > This is because NaN, IMHO, it's not the
Steven D'Aprano wrote:
> Marco, you don't have to use median_low and median_high if you don't
> like them, but they aren't any worse than any other choice for
> calculating order statistics. All order statistics (apart from min and
> max) require you to sometimes make a choice between returning
It's very common to see:
```
for i, x in enumerate(sequence):
[...]
```
and also to see
```
for i in range(len(sequence)):
[...]
```
I propose to introduce for sequences the methods `indexes()` and `entries()`.
They are similar to `keys()` and `items()` for maps. I changed the names
David Mertz wrote:
> So we could get the Pandas-style behavior simply by calling median like so:
> statistics.median((x for x in it if not math.isnan(x)))
This is wrong. Or maybe potentially wrong.
This way you're removing items from the iterable, so you're moving the median.
If the NaNs are not
Oh my... Mertz, listen to me, you don't need a parameter. You only need a key
function to pass to `sorted()`
If you use this key function:
https://mail.python.org/archives/list/python-ideas@python.org/message/M3DEOZLA63Z5OIF6H6ZCEXK36GQMLVVA/
in my median() function:
https://mail.python.org/arch
Excuse me, but extraordinarily I agree with D'Aprano :D
Usually if you want the first element of an iterable, you have just to do:
```
it = iter(iterable)
first = next(it)
```
Yes, `first()` is really sexy... but a simple question: where is the iterator?
With the code above, I can continue to
their code because it slow down their applications like an old
man with the hat driving a camion in a street, and be happy. Sayonara.
> On Thu, Dec 26, 2019, 10:42 PM Marco Sulla via Python-ideas
> python-ideas@python.org wrote:
> > Oh my... Mertz, listen to me, you don't need
Steven, can you please remember me what operations can return NaN? I remember
for example 0/0 and +Infinity - +Infinity.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.p
Steven D'Aprano wrote:
> On Fri, Dec 27, 2019 at 02:22:48AM -0000, Marco Sulla via Python-ideas wrote:
> > It's very common to see:
> > for i, x in enumerate(sequence):
> > [...]
> >
> > Yes, that is very common, except that "sequence" ca
Excuse me Mr. Fine, can't you simply do `d2.update(c2)`???
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archi
Eric Fahlgren wrote:
> You apparently did not read the posts, because the point was whether it
> raises or returns a default value, not whether it saves one line or ten.
You apparently don't know Python:
```
next(iterator) # raises an exception if no more elements
next(iterator, _sentinel) # retu
On Wed, 4 Mar 2020 at 12:33, Chris Angelico wrote:
> Being able to easily distinguish "that isn't callable" from "the
> parameters don't line up" from "the function, during execution, raised
> TypeError" would be useful.
I **completely** agree. And I add that the change can also be
non-breaking,
On Wed, 11 Mar 2020 at 18:08, Serhiy Storchaka wrote:
> There is a precedence (although not in the stdlib): NumPy array with
> dtype=bool.
>
> >>> import numpy
> >>> bool(numpy.array([False, False]))
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: The truth v
I can be wrong, but for what I know, `del variable_name` does not
optimize the code, in the sense of performance. On the contrary, it
should slow it down, since it simply removes the binding between the
variable name from the namespace, allowing the gc to free the memory
if that variable was the la
On Thu, 12 Mar 2020 at 17:09, Christopher Barker wrote:
>> I was so used to have False for an empty iterable
> I hate to be pedantic, but it doesn't work for iterables anyway:
Yes, I know that it does not work for iterators. This is another problem :-)
> but If I really want to know if a sequen
On Thu, 12 Mar 2020 at 18:19, Chris Angelico wrote:
> No, it wouldn't - the use of the value as a return value counts as a
> reference. It's exactly the same as any other function that returns a
> brand-new value.
So the memory of that object will never free... since there's a
reference that can'
On Thu, 12 Mar 2020 at 17:42, Eric Wieser wrote:
> As an example of these optimizations being valuable, see
> https://github.com/numpy/numpy/pull/7997, which claims the optimization I
> described at the beginning resulted in a 1.5x-2x speedup.
This speedup is observed only for large objects. I
On Thu, 12 Mar 2020 at 19:05, Chris Angelico wrote:
> The action of deleting a *name* is not the same as disposing of an
> *object*. You can consider "del x" to be very similar to "x = None",
> except that instead of rebinding to some other object, it unbinds x
> altogether.
Exactly. But if `x =
On Thu, 12 Mar 2020 at 19:10, Andrew Barnert
wrote:
> No, because the return value only lives until (effectively) the end of the
> statement. A statement has no value, so the effect of an expression statement
> is to immediately discard whatever the value of the expression was. (In
> CPython th
On Thu, 12 Mar 2020 at 19:52, Andrew Barnert
wrote:
> I suppose it could track calls out to C functions as they happen and mark
> every value that was live before the call, and then instead of numpy checking
> refs==1 is could check refs==1 && !c_flagged, and then it wouldn’t need the C
> frame
On Thu, 12 Mar 2020 at 18:42, Andrew Barnert via Python-ideas
wrote:
> What if a for loop, instead of nexting the iterator and binding the result to
> the loop variable, instead unbound the loop variable, nexted the Iterator,
> and bound the result to the loop variable?
I missed that. But I do
On Thu, 12 Mar 2020 at 19:35, Chris Angelico wrote:
> I don't understand your point.
Yes, Andrew Barnert already explained me that :)
> The broad idea of "del x" returning a value isn't inherently
> ridiculous
The point is Eric Wieser does not really want this. What he want is
something similar
On Thu, 12 Mar 2020 at 21:22, Chris Angelico wrote:
> They actually ARE already discarded
0O
You're right. So *how* can juliantaylor said he measured a speedup of
2x for large ndarrays? He added also benchmarks, that are still in
numpy code.
Furthermore he stated that what he done it's done b
Little test:
>>> from itertools import combinations
>>> [id(v) for v in combinations(range(10), 1)]
[140347856824784, 140347856101328, 140347856824784, 140347856101328,
140347856824784, 140347856101328, 140347856824784, 140347856101328,
140347856824784, 140347856101328]
>>> for v in combinations(r
???
We are saying the same thing.
On Thu, Mar 12, 2020 at 11:18 AM Marco Sulla via Python-ideas
wrote:
> This speedup is observed only for large objects
On Fri, 13 Mar 2020 at 00:45, Ben Rudiak-Gould wrote:
> it's only beneficial to try it when the array
On Thu, 12 Mar 2020 at 23:55, Andrew Barnert
wrote:
> Because Julian’s patch has nothing to do with discarding the temporary
> references. It has to do with knowing that an array is safe to reuse.
Sorry, but I do not understand. Are you saying that the patch does not
create a new temporary ndarr
Well, so all this discussion is only for freeing _one_ memory location earlier?
Seriously... as the other users already said, if someone really need
it, he can use normal loops instead of comprehensions and split
complex expression so temporary objects are immediately free.
Furthermore, 2x speedup
42 matches
Mail list logo
