Steve Jorgensen wrote:
> Steve Jorgensen wrote:
> > Steve Jorgensen wrote:
> >
> > The problem I came up with trying to spike out
> > my
> > proposal last night is that there
> > doesn't seem to be anyway to implement it without creating infinite
> > recursion in the
> > issublcass call. If I
[Tim]
>> If the result of Python's sort is
>>
>> [x, y]
>>
>> then I happen to know (because I know everything about its
>> implementation) that one of two things is true:
>>
>> - The original list was also [x, y], and y < x was False.
[Steven]
> That's my reasoning, based on your
On Mon, Mar 09, 2020 at 04:50:49PM -0500, Tim Peters wrote:
> [Steven D'Aprano ]
> > ...
> > All I intended was to say that sort would "work" in the sense you state:
> > it will give *some* permutation of the data, where (I think, correct me
> > if I'm wrong) each element compares less than the
[Steven D'Aprano ]
> ...
> All I intended was to say that sort would "work" in the sense you state:
> it will give *some* permutation of the data, where (I think, correct me
> if I'm wrong) each element compares less than the following element.
>
> Wait, no, that's not right either... each element
On 3/9/20 7:45 AM, Steven D'Aprano wrote:
> On Mon, Mar 09, 2020 at 06:39:10AM -0400, Richard Damon wrote:
>> On 3/9/20 12:41 AM, Steven D'Aprano wrote:
>>> Wait, no, that's not right either... each element doesn't compare less
>>> than the previous element?
>>>
>> If the elements of the list
On Mon, Mar 09, 2020 at 06:39:10AM -0400, Richard Damon wrote:
> On 3/9/20 12:41 AM, Steven D'Aprano wrote:
> > Wait, no, that's not right either... each element doesn't compare less
> > than the previous element?
> >
> If the elements of the list don't form a total order, then sort makes NO
>
On 3/9/20 12:41 AM, Steven D'Aprano wrote:
> Wait, no, that's not right either... each element doesn't compare less
> than the previous element?
>
If the elements of the list don't form a total order, then sort makes NO
promises about the data returned, other than it is the input data in
some
On Thu, Mar 05, 2020 at 04:46:14PM -0600, Tim Peters wrote:
> [Steven D'Aprano ]
> > Sorting doesn't require a total order. Sorting only requires a weak
> > order where the only operator required is the "comes before" operator,
> > or less than. That's precisely how sorting in Python is
On 3/5/20 1:37 PM, Andrew Barnert via Python-ideas wrote:
On Mar 5, 2020, at 05:24, Richard Damon wrote:
On 3/4/20 11:07 PM, Andrew Barnert via Python-ideas wrote:
On Mar 4, 2020, at 19:12, Richard Damon wrote:
Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and
Andrew Barnert wrote:
> On Mar 5, 2020, at 11:05, Steve Jorgensen ste...@stevej.name wrote:
> > Steve Jorgensen wrote:
> > Steve Jorgensen wrote:
> >
> > The problem I came up with trying to spike out
> > my
> > proposal last night is that there
> > doesn't seem to be anyway to implement it
On 3/5/20 9:10 AM, Steven D'Aprano wrote:
On Thu, Mar 05, 2020 at 08:23:22AM -0500, Richard Damon wrote:
Yes, that is the idea of AlmostTotalOrder, to have algorithms that
really require a total order (like sorting)
Sorting doesn't require a total order. Sorting only requires a weak
order
[Steven D'Aprano ]
> Sorting doesn't require a total order. Sorting only requires a weak
> order where the only operator required is the "comes before" operator,
> or less than. That's precisely how sorting in Python is implemented.
Let's be careful here. Python's list.sort() guarantees that
On Mar 5, 2020, at 11:05, Steve Jorgensen wrote:
>
> Steve Jorgensen wrote:
>> Steve Jorgensen wrote:
>>
>>> The problem I came up with trying to spike out my
>>> proposal last night is that there
>>> doesn't seem to be anyway to implement it without creating infinite
>>> recursion in the
>>>
Steve Jorgensen wrote:
> Steve Jorgensen wrote:
>
> > The problem I came up with trying to spike out my
> > proposal last night is that there
> > doesn't seem to be anyway to implement it without creating infinite
> > recursion in the
> > issublcass call. If I make Orderable a real or virtual
On Mar 5, 2020, at 05:24, Richard Damon wrote:
>
> On 3/4/20 11:07 PM, Andrew Barnert via Python-ideas wrote:
>>> On Mar 4, 2020, at 19:12, Richard Damon wrote:
>>> Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and
>>> 'Really Truly a Total Order', the first allowing
On Thu, Mar 05, 2020 at 08:23:22AM -0500, Richard Damon wrote:
> Yes, that is the idea of AlmostTotalOrder, to have algorithms that
> really require a total order (like sorting)
Sorting doesn't require a total order. Sorting only requires a weak
order where the only operator required is the
On 3/4/20 11:07 PM, Andrew Barnert via Python-ideas wrote:
On Mar 4, 2020, at 19:12, Richard Damon wrote:
Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and
'Really Truly a Total Order', the first allowing the small exception of a very
limited (maybe only one)
On 3/5/20 1:27 AM, Greg Ewing wrote:
On 5/03/20 4:08 pm, Richard Damon wrote:
Sometimes I wonder if since Python supports dynamic typing of
results, might not do better by removing the NaN value from Floats
and Decimals, and make the operations that generate the NaN generate
an object of a
Steve Jorgensen wrote:
> The problem I came up with trying to spike out my proposal last night is that
> there
> doesn't seem to be anyway to implement it without creating infinite recursion
> in the
> issublcass call. If I make Orderable a real or virtual subclass
> of ProtoOrderable and
On 5/03/20 4:08 pm, Richard Damon wrote:
Sometimes I wonder if
since Python supports dynamic typing of results, might not do better by
removing the NaN value from Floats and Decimals, and make the operations
that generate the NaN generate an object of a special NaN type.
I don't see what
On Mar 4, 2020, at 19:12, Richard Damon wrote:
>
> Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and
> 'Really Truly a Total Order', the first allowing the small exception of a
> very limited (maybe only one) special value that breaks the true definition
> of Total
>
>
> > Is there any commonly used or even imaginable useful type that uses
> > them in weirder ways than set and float
I don’t think this is relevant— Python is very dynamic, operator
overloading is a way to make your custom classes work
With the operators. There is no guarantee at all that
On 3/4/20 11:43 AM, Steven D'Aprano wrote:
On Wed, Mar 04, 2020 at 04:21:46PM +, Mark Dickinson wrote:
I'd argue that on a practicality-beats-purity basis, it wouldn't be
unreasonable to register both `Decimal` and `float` as implementing
`TotalOrdering` (or whatever the ABC ends up being
Andrew Barnert via Python-ideas writes:
> Is there any commonly used or even imaginable useful type that uses
> them in weirder ways than set and float (which are both partially
> ordered) or np.array (where they aren’t even Boolean-values)?
I've had occasion (a class for outcomes in
On Mar 4, 2020, at 01:56, Mark Dickinson wrote:
>
>> On Wed, Mar 4, 2020 at 9:22 AM Andrew Barnert via Python-ideas
>> wrote:
>
>> Is there any commonly used or even imaginable useful type that uses them in
>> weirder ways than set and float (which are both partially ordered) [...]
>
>
Andrew Barnert wrote:
> On Mar 4, 2020, at 00:07, Steve Jorgensen ste...@stevej.name wrote:
> > Taking one step back out of the realm of mathematical
> > definition, however, the original idea was simply to distinguish what I now
> > understand to
> > be "totally ordered" types from other types,
On Wed, Mar 4, 2020 at 11:23 AM Mark Dickinson wrote:
> So Decimal is totally orderable to exactly the same extent that float is.
> (Though the behaviour with NaNs is a little more extreme, since comparisons
> involving sNaNs will raise rather than return False.) I'd argue that on a
>
On Wed, Mar 04, 2020 at 04:21:46PM +, Mark Dickinson wrote:
> I'd argue that on a practicality-beats-purity basis, it wouldn't be
> unreasonable to register both `Decimal` and `float` as implementing
> `TotalOrdering` (or whatever the ABC ends up being called).
And that seems perfectly
On Wed, Mar 4, 2020 at 4:08 PM David Mertz wrote:
>
> And I'm also fudging the Decimal question too. The relationship between
> *expressions* can vary by decimal context. But not of a value named by a
> single variable.
>
Right: Decimal objects don't know anything about context, and
On Wed, Mar 4, 2020 at 10:22 AM Richard Damon
wrote:
> > But on one narrow point, I'm trying to think of everything in the
> standard library or builtins that actually forms a total order with
> elements of the same type.
> > * Not floats
> > * I think not strings with unicode canonical
> On Mar 4, 2020, at 10:09 AM, David Mertz wrote:
>
>
> This thread feels very much like a solution looking for a problem.
>
> But on one narrow point, I'm trying to think of everything in the standard
> library or builtins that actually forms a total order with elements of the
> same
This thread feels very much like a solution looking for a problem.
But on one narrow point, I'm trying to think of everything in the standard
library or builtins that actually forms a total order with elements of the
same type.
* Not floats
* I think not strings with unicode canonical
>
> Is there any commonly used or even imaginable useful type that uses them
> in weirder ways than set and float (which are both partially ordered) or
> np.array (where they aren’t even Boolean-values)? In particular,
> transitivity keeps coming up, but all of those examples are transitive
>
On Wed, Mar 4, 2020 at 9:22 AM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> Is there any commonly used or even imaginable useful type that uses them
> in weirder ways than set and float (which are both partially ordered) [...]
Nitpick: why do you say "partially ordered"
On Mar 4, 2020, at 00:07, Steve Jorgensen wrote:
>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered —
>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered — not even having a full complement of rich comparison
Stéfane Fermigier wrote:
> On Wed, Mar 4, 2020 at 8:24 AM Steve Jorgensen ste...@stevej.name wrote:
> > Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen
> > ste...@stevej.name wrote:
> >
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means
On Wed, Mar 4, 2020 at 9:26 AM Steve Jorgensen wrote:
> Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen ste...@stevej.name wrote:
>
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means you can compare pairs of elements and find
> >
On Wed, Mar 4, 2020 at 8:24 AM Steve Jorgensen wrote:
> Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen ste...@stevej.name wrote:
>
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means you can compare pairs of elements and find
> >
Steve Jorgensen wrote:
> Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen
> > ste...@stevej.name wrote:
> >
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means you can compare pairs of elements and find
> > which one comes first. "Totally
Chris Angelico wrote:
> On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen ste...@stevej.name wrote:
> https://en.wikipedia.org/wiki/Partially_ordered_set
> "Partially ordered" means you can compare pairs of elements and find
> which one comes first. "Totally ordered" means you can compare ANY
>
On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen wrote:
>
> Greg Ewing wrote:
> > On 4/03/20 7:42 am, Steve Jorgensen wrote:
> > > That's a much better term. Orderable and
> > > ProtoOrderable.
> > > I would suggest "TotallyOrdered" and "PartiallyOrdered".
>
> Possibly, but the reasoning is not
Greg Ewing wrote:
> On 4/03/20 7:42 am, Steve Jorgensen wrote:
> > That's a much better term. Orderable and
> > ProtoOrderable.
> > I would suggest "TotallyOrdered" and "PartiallyOrdered".
Possibly, but the reasoning is not obvious to me. Can you explain? I get that
`TotallyOrdered` is
On 4/03/20 7:42 am, Steve Jorgensen wrote:
That's a much better term. `Orderable` and `ProtoOrderable`.
I would suggest "TotallyOrdered" and "PartiallyOrdered".
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
On 2020-03-04 00:58, Tim Peters wrote:
[Guido]
But beware, IIRC there are pathological cases involving floats, (long) ints
and rounding where transitivity may be violated in Python (though I believe
only Tim Peters can produce an example :-).
Not anymore ;-) That is, while comparisons mixing
[Guido]
> But beware, IIRC there are pathological cases involving floats, (long) ints
> and rounding where transitivity may be violated in Python (though I believe
> only Tim Peters can produce an example :-).
Not anymore ;-) That is, while comparisons mixing bigints and floats
may have suffered
Guido van Rossum wrote:
> On Tue, Mar 3, 2020 at 10:43 AM Steve Jorgensen ste...@stevej.name wrote:
> > Guido van Rossum wrote:
> > I think it’s usually called Orderable. It’s a
> > useful concept in static
> > type
> > checking too (e.g. mypy), where we’d use it as an upper bound for type
> >
On Tue, Mar 3, 2020 at 5:35 PM Guido van Rossum wrote:
> But beware, IIRC there are pathological cases involving floats, (long)
> ints and rounding where transitivity may be violated in Python (though I
> believe only Tim Peters can produce an example :-). I'm honestly not sure
> that that's
On Tue, Mar 3, 2020 at 10:43 AM Steve Jorgensen wrote:
> Guido van Rossum wrote:
> > I think it’s usually called Orderable. It’s a useful concept in static
> type
> > checking too (e.g. mypy), where we’d use it as an upper bound for type
> > variables, if we had it. I guess to exclude sets you’d
Guido van Rossum wrote:
> I think it’s usually called Orderable. It’s a useful concept in static type
> checking too (e.g. mypy), where we’d use it as an upper bound for type
> variables, if we had it. I guess to exclude sets you’d have to introduce
> TotalOrderable.
> On Tue, Mar 3, 2020 at 04:03
I think it’s usually called Orderable. It’s a useful concept in static type
checking too (e.g. mypy), where we’d use it as an upper bound for type
variables, if we had it. I guess to exclude sets you’d have to introduce
TotalOrderable.
On Tue, Mar 3, 2020 at 04:03 Steve Jorgensen wrote:
> I
51 matches
Mail list logo
