On 2016-12-04 19:39, Marc Mezzarobba wrote:
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?
No. As far as I know, It does so for historical reasons only. I am in
favour of making elements
On 2016-12-04 08:59, Jori Mäntysalo wrote:
Currently
Posets.PentagonPoset().is_antichain_of_poset([2,3,'junk'])
returns False and
Posets.PentagonPoset().is_antichain_of_poset(['junk',2,3])
raises an error. At https://trac.sagemath.org/ticket/19078 I and Travis
have different opinion about whi
Travis Scrimshaw wrote:
> We need to be very careful about defining "not knowing". I (stongly)
> believe when the objects/types are incomparable (say the rings ZZ and
> QQ), then == should return False and != should return True.
Sorry, I don't understand your example: I think everyone agrees that
On Sunday, December 4, 2016 at 1:59:00 PM UTC-6, Frédéric Chapoton wrote:
>
> 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 necessar
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 are
Frédéric Chapoton wrote:
> richcmp, when not knowing what to do, should most probably return
> NotImplemented
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
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 "", line 1, in
TypeError: unorderable types: int() < str()
The current behavior is certainly not great, and was just defaulted because
thats wh
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 to
comp
On Sun, Dec 4, 2016 at 10:37 AM, Dima Pasechnik 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
>>> wrote:
>>> > There's apparently
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 essentially ar
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
>> wrote:
>> > There's apparently no good way in general to test whether the scene is
>> > unchanged
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 implements
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 better unde
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't seein
PS actually, i am a little wrong with Python ints being arbitrary
precision. In fact there is no such thing as just a python int, there is
"int" and "long", but computations with ints can give you an answer which
is "long"; presumably this mostly means that everything is as slow as if
everythin
To clarify slightly, I want both cases to return False, whereas Jori wants
both cases to raise an error. Same reasoning for me as is_similar for
matrices.
Best,
Travis
On Sunday, December 4, 2016 at 1:59:47 AM UTC-6, Jori Mäntysalo wrote:
>
> Currently
>
> Posets.PentagonPoset().is_antichain_
Hi all,
Thanks for your answers. There are a few things that I now understand, but
i'm still confused. One crucial mistake I made was, as I see now thanks to
Ralf's message, to believe that numpy.int meant "C int": no, it means
python int ! For C ints, use numpy.int32 (or 64). In fact :
sage:
On 2016-11-28 20:14, Vincent Delecroix wrote:
- Relying on Python packaging and PyPI might be too limited for Sage at
some point (tricky dependencies, Sage recompilation needed)
I would say it's limited only because it deals with Python packages, not
other libraries. I don't quite get what you
PS:
On 2016-12-03, Pierre wrote:
> I thought about multiplying large matrices, but I'm afraid that completely
> different algorithms/libraries will be used depending on the parent ring
Yes, this would measure the efficiency of matrix arithmetics but would
give no real clue about the efficiency
Hi Pierre,
On 2016-12-03, Pierre wrote:
> We are talking about very basic advice to give to a beginner, and so, I
> knew enough to say that well, C ints (so I guess numpy.int's) will be fast,
> but limited in size, and elements of ZZ can be as large as your memory
> allows etc (and a similar,
Currently
Posets.PentagonPoset().is_antichain_of_poset([2,3,'junk'])
returns False and
Posets.PentagonPoset().is_antichain_of_poset(['junk',2,3])
raises an error. At https://trac.sagemath.org/ticket/19078 I and Travis
have different opinion about which one is the right answer. So please give
21 matches
Mail list logo
