[sage-devel] Re: Some polynomial timings

[Travis Scrimshaw]

> Just to correct a misconception earlier in the thread, the issue with 
> Skylake has nothing to do with Flint. That is an issue in MPIR which is a 
> community supported project. No one is currently paid to work on MPIR. 
>
> Sorry about that; got my projects crossed.

Best,
Travis
 

-- 
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.

Re: [sage-devel] Re: SageNB, publishing and error 500

[Jori Mäntysalo]

On Wed, 6 Sep 2017, kcrisman wrote:


I suspect perhaps 
https://github.com/sagemath/sagenb/commit/9dd5c0f8c783de7cb0ae21c9f445ab8260b5a0ac
 is the culprit, and
put something on #432 to the author of that change.  It seems like the kind of 
thing that might happen when a module is
updated, as that change did, though I could be barking up the wrong tree too.  
Thanks for pursuing this.


Another question: Can I downgrade SageNB when waiting correction for this 
bug? Is so, how?


--
Jori Mäntysalo

Re: [sage-devel] Re: Sage 8.0 Build Error on MacOS, [mpir-3.0.0.p0] Error building MPIR.

['Bill Hart' via sage-devel]

That's right. For now that is the only workaround. We know what the problem 
is now, but don't have a working patch to fix it. It's the JMPENT macro in 
mpn/x86_64/x86_64-defs.m4 that doesn't work on 64 bit OSX.

Details of the issue can be found here, I believe [1].

Bill.

[1] https://gmplib.org/list-archives/gmp-bugs/2012-December/002836.html

On Tuesday, 22 August 2017 19:37:50 UTC+2, Alex J Best wrote:
>
> As the problem is skylake I assume mpn/x86_64/skylake/avx/addmul_1.asm is 
> the one to patch out.
>
> On Monday, August 21, 2017 at 11:51:28 AM UTC-4, Dima Pasechnik wrote:
>>
>>
>>
>> On Monday, August 21, 2017 at 4:15:29 PM UTC+1, Michael Frey wrote:
>>>
>>> What is the best way to do this?  The file is extracted from the 
>>> mpir-3.0.0.tar.bz2 every time make is run.
>>>
>>
>> the standard way would be to add the patch removing  this file (which one 
>> exactly, there are few files named so?)
>> build/pkgs/mpir/patches/
>>
>>
>>
>>> On Wednesday, August 2, 2017 at 5:41:01 PM UTC-4, Bill Hart wrote:

 The only workaround I'm currently aware of is to remove the offending 
 addmul_1.asm file. It is to do with our use of jump tables.


>>

-- 
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.

[sage-devel] Re: Some polynomial timings

['Bill Hart' via sage-devel]

We are faster for sparse multivariate multiplication on multiple cores too. 
We just haven't blogged about it yet. :-)

But you are right, Giac is years ahead at this point. We do not envision 
adding multivariate factorisation within the scope of the OpenDreamKit 
funded project that is allowing us to work on this. We do hope to add it 
eventually of course.

Just to correct a misconception earlier in the thread, the issue with 
Skylake has nothing to do with Flint. That is an issue in MPIR which is a 
community supported project. No one is currently paid to work on MPIR. 

On Tuesday, 5 September 2017 07:54:10 UTC+2, parisse wrote:
>
> And why not giac? flint is a little faster for basic multivariate 
> polynomial arithmetic on 1 thread, but giac is multithread and has more 
> advanced fast functionnalities like gcd, factorization, Groebner basis or 
> rational univariate representation.
>

-- 
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.

Re: [sage-packaging] Re: [sage-devel] Upgrade PARI to git master

[Vincent Delecroix]

On 06/09/2017 10:28, Ximin Luo wrote:

Jeroen Demeyer:

On 2017-09-06 14:53, Ximin Luo wrote:

I've seen numerous cases where Sage has to change the expected test output 
simply because a dependency was upgraded. There has to be a more sustainable 
way of achieving this...


Suggestions welcome...

Note that none of your above proposals is relevant to the typical PARI failures. We would need 
support in the doctest framework for stuff like "# generates same group" or "# same 
element of H^1(...)" or whatever. I don't think this can be fixed in the doctest framework.



OK. Another suggestion would be to wrap many of the test cases in normalising 
functions like round() or whatever is appropriate (for PARI it would be group 
theory related stuff). For example:


+1 It would be nice to have the testsuite pass on the different PARI 
versions.


--
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.

Re: [sage-packaging] Re: [sage-devel] Upgrade PARI to git master

[Ximin Luo]

Jeroen Demeyer:
> On 2017-09-06 14:53, Ximin Luo wrote:
>> I've seen numerous cases where Sage has to change the expected test output 
>> simply because a dependency was upgraded. There has to be a more sustainable 
>> way of achieving this...
> 
> Suggestions welcome...
> 
> Note that none of your above proposals is relevant to the typical PARI 
> failures. We would need support in the doctest framework for stuff like "# 
> generates same group" or "# same element of H^1(...)" or whatever. I don't 
> think this can be fixed in the doctest framework.
> 

OK. Another suggestion would be to wrap many of the test cases in normalising 
functions like round() or whatever is appropriate (for PARI it would be group 
theory related stuff). For example:

>>> calculate_many_floats()
((0.100, 25.000), (3.555, 123.000))
- becomes
>>> recursive_round(calculate_many_floats(), 4)
((0.100, 25.000), (3.555, 123.000))

and

>>> generate_group()
# whatever
- becomes
>>> normalise(generate_group())
# whatever

If there is no "normalise" function for that context, perhaps there is at least 
a method to check that two objects represent the same mathematical group, so:

>>> generate_group()
[some representation]
- becomes
>>> is_same_group(generate_group(), [other representation])
True

Hopefully this is less brittle than what happens currently.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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.

Re: [sage-devel] hash issue in python3 experimental branch

[Erik Bray]

On Wed, Sep 6, 2017 at 5:13 PM, Jeroen Demeyer  wrote:
> On 2017-09-06 17:05, Erik Bray wrote:
>>
>> "language level 2" [...], where "str" means "bytes".
>
>
> [citation needed]
>
> Where did you get the idea that Cython interprets "str" as "bytes" with
> Python 3?
>
> In https://trac.sagemath.org/ticket/23089 I argued *against* changing the
> Cython language_level.

It's pretty clear about that in the docs:
http://cython.readthedocs.io/en/latest/src/tutorial/strings.html#python-string-types-in-cython-code

This makes sense because there is no equivalent to Python 2 "str" in
Python 3.  The nearest equivalent is Python 3 "bytes".  Interpreting
"str" as "bytes" is the only way it can be if language_level=2.  So
for example with language_level=2 you get conversions like:


19832   /* "sage/rings/rational.pyx":2075
19833  * sig_on()
19834  * mpq_get_str(s, base, self.value)
19835  * sig_off() # <<
19836  * k = str(s)
19837  * PyMem_Free(s)
19838  */
19839   sig_off();
19840
19841   /* "sage/rings/rational.pyx":2076
19842  * mpq_get_str(s, base, self.value)
19843  * sig_off()
19844  * k = str(s) # <<
19845  * PyMem_Free(s)
19846  * return k
19847  */
19848   __pyx_t_4 = __Pyx_PyBytes_FromString(__pyx_v_s); if
(unlikely(!__pyx_t_4  )) __PYX_ERR(0, 2076, __pyx_L1_error)

So this causes Rational.__repr__ to return a bytes instead of a str. Ick.

I'll have to look at your argument against it. I actually didn't know
about language_level until now--I had assumed that if you Cython on
Python 3 it's going to be nearer to Python 3 in terms of semantics.
But I think it makes enormous sense to set the correct language_level
for the Python in use, otherwise writing 2/3 code requires different
idioms when moving between Python and Cython code and that's a recipe
for headaches.

-- 
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.

[sage-devel] Re: Some polynomial timings

[rjf]

Bill Hart's blog is, as I expected, thorough and informative.
It does not make for an entirely fair comparison to show
timings for systems that restrict the exponents of polynomials
to different lengths.  That is, there are problems that 
can be done very simply in a system with 64 bit exponents
but not with 16 bit exponents.  Maxima's polynomial "rat"
subsystem has exponents which are arbitrary precision,
and are available in Sage.   Since it is possible to encode
multiple variables into a single variable by encoding in
exponents, this can matter.

I have pointed out numerous times that relatively high speed
on polynomial problems of astronomical size may not be the
criterion for choosing a method and representation for most
users.  But this is a fun target for making improvements.
RJF

On Sunday, September 3, 2017 at 10:13:59 PM UTC-7, parisse wrote:
>
>
>
> Le dimanche 3 septembre 2017 16:06:46 UTC+2, rjf a écrit :
>>
>> I was doing timing on the same task and found that one system
>> (used for celestial mechanics) was spectacularly fast on a test just like 
>> this one.
>> One reason was that it first changed f*(f+1)   to
>>
>> f^2 +f
>> and was clever in computing f^2.  You should be clever
>> at this too.
>>
>> Anyway, be careful when you are testing.
>>
>>
> giac does not cheat, it does the product f*(f+1) not f^2+f. For more 
> details, you can have a look at Bill Hart blog:
>
> http://wbhart.blogspot.fr/2017/07/update-on-fast-multivariate-polynomial.html
>

-- 
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.

Re: [sage-devel] hash issue in python3 experimental branch

[Erik Bray]

On Wed, Sep 6, 2017 at 5:05 PM, Erik Bray  wrote:
> On Wed, Sep 6, 2017 at 3:35 PM, Frédéric Chapoton  
> wrote:
>> This [b'1', b'1'] is the next problem, once the hash issue is corrected. I
>> only have a branch with the added hash on my own computer at home, so I can
>> not push it to trac immediatly.
>
> This error (and many others like it) comes from the fact that we're
> compiling Cython sources with "language level 2" (i.e. closer to
> Python 2 semantics, the default), where "str" means "bytes".  So there
> are many methods that return "bytes" objects that really should be
> returning "str" on Python 3, causing much confusion in interfaces that
> consume those methods.  This can be worked around of course, but the
> question becomes:  For SAGE_PYTHON3 do we want to compile Cython
> sources with "language level 3"?
>
> I would suggest yes, we do, as it makes the semantics of Python
> 2/3-straddling code more similar in Python and Cython code.  Otherwise
> we're stuck with this terribly confusing situation where Cython code
> needs to still be written in a way that is compatible with Python 3
> pure Python code, but types like "str" still keep the Python 2
> semantics, but only sort of...
>
> I'm going to experiment with setting Cython to -3 and see how far I get...

Ah, this leads to a ton of errors like:

Error compiling Cython file:

...
except KeyError:
return chr(token)


cdef inline bint is_alphanumeric(char c):
return 'a' <= c <= 'z' or 'A' <= c <= 'Z' or '0' <= c <= '9' or c == '_'
  ^


sage/misc/parser.pyx:97:11: Unicode literals do not support coercion
to C types other than Py_UNICODE/Py_UCS4 (for characters) or
Py_UNICODE* (for strings).


That's good though.  It's treating string literals as unicode literals
on Python 3, which is the correct semantics. And indeed when we try to
use unicode string literals as though they're character arrays Cython
throws up on us which is good.

These are the sorts of cases (dealing with ASCII character strings)
where *explicitly* using bytes literals is appropriate.  So there's
going to need to be a lot of '' => b'' in code like this.  Fortunately
this makes sense in both Python 2 and 3.


>> Le mercredi 6 septembre 2017 15:29:01 UTC+2, Erik Bray a écrit :
>>>
>>> On Mon, Aug 28, 2017 at 8:45 PM, Frédéric Chapoton 
>>> wrote:
>>> > Indeed, adding __hash__ to the CDF class seems to fix this specific
>>> > issue. I
>>> > wonder how many hash we are going to be forced to add..
>>>
>>> I've finally gotten my python3 build to a point where I'm able to
>>> reproduce this problem.  Have you committed any changes related to
>>> this yet, or is this the latest updated on this issue?  What exactly
>>> does the __hash__ you added look like?
>>>
>>> > The next problem is very strange. During the initialisation of the damn
>>> > I
>>> > symbol (that seems to be responsible for a non-negligible part of our
>>> > startup time), the following code
>>> >
>>> > R = QQ['x']
>>> > f = R([-D,0,1])
>>> >
>>> > and the replacement code that I tried
>>> >
>>> > 919 x = polygen(QQ, 'x')
>>> > 920 f = x * x - D
>>> >
>>> > both return a polynomial with coefficients [b'1', b'1'], which of course
>>> > does not make any sense..
>>>
>>> I'm a little confused--this doesn't have anything to do with the
>>> __hash__ problem does it?  Why does the existing code here need to be
>>> replaced with anything at all?
>>>
>>>
>>>
>>> > Le lundi 28 août 2017 14:30:20 UTC+2, Jeroen Demeyer a écrit :
>>> >>
>>> >> I'm guessing it might be this from
>>> >> https://docs.python.org/3.6/reference/datamodel.html#object.__hash__
>>> >>
>>> >> A class that overrides __eq__() and does not define __hash__() will
>>> >> have
>>> >> its __hash__() implicitly set to None.
>>> >>
>>> >>
>>> >> Python2:
>>> >>
>>> >>  >>> class X(tuple):
>>> >> ... def __eq__(self, other): return False
>>> >>  >>> hash(X())
>>> >> 3527539
>>> >>
>>> >> Python 3:
>>> >>
>>> >>  >>> class X(tuple):
>>> >> ... def __eq__(self, other): return False
>>> >>  >>> hash(X())
>>> >> Traceback (most recent call last):
>>> >>File "", line 1, in 
>>> >> TypeError: unhashable type: 'X'
>>> >>
>>> >>
>>> >> Interestingly, Python 2 also acts like this for *extension types* (such
>>> >> as Cython cdef classes) but not for ordinary Python classes.
>>> >
>>> > --
>>> > 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+...@googlegroups.com.
>>> > To post to this group, send email to sage-...@googlegroups.com.
>>> > Visit this group at https://groups.google.com/group/sage-devel.
>>> > For more options, visit https://groups.google.com/d/optout.
>>
>> 

Re: [sage-devel] hash issue in python3 experimental branch

[Jeroen Demeyer]

On 2017-09-06 17:05, Erik Bray wrote:

"language level 2" [...], where "str" means "bytes".


[citation needed]

Where did you get the idea that Cython interprets "str" as "bytes" with 
Python 3?


In https://trac.sagemath.org/ticket/23089 I argued *against* changing 
the Cython language_level.


--
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.

Re: [sage-devel] hash issue in python3 experimental branch

[Erik Bray]

On Wed, Sep 6, 2017 at 3:35 PM, Frédéric Chapoton  wrote:
> This [b'1', b'1'] is the next problem, once the hash issue is corrected. I
> only have a branch with the added hash on my own computer at home, so I can
> not push it to trac immediatly.

This error (and many others like it) comes from the fact that we're
compiling Cython sources with "language level 2" (i.e. closer to
Python 2 semantics, the default), where "str" means "bytes".  So there
are many methods that return "bytes" objects that really should be
returning "str" on Python 3, causing much confusion in interfaces that
consume those methods.  This can be worked around of course, but the
question becomes:  For SAGE_PYTHON3 do we want to compile Cython
sources with "language level 3"?

I would suggest yes, we do, as it makes the semantics of Python
2/3-straddling code more similar in Python and Cython code.  Otherwise
we're stuck with this terribly confusing situation where Cython code
needs to still be written in a way that is compatible with Python 3
pure Python code, but types like "str" still keep the Python 2
semantics, but only sort of...

I'm going to experiment with setting Cython to -3 and see how far I get...

> Le mercredi 6 septembre 2017 15:29:01 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Aug 28, 2017 at 8:45 PM, Frédéric Chapoton 
>> wrote:
>> > Indeed, adding __hash__ to the CDF class seems to fix this specific
>> > issue. I
>> > wonder how many hash we are going to be forced to add..
>>
>> I've finally gotten my python3 build to a point where I'm able to
>> reproduce this problem.  Have you committed any changes related to
>> this yet, or is this the latest updated on this issue?  What exactly
>> does the __hash__ you added look like?
>>
>> > The next problem is very strange. During the initialisation of the damn
>> > I
>> > symbol (that seems to be responsible for a non-negligible part of our
>> > startup time), the following code
>> >
>> > R = QQ['x']
>> > f = R([-D,0,1])
>> >
>> > and the replacement code that I tried
>> >
>> > 919 x = polygen(QQ, 'x')
>> > 920 f = x * x - D
>> >
>> > both return a polynomial with coefficients [b'1', b'1'], which of course
>> > does not make any sense..
>>
>> I'm a little confused--this doesn't have anything to do with the
>> __hash__ problem does it?  Why does the existing code here need to be
>> replaced with anything at all?
>>
>>
>>
>> > Le lundi 28 août 2017 14:30:20 UTC+2, Jeroen Demeyer a écrit :
>> >>
>> >> I'm guessing it might be this from
>> >> https://docs.python.org/3.6/reference/datamodel.html#object.__hash__
>> >>
>> >> A class that overrides __eq__() and does not define __hash__() will
>> >> have
>> >> its __hash__() implicitly set to None.
>> >>
>> >>
>> >> Python2:
>> >>
>> >>  >>> class X(tuple):
>> >> ... def __eq__(self, other): return False
>> >>  >>> hash(X())
>> >> 3527539
>> >>
>> >> Python 3:
>> >>
>> >>  >>> class X(tuple):
>> >> ... def __eq__(self, other): return False
>> >>  >>> hash(X())
>> >> Traceback (most recent call last):
>> >>File "", line 1, in 
>> >> TypeError: unhashable type: 'X'
>> >>
>> >>
>> >> Interestingly, Python 2 also acts like this for *extension types* (such
>> >> as Cython cdef classes) but not for ordinary Python classes.
>> >
>> > --
>> > 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+...@googlegroups.com.
>> > To post to this group, send email to sage-...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

-- 
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.

[sage-devel] Re: SageNB, publishing and error 500

[kcrisman]

>File 
> "/home/jm58660/sage/local/lib/python2.7/site-packages/sagenb/flask_version/worksheet.py",
>  
>
> line 879, in worksheet_publish 
>  print worksheet_publish.url_for(worksheet) 
>
>File 
> "/home/jm58660/sage/local/lib/python2.7/site-packages/sagenb/flask_version/worksheet.py",
>  
>
> line 147, in wc_url_for 
>  return url_for(f.__name__, *args, **kwds) 
>
> "/home/jm58660/sage/local/lib/python2.7/site-packages/werkzeug/routing.py", 
>
> line 1758, in build 
>
>  raise BuildError(endpoint, values, method, self) 
> BuildError: Could not build url for endpoint 'worksheet_publish' with 
> values ['id', 'username']. Did you mean 'worksheet.worksheet_publish' 
> instead? 
>

This suggests hacking line 879 ... but you are right that things don't 
quite correspond. 

I suspect 
perhaps 
https://github.com/sagemath/sagenb/commit/9dd5c0f8c783de7cb0ae21c9f445ab8260b5a0ac
 
is the culprit, and put something on #432 to the author of that change.  It 
seems like the kind of thing that might happen when a module is updated, as 
that change did, though I could be barking up the wrong tree too.  Thanks 
for pursuing this.

 

>
> However, this seems to be documented bug already: 
>
> https://github.com/sagemath/sagenb/issues/432 
>
>
Could be, though they didn't give the traceback :( 

-- 
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.

Re: [sage-devel] hash issue in python3 experimental branch

[Frédéric Chapoton]

This [b'1', b'1'] is the next problem, once the hash issue is corrected. I 
only have a branch with the added hash on my own computer at home, so I can 
not push it to trac immediatly.


Le mercredi 6 septembre 2017 15:29:01 UTC+2, Erik Bray a écrit :
>
> On Mon, Aug 28, 2017 at 8:45 PM, Frédéric Chapoton  > wrote: 
> > Indeed, adding __hash__ to the CDF class seems to fix this specific 
> issue. I 
> > wonder how many hash we are going to be forced to add.. 
>
> I've finally gotten my python3 build to a point where I'm able to 
> reproduce this problem.  Have you committed any changes related to 
> this yet, or is this the latest updated on this issue?  What exactly 
> does the __hash__ you added look like? 
>
> > The next problem is very strange. During the initialisation of the damn 
> I 
> > symbol (that seems to be responsible for a non-negligible part of our 
> > startup time), the following code 
> > 
> > R = QQ['x'] 
> > f = R([-D,0,1]) 
> > 
> > and the replacement code that I tried 
> > 
> > 919 x = polygen(QQ, 'x') 
> > 920 f = x * x - D 
> > 
> > both return a polynomial with coefficients [b'1', b'1'], which of course 
> > does not make any sense.. 
>
> I'm a little confused--this doesn't have anything to do with the 
> __hash__ problem does it?  Why does the existing code here need to be 
> replaced with anything at all? 
>
>
>
> > Le lundi 28 août 2017 14:30:20 UTC+2, Jeroen Demeyer a écrit : 
> >> 
> >> I'm guessing it might be this from 
> >> https://docs.python.org/3.6/reference/datamodel.html#object.__hash__ 
> >> 
> >> A class that overrides __eq__() and does not define __hash__() will 
> have 
> >> its __hash__() implicitly set to None. 
> >> 
> >> 
> >> Python2: 
> >> 
> >>  >>> class X(tuple): 
> >> ... def __eq__(self, other): return False 
> >>  >>> hash(X()) 
> >> 3527539 
> >> 
> >> Python 3: 
> >> 
> >>  >>> class X(tuple): 
> >> ... def __eq__(self, other): return False 
> >>  >>> hash(X()) 
> >> Traceback (most recent call last): 
> >>File "", line 1, in  
> >> TypeError: unhashable type: 'X' 
> >> 
> >> 
> >> Interestingly, Python 2 also acts like this for *extension types* (such 
> >> as Cython cdef classes) but not for ordinary Python classes. 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.

Re: [sage-devel] hash issue in python3 experimental branch

[Erik Bray]

On Mon, Aug 28, 2017 at 8:45 PM, Frédéric Chapoton  wrote:
> Indeed, adding __hash__ to the CDF class seems to fix this specific issue. I
> wonder how many hash we are going to be forced to add..

I've finally gotten my python3 build to a point where I'm able to
reproduce this problem.  Have you committed any changes related to
this yet, or is this the latest updated on this issue?  What exactly
does the __hash__ you added look like?

> The next problem is very strange. During the initialisation of the damn I
> symbol (that seems to be responsible for a non-negligible part of our
> startup time), the following code
>
> R = QQ['x']
> f = R([-D,0,1])
>
> and the replacement code that I tried
>
> 919 x = polygen(QQ, 'x')
> 920 f = x * x - D
>
> both return a polynomial with coefficients [b'1', b'1'], which of course
> does not make any sense..

I'm a little confused--this doesn't have anything to do with the
__hash__ problem does it?  Why does the existing code here need to be
replaced with anything at all?



> Le lundi 28 août 2017 14:30:20 UTC+2, Jeroen Demeyer a écrit :
>>
>> I'm guessing it might be this from
>> https://docs.python.org/3.6/reference/datamodel.html#object.__hash__
>>
>> A class that overrides __eq__() and does not define __hash__() will have
>> its __hash__() implicitly set to None.
>>
>>
>> Python2:
>>
>>  >>> class X(tuple):
>> ... def __eq__(self, other): return False
>>  >>> hash(X())
>> 3527539
>>
>> Python 3:
>>
>>  >>> class X(tuple):
>> ... def __eq__(self, other): return False
>>  >>> hash(X())
>> Traceback (most recent call last):
>>File "", line 1, in 
>> TypeError: unhashable type: 'X'
>>
>>
>> Interestingly, Python 2 also acts like this for *extension types* (such
>> as Cython cdef classes) but not for ordinary Python classes.
>
> --
> 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.

-- 
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.

Re: [sage-devel] Upgrade PARI to git master

[John Cremona]

On 6 September 2017 at 12:48, Jeroen Demeyer  wrote:
> On 2017-07-25 22:16, Jeroen Demeyer wrote:
>>
>> Hello sage-devel and sage-packaging,
>>
>> I propose to upgrade the PARI package to the git master version instead
>> of the current released version.
>
>
> Now that the cypari2 upgrade has been merged, I am working on this. Thanks
> to the new cypari2, *building* Sage with PARI master works out of the box
> already.
>
> There are quite a bit of doctest failures though (for now, I only tested
> src/sage/rings and src/sage/schemes/ because that is where most non-trivial
> uses of PARI are):
>
> --
> sage -t src/sage/schemes/elliptic_curves/ell_number_field.py  # 2 doctests
> failed
> sage -t src/sage/schemes/projective/projective_morphism.py  # 1 doctest
> failed
> sage -t src/sage/rings/number_field/number_field.py  # 3 doctests failed
> sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # 11
> doctests failed
> sage -t src/sage/schemes/elliptic_curves/heegner.py  # 37 doctests failed
> sage -t src/sage/rings/qqbar.py  # 2 doctests failed
> sage -t src/sage/rings/number_field/number_field_ideal.py  # 1 doctest
> failed
> sage -t src/sage/rings/number_field/number_field_rel.py  # 2 doctests failed
> sage -t src/sage/schemes/elliptic_curves/period_lattice.py  # 13 doctests
> failed
> sage -t src/sage/rings/padics/padic_capped_absolute_element.pyx  # 1 doctest
> failed
> sage -t src/sage/rings/padics/padic_capped_relative_element.pyx  # 1 doctest
> failed
> sage -t src/sage/rings/padics/padic_fixed_mod_element.pyx  # 1 doctest
> failed
> sage -t src/sage/schemes/elliptic_curves/modular_parametrization.py  # 8
> doctests failed
> --
>
> Usually, this means that the output is still correct, but different. So most
> of these will be fixed by simply changing the expected output.

Indeed.  Let me know if you want help with judging this.  I can't tell
why heegner should be so much worse

>
>
> --
> 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.

-- 
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.

Re: [sage-devel] Upgrade PARI to git master

[Jeroen Demeyer]

On 2017-07-25 22:16, Jeroen Demeyer wrote:

Hello sage-devel and sage-packaging,

I propose to upgrade the PARI package to the git master version instead
of the current released version.


Now that the cypari2 upgrade has been merged, I am working on this. 
Thanks to the new cypari2, *building* Sage with PARI master works out of 
the box already.


There are quite a bit of doctest failures though (for now, I only tested 
src/sage/rings and src/sage/schemes/ because that is where most 
non-trivial uses of PARI are):


--
sage -t src/sage/schemes/elliptic_curves/ell_number_field.py  # 2 
doctests failed
sage -t src/sage/schemes/projective/projective_morphism.py  # 1 doctest 
failed

sage -t src/sage/rings/number_field/number_field.py  # 3 doctests failed
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # 11 
doctests failed

sage -t src/sage/schemes/elliptic_curves/heegner.py  # 37 doctests failed
sage -t src/sage/rings/qqbar.py  # 2 doctests failed
sage -t src/sage/rings/number_field/number_field_ideal.py  # 1 doctest 
failed

sage -t src/sage/rings/number_field/number_field_rel.py  # 2 doctests failed
sage -t src/sage/schemes/elliptic_curves/period_lattice.py  # 13 
doctests failed
sage -t src/sage/rings/padics/padic_capped_absolute_element.pyx  # 1 
doctest failed
sage -t src/sage/rings/padics/padic_capped_relative_element.pyx  # 1 
doctest failed
sage -t src/sage/rings/padics/padic_fixed_mod_element.pyx  # 1 doctest 
failed
sage -t src/sage/schemes/elliptic_curves/modular_parametrization.py  # 8 
doctests failed

--

Usually, this means that the output is still correct, but different. So 
most of these will be fixed by simply changing the expected output.


--
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.

[sage-devel] SAGE_PATH and PYTHONPATH

[Ralf Hemmecke]

Since my settings using SAGE_PATH do seemingly not work anymore, I
looked for the use of SAGE_PATH in the sources.

I found in 7.6 some code

if [ -n "$SAGE_PATH" ]; then
PYTHONPATH="$SAGE_PATH:$PYTHONPATH"
fi

but that was removed in commit

22e470c2d6941875908f35ff3657843f1fe83f21

So it looks like SAGE_PATH is not used in 8.0 anymore although the
documentation still suggests its use.

http://doc.sagemath.org/html/en/reference/repl/environ.html

What exactly is the situation?

And how should I set a path for additional packages?

Thank you
Ralf

-- 
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.