The choice seems to be between
* non-mathematical order
* no order (undefined in Python2, raise in Python3)
I don't really have a strong opinion on which to use here.
One advantage of having an order is that you can speed up algorithms by
working with ordered collections.
On Saturday, February 6, 2016 at 10:57:46 PM UTC+1, Nils Bruin wrote:
> For example, a function which returns the roots of a
>> polynomial over a number field *must* return these sorted into an
>> order that is not going to change if (for instance) the root-finding
>> algorithm changes. Otherwise getting any doctests to work
>> consistently would be impossible.
>>
>
> No, that is not impossible. A routine that computes roots should be
> returning a *set*, not a list. One may decide to return a list instead of a
> set because that might be more efficient, but proper usage of the "roots"
> routine should not depend on the order of that list. The way around that is
> by doctesting in a way that's not sensitive to return order:
>
IPython and doctests attempt to sort sets and dictionary keys in output,
e.g. plain python:
>>> set(['a', 'z', 'b'])
set(['a', 'z', 'b'])
vs. IPython:
In [1]: set(['a', 'z', 'b'])
Out[1]: {'a', 'b', 'z'}
So as long as the elements are sortable a set is just as good as a list for
doctests purposes.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
