On Tuesday, July 22, 2014 11:51:29 AM UTC-7, Clemens Heuberger wrote:
>
>
> May I ask on which system?
>
Fedora 19 x86_64. I tried your makefile trick and I got consistent results,
so I haven't been able to nudge sage or python into the comparison
behaviour you described (for any type, really). Since modern systems try to
randomize the memory layout of executables, it's very well possible that
you're just observing a rare event.
> My problem is that I need to sort anyway---there, the exact order does not
> matter, but it does matter to distinguish between 0 and '0' because of a
> follow-up groupby.
Then you need to make sure that your key-space has an ordering. That means
you should not be using both 0 and '0'. Sage tried to have "universal
ordering" of all objects, but I think by now it's recognized that this was
misguided. It seems to be not possible to have a "<" that agrees with
mathematical intuition in cases where there is an ordering and is
consistent across the whole system. Python used to try to have universal
comparison (which is nice because that meant arbitrary lists could be
sorted), but this was abandoned for complex numbers and is completely
abandoned in Python 3.0 (where comparison tends to raise an exception for
incompatible arguments).
> So I cannot use key=str there (and that would be hobbling according your
> outlined policy).
>
Indeed, I would not suggest putting any "sorted(... , key = str )" *in the
code*, but in doctests it would be fine. If you want '0' to sort
differently from 0, you might try "sorted( ..., key = repr)" instead?
>
> The closest I could do to follow your suggestion would be a doctest
> for line in sorted(latex(F).split("\n"))
> print line
>
Do you want to doctest the "latex" routine? and do you need F to have a
well-defined ordering only to be able to doctest "latex(F)"? In that case
our doctest procedure is broken. I'd solve that by putting a "#random" on
the thing or by putting "..." wildcards in the output template to test some
of the non-varying bits of the output (in particular, that it doesn't
produce an error).
> But if cmp(type(0), type('I')) is indeed random: why not using str at this
> place in sage.structure.element.Element._richcmp ? (and see what doctests
> break
> then)?
>
Because that's fixing something that's very broken already. If anything, we
should be throwing an exception when it comes to this. I'm sure we'll
slowly get rid of the universal ordering attempt eventually, perhaps
if/when we transition to Python 3, since there it's not expected anyway.
There comparing types indeed raises an exception.
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
