sage-devel
https://groups.google.com/d/forum/sage-devel
This email list is for discussion of Sage (<a href="http://www.sagemath.org">www.sagemath.org</a>) development issues. This list usually has heavy traffic.enRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/Nti_iM70BgAJ
Is there already a replacement for cmp() in Sage (i.e., something that allows one to sort arbitrary objects--say, for printing them--and calls _cmp_() in the case of Elements)? If not, is there a plan to add one? Thanks, -- Marchttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Marc MezzarobbaMon, 05 Dec 2016 08:35:47 UTCRe: [sage-devel] Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/IJvYGM_vBgAJ
No. As far as I know, It does so for historical reasons only. I am in favour of making elements without a common parent uncomparable.https://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Jeroen DemeyerMon, 05 Dec 2016 07:04:12 UTCRe: [sage-devel] Return false or raise error on some situations
https://groups.google.com/d/msg/sage-devel/Rim2qaepilM/2F5-sHbvBgAJ
I would vote for both cases to give an error. When some user does Posets.PentagonPoset().is_antichain_of_poset(['junk',2,3]) it is most likely to be an error. I don't see much usefulness of a "False" answer here. I understand the mathematical argument why you want to return False to a yes/nohttps://groups.google.com/d/topic/sage-devel/Rim2qaepilM
Jeroen DemeyerMon, 05 Dec 2016 06:57:52 UTCRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/zY0pGAntBgAJ
Sorry, I don't understand your example: I think everyone agrees that ZZ == QQ should be False, but many people think that ZZ(1) == QQ(1) should be True (though I personally disagree), and my post only was about Elements. > Subsequently, when there is no coercion between the parents, they >https://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Marc MezzarobbaMon, 05 Dec 2016 06:13:22 UTCRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/G4z6BYDRBgAJ
believe when the objects/types are incomparable (say the rings ZZ and QQ), then == should return False and != should return True. Subsequently, when there is no coercion between the parents, they should not raise an error. Best, Travishttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Travis ScrimshawSun, 04 Dec 2016 21:48:47 UTCLicense of the SageMath documentation
https://groups.google.com/d/msg/sage-devel/n0B16q4h2c8/dcebmlHRBgAJ
Hi, I found conflicting information about the license of the SageMath documentation. While it says nothing in COPYING.txt, it says in src/doc/en/reference/history_and_license/index.rst that "All documentation is released under the GNU Free Documentation License." On the other hand, there arehttps://groups.google.com/d/topic/sage-devel/n0B16q4h2c8
tha...@debian.orgSun, 04 Dec 2016 21:45:27 UTCRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/i9KlCVrMBgAJ
In the case of Element.__richcmp__: not when both operands are Elements, IMO, but perhaps indeed when the other one is a non-Element. > I do not think we should whitelist comparison with strings. That was just an example of a temporary kludge that could make things simpler :-) > What do thehttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Marc MezzarobbaSun, 04 Dec 2016 20:14:26 UTCRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/fvpvoSvMBgAJ
In the Python3 spirit, it would be nice to get a type error instead of ordering by id: $ python3 >>> 1 < 'a' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: int() < str() The current behavior is certainly not great, and was just defaultedhttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Volker BraunSun, 04 Dec 2016 20:11:07 UTCRe: Cross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/XfIMWoLLBgAJ
There is currently an effort being made (by me and a few referees) to get rid of cmp() in all pyx files. And the Element/Parent is one of the hardest cases remaining. Getting rid of all calls to cmp( ) is necessary for compatibility with python3. The intermediate objective is to be able tohttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Frédéric ChapotonSun, 04 Dec 2016 19:59:00 UTCRe: [sage-devel] Re: three.js on 7.5 beta 5: cpu...
https://groups.google.com/d/msg/sage-devel/pGLZrwfdQB8/OmmPKVDJBgAJ
On Sun, Dec 4, 2016 at 10:37 AM, Dima Pasechnik <dim...@gmail.com> wrote: > > > On Saturday, December 3, 2016 at 10:34:50 PM UTC, Paul Masson wrote: >> >> >> >> On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote: >>> >>> On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson <paulm...@comcast.nehttps://groups.google.com/d/topic/sage-devel/pGLZrwfdQB8
WilliamSun, 04 Dec 2016 19:18:45 UTCCross-type comparisons
https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/4OZUmzLHBgAJ
Hi, Does Element.__richcmp__() (via CoercionModel_cache_maps.richcmp()) really need to fall back on comparing by type/id when no common parent is found? Since comparison operators are part of the coercion framework, it would seem more sensible to raise an error. Moreover, having an essentiallhttps://groups.google.com/d/topic/sage-devel/YVFdxPH6avk
Marc MezzarobbaSun, 04 Dec 2016 18:39:59 UTCRe: [sage-devel] Re: three.js on 7.5 beta 5: cpu...
https://groups.google.com/d/msg/sage-devel/pGLZrwfdQB8/KcUGfBDHBgAJ
to me this screams of wrong design, don't know whether it's in three.js or just in js... Indeed, the renderer can be awaken by user interaction, as you say. Why can't it be awaken by an animation function?! How come rotating picture by hand is different from, say, rotating a part of it by ahttps://groups.google.com/d/topic/sage-devel/pGLZrwfdQB8
Dima PasechnikSun, 04 Dec 2016 18:37:32 UTCRe: [sage-devel] Re: devising a speed comparison test between different types
https://groups.google.com/d/msg/sage-devel/HNX5rHzuBc8/jA2tqwzGBgAJ
On Sat, Dec 3, 2016 at 10:53 PM, Ralf Stephan <> wrote: “Both ZZ and numpy use libgmp internally “ No, ZZ uses libgmp (actually really MPIR, which is a fork of GMP), and numpy uses Python’s ints/longs. Python’s int/long type is arbitrary precision, despite the confusing naming. It only implementhttps://groups.google.com/d/topic/sage-devel/HNX5rHzuBc8
WilliamSun, 04 Dec 2016 18:18:56 UTCRe: [sage-devel] Re: devising a speed comparison test between different types
https://groups.google.com/d/msg/sage-devel/HNX5rHzuBc8/UoqUewvEBgAJ
On Sunday, December 4, 2016 at 5:58:45 PM UTC+1, Pierre wrote: > -- numpy.int32 or int.64: like "int" initially, but works mod 2^32 or > 2^64, and gives an overflow warning when it happens. No increase in > speed, for general reasons which I will just call "overhead" for lack > of a betterhttps://groups.google.com/d/topic/sage-devel/HNX5rHzuBc8
Volker BraunSun, 04 Dec 2016 17:42:12 UTCRe: [sage-devel] Re: devising a speed comparison test between different types
https://groups.google.com/d/msg/sage-devel/HNX5rHzuBc8/wuERdazBBgAJ
PPS come to think of it, my last PS explains it all. So in summary: -- ZZ= always arbitrary precision. -- int= a C int when the numbers stay < 2^64, so there is an increase of speed -- but not nearly as much of an increase as I expected, which is why I was confused at first, because I wasn'thttps://groups.google.com/d/topic/sage-devel/HNX5rHzuBc8
PierreSun, 04 Dec 2016 16:58:45 UTC