I think it is a very bad idea to have default sorting based upon hashing.
This could make a lot of output appear seemingly random (despite having a
natural order), nor there is no way to deal consistently with hash
collisions. This would cause far more problems than it would solve when
working
I see the following in the most recent (beta) release of Sage:
sage: g1=Graph([(0,'a')])
sage: g1.vertices()
:1: DeprecationWarning: parameter 'sort' will
be set to False by default in the future
See http://trac.sagemath.org/22349 for details.
g1.vertices()
-
On Wed, Jul 13, 2022 at 5:46 PM John H Palmieri wrote:
>
> "Fix your old code" could just mean using `vertices(sort=False)`. See also
> https://trac.sagemath.org/ticket/22349.
>
fixing the sort() appears easy:
>>> li=['a',0]
>>> li.sort(key=hash);li
[0, 'a']
--
You received this message becau
"Fix your old code" could just mean using `vertices(sort=False)`. See also
https://trac.sagemath.org/ticket/22349.
On Wednesday, July 13, 2022 at 12:59:45 AM UTC-7 dim...@gmail.com wrote:
>
>
> On Wed, 13 Jul 2022, 08:17 Georgi Guninski, wrote:
>
>> hi sage developers :)
>> long time no see.
On Wed, 13 Jul 2022, 08:17 Georgi Guninski, wrote:
> hi sage developers :)
> long time no see.
>
> i think the migration python2 to python3 regressed a lot
> of Graph() stuff related to ordering the vertices.
>
yes, indeed. I don't think much can be done here; i.e., fix your old code.
>
>
>
> H
hi sage developers :)
long time no see.
i think the migration python2 to python3 regressed a lot
of Graph() stuff related to ordering the vertices.
Here is test case from sagecell:
===
g1=Graph([(0,'a')])
g2=g1.copy()
g2.relabel()
g2.vertices()
g1.vertices()
TypeError: '<' not supported between