Re: [sage-devel] Unable to compile JuPiMake

[VulK]

I can confirm: it is due to an extra space in the output of `polymake-config 
--cflags`.


Now that you pointed this out I noticed that there is already a PR open on 
this https://github.com/sebasguts/JuPyMake/pull/5 with the same error message 
I got. My google-foo is failing me.


Thanks again for the help.
S.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZYMQuSEM1m8yOLvC%40bunion.homenet.telecomitalia.it.

Re: [sage-devel] Unable to compile JuPiMake

[VulK]

Hm, my next guess is then

 https://github.com/sebasguts/JuPyMake/issues/4

since I think that's also on Gentoo. I can be more certain in a few
hours after polymake builds.


It does look so: 


$ polymake-config --cflags | grep "  " | wc -l
1

Let me try to fix this on the fly
S.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZYMO6uXUgNCqYd0L%40bunion.homenet.telecomitalia.it.

Re: [sage-devel] Re: quo_rem for multivariate Laurent polynomial rings

[VulK]

Oops, thanks for catching the mistake
S.

* dmo...@deductivepress.ca  [2021-01-17 12:01:41]:


I agree that this needs to be fixed. Offhand, I don't know what the answer
should be (for example, (1/(x*y), 0) also seems reasonable), but (0,1) is
certainly not correct. So please do open a ticket.

Please correct the typo when you make the ticket, though: q*y + r == x
should be q*y + r == 1/x (in both places).

On Sunday, January 17, 2021 at 8:25:27 AM UTC-7 Salvatore Stella wrote:


Dear all,
can someone please confirm that the current behaviour of sage is not the
expected one before I open a ticket about it?

sage: R. = LaurentPolynomialRing(QQ)
sage: q,r = (1/x).quo_rem(y) ; q,r
(0, 1)
sage: q*y + r == x
False

The correct answer should have been:

sage: R. = LaurentPolynomialRing(QQ)
sage: q,r = (1/x).quo_rem(y) ; q,r
(0, 1/x)
sage: q*y + r == x
True

Thanks
S.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b4978f27-bcfb-44c1-95a9-354275bb1b9bn%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/YASjSutxivgIkbzf%40bunion.homenet.telecomitalia.it.

[sage-devel] quo_rem for multivariate Laurent polynomial rings

[VulK]

Dear all,
can someone please confirm that the current behaviour of sage is not the 
expected one before I open a ticket about it?


sage: R. = LaurentPolynomialRing(QQ)
sage: q,r = (1/x).quo_rem(y) ; q,r
(0, 1)
sage: q*y + r  == x
False

The correct answer should have been:

sage: R. = LaurentPolynomialRing(QQ)
sage: q,r = (1/x).quo_rem(y) ; q,r
(0, 1/x)
sage: q*y + r  == x
True

Thanks
S.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/YARW3SSF%2BXAN8X9A%40bunion.homenet.telecomitalia.it.

Re: [sage-devel] Re: trouble upgrading to latest stable version

[VulK]

Unpacking of lambda functions' arguments is, alas,  no longer supported in 
python3.


cf. https://www.python.org/dev/peps/pep-3113/

S.



* Anne Schilling  [2020-05-26 11:24:01]:


Ok, success!!! Finally sage compiled for me using Matthias' suggestion of
"./configure --without-system-freetype"
before make.

Something else must have changed though since sage does not like my
sage.init file any longer:

sage
┌┐
│ SageMath version 9.1, Release Date: 2020-05-20 │
│ Using Python 3.7.7. Type "help()" for help.│
└┘
 File "", line 15
   latex_options = {'format': "dot2tex",
'edge_labels':True,'color_by_label':{Integer(1):"blue", Integer(2):"red",
Integer(3):"green", Integer(4):"yellow",-Integer(1):"blue",
-Integer(2):"red", -Integer(3):"green",-Integer(4):"yellow"},
'edge_options': lambda (u,v,l): {'backward': l is not None and
l>Integer(0)}}

^
SyntaxError: invalid syntax

On Tuesday, May 26, 2020 at 12:11:38 AM UTC-7, Matthias Koeppe wrote:


By "install freetype by hand", do you mean you installed with homebrew?
If not, that's worth trying.
Alternatively, you could try "./configure --without-system-freetype"
before "make".

Matthias

On Tuesday, May 26, 2020 at 12:06:57 AM UTC-7, Anne Schilling wrote:


https://www.math.ucdavis.edu/~anne/config.log

On Tuesday, May 26, 2020 at 12:00:46 AM UTC-7, Matthias Koeppe wrote:


config.log again please...

On Monday, May 25, 2020 at 11:53:50 PM UTC-7, Anne Schilling wrote:


Thank you! I installed all those. Now it hangs here:

https://www.math.ucdavis.edu/~anne/matplotlib-2.2.5.log

I tried to install freetype by hand, but it does not seem to help.




--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b9bd4221-3f5c-4939-b8ae-7611fc9d3c6b%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200526185919.GN29640%40bunion.homenet.telecomitalia.it.

Re: [sage-devel] Proposal for Sage 9.2: require "./configure" before "make"

[VulK]

+1 for standard behaviour


* John H Palmieri  [2020-04-18 13:51:29]:


Several of us are in favor of requiring that, in order to build Sage,
people should have to run "./configure" before running "make". I would
further propose that "make" should not itself then run "configure".

Some advantages:

- This is the same procedure used with many other software packages.
- Configuration should be done separately from building, and this makes
that separation explicit.
- It would help to avoid the issue that ./configure gets run too often; for
example, "make distclean" may cause ./configure to run.

Some disadvantages:

- It adds one step or a least requires the typing of some extra characters
- It's not what we're used to doing to build Sage.

Ticket #29316 proposes doing at least some of this, and Sage 9.2 seems like
a good time to do this. Comments?

(https://trac.sagemath.org/ticket/29316)

--
John

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5d1a5823-b4e2-498f-b73b-a2a655868039%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200418210101.GE12831%40bunion.homenet.telecomitalia.it.

Re: [sage-devel] Re: Chain Complexes and homology

[VulK]

Hi Travis (and all),
I already have a toy implementation and it is indeed worth including in sage.
Given a chain complex it produces a new chain complex that has the same 
homology but whose differentials are much much smaller.

You can look at it here: https://github.com/Etn40ff/chromatic_symmetric_homology
I'll make a ticket about this as soon as we are done with the actual writing 
of our paper.

Best
S.


* Travis Scrimshaw  [2019-11-27 07:32:59]:


From the code provided in the paper, it doesn't look too indecipherable. So
a first step might just be doing a direct translation of that since
understanding the math is not as necessary to do that.

Best,
Travis


On Thursday, November 14, 2019 at 9:01:24 PM UTC+10, Salvatore Stella wrote:


I may be interested in helping out with this but I am definitely not
knowledgeable enough on the math behind to tackle the task on my own.
S.


* John H Palmieri > [2019-11-13
18:36:25]:

>Sage is not using very sophisticated methods for computing homology. If
>anyone wants to implement something better, they are certainly welcome
to.
>I may try to look at the paper, but it may take me a while to get to it.
>
>-- John
>
>
>On Wednesday, November 13, 2019 at 4:48:18 PM UTC-8, Salvatore Stella
wrote:
>>
>> Dear All,
>> I was looking into computing homology of a certain chain complex when I
>> came
>> across this paper arXiv:1903.00783v1. Apparently he claims that he has
an
>> algorithm to do so that is much faster than the one we currently have
in
>> sage. Did I understand correctly the claim? If so, would it be worth to
>> port
>> his Mathematica code? Input from someone more knowledgeable than me on
>> (co)homology computations would be most welcome.  Thanks
>> S.
>>
>>
>
>--
>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-...@googlegroups.com .
>To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/70f6386f-8a51-40e0-9660-9110a6665826%40googlegroups.com.





--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ae3b8722-d56c-4fda-8405-312dae5a38c4%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191127153738.GC25856%40strabo.

Re: [sage-devel] Re: Chain Complexes and homology

[VulK]

I may be interested in helping out with this but I am definitely not 
knowledgeable enough on the math behind to tackle the task on my own.

S.


* John H Palmieri  [2019-11-13 18:36:25]:


Sage is not using very sophisticated methods for computing homology. If
anyone wants to implement something better, they are certainly welcome to.
I may try to look at the paper, but it may take me a while to get to it.

-- John


On Wednesday, November 13, 2019 at 4:48:18 PM UTC-8, Salvatore Stella wrote:


Dear All,
I was looking into computing homology of a certain chain complex when I
came
across this paper arXiv:1903.00783v1. Apparently he claims that he has an
algorithm to do so that is much faster than the one we currently have in
sage. Did I understand correctly the claim? If so, would it be worth to
port
his Mathematica code? Input from someone more knowledgeable than me on
(co)homology computations would be most welcome.  Thanks
S.




--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/70f6386f-8a51-40e0-9660-9110a6665826%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191114110021.GA26934%40strabo.

[sage-devel] Chain Complexes and homology

[VulK]

Dear All,
I was looking into computing homology of a certain chain complex when I came 
across this paper arXiv:1903.00783v1. Apparently he claims that he has an 
algorithm to do so that is much faster than the one we currently have in 
sage. Did I understand correctly the claim? If so, would it be worth to port 
his Mathematica code? Input from someone more knowledgeable than me on 
(co)homology computations would be most welcome.  Thanks

S.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191114004758.GI11163%40bunion.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

I am saying that I am not super fond of the idea or recompiling because of a 
java update: I can see how one could get confused. Either way, considering 
that no-one noticed this "feature" till now I doubt that this will have any 
impact.


On a side note: is jmol going to be replaced? If so, should we just ignore 
the issue?


S.




* Dima Pasechnik  [2019-11-05 10:29:52]:


On Tue, Nov 5, 2019 at 10:19 AM VulK  wrote:


I am not sure I agree with setting this at build time: a jvm could be
installed afterwards and/or updated independently of sage


if the configuration of the system has changed,
one may have to re-configure/rebuild.

Or are you saying that Sage fails to appreciate these truly unique
advantages of the superior Java technology? :-P



S.



* Michael Orlitzky
 [2019-11-04 08:49:18]:

>On 11/3/19 4:55 PM, VulK wrote:
>>
>> On the same note: the current implementation of `is_jvm_available` is not
>> really robust and I should open a ticket about this; any suggestion for a
>> better implementation?
>> S.
>>
>
>const false
>
>Does it do anything except jmol? The right way to do it would be to add
>--with-jvm=/path/to/jvm or something like that to the ./configure
>script. The is_jvm_available() implementation would then be hard-coded
>at build time, and not enabled automagically. But that's a lot of work a
>  a feature that no one's going to use after jmol is replaced.
>
>--
>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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e01aeb45-7170-ef2e-9f0b-77f5c8301a5b%40orlitzky.com.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191105101851.GA15686%40strabo.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq07PM36PvCOyvcuBerh6icyf0R-FXBR%3DybpeivSbsa%2Btg%40mail.gmail.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191105103348.GB15686%40strabo.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

I am not sure I agree with setting this at build time: a jvm could be 
installed afterwards and/or updated independently of sage

S.



* Michael Orlitzky 
 [2019-11-04 08:49:18]:



On 11/3/19 4:55 PM, VulK wrote:


On the same note: the current implementation of `is_jvm_available` is not
really robust and I should open a ticket about this; any suggestion for a
better implementation?
S.



const false

Does it do anything except jmol? The right way to do it would be to add
--with-jvm=/path/to/jvm or something like that to the ./configure
script. The is_jvm_available() implementation would then be hard-coded
at build time, and not enabled automagically. But that's a lot of work a
 a feature that no one's going to use after jmol is replaced.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e01aeb45-7170-ef2e-9f0b-77f5c8301a5b%40orlitzky.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191105101851.GA15686%40strabo.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

All test passed!

Gentoo linux running on x86_64 Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz

Three doctests in src/sage/rings/padics/padic_lattice_element.py failed on 
safe -t --all but were succesful when the file was checked individually.


I confirm my green light
S.




* Dima Pasechnik  [2019-11-03 19:16:35]:


On Sun, 3 Nov 2019, 16:57 VulK,  wrote:


I have issues with a symlink when installing ipython:

"""
  ...
  Successfully installed ipython-5.8.0
  Cleaning up...
  Removed build tracker '/tmp/pip-req-tracker-x6b62y1w'

  real0m3.382s
  user0m3.027s
  sys 0m0.498s
  Copying package files from temporary location
/opt/sage-python3/local/var/tmp/sage/build/ipython-5.8.0/inst to
/opt/sage-python3/local
  cp: not writing through dangling symlink
'/opt/sage-python3/local/./bin/ipython'
  
  Error copying files for ipython-5.8.0.
  
  ...
"""

This install was in a dir where previously I had installed using python3
and
with ./configure --with-python=3 but I ran make maintainer-clean before
attempting to compile public/python3_switch




this should be fixed in
https://trac.sagemath.org/ticket/28673


S.





* Frédéric Chapoton  [2019-11-03 05:18:13]:

>Could please some of the many plus-one-ing people try the branch at #28660
>and report there if it works for them, namely builds a working
python3-sage
>by default ?
>
>Frédéric
>
>Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :
>>
>> Maybe I missed it, but I didn't find a ticket for that. I think now
would
>> be a good time to flip the switch, though. Any thoughts?
>>
>
>--
>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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/ad9edbd6-525f-4e6c-8036-3d962e6d07a1%40googlegroups.com
.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/20191103165706.GD29746%40bunion
.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq07_FAOJfP7BXDAjtdmW1WJRunO13cExo%3D7Cu-3pSFLPw%40mail.gmail.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191104003515.GH29746%40bunion.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

I figured out that the error I posted depended on an ambient variable that I
have set um in my rc files, namely 


export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true"

with this `java -version` returns

Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (IcedTea 3.8.0) (Gentoo icedtea-3.8.0)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

and `sage.interfaces.jmoldata.JmolData.is_jvm_available` fails. This is 
independent of python3. 

On the same note: the current implementation of `is_jvm_available` is not 
really robust and I should open a ticket about this; any suggestion for a 
better implementation?

S.


* Dima Pasechnik  [2019-11-03 19:16:35]:


On Sun, 3 Nov 2019, 16:57 VulK,  wrote:


I have issues with a symlink when installing ipython:

"""
  ...
  Successfully installed ipython-5.8.0
  Cleaning up...
  Removed build tracker '/tmp/pip-req-tracker-x6b62y1w'

  real0m3.382s
  user0m3.027s
  sys 0m0.498s
  Copying package files from temporary location
/opt/sage-python3/local/var/tmp/sage/build/ipython-5.8.0/inst to
/opt/sage-python3/local
  cp: not writing through dangling symlink
'/opt/sage-python3/local/./bin/ipython'
  
  Error copying files for ipython-5.8.0.
  
  ...
"""

This install was in a dir where previously I had installed using python3
and
with ./configure --with-python=3 but I ran make maintainer-clean before
attempting to compile public/python3_switch




this should be fixed in
https://trac.sagemath.org/ticket/28673


S.





* Frédéric Chapoton  [2019-11-03 05:18:13]:

>Could please some of the many plus-one-ing people try the branch at #28660
>and report there if it works for them, namely builds a working
python3-sage
>by default ?
>
>Frédéric
>
>Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :
>>
>> Maybe I missed it, but I didn't find a ticket for that. I think now
would
>> be a good time to flip the switch, though. Any thoughts?
>>
>
>--
>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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/ad9edbd6-525f-4e6c-8036-3d962e6d07a1%40googlegroups.com
.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/20191103165706.GD29746%40bunion
.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq07_FAOJfP7BXDAjtdmW1WJRunO13cExo%3D7Cu-3pSFLPw%40mail.gmail.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191103215508.GF29746%40bunion.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

Thanks!

Next up an error while building docs

[dochtml] [discrete_]  from 
/opt/sage-python3/src/doc/en/reference/discrete_geometry/sage/geometry/triangulation/point_configuration.rst:
[dochtml] [discrete_] Traceback (most recent call last):
[dochtml] [discrete_]   File 
"/opt/sage-python3/local/lib/python3.7/site-packages/matplotlib/sphinxext/plot_directive.py",
 line 524, in run_code
[dochtml] [discrete_] six.exec_(code, ns)
[dochtml] [discrete_]   File "", line 4, in 
[dochtml] [discrete_]   File "", line 41, in sphinx_plot
[dochtml] [discrete_]   File "sage/plot/plot3d/base.pyx", line 1637, in 
sage.plot.plot3d.base.Graphics3d.save (build/cythonized/sage/plot/plot3d/base.c:21661)
[dochtml] [discrete_] self.save_image(filename, **kwds)
[dochtml] [discrete_]   File "sage/plot/plot3d/base.pyx", line 1566, in 
sage.plot.plot3d.base.Graphics3d.save_image (build/cythonized/sage/plot/plot3d/base.c:2
1219)
[dochtml] [discrete_] self._save_image_png(filename, **kwds)
[dochtml] [discrete_]   File "sage/plot/plot3d/base.pyx", line 1528, in 
sage.plot.plot3d.base.Graphics3d._save_image_png (build/cythonized/sage/plot/plot3d/bas
e.c:20856)
[dochtml] [discrete_] scene = self._rich_repr_jmol(**opts)
[dochtml] [discrete_]   File "sage/plot/plot3d/base.pyx", line 261, in 
sage.plot.plot3d.base.Graphics3d._rich_repr_jmol (build/cythonized/sage/plot/plot3d/base
.c:7224)
[dochtml] [discrete_] if not jdata.is_jvm_available():
[dochtml] [discrete_]   File 
"/opt/sage-python3/local/lib/python3.7/site-packages/sage/interfaces/jmoldata.py",
 line 70, in is_jvm_available
[dochtml] [discrete_] java_version_number = int(re.sub(r'.*version 
"(0\.|1\.)?(\d*)[\s\S]*', r'\2', version))
[dochtml] [discrete_] ValueError: invalid literal for int() with base 10: 
'Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on 
-Dswing.aatext=true\n8'

S.

* Dima Pasechnik  [2019-11-03 19:16:35]:


On Sun, 3 Nov 2019, 16:57 VulK,  wrote:


I have issues with a symlink when installing ipython:

"""
  ...
  Successfully installed ipython-5.8.0
  Cleaning up...
  Removed build tracker '/tmp/pip-req-tracker-x6b62y1w'

  real0m3.382s
  user0m3.027s
  sys 0m0.498s
  Copying package files from temporary location
/opt/sage-python3/local/var/tmp/sage/build/ipython-5.8.0/inst to
/opt/sage-python3/local
  cp: not writing through dangling symlink
'/opt/sage-python3/local/./bin/ipython'
  
  Error copying files for ipython-5.8.0.
  
  ...
"""

This install was in a dir where previously I had installed using python3
and
with ./configure --with-python=3 but I ran make maintainer-clean before
attempting to compile public/python3_switch




this should be fixed in
https://trac.sagemath.org/ticket/28673


S.





* Frédéric Chapoton  [2019-11-03 05:18:13]:

>Could please some of the many plus-one-ing people try the branch at #28660
>and report there if it works for them, namely builds a working
python3-sage
>by default ?
>
>Frédéric
>
>Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :
>>
>> Maybe I missed it, but I didn't find a ticket for that. I think now
would
>> be a good time to flip the switch, though. Any thoughts?
>>
>
>--
>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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/ad9edbd6-525f-4e6c-8036-3d962e6d07a1%40googlegroups.com
.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/20191103165706.GD29746%40bunion
.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq07_FAOJfP7BXDAjtdmW1WJRunO13cExo%3D7Cu-3pSFLPw%40mail.gmail.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191103185015.GE29746%40bunion.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

I have issues with a symlink when installing ipython:

"""
 ...
 Successfully installed ipython-5.8.0
 Cleaning up...
 Removed build tracker '/tmp/pip-req-tracker-x6b62y1w'

 real0m3.382s
 user0m3.027s
 sys 0m0.498s
 Copying package files from temporary location 
/opt/sage-python3/local/var/tmp/sage/build/ipython-5.8.0/inst to 
/opt/sage-python3/local
 cp: not writing through dangling symlink 
'/opt/sage-python3/local/./bin/ipython'
 
 Error copying files for ipython-5.8.0.
 
 ...
"""

This install was in a dir where previously I had installed using python3 and 
with ./configure --with-python=3 but I ran make maintainer-clean before 
attempting to compile public/python3_switch

S.




* Frédéric Chapoton  [2019-11-03 05:18:13]:


Could please some of the many plus-one-ing people try the branch at #28660
and report there if it works for them, namely builds a working python3-sage
by default ?

Frédéric

Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :


Maybe I missed it, but I didn't find a ticket for that. I think now would
be a good time to flip the switch, though. Any thoughts?



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ad9edbd6-525f-4e6c-8036-3d962e6d07a1%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191103165706.GD29746%40bunion.

Re: [sage-devel] Re: Switch to Python 3 by default

[VulK]

Building now
S.


* Frédéric Chapoton  [2019-11-03 05:18:13]:


Could please some of the many plus-one-ing people try the branch at #28660
and report there if it works for them, namely builds a working python3-sage
by default ?

Frédéric

Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :


Maybe I missed it, but I didn't find a ticket for that. I think now would
be a good time to flip the switch, though. Any thoughts?



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ad9edbd6-525f-4e6c-8036-3d962e6d07a1%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191103134629.GC29746%40bunion.

Re: [sage-devel] Switch to Python 3 by default

[VulK]

+1

* Samuel Lelievre  [2019-10-26 22:29:40]:


+1

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ca69beab-7948-4c5a-8530-9bd13bd299d5%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20191027102802.GC9511%40bunion.

Re: [sage-devel] Re: UniqueRepresentation inheritance and __classcall__

[VulK]

Indeed it seems to be documented. Why is this not in the online 
documentation?

S.


* Travis Scrimshaw  [2019-09-26 17:59:38]:


There is also an example of this inheritance and discussion in one of the
sage.structure.unique_representation examples.

Best,
Travis


On Friday, September 27, 2019 at 10:57:52 AM UTC+10, Travis Scrimshaw wrote:



The prototype does, now I have to implement the real thing.


Is there any way to add this info to the documentation? It took me a lot
of
trial and error to figure out how to do what I wanted.
S.

Definitely. The topical place would be in sage.misc.classcall_metaclass,

since that is the module that implements the __classcall__ mechanism.
That's also the documentation you find when you google "__classcall__"
(once you convince google you don't want the results for __call__).



This is actually documented. The problem is the
ClasscallMetaclass.__call__ is not in the online documentation (in some
sense, Google does know better :P).

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ef937635-dbf2-4e7e-ab85-6ef5c8a24335%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20190927104200.GM22409%40strabo.

Re: [sage-devel] Re: UniqueRepresentation inheritance and __classcall__

[VulK]

The prototype does, now I have to implement the real thing.

Is there any way to add this info to the documentation? It took me a lot of 
trial and error to figure out how to do what I wanted.

S.


* Travis Scrimshaw  [2019-09-26 15:11:07]:


So it works now, correct?

Best,
Travis


On Friday, September 27, 2019 at 12:42:23 AM UTC+10, Salvatore Stella wrote:


Oops, I think that I figured out where the mistake was. Here is the
correct
code:

class OldFoo(UniqueRepresentation):

@staticmethod
def __classcall__(self, data, **kwargs):
hashable_data = tuple(data)
kwargs['some_default_option'] = 'bar'
return super(OldFoo, self).__classcall__(self, hashable_data,
**kwargs)

def __init__(self, data, **kwargs):
self._data = data
self._some_default_option = kwargs['some_default_option']

def __repr__(self):
return 'Data = %s, option = %s'%(self._data,
self._some_default_option)

class NewFoo(OldFoo):

@staticmethod
def __classcall__(self, data, **kwargs):
new_data = data+data
return super(NewFoo, self).__classcall__(self, new_data, **kwargs)


Thanks
S.



* Travis Scrimshaw > [2019-09-25
16:59:13]:

>Although it almost sounds like you should be doing the NewFoo preparsing
>inside NewFoo.__classcall__ (or NewFoo.__classcall_private__), which then
>should get passed up and handled by OldFoo.__classcall__. You might need
>some extra *args or **kwds to the __init__ and/or __classcall__ to handle
>this. The other option would be to separate out the preparsing portion
into
>a separate @classmethod or @staticmethod.
>
>Best,
>Travis
>
>
>On Thursday, September 26, 2019 at 9:55:56 AM UTC+10, Travis Scrimshaw
>wrote:
>>
>> Make OldFoo.__classcall_private__, then it is not inherited.
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, September 26, 2019 at 8:22:23 AM UTC+10, Salvatore Stella
>> wrote:
>>>
>>> Dear All,
>>> I would like to make a new class inheriting from a class based on
>>> UniqueRepresentation. My goal, among other things, is to preparse the
>>> arguments a little before calling the class I am inheriting from.
>>> Unfortunately this class also does some preparsing via __classcall__
to
>>> make
>>> the input hashable. Could you point me to the correct way of setting
this
>>> up?
>>>
>>> Sketch of the situation:
>>>
>>> class OldFoo(UniqueRepresentation):
>>>
>>> @staticmethod
>>> def __classcall__(self, data):
>>># make data hashable
>>>return super(oldFoo, self).__classcall__(self, hashable_data)
>>>
>>> def __init__(self, hashable_data):
>>> # do something
>>>
>>> class NewFoo(OldFoo):
>>>
>>> # First neutralize OldFoo __classcall__
>>> __classcall__ = None
>>>
>>> def __init__(self, data):
>>> # preparse data then initialize OldFoo
>>>
>>>
>>> If __classcall__ were not there I would call OldFoo.__init__ but this
>>> does
>>> not seem to work with OldFoo.__classcall__
>>>
>>>
>>> Thanks
>>> S.
>>>
>>>
>>>
>>>
>
>--
>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-...@googlegroups.com .
>To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/5475d883-8c54-4a8b-8fb5-f33859e464a3%40googlegroups.com.





--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/869947d6-8388-4455-96a2-75550bad4dd1%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20190926221344.GA22561%40bunion.

Re: [sage-devel] Re: UniqueRepresentation inheritance and __classcall__

[VulK]

Oops, I think that I figured out where the mistake was. Here is the correct 
code:


class OldFoo(UniqueRepresentation):

   @staticmethod
   def __classcall__(self, data, **kwargs):
   hashable_data = tuple(data)
   kwargs['some_default_option'] = 'bar'
   return super(OldFoo, self).__classcall__(self, hashable_data, **kwargs)

   def __init__(self, data, **kwargs):
   self._data = data
   self._some_default_option = kwargs['some_default_option']

   def __repr__(self):
   return 'Data = %s, option = %s'%(self._data, self._some_default_option)

class NewFoo(OldFoo):

   @staticmethod
   def __classcall__(self, data, **kwargs):
   new_data = data+data
   return super(NewFoo, self).__classcall__(self, new_data, **kwargs)


Thanks
S.



* Travis Scrimshaw  [2019-09-25 16:59:13]:


Although it almost sounds like you should be doing the NewFoo preparsing
inside NewFoo.__classcall__ (or NewFoo.__classcall_private__), which then
should get passed up and handled by OldFoo.__classcall__. You might need
some extra *args or **kwds to the __init__ and/or __classcall__ to handle
this. The other option would be to separate out the preparsing portion into
a separate @classmethod or @staticmethod.

Best,
Travis


On Thursday, September 26, 2019 at 9:55:56 AM UTC+10, Travis Scrimshaw
wrote:


Make OldFoo.__classcall_private__, then it is not inherited.

Best,
Travis


On Thursday, September 26, 2019 at 8:22:23 AM UTC+10, Salvatore Stella
wrote:


Dear All,
I would like to make a new class inheriting from a class based on
UniqueRepresentation. My goal, among other things, is to preparse the
arguments a little before calling the class I am inheriting from.
Unfortunately this class also does some preparsing via __classcall__ to
make
the input hashable. Could you point me to the correct way of setting this
up?

Sketch of the situation:

class OldFoo(UniqueRepresentation):

@staticmethod
def __classcall__(self, data):
   # make data hashable
   return super(oldFoo, self).__classcall__(self, hashable_data)

def __init__(self, hashable_data):
# do something

class NewFoo(OldFoo):

# First neutralize OldFoo __classcall__
__classcall__ = None

def __init__(self, data):
# preparse data then initialize OldFoo


If __classcall__ were not there I would call OldFoo.__init__ but this
does
not seem to work with OldFoo.__classcall__


Thanks
S.






--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5475d883-8c54-4a8b-8fb5-f33859e464a3%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20190926144141.GL22409%40strabo.

Re: [sage-devel] Re: UniqueRepresentation inheritance and __classcall__

[VulK]

Thank you Travis for your reply. Here is an attempt at implementing your 
suggestion that does not work: it looks like OldFoo.__classcall__ is skipped 
and OldFoo.__init__ is run directly instead. This is not what I want: I would 
like the preparsing in OldFoo to still be performed after the preparsing in 
NewFoo


class OldFoo(UniqueRepresentation):

   @staticmethod
   def __classcall__(self, data, **kwargs):
   hashable_data = tuple(data)
   kwargs['some_default_option'] = 'bar'
   return super(OldFoo, self).__classcall__(self, hashable_data, **kwargs)

   def __init__(self, data, **kwargs):
   self._data = data
   self._some_default_option = kwargs['some_default_option']

   def __repr__(self):
   return 'Data = %s, option = %s'%(self._data, self._some_default_option)

class NewFoo(OldFoo):

   @staticmethod
   def __classcall__(self, data, **kwargs):
   new_data = data+data
   return super(OldFoo, self).__classcall__(self, new_data, **kwargs)


If you try this code it runs as follows:

sage: OldFoo([0,1,2,3])
Data = (0, 1, 2, 3), option = bar
sage: NewFoo([0,1,2,3])
...
TypeError: unhashable type: 'list'
sage: NewFoo((0,1,2,3))
...
KeyError: 'some_default_option'


Thanks
S.


* Travis Scrimshaw  [2019-09-25 16:59:13]:


Although it almost sounds like you should be doing the NewFoo preparsing
inside NewFoo.__classcall__ (or NewFoo.__classcall_private__), which then
should get passed up and handled by OldFoo.__classcall__. You might need
some extra *args or **kwds to the __init__ and/or __classcall__ to handle
this. The other option would be to separate out the preparsing portion into
a separate @classmethod or @staticmethod.

Best,
Travis


On Thursday, September 26, 2019 at 9:55:56 AM UTC+10, Travis Scrimshaw
wrote:


Make OldFoo.__classcall_private__, then it is not inherited.

Best,
Travis


On Thursday, September 26, 2019 at 8:22:23 AM UTC+10, Salvatore Stella
wrote:


Dear All,
I would like to make a new class inheriting from a class based on
UniqueRepresentation. My goal, among other things, is to preparse the
arguments a little before calling the class I am inheriting from.
Unfortunately this class also does some preparsing via __classcall__ to
make
the input hashable. Could you point me to the correct way of setting this
up?

Sketch of the situation:

class OldFoo(UniqueRepresentation):

@staticmethod
def __classcall__(self, data):
   # make data hashable
   return super(oldFoo, self).__classcall__(self, hashable_data)

def __init__(self, hashable_data):
# do something

class NewFoo(OldFoo):

# First neutralize OldFoo __classcall__
__classcall__ = None

def __init__(self, data):
# preparse data then initialize OldFoo


If __classcall__ were not there I would call OldFoo.__init__ but this
does
not seem to work with OldFoo.__classcall__


Thanks
S.






--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5475d883-8c54-4a8b-8fb5-f33859e464a3%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20190926110327.GH22409%40strabo.

[sage-devel] UniqueRepresentation inheritance and __classcall__

[VulK]

Dear All,
I would like to make a new class inheriting from a class based on 
UniqueRepresentation. My goal, among other things, is to preparse the 
arguments a little before calling the class I am inheriting from.
Unfortunately this class also does some preparsing via __classcall__ to make 
the input hashable. Could you point me to the correct way of setting this up?


Sketch of the situation:

class OldFoo(UniqueRepresentation):
   
   @staticmethod

   def __classcall__(self, data):
  # make data hashable
  return super(oldFoo, self).__classcall__(self, hashable_data)

   def __init__(self, hashable_data):
   # do something

class NewFoo(OldFoo):
   
   # First neutralize OldFoo __classcall__

   __classcall__ = None

   def __init__(self, data):
   # preparse data then initialize OldFoo


If __classcall__ were not there I would call OldFoo.__init__ but this does 
not seem to work with OldFoo.__classcall__



Thanks
S.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20190925222158.GE27171%40bunion.

Re: [sage-devel] Re: CHomP

[VulK]

Thanks I'll have a look into that.
S.


* John H Palmieri  [2019-05-03 10:57:31]:




On Friday, May 3, 2019 at 10:22:25 AM UTC-7, Salvatore Stella wrote:


Hi All,
has anyone tried installing CHomP recently? For me it fails applying
patches.
It is an old-style package and apparently it is very stale; does it
provide
any tangible speedup in `ChainComplex_class.homology` compared to the
default
pari algorithm?
Thanks
S.


It used to provide a speed up in computing the homology of simplicial

complexes; if I remember right, it was also faster with homology of chain
complexes.

https://trac.sagemath.org/ticket/15202 is an old ticket for converting
CHomP to a new-style package, but no one has worked on it in a few years.

--
John

--
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] CHomP

[VulK]

Hi All,
has anyone tried installing CHomP recently? For me it fails applying patches.
It is an old-style package and apparently it is very stale; does it provide 
any tangible speedup in `ChainComplex_class.homology` compared to the default 
pari algorithm?

Thanks
S.


--
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: CachedInParentMethod clear cache

[VulK]

I was being stupid and pretended to clear the cache by hand *facepalm*.
I can confirm that doing things properly everything works as expected.
Sorry about the noise
S.


* Nils Bruin  [2019-01-08 08:47:54]:


On Tuesday, January 8, 2019 at 6:21:39 AM UTC-8, Salvatore Stella wrote:


Dear all,
sorry for disappearing on this. I am a little confused: if both parent and
element refer to the same cache how is it possible that clearing one does
not
clear the other?
S.



If you have
D={1:1}
A=D
B=D

You have two references to the same dictionary. Executing

A.clear()

will lead to B pointing to an empty dictionary (the same one A is pointing
to). If however you do

A={}

then A will be pointing to a fresh empty dict and B will still be pointing
to the original dictionary, which is not empty.

Is that perhaps how you were trying to clear the cache?

As far as I can see, calling clear on the one reference of the cache also
ensures that the other reference points to an empty cache.

--
Incidentally, I found an error in sage/misc/cachefunc.pyx:3286.

   try:
   P = inst.parent()
   return P.__dict__.setdefault(self._cache_name, default)
   except AttributeError:
   pass
   if not hasattr(P,'__cached_methods'):

If "P=inst.parent()" fails with an AttributeError then this gets silence
and the "hasattr" fails due to P not having been assigned. I think the
initialization of P should be moved out of the try block. It's the lookup
of P.__dict__ that should be silenced, not the initialization of P.

--
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] Re: CachedInParentMethod clear cache

[VulK]

Dear all,
sorry for disappearing on this. I am a little confused: if both parent and 
element refer to the same cache how is it possible that clearing one does not 
clear the other?

S.


* E. Madison Bray  [2019-01-08 14:49:36]:


On Tue, Jan 8, 2019 at 1:51 AM Nils Bruin  wrote:


On Monday, January 7, 2019 at 12:48:30 PM UTC-8, Simon King wrote:I did the 
implementation a couple of years ago, so, it is possible that


I misremember. However, if I recall correctly, having a reference
directly from the wrapped method to the cache, rather than going from the
wrapped method to the instance to which the method is bound and finally
to an item of the __dict__ of the instance, had a noticeable effect.


Yes, by the time you're operating on cython level, saving a few 
attribute/dictionary lookups can be quite measurable.


Indeed--I was tired when I wrote my last message and did not mean
"either way" the way it reads.  I specifically meant that two separate
caches seemed unnecessary.  But each element having its own reference
to the cache can definitely be a speedup.  In that case I don't see
what the problem is.

--
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] Inheriting from MPolynomialRing_libsingular crashes sage

[VulK]

Dear All,
I just came acreoss the following strange behavior:

{{{
   sage: from sage.rings.polynomial.multi_polynomial_libsingular import 
MPolynomialRing_libsingular

   # This works as expected
   sage: MPolynomialRing_libsingular(QQ, 2, ['x','y'], 'degrevlex')
   Multivariate Polynomial Ring in x, y over Rational Field
   
   # But this crashes sage with a segmentation fault and core dump

   sage: class Test(MPolynomialRing_libsingular):
   : pass
   sage: Test(QQ, 2, ['x','y'], 'degrevlex')
   
}}}


At first I thought it might be something related to the fact that 
MPolynomialRing_libsingular is a cython class but this other example works as

one would expect:

{{{
   sage: from sage.rings.polynomial.pbori import BooleanPolynomialRing

   # As expected
   sage: BooleanPolynomialRing(2, ['x','y'], 'degrevlex')
   Boolean PolynomialRing in x, y

   # As expacted
   sage: class Test2(BooleanPolynomialRing):
   : pass
   sage: Test2(2, ['x','y'], 'degrevlex')
   Boolean PolynomialRing in x, y

}}}

Am I missing something?
Thanks
S.

--
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: Delaying 8.5 or fast-tracking 8.6?

[VulK]

Same here

* 'Martin R' via sage-devel  [2018-12-20 00:36:35]:


I have very little time, but if someone posts very precise compilation
instructions to upgrade from current develop, I would let my computer play
with it in the background.

(currently compiling 8.5.rc1)

In particular: was gap 4.10 already tested with optional packages like
coxeter3 and the experimental gap3 package?

Martin

Am Donnerstag, 20. Dezember 2018 08:41:40 UTC+1 schrieb Emmanuel
Charpentier:


Well...

Gap 4.10 and associated packages are a large change. I can't see it going
straight from positive_review to release. Including it would entail at
least a 8.5.rc2, and a decent shakedown period. This argues strongly in
favor of Volker's suggestion of releasing 8.5 "as is" from 8.5.rc1.

But let's look at an alternative, aiming at advancing Debian's Sage and
supporting software as far as possible :

Le jeudi 20 décembre 2018 00:12:42 UTC+1, Dima Pasechnik a écrit :


I`ve just given #22626 (port gap/libgap to GAP 4.10) a positive
review (Erik deserves a round of applause for this great work!)
And the associated #26856 (gap_packages/database) will be up for
reviewing very soon,
I`m just running one last round of tests; that is, it should be possible
to get
GAP 4.10 ready on the 20.12.



Nice ! That would allow 8.5.rc2 about Dec, 22 and, if all goes well and
Volker _ajuvante_, 8.5 release on Dec 29.

What about Debian packaging ? Postulating 8.5 release on Dec 29, cant Sage
be packaged and uploaded to unstable before Jan. 12 ?



How about trying to get this into 8.5? (or perhaps 8.5.1?)



Call that 8.6 rather than 8.5.1 (better marketing...). But 8.5 would be
even better...



Dima

On Wed, Dec 19, 2018 at 8:34 PM Volker Braun  wrote:
>
> I'm inclined to release 8.5 this weekend...
>
> --
> 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] CachedInParentMethod clear cache

[VulK]

Dear All,
I am working on some multivariate polynomial ring and I need to be able to 
repeatedly evaluate some elements numerically. Since the elements I am 
evaluating are few while the number of evaluations is high I thought to cache 
the result of this evaluation. Every now and then I need to change the random 
sequence of numbers I evaluate at but keep the same polynomials.  
@cached_in_parent_method seemed the tool for the job. As the name suggests, 
it should stores the cache in the parent so that it should be sufficient to 
clear the cache there to propagate the changes to all the elements. 

Unfortunately this is not the case; this method store its cache *both* in the 
parent and in the element. Apparently this was done in #8611 for speed 
reasons. I do not really understand the rationale behind this though. Why do 
we need to keep two copies of the cache?


Best
S.


--
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: Implementing rings of coordinates

[VulK]

There is now a ticket (#26741) ready for review in which the changes have 
been implemented. I decided not to refactor __call__ because the number of 
failing doctest was quite big. Maybe this is a project for a separate ticket.


I have no idea on how to test reliably if the changes introduced any 
measurable slowdown. Can anyone chime in on how to do it?

Thanks
S.



* Nils Bruin  [2018-11-22 11:10:11]:


Pay attention, though. There may be all kinds of guidelines about how to
write sage code "appropriately", but in classes where performance is very
important there may be shortcuts that violate the guidelines. That may very
well be intentional. It may also be that it's legacy code and that
rewriting it according to the latest trends does not particularly affect
performance negatively.

On Thursday, November 22, 2018 at 9:48:41 AM UTC-8, Salvatore Stella wrote:


After a more accurate inspection, it appears that MPolynomialRing_polydict
is
in quite a bad shape. First of all it redefines __call__ which, if I read
[1]
correctly, should not be done. Second, within the many cases in __call__
one
can find:

{{{
510 elif isinstance(x, dict):
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in
iteritems(x)})
}}}

and few lines below

{{{
561 if isinstance(x, dict):
562 return MPolynomial_polydict(self, x)
}}}

Clearly some housekeeping is in order. I'll try to do something about it
and
then post again. Any input is welcome
S.

[1]
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics




* Simon King > [2018-11-22 14:10:14]:

>On 2018-11-22, Simon King > wrote:
>> However, I believe it is bad usage to hard-code a certain class as
>> output of arithmetic errors.
>
>Oops. "errors" is an error, it should be "operations".
>
>--
>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.

Re: [sage-devel] Re: Implementing rings of coordinates

[VulK]

You make a very good point, I'll try to be careful. I doubt this is a case of 
efficiency since now __call__ goes through redundant cases and even has an 
argument that is not used anywhere. Anyway I will cobble together something 
and we can do speed testing before merging.




* Nils Bruin  [2018-11-22 11:10:11]:


Pay attention, though. There may be all kinds of guidelines about how to
write sage code "appropriately", but in classes where performance is very
important there may be shortcuts that violate the guidelines. That may very
well be intentional. It may also be that it's legacy code and that
rewriting it according to the latest trends does not particularly affect
performance negatively.

On Thursday, November 22, 2018 at 9:48:41 AM UTC-8, Salvatore Stella wrote:


After a more accurate inspection, it appears that MPolynomialRing_polydict
is
in quite a bad shape. First of all it redefines __call__ which, if I read
[1]
correctly, should not be done. Second, within the many cases in __call__
one
can find:

{{{
510 elif isinstance(x, dict):
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in
iteritems(x)})
}}}

and few lines below

{{{
561 if isinstance(x, dict):
562 return MPolynomial_polydict(self, x)
}}}

Clearly some housekeeping is in order. I'll try to do something about it
and
then post again. Any input is welcome
S.

[1]
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics




* Simon King > [2018-11-22 14:10:14]:

>On 2018-11-22, Simon King > wrote:
>> However, I believe it is bad usage to hard-code a certain class as
>> output of arithmetic errors.
>
>Oops. "errors" is an error, it should be "operations".
>
>--
>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.

Re: [sage-devel] Re: Implementing rings of coordinates

[VulK]

After a more accurate inspection, it appears that MPolynomialRing_polydict is
in quite a bad shape. First of all it redefines __call__ which, if I read [1]
correctly, should not be done. Second, within the many cases in __call__ one
can find:

{{{
510 elif isinstance(x, dict):
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in 
iteritems(x)})
}}}

and few lines below

{{{
561 if isinstance(x, dict):
562 return MPolynomial_polydict(self, x)
}}}

Clearly some housekeeping is in order. I'll try to do something about it and 
then post again. Any input is welcome

S.

[1] 
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics




* Simon King  [2018-11-22 14:10:14]:


On 2018-11-22, Simon King  wrote:

However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.


Oops. "errors" is an error, it should be "operations".

--
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] Re: Implementing rings of coordinates

[VulK]

Done: https://trac.sagemath.org/ticket/26741
It appears that the change messes up with coercions. More details in the 
ticket description.

S.



* Simon King  [2018-11-22 14:10:14]:


On 2018-11-22, Simon King  wrote:

However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.


Oops. "errors" is an error, it should be "operations".

--
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] Re: Implementing rings of coordinates

[VulK]

Dear All,
I decided to try inheriting from polynomials, specifically from 
`MPolynomialRing_polydict` and `MPolynomial_polydict`, but I noticed 
something strange: is there any reason why `MPolynomialRing_polydict` 
hardcodes `MPolynomial_polydict` as its element class?


I would have expected something like 


```
class MPolynomialRing_polydict( MPolynomialRing_macaulay2_repr, 
PolynomialRing_singular_repr, MPolynomialRing_base):

   Element = MPolynomial_polydict
```
followed by the use of `Element` whenever this was needed. Instead this class 
defines a method `_poly_class` which is only used once in `__init__` to 
define generators (at line 142). Afterwards, every method that needs to build 
elements imports again MPolynomial_polydict. This happens for example at line 
437 for `__call__` and again at line 646 for `monomial_quotient`.


This obviously makes it complicated to add funtionality to the elements.
Thanks
S.




* Simon King  [2018-11-21 12:03:24]:


Dear S.,

On 2018-11-20, VulK  wrote:

I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.

Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?

From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?


I guess as the author of InfinitePolynomial*, I should chime in.

Unfortunately I don't know the background of what you want to achieve.
In particular, I don't know what indexing set you need. Of course,
changing _repr_ in a sub-class is not a hack but common usage.

Perhaps I should try to explain the purpose of InfinitePolynomial: You
have a finite list of symbols and for each symbol you have a family of
generators indexed by natural numbers. Together, they generate a free
commutative K-algebra R (an "infinite polynomial ring"), where K is a field.
Then, the symmetric group S of the natural numbers acts on each family
of generators by permuting indices. Any ideal J in R that is (as a set)
invariant under the S-action is finitely generated in the sense that there
is a finite list of elements g1,...,gn of J such that the union of the
S-orbits of g1,...,gn generates J as an R-ideal. Moreover, ideal
containment can be effectively tested by some flavour of Gröbner basis
theory ("symmetric Gröbner bases").

The purpose of my implementation is to compute symmetric Gröbner bases
and test ideal containment.

Is any of that useful for your application? Or do you just need an
algebra with an indexed family of generators? Then, I suppose it is
possible to implement it using the stuff in sage.sets.family, together
with sage.combinat.free_module.CombinatorialFreeModule

Inspite of its name, CombinatorialFreeModule can be used to implement an
algebra. Beware, however, that it is all a very *general* implementation in
*Python* (not Cython) and (I think) quite convoluted and indirect [e.g.,
apparently one is supposed to implement multiplication of elements not
by providing _mul_ for the elements but by providing a method
product_on_basis for the ring, which is then used in a multiplication
method (again not of the elements but of the ring) that is provided by
the category of AlgebrasWithBasis that is then finally used in a
multiplication method for elements that (if I recall correctly) also is
implemented in Python and is inherited from the category framework].

So, my impression has been that CombinatorialFreeModule is by design not
to be competitive in terms of speed. But I am sure that other people will
disagree with me on that point.

I would recommend to find an appropriate Cython base class for your elements.
You'd sub-class it (in Cython, if you care for speed), by providing _mul_
and _lmul_ for the elements. The parent (i.e., ring) can very well be
implemented in Python, as typically speed matters less for the ring than
for its elements. I could actually imagine to use
CombinatorielFreeModule to implement the ring, but without relying on
product_on_basis, and use a Cython class for the elements.

And please do use the category and coercion framework! You may want to
read this thematic tutorial:
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html


In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?


There is no default implementation for the __call__() method of ring
elements. So, I guess you can just provide it. It's the usual cython way
of making something callable.

Best regards,
Si

Re: [sage-devel] Re: Implementing rings of coordinates

[VulK]

Hi Simon,
thank you for the explanation. As you guessed I do not need ideals nor 
Gröbner basis. Forget for the moment the matter of infinitely many 
generators: what I would like to implement is a polynomial ring whose 
variables are certain functions. One possible way to do this would be to wrap 
around multivariate polynomials with a class that keeps a dictionary in 
between the actual dummy variables in the ring and the functions I would like 
as generators. I would then perform substitutions every time that's needed.  
My impression though is that this will get soon very messy.


Going the CombinatorialFreeModule route sounds like a good option (speed is 
not a concern at the moment) but I am not sure if there is any facility 
already in place to build a monomial basis out of some generators.


Thanks again
Salvatore




* Simon King  [2018-11-21 12:03:24]:


Dear S.,

On 2018-11-20, VulK  wrote:

I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.

Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?

From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?


I guess as the author of InfinitePolynomial*, I should chime in.

Unfortunately I don't know the background of what you want to achieve.
In particular, I don't know what indexing set you need. Of course,
changing _repr_ in a sub-class is not a hack but common usage.

Perhaps I should try to explain the purpose of InfinitePolynomial: You
have a finite list of symbols and for each symbol you have a family of
generators indexed by natural numbers. Together, they generate a free
commutative K-algebra R (an "infinite polynomial ring"), where K is a field.
Then, the symmetric group S of the natural numbers acts on each family
of generators by permuting indices. Any ideal J in R that is (as a set)
invariant under the S-action is finitely generated in the sense that there
is a finite list of elements g1,...,gn of J such that the union of the
S-orbits of g1,...,gn generates J as an R-ideal. Moreover, ideal
containment can be effectively tested by some flavour of Gröbner basis
theory ("symmetric Gröbner bases").

The purpose of my implementation is to compute symmetric Gröbner bases
and test ideal containment.

Is any of that useful for your application? Or do you just need an
algebra with an indexed family of generators? Then, I suppose it is
possible to implement it using the stuff in sage.sets.family, together
with sage.combinat.free_module.CombinatorialFreeModule

Inspite of its name, CombinatorialFreeModule can be used to implement an
algebra. Beware, however, that it is all a very *general* implementation in
*Python* (not Cython) and (I think) quite convoluted and indirect [e.g.,
apparently one is supposed to implement multiplication of elements not
by providing _mul_ for the elements but by providing a method
product_on_basis for the ring, which is then used in a multiplication
method (again not of the elements but of the ring) that is provided by
the category of AlgebrasWithBasis that is then finally used in a
multiplication method for elements that (if I recall correctly) also is
implemented in Python and is inherited from the category framework].

So, my impression has been that CombinatorialFreeModule is by design not
to be competitive in terms of speed. But I am sure that other people will
disagree with me on that point.

I would recommend to find an appropriate Cython base class for your elements.
You'd sub-class it (in Cython, if you care for speed), by providing _mul_
and _lmul_ for the elements. The parent (i.e., ring) can very well be
implemented in Python, as typically speed matters less for the ring than
for its elements. I could actually imagine to use
CombinatorielFreeModule to implement the ring, but without relying on
product_on_basis, and use a Cython class for the elements.

And please do use the category and coercion framework! You may want to
read this thematic tutorial:
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html


In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?


There is no default implementation for the __call__() method of ring
elements. So, I guess you can just provide it. It's the usual cython way
of making something callable.

Best regards,
Simon

--
You received this message because you are subscribed to the Google Groups 
"sage-devel&qu

[sage-devel] Implementing rings of coordinates

[VulK]

Dear all,
I am trying to implement the ring of coordinates of a Lie group in the 
perspective of Peter-Weyl theorem.


Concretely I would like to define a polynomial ring with infinitely many 
generators each depending on two points on a lattice. These generators 
satisfy many relations but, for the moment, I am happy to forget this fact.  
Is this possible in the current sage framework? Which are the classes I 
should inherit from?


From a quick look at available classes it looks like InfinitePolynomialRing 
and InfinitePolynomial might be the one I am after but I do not see how to 
change the indexing sets as I need apart from brute force: I could keep a 
dictionary and hack _repr_ accordingly. Any better idea?


In a second moment I would like to be able to evaluate the element of this 
ring at point on the group; is there a way to make them callable?

Thanks
S.


--
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] first python3 build of sage

[VulK]

Indeed if one comments line 847 in src/setup.py the files looks to be there.  
Sage crashes anyway but now:



VulK@bunion /mnt/backup/sage-py3 (git)-[my_py3] % ./sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
* Do not do anything with other copies of Sage on your system.
* Do not use this for installing Sage packages using "sage -i" or for
  running "make" at Sage's root directory.  These should be done
  outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/mnt/backup/sage-py3
(sage-sh) VulK@bunion:/mnt/backup/sage-py3$ python3
Python 3.5.1 (default, Apr 20 2017, 12:56:34)
[GCC 4.9.4] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sage.all

Traceback (most recent call last):
 File "", line 1, in 
 File "/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/all.py", line 87, 
in 
   from sage.misc.all   import * # takes a while
 File "/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/misc/all.py", line 
27, in 
   from .html import html
 File "/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/misc/html.py", 
line 20, in 
   from sage.misc.latex import latex
 File "/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/misc/latex.py", 
line 408, in 
   long: str,
NameError: name 'long' is not defined






* Frédéric Chapoton <fchapot...@gmail.com> [2017-04-20 00:46:52]:


~/sage3/src/build$ find -name "*.so"

returns nothing :(

Le jeudi 20 avril 2017 09:35:50 UTC+2, vdelecroix a écrit :


Can you look at SAGE_ROOT/src/build and try to find is there is a .so
there. For example

$ find $(sage -root)/src/build -name "*.so"

(normally there should be, the cythonization process put stuff there)

On 20/04/2017 09:07, Frédéric Chapoton wrote:
> STOP ! you should export SAGE_PYTHON3=yes
>
> Le jeudi 20 avril 2017 09:02:54 UTC+2, Frédéric Chapoton a écrit :
>>
>> Really 355 ? More like 20, but I agree that it is a mess.
>>
>> This is my own experimental branch, not for evereybody's eyes.. It is
made
>> from 22764, 22756, 22305 and 22775
>>
>> plus one own commit that takes care (not in a good way) of the last two
>> calls to cmp() in pyx files.
>>
>> Frederic
>>
>> Le jeudi 20 avril 2017 08:57:30 UTC+2, vdelecroix a écrit :
>>>
>>> Why do you have 355 commits on public/experimental_python3_v0?! It is
>>> hard to find its way...
>>>
>>> On 20/04/2017 08:52, Frédéric Chapoton wrote:
>>>> Salut,
>>>>
>>>> you have to apply first : public/experimental_python3_v0
>>>>
>>>> then the ticket 22775 (new conway_polynomial
>>>> package) https://trac.sagemath.org/ticket/22775
>>>>
>>>> Frederic
>>>>
>>>> Le jeudi 20 avril 2017 08:40:33 UTC+2, vdelecroix a écrit :
>>>>>
>>>>> Salut Frédéric,
>>>>>
>>>>> Then this is the problem. Cython should generate .so files for each
>>> .pyx
>>>>> present in the Sage source code (which should be in the
site-packages
>>> of
>>>>> Python3). If you provide an explicit branch with your "hacks" to get
>>>>> Sage compiled I might be able to provide more help.
>>>>>
>>>>> Vincent
>>>>>
>>>>> On 20/04/2017 08:35, Frédéric Chapoton wrote:
>>>>>> Salut,
>>>>>>
>>>>>> There is no lazy_import.so in
>>>>> local/lib/python3.5/site-packages/sage/misc
>>>>>> folder (and in fact no .so file at all there)
>>>>>>
>>>>>> And I get
>>>>>>
>>>>>> Python 3.5.1 (default, Apr 16 2017, 11:35:45)
>>>>>> Type "copyright", "credits" or "license" for more information.
>>>>>>
>>>>>>
>>>>>> IPython 5.1.0 -- An enhanced Interactive Python.
>>>>>> ? -> Introduction and overview of IPython's features.
>>>>>> %quickref -> Quick reference.
>>>>>> help  -> Python's own help system.
>>>>>> object?   -> Details about 'object', use 'object??' for extra
>>> details.
>>>>>>
>>>>>>
>>>>>> In [1]: import sage.misc.lazy_import
>>>>>>
>>>>>
>>>
---
>&

Re: [sage-devel] first python3 build of sage

[VulK]

It looks to me that the various .so files get compiled but then removed just 
before the build finishes. Here is a snippet of the log:


byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/stats/r.py to 
r.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/stats/hmm/__init__.py
 to __init__.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/stats/hmm/all.py to 
all.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/stats/all.py to 
all.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/finance/__init__.py 
to __init__.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/finance/easter.py 
to easter.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/finance/markov_multifractal.py
 to markov_multifractal.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/finance/stock.py to 
stock.cpython-35.pyc
byte-compiling 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/finance/all.py to 
all.cpython-35.pyc
running install_egg_info
Removing 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage-8.0.beta2-py3.5.egg-info
Writing 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage-8.0.beta2-py3.5.egg-info
Cleaning up stale installed files
- cleaning /mnt/backup/sage-py3/local/lib/python3.5/site-packages
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/modular/modform_hecketriangle/__pycache__/abstract_space.cpython-35.pyc
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/rings/polynomial/polynomial_zmod_flint.cpython-35m-x86_64-linux-gnu.so
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/libs/gsl/array.cpython-35m-x86_64-linux-gnu.so
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/modular/quatalg/__pycache__/all.cpython-35.pyc
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/rings/__pycache__/infinity.cpython-35.pyc
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/manifolds/differentiable/__pycache__/chart.cpython-35.pyc
Cleaning up stale file: 
/mnt/backup/sage-py3/local/lib/python3.5/site-packages/sage/interacts/__pycache__/all.cpython-35.pyc


S.




* Frédéric Chapoton  [2017-04-20 00:46:52]:


~/sage3/src/build$ find -name "*.so"

returns nothing :(

Le jeudi 20 avril 2017 09:35:50 UTC+2, vdelecroix a écrit :


Can you look at SAGE_ROOT/src/build and try to find is there is a .so
there. For example

$ find $(sage -root)/src/build -name "*.so"

(normally there should be, the cythonization process put stuff there)

On 20/04/2017 09:07, Frédéric Chapoton wrote:
> STOP ! you should export SAGE_PYTHON3=yes
>
> Le jeudi 20 avril 2017 09:02:54 UTC+2, Frédéric Chapoton a écrit :
>>
>> Really 355 ? More like 20, but I agree that it is a mess.
>>
>> This is my own experimental branch, not for evereybody's eyes.. It is
made
>> from 22764, 22756, 22305 and 22775
>>
>> plus one own commit that takes care (not in a good way) of the last two
>> calls to cmp() in pyx files.
>>
>> Frederic
>>
>> Le jeudi 20 avril 2017 08:57:30 UTC+2, vdelecroix a écrit :
>>>
>>> Why do you have 355 commits on public/experimental_python3_v0?! It is
>>> hard to find its way...
>>>
>>> On 20/04/2017 08:52, Frédéric Chapoton wrote:
 Salut,

 you have to apply first : public/experimental_python3_v0

 then the ticket 22775 (new conway_polynomial
 package) https://trac.sagemath.org/ticket/22775

 Frederic

 Le jeudi 20 avril 2017 08:40:33 UTC+2, vdelecroix a écrit :
>
> Salut Frédéric,
>
> Then this is the problem. Cython should generate .so files for each
>>> .pyx
> present in the Sage source code (which should be in the
site-packages
>>> of
> Python3). If you provide an explicit branch with your "hacks" to get
> Sage compiled I might be able to provide more help.
>
> Vincent
>
> On 20/04/2017 08:35, Frédéric Chapoton wrote:
>> Salut,
>>
>> There is no lazy_import.so in
> local/lib/python3.5/site-packages/sage/misc
>> folder (and in fact no .so file at all there)
>>
>> And I get
>>
>> Python 3.5.1 (default, Apr 16 2017, 11:35:45)
>> Type "copyright", "credits" or "license" for more information.
>>
>>
>> IPython 5.1.0 -- An enhanced Interactive Python.
>> ? -> Introduction and overview of IPython's features.
>> %quickref -> Quick reference.
>> help  -> Python's own help system.
>> object?   -> Details about 'object', use 'object??' for extra
>>> details.
>>
>>
>> In [1]: import sage.misc.lazy_import
>>
>
>>>

[sage-devel] Re: How do I handle a bug I do not have time to fix?

[VulK]

Sorry for the mess, I just read the procedure on the developer's manual. I'll 
be creating a new ticket for the stopgap in a second.

S.


* Travis Scrimshaw  [2017-02-27 09:01:03]:


Hey Salvatore,
  The typical approach is to put a stopgap, but it is best to do it in
such a way that is as minimal as possible (i.e., hopefully not every
ClusterQuiver from a matrix will have this stopgap pop up, or at worst only
when the input is a matrix).

Best,
Travis


On Monday, February 27, 2017 at 10:02:50 AM UTC-6, Salvatore Stella wrote:


Dear all,
some time ago I reported a bug in the implementation of `ClusterQuiver`
which
yields wrong answers. The relevant ticket is #22381. To give you an idea
things like this happen:

{{{
sage: B = Matrix([[0,1,0],[-1,0,1],[0,-1,0],[2,0,0]])
sage: Q = ClusterQuiver(B)
sage: Q.is_mutation_finite()# This should return True
False
}}}

After some thought I realized that properly fixing all the issues in that
ticket will require quite a lot of work: they all stem from how the data
structure is implemented. Unfortunately I am currently unable to set aside
enough time to handle it. Which is the best way of proceeding here?
 Should I
add a warning message and leave it be? Is there any other option
available?
Thanks
S.





--
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: How do I handle a bug I do not have time to fix?

[VulK]

Hi Travis,
thank you for the info.
Could you please check that the branch public/ticket/22381 currently attached 
to the ticket is acceptable? Issues arise with any kind of input but only 
when there are frozen variables so I added the stopgap any time they are 
present.


Is there a fast lane to get stopgaps into sage?
S.





* Travis Scrimshaw  [2017-02-27 09:01:03]:


Hey Salvatore,
  The typical approach is to put a stopgap, but it is best to do it in
such a way that is as minimal as possible (i.e., hopefully not every
ClusterQuiver from a matrix will have this stopgap pop up, or at worst only
when the input is a matrix).

Best,
Travis


On Monday, February 27, 2017 at 10:02:50 AM UTC-6, Salvatore Stella wrote:


Dear all,
some time ago I reported a bug in the implementation of `ClusterQuiver`
which
yields wrong answers. The relevant ticket is #22381. To give you an idea
things like this happen:

{{{
sage: B = Matrix([[0,1,0],[-1,0,1],[0,-1,0],[2,0,0]])
sage: Q = ClusterQuiver(B)
sage: Q.is_mutation_finite()# This should return True
False
}}}

After some thought I realized that properly fixing all the issues in that
ticket will require quite a lot of work: they all stem from how the data
structure is implemented. Unfortunately I am currently unable to set aside
enough time to handle it. Which is the best way of proceeding here?
 Should I
add a warning message and leave it be? Is there any other option
available?
Thanks
S.





--
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] How do I handle a bug I do not have time to fix?

[VulK]

Dear all,
some time ago I reported a bug in the implementation of `ClusterQuiver` which 
yields wrong answers. The relevant ticket is #22381. To give you an idea 
things like this happen:


{{{
sage: B = Matrix([[0,1,0],[-1,0,1],[0,-1,0],[2,0,0]])
sage: Q = ClusterQuiver(B)
sage: Q.is_mutation_finite()# This should return True
False
}}}

After some thought I realized that properly fixing all the issues in that 
ticket will require quite a lot of work: they all stem from how the data 
structure is implemented. Unfortunately I am currently unable to set aside 
enough time to handle it. Which is the best way of proceeding here?  Should I 
add a warning message and leave it be? Is there any other option available?

Thanks
S.


--
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] A strange bug I cant't reproduce in any simpler way (LaurentPolynomialRing)

[VulK]

I just did it, it seems to work.
Thanks
S.


* Daniel Krenn <kr...@aon.at> [2017-02-20 20:47:03]:


On 2017-02-20 19:24, VulK wrote:

Dear All,
I just found a bug I can't really reproduce in any simpler way than the
one I have here. I did not open a ticket yet on this because I would
like to have a simpler way to explain the issue first. Any idea?


Yes, a bit above from the line where your AttributeError occurs, there
is a for loop "k in x" which itself changes the keys of x. I believe
this is the case, as using copy(x) instead seems to make the error
disappear. ("seems" as it depends on how the elements in the dict are
ordered which is (or can be) machine dependent, i.e. is maybe random.)

Please create a ticket and test the branch u/dkrenn/laurent-copy-for-x

Best

Daniel

--
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] A strange bug I cant't reproduce in any simpler way (LaurentPolynomialRing)

[VulK]

Dear All,
I just found a bug I can't really reproduce in any simpler way than the one I 
have here. I did not open a ticket yet on this because I would like to have a 
simpler way to explain the issue first. Any idea?


{{{

sage: LQ = LaurentPolynomialRing(QQ, 'x0, x1, x2, y0, y1, y2, y3, y4, 
y5')
sage: LZ = LaurentPolynomialRing(ZZ, 'x0, x1, x2, y0, y1, y2, y3, y4, 
y5')
sage: LQ.inject_variables()
Defining x0, x1, x2, y0, y1, y2, y3, y4, y5
sage: x2^-1*y0*y1*y2*y3*y4*y5 + x1^-1*x2^-1*y0*y1*y3*y4 + x0^-1 in LZ
True
sage: x2^-1*y0*y1*y2*y3*y4*y5 + x1^-1*x2^-1*y0*y1*y3*y4 + 
x0^-1*x1^-1*y0*y3 + x0^-1 in LZ
Traceback (most recent call last):
...
AttributeError: 'tuple' object has no attribute 'esub'

}}}

I am running 7.6.beta4
Thanks
S.

--
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] RFC: correct way to deal with particular methods

[VulK]

Dear All,
sorry for the late reply and thank you very much for the input.



As far as having methods not always defined the consensus here is leaning 
towards making sublcasses but I am quite reluctant to do that because of 
future things I want to implement. Down the road there are going to be many 
more methods that only make sense in certain cases and not in others.  
Unfortunately the cases are many so that I would have to implement lots of 
different classes. The sublclass approach is the OOP-clean way but it can be
nightmarish to maintain if there are too many corner cases. This will be one 
such situation when everything is implemented.


Johan's suggestion is very intriguing but, unless I am completely mistaken, 
it does not work in python. If I understand correctly if O is an instance of 
Foo and O does not have the attribute x then python looks for Foo().x


At the moment it seems "better" (sigh) to define the methods anyway and raise 
an error in case they are meaningless. Any objection?




As for the question about the wrapper. Currently I am using @wrap and not 
@sage_wrap but the result is analogous. I am indeed changing the 
documentation at decoration-time (that is what I meant by "on the fly") and 
reviewers are objecting precisely to this.


Could someone explain to me how sublcasses can help here?

Could you please have a look at the code? The branch is 	 
public/ticket/21254. The wrapper begins at line 358 and the documentation 
edit at line 384. The methods being wrapped are at lines 1047 and 2150.


Thanks
S.





* Johan S. H. Rosenkilde <maill...@atuin.dk> [2016-11-07 09:45:57]:


VulK writes:

The first question is about which is the correct way to implement methods
that are not always defined.


I agree with Nils that subclassing is the most OOP-clean way of
achieving this. That being said, one might argue that it is a pretty
heavy-handed solution which potentially leads to class-explosion and
mega-multiple-inheritance.

Another possibility is to do the converse of what you are doing: add the
method on the class but *delete* at construction time if it is not
appropriate. This can be done using delattr.

VulK writes:

The second problem is a little more involved, I will try to give you a souped
up version here.
...


Did you take a look at performing the preparsing using a decorator which
properly uses @sage_wraps? It is possible to do the documentation
modification at decoration-time, and then it should properly show up in
Sphinx as well.

Best,
Johan

--
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] RFC: correct way to deal with particular methods

[VulK]

Dear all,
I am writing to you to ask your opinion on the best way to address two issues 
that were raised during the review of #21254. People are quite unhappy on how 
these are addressed right now so I figured it would be better to ask for 
opinions on how to best implement them.



The first question is about which is the correct way to implement methods 
that are not always defined.


We are implementing an algebra `ClusterAlgebra` that is defined from some 
integer matrix. When this matrix has precisely two columns then the algebra 
has certain special elements and we want to create a method to construct 
them. In all the other cases these elements do not make any mathematical 
sense.


Rather than having these methods check for this condition every time they are 
invoked, and still be listed among the methods defined (say through `dir`), 
we opted for defining them outside of the class and then add them "manually" 
when __init__ is run.  The relevant code is something like:


{{{
if n == 2 and m == 0:
   self.greedy_element = MethodType(greedy_element, self, self.__class__)
}}}

This has at least one drawback: the documentation produced by Sphinx looks 
weird because these methods appears as functions outside the scope of the 
class. Furthermore is not very readable and subsequently harder to debug.


The same issue happens also at the level of `ClusterAlgebraElement` (the 
elements of `ClusterAlgebra`).


Which is the standard way to proceed here? Is there a way to define method 
conditionally (maybe using a wrapper)? Alternatively, is it possible to 
always define these methods but mask them unless some condition is satisfied?



The second problem is a little more involved, I will try to give you a souped 
up version here.


Suppose you are building two classes `MyClassA` and `MyClassS`. They are 
quite different classes but they both have a method `change_me` that morally 
performs the same operation on each. Of course the implementations of the two
`change_me` are quite different as well. In both cases the input of 
`change_me` is an integer. 

Having implemented this one may be interested in calling `change_me` on the 
entries of a list. Sometime such a list may not be specified explicitly but 
might be computed from some description or from some other data. In short one 
would like to preparse the input of `change_me` before calling the original 
functions. Now this preparsing is identical for both classes. To avoid 
duplicated code we made a wrapper that takes care of the preparsing and we 
used it in both classes. So far so good. The problems starts when writing the 
documentation for this setup. Right now each `change_me` only has the 
documentation regarding the integer input. All the other possibilities are in 
the documentation of the wrapper. Moreover the wrapper changes on the fly the 
documentation of `change_me` to add the relevant extra possibilities and make 
them available from the inline help. 

Now this is clearly an hack which saves on code redundancy at the price of a 
possible nightmarish maintenance. Is there a more streamlined solution?


The relevant functions are `ClusterAlgebraSeed.mutate` and 
`ClusterAlgebra.mutate_initial`; the wrapper is `_mutation_parse`.



Any comment is welcome.
Thanks
S.

--
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] Regression introduced by #21670 ?

[VulK]

Dear All,
it seems that the ticket #21670 recently merged into develop makes sage crash 
on my machine, can anyone replicate this? 


In a new xterm run this:

$ echo "a = 1" > /tmp/test.py
$ sage
┌┐
│ SageMath version 7.4.rc2, Release Date: 2016-10-15 │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage:

now resize the xterm, everything works as it is supposed to.
now attach /tmp/test.py and again resize the window. I get this:

sage: %attach /tmp/prova.py
sage:   


**

Oops, Sage crashed. We do our best to make it stable, but...

A crash report was automatically generated with the following information:
 - A verbatim copy of the crash traceback.
 - A copy of your input history during this session.
 - Data on your current Sage configuration.

It was left in the file named:
   '/home/VulK/.sage/ipython-5.0.0/Sage_crash_report.txt'
If you can email this file to the developers, the information in it will help
them in understanding and correcting the problem.

You can mail it to: sage-support at sage-supp...@googlegroups.com
with the subject 'Sage Crash Report'.

If you want to do it now, the following command will work (under Unix):
mail -s 'Sage Crash Report' sage-supp...@googlegroups.com < 
/home/VulK/.sage/ipython-5.0.0/Sage_crash_report.txt

To ensure accurate tracking of this issue, please file a report about it at:
http://trac.sagemath.org

Hit  to quit (your terminal may close):



I attached to this e-mail the crash report.

Best
S.

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

IPython post-mortem report

{'commit_hash': u'1ba246d',
 'commit_source': 'installation',
 'default_encoding': 'UTF-8',
 'ipython_path': '/mnt/sage/local/lib/python2.7/site-packages/IPython',
 'ipython_version': '5.0.0',
 'os_name': 'posix',
 'platform': 
'Linux-4.1.12-gentoo-x86_64-Intel-R-_Core-TM-_i7-5600U_CPU_@_2.60GHz-with-gentoo-2.2',
 'sys_executable': '/mnt/sage/local/bin/python',
 'sys_platform': 'linux2',
 'sys_version': '2.7.10 (default, Oct 15 2016, 20:24:20) \n[GCC 4.9.3]'}

***



***

Crash traceback:

---
---
error Python 2.7.10: /mnt/sage/local/bin/python
   Sat Oct 15 22:13:36 2016
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/mnt/sage/src/bin/sage-ipython in ()
  1 #!/usr/bin/env python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 from sage.repl.interpreter import SageTerminalApp
  8 
  9 app = SageTerminalApp.instance()
 10 app.initialize()
---> 11 app.start()
global app.start = >

/mnt/sage/local/lib/python2.7/site-packages/IPython/terminal/ipapp.pyc in 
start(self=)
333 if self.log_level <= logging.INFO: print()
334 
335 def _pylab_changed(self, name, old, new):
336 """Replace --pylab='inline' with --pylab='auto'"""
337 if new == 'inline':
338 warnings.warn("'inline' not available as pylab backend, "
339   "using 'auto' instead.")
340 self.pylab = 'auto'
341 
342 def start(self):
343 if self.subapp is not None:
344 return self.subapp.start()
345 # perform any prexec steps:
346 if self.interact:
347 self.log.debug("Starting IPython's mainloop...&q

Re: [sage-devel] Sage and pylint

[VulK]

Hi Erik,
no options. As an example of the errors I get let's consider the ticket I am 
working on (#21254).


I installed pylint via

	$ sage -pip install pylint 


my sage install is in /opt/sage so

$ /opt/sage/local/bin/pylint 
/opt/sage/src/sage/algebras/cluster_algebra.py | grep E: | head
No config file found, using default configuration
E:327, 0: No name 'morphism' in module 'sage.categories' 
(no-name-in-module)
E:335, 0: No name 'constructor' in module 'sage.matrix' 
(no-name-in-module)
E:337, 0: No name 'cachefunc' in module 'sage.misc' (no-name-in-module)
E:338, 0: No name 'misc_c' in module 'sage.misc' (no-name-in-module)
E:339, 0: No name 'free_module_element' in module 'sage.modules' 
(no-name-in-module)
E:341, 0: No name 'integer' in module 'sage.rings' (no-name-in-module)
E:342, 0: No name 'integer_ring' in module 'sage.rings' 
(no-name-in-module)
E:347, 0: No name 'element_wrapper' in module 'sage.structure' 
(no-name-in-module)
E:348, 0: No name 'parent' in module 'sage.structure' 
(no-name-in-module)
E:349, 0: No name 'sage_object' in module 'sage.structure' 
(no-name-in-module)

I get many more warnings about lines being too long, having too many/too few 
methods etc but I do not care about those. 


Something weird: line 326 and 327 are
from sage.categories.homset import Hom
	from sage.categories.morphism import SetMorphism  
pylint complains only about the second.


Best
S.




* Erik Bray <erik.m.b...@gmail.com> [2016-09-22 17:24:05]:


On Fri, Sep 16, 2016 at 1:12 PM, VulK <etn45...@gmail.com> wrote:

Hi,
I thought this was a question for sage-devel because it is about tickets I
am currently working on (#21254 specifically). Sorry for the wrong
assumption.

I did try sage -pip install pylint before posting but the results were
identical (even launching it from within sage -sh)


That sounds suspicious, though I admit I haven't tried it myself yet.
With what options did you run pylint?  If it installed correctly into
Sage's Python it should work.

I wouldn't mind getting that working myself.  It would be very nice to
see what cleanup pylint can suggest (though a foolish consistency is
the hobgoblin of little minds--I suspect pylint will require a lot of
exceptions for sage :)


* Thierry <sage-googlesu...@lma.metelu.net> [2016-09-16 13:08:10]:



Hi,

note that https://ask.sagemath.org is a nice place to ask such questions
that are not related to sage development but still interesting.

Anyway, Sage uses its own Python install, so you should install pylint
within Sage and import it from there.

A priori, the following should work:

sage -pip install pylint

If you really want to use the pylint from your distro, you should add the
path to your distro's '/${WHATEVER}/python2.7/dist-packages' directory to
Sage's PYTHONPATH, at your own risks.

Ciao,
Thierry



On Fri, Sep 16, 2016 at 12:55:29PM +0200, VulK wrote:


Dear all,
I am trying to use pylint to validate some of the code in a patch I wrote
for sage and, unsurprisingly, I am getting several complaints because my
system-wide pylint can't resolve modules like sage.something.

What is the correct way of doing this? Is there any other alternative to
pylint that I should use instead?
Thanks
S.


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



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

Re: [sage-devel] Re: Sage's references: new policy?

[VulK]

* Thierry  [2016-09-21 18:35:25]:


Hi,

bikeshedding for bikeshedding:

- if we decide to centralize everything in a single file (but we should be
 aware that a backward move (e.g. for modularization) will require some
 work), why not using bibtex (there must be some sphinx interface
 somewhere), to that we keep all information with proper fields (might
 also be good for pdf rendering) ?


Et Voilà:
https://sphinxcontrib-bibtex.readthedocs.io/en/latest/



- regarding the citation link, explicit is better than implicit, avoids
 collisions, and is not that verbose: [Milnor1958], [AuthorCoauthor2016], ...

My two cents,
Thierry



On Wed, Sep 21, 2016 at 08:46:29AM -0700, John H Palmieri wrote:

There may be two issues here.

- How should references be written in source code?
- How should references appear in documentation output?

The default behavior in Sphinx is to use the source code citation name also
in the output. I don't know how hard it would be to change that.

We can have discussions about the best way to format references purely in
the documentation output, and I think it is clear that we will not come to
universal agreement. More importantly, any discussion strictly about the
documentation output (for example, using [1], [2], ... -- no one is
suggesting that this is how the references should be named in the source
code, right?) is orthogonal to the issue at hand: anyone can work on
modifying Sphinx so it formats the references in another way independently
of the format in the source code. Feel free to do that and propose such a
change here. For now, the discussion should be on how to format code in the
source (= the format in the output for now, because that is Sphinx's
behavior).

So we can discuss the best way to format references in the source code. To
some extent, of course, this is bikeshedding. Whether we use [AC2016] or
[MR234898349] or [doi:...] or something else, there will always be
arguments for doing one of the others. I personally find [Mil1958] in a
discussion of the Steenrod algebra to convey information: I know that it
refers to Milnor's 1958 paper. I would not recognize the MR number or the
doi number for this. So I personally find the format [AC2016] a good
balance between readability, brevity, and (to a large extent) unique
representation. (Also, my suggested usage would be to often include more
information than just the citation name: "In [Mil1958], Milnor showed ..."
or "Milnor showed that ... -- see [Mil1958]" or something similar. Again,
there is a balance between readability and verbosity.)

--
John

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


--
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] Sage and pylint

[VulK]

Hi,
I thought this was a question for sage-devel because it is about tickets I am 
currently working on (#21254 specifically). Sorry for the wrong assumption.


I did try sage -pip install pylint before posting but the results were 
identical (even launching it from within sage -sh)


Thanks
S.


* Thierry <sage-googlesu...@lma.metelu.net> [2016-09-16 13:08:10]:


Hi,

note that https://ask.sagemath.org is a nice place to ask such questions
that are not related to sage development but still interesting.

Anyway, Sage uses its own Python install, so you should install pylint
within Sage and import it from there.

A priori, the following should work:

sage -pip install pylint

If you really want to use the pylint from your distro, you should add the
path to your distro's '/${WHATEVER}/python2.7/dist-packages' directory to
Sage's PYTHONPATH, at your own risks.

Ciao,
Thierry



On Fri, Sep 16, 2016 at 12:55:29PM +0200, VulK wrote:

Dear all,
I am trying to use pylint to validate some of the code in a patch I wrote
for sage and, unsurprisingly, I am getting several complaints because my
system-wide pylint can't resolve modules like sage.something.

What is the correct way of doing this? Is there any other alternative to
pylint that I should use instead?
Thanks
S.


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


--
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 and pylint

[VulK]

Dear all,
I am trying to use pylint to validate some of the code in a patch I wrote for 
sage and, unsurprisingly, I am getting several complaints because my 
system-wide pylint can't resolve modules like sage.something.


What is the correct way of doing this? Is there any other alternative to 
pylint that I should use instead?

Thanks
S.


--
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] line_profiler (%lprun) also broken from IPython upgrade

[VulK]

these might be useful:

https://github.com/rkern/line_profiler/issues/61
https://github.com/rkern/line_profiler/issues/62
https://github.com/rkern/line_profiler/pull/65
https://github.com/rkern/line_profiler/pull/68

Best
S.


* Travis Scrimshaw  [2016-09-01 07:03:31]:

>I just installed the line profiler because I want to do %lprun, but
>this is broken in 7.4.beta2 (likely is beta0)
>ââ
>â SageMath version 7.4.beta2, Release Date: 2016-08-26 Â  Â  Â  Â  Â
>Â  Â  â
>â Type "notebook()" for the browser-based notebook interface. Â  Â  Â
>Â â
>â Type "help()" for help. Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>Â  Â  Â  Â  Â  Â  Â â
>ââ
>ââ
>â Warning: this is a prerelease version, and it may be unstable. Â  Â
>â
>ââ
>from[SageTerminalApp] WARNING | Error in loading extension:
>line_profiler
>Check your config files in
>/home/travis/.sage/ipython-5.0.0/profile_default
>Traceback (most recent call last):
>Â  File
>"/home/travis/sage-build/local/lib/python2.7/site-packages/IPython/core
>/shellapp.py", line 246, in init_extensions
>Â  Â  self.shell.extension_manager.load_extension(ext)
>Â  File
>"/home/travis/sage-build/local/lib/python2.7/site-packages/IPython/core
>/extensions.py", line 85, in load_extension
>Â  Â  if self._call_load_ipython_extension(mod):
>Â  File
>"/home/travis/sage-build/local/lib/python2.7/site-packages/IPython/core
>/extensions.py", line 132, in _call_load_ipython_extension
>Â  Â  mod.load_ipython_extension(self.shell)
>Â  File
>"/home/travis/sage-build/local/lib/python2.7/site-packages/line_profile
>r.py", line 372, in load_ipython_extension
>Â  Â  ip.define_magic('lprun', magic_lprun)
>AttributeError: 'SageTerminalInteractiveShell' object has no attribute
>'define_magic'
>Volker and IPython upgrade people, please fix this (and %attach).
>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 [1]sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to [2]sage-devel@googlegroups.com.
>Visit this group at [3]https://groups.google.com/group/sage-devel.
>For more options, visit [4]https://groups.google.com/d/optout.
> 
> References
> 
>1. mailto:sage-devel+unsubscr...@googlegroups.com
>2. mailto:sage-devel@googlegroups.com
>3. https://groups.google.com/group/sage-devel
>4. 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] Re: broken %attach and %debug ?

[VulK]

> You mean submitting a patch upstream?
Yes. I had not realized we behave differently with respect to Cython. Would
it not be enough to pass whatever an hypothetical upstream version of attach
produces through the preparser we use in the interactive shell?
S.


* leif <not.rea...@online.de> [2016-08-26 16:23:53]:

> VulK wrote:
> >>and me too, this is really very annoying that %attach is broken..
> > +1
> > 
> > A related question: why do we implement %attach in sage rather than making a
> > patch for upstream IPython?
> 
> You mean submitting a patch upstream?
> 
> (Otherwise repackagers won't be happy, but upstream would have to accept
> it of course.  I'm not sure it would be suitable, as AFAIK we use our
> own Cython stuff to attach Cython files, i.e., extension modules.)
> 
> 
> -leif
> 
> 
> > * Frédéric Chapoton <fchapot...@gmail.com> [2016-08-26 06:01:23]:
> > 
> >>and me too, this is really very annoying that %attach is broken..
> >>Le dimanche 14 août 2016 02:14:44 UTC+2, Travis Scrimshaw a écrit :
> >>
> >>I would really like to have %attach back working.
> >>Best,
> >>Travis
> >>On Friday, August 12, 2016 at 12:50:23 PM UTC-5, Volker Braun wrote:
> >>
> >>Presumably attach (or, more generally, using the python inputhook)
> >>doesn't work since Ipython 5 now implements its own input handling.
> >>On Friday, August 12, 2016 at 2:22:51 PM UTC+2, Frédéric Chapoton
> >>wrote:
> >>
> >>is this only me, or the recent update to ipython 5.0 has broken severel
> >>things in 7.4.b0 ?
> >>it seems that somebody already complained about sage_mode and %lprun
> >>(see [1]https://trac.sagemath.org/ticket/21006)
> >>for me, %attach does not seem to reload the files that changed
> >>and using %debug doe snot quite work, because the special command r and
> >>n are still mapped to numerical and R interpreter inside the ipbd
> >>session
> >>Frederic
> >>
> >>--
> >>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 [2]sage-devel+unsubscr...@googlegroups.com.
> >>To post to this group, send email to [3]sage-devel@googlegroups.com.
> >>Visit this group at [4]https://groups.google.com/group/sage-devel.
> >>For more options, visit [5]https://groups.google.com/d/optout.
> >>
> >> References
> >>
> >>1. https://trac.sagemath.org/ticket/21006
> >>2. mailto:sage-devel+unsubscr...@googlegroups.com
> >>3. mailto:sage-devel@googlegroups.com
> >>4. https://groups.google.com/group/sage-devel
> >>5. 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.

Re: [sage-devel] Re: broken %attach and %debug ?

[VulK]

>and me too, this is really very annoying that %attach is broken..
+1

A related question: why do we implement %attach in sage rather than making a
patch for upstream IPython?
S.




* Frédéric Chapoton  [2016-08-26 06:01:23]:

>and me too, this is really very annoying that %attach is broken..
>Le dimanche 14 août 2016 02:14:44 UTC+2, Travis Scrimshaw a écrit :
> 
>I would really like to have %attach back working.
>Best,
>Travis
>On Friday, August 12, 2016 at 12:50:23 PM UTC-5, Volker Braun wrote:
> 
>Presumably attach (or, more generally, using the python inputhook)
>doesn't work since Ipython 5 now implements its own input handling.
>On Friday, August 12, 2016 at 2:22:51 PM UTC+2, Frédéric Chapoton
>wrote:
> 
>is this only me, or the recent update to ipython 5.0 has broken severel
>things in 7.4.b0 ?
>it seems that somebody already complained about sage_mode and %lprun
>(see [1]https://trac.sagemath.org/ticket/21006)
>for me, %attach does not seem to reload the files that changed
>and using %debug doe snot quite work, because the special command r and
>n are still mapped to numerical and R interpreter inside the ipbd
>session
>Frederic
> 
>--
>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 [2]sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to [3]sage-devel@googlegroups.com.
>Visit this group at [4]https://groups.google.com/group/sage-devel.
>For more options, visit [5]https://groups.google.com/d/optout.
> 
> References
> 
>1. https://trac.sagemath.org/ticket/21006
>2. mailto:sage-devel+unsubscr...@googlegroups.com
>3. mailto:sage-devel@googlegroups.com
>4. https://groups.google.com/group/sage-devel
>5. 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] Re: Iterators and KeyboardInterrupt

[VulK]

Indeed RecursivelyEnumeratedSet seems to be a good fit for my needs.
The only problem I encountered so far is that it does not handle
KeybordInterrupts nicely either: if you interrupt the computation of
graded_component(n) then graded_component(m) with m [2016-08-23 00:51:34]:

>  > Are you really getting benefit from storing the state (i.e., the
>  actual
>  > iterator) on the parent itself? (I see you haven't made
>  ClusterAlgebra
>  > UniqueRepresentation, so it's not an immediate bug to have it this
>  way)
>  > Perhaps it's cleaner to hand out iterator objects that are kept
>  track
>  > of in the relevant loop. That iterator would then just die
>  whenever the
>  > frames of a KeyboardInterrupt exception are discarded and the
>  flawed
>  > state wouldn't persist.
>  The main benefit I get from storing the iterator is that, if the
>  user is
>  careful in calling the various functions with reasonable stopping
>  points, the
>  code never has to start searching from scratch. For example
>  currently
>  Â  Â  sage: A = ClusterAlgebra(['A',2,1])
>  Â  Â  sage: A.explore_to_depth(10)
>  Â  Â  sage: A.explore_to_depth(11)
>  effectively only traverses the tree once to depth 11. If I were not
>  to store
>  the iterator then I would be traversing the tree twice. And
>  unfortunately
>  this is expensive.
> 
>The method graded_component does exactly what you want. See
> 
>https://github.com/sagemath/sage/blob/master/src/sage/sets/recursively_
>enumerated_set.pyx#L607
>Â
> 
>--
>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 [1]sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to [2]sage-devel@googlegroups.com.
>Visit this group at [3]https://groups.google.com/group/sage-devel.
>For more options, visit [4]https://groups.google.com/d/optout.
> 
> References
> 
>1. mailto:sage-devel+unsubscr...@googlegroups.com
>2. mailto:sage-devel@googlegroups.com
>3. https://groups.google.com/group/sage-devel
>4. 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: Iterators and KeyboardInterrupt

[VulK]

Hi All,
thank you very much for all the inputs!

> Breath-first search = Search & pray? ;-)
> 
> (Possibly infinite apnoea can't be healthy.)

/me fails
:)

> Well, one usually implements checkpoints for such things (continually
> saving state to optionally resume later if interrupted).

I am not sure what data to store nor if it is a good compromise, I will think
about this a little but I guess Sébastien gave me a way out of this.

> Are you really getting benefit from storing the state (i.e., the actual
> iterator) on the parent itself? (I see you haven't made ClusterAlgebra
> UniqueRepresentation, so it's not an immediate bug to have it this way)
> Perhaps it's cleaner to hand out iterator objects that are kept track
> of in the relevant loop. That iterator would then just die whenever the
> frames of a KeyboardInterrupt exception are discarded and the flawed
> state wouldn't persist.

The main benefit I get from storing the iterator is that, if the user is
careful in calling the various functions with reasonable stopping points, the
code never has to start searching from scratch. For example currently

sage: A = ClusterAlgebra(['A',2,1])
sage: A.explore_to_depth(10)
sage: A.explore_to_depth(11)

effectively only traverses the tree once to depth 11. If I were not to store
the iterator then I would be traversing the tree twice. And unfortunately
this is expensive.

> Using "yield" is a convenient way of writing simple iterators, but it
> is in no way the only way of doing it. When you explicitly store state
> yourself it is much easier to define the right behaviour in the face of
> unexpected interrupts.

I never thought of this before.

> IMHO iterators must not have global state, which is really just a
> corollary to "global variables are bad". In particular, iterating twice
> simultaneously should work. With the exception of input iterators of
> course, but iterating over a tree doesn't consume it.

I agree in principle with the idea that "global variables are bad" but how do
you avoid to perform expensive computations multiple times?

> Do you know about
> sage: RecursivelyEnumeratedSet?

No and it looks extremely promising! Unfortunately the graph I have has
only a symmetric structure so it looks like I will not be able to use any
parallelization (unless there is some other wonder piece of code I know
nothing about!!!).

> I let you look whether KeyboardInterrupts works ok for your need, but
> consider including your tree iterator into these existing modules (I
> will be willing to review your code).

At this point I definitely intend to try RecursivelyEnumeratedSet; I'll keep
you posted on the outcome and hold you to the promise of a review!

Thanks 
S.

-- 
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] Iterators and KeyboardInterrupt

[VulK]

Dear All,
in a ticket (#21254) I recently created with Dylan Rupel I need to explore a
(possibly) infinite n-regular tree in a breath-first search. The way it is
implemented right now is via iterators. I am writing to you to ask if there
is a preferred way to deal with user interaction and KeyboardInterrupt.

At the moment the init function of :class:`ClusterAlgebra` calls
:meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` and
stores it in an internal var ``_sd_iter``. The methods that need to explore
the tree just call ``next`` on this iterator till they get the data they are
looking for. This process is potentially never ending. For this reason the
user may specify a maximum depth at which to stop.

Since this iterator is computationally intense, it easy to imagine that
users will tend to start searching but change their mind in mid computation
and send an interrupt. This, unfortunately, leaves ``_sd_iter`` in a
corrupted state and all future calls to it will result in a StopIteration.

At the moment we have a warning in the docstring of each method accessing
_sd_iter to explain that after sending a KeyboardInterrupt the user needs to
call :meth:`reset_exploring_iterator`. Do you think we should instead catch
the interrupt, reset the iterator and then raise it again like this?


@@ -1999,12 +1999,17 @@ class ClusterAlgebra(Parent):
 sage: len(A.g_vectors_so_far())
 14
 """
-while self._explored_depth <= depth:
-try:
-seed = next(self._sd_iter)
-self._explored_depth = seed.depth()
-except StopIteration:
-break
+try:
+while self._explored_depth <= depth:
+try:
+seed = next(self._sd_iter)
+self._explored_depth = seed.depth()
+except StopIteration:
+break
+except KeyboardInterrupt:
+print("Got a KeyboardInterrupt, cleaning up before returning.")
+self.reset_exploring_iterator()
+raise KeyboardInterrupt

The advantage of this is that the user does not have to remember an extra
(unnatural?) step. The drawback is that he/she looses any customization that
may have been made by a previous call to :meth:`reset_exploring_iterator`.


On a related topic. In the situation just described, the next exploration
will have to begin from the root of the tree resulting in a lot of wasted
effort. Is there any way around this? Sending a node of the tree back to the
iterator does not seem useful because of the breath-first search.

Thanks
S.


-- 
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: py3: what to do with cmp ?

[VulK]

you got me: I was including $SAGE_ROOT/src/build/
now the numbers agree
S.


* leif <not.rea...@online.de> [2016-08-14 16:55:23]:

> leif wrote:
> > VulK wrote:
> >> Really weird, his is what I have:
> >>
> >> $ cd $SAGE_ROOT/src
> >> $ grep __cmp__ **/*.py* | grep def |  wc
> >> 6242538   48212
> >> $ grep __cmp__ **/*.py* | wc
> >> 9154020   76837
> >>
> >> (I am running zsh so **/*.py* is expanded to any file under $SAGE_ROOT/src
> >> whose extension begin by py)
> > 
> > $ grep -R --include "*.py" --include "*.pyx" --include "*.pxi" --include
> > "*.pxd" 'def[ \t]\+__cmp__' src/sage/ | wc -l
> > 339
> > 
> > (Still 7.3.beta9 though.  There are two definitions below src/mac-app/,
> > too.  And none in *.px[di] AFAICT, so you could omit these.)
> > 
> > You presumably grepped src/build/ as well, and also *.pyc files.
> 
> P.S.:
> 
> $ grep -Rc --include "*.py" --include "*.pyx" --include "*.pxi"
> --include "*.pxd" 'def[ \t]\+__cmp__' src/sage/ | grep -v ':0$' | sort | nl
>  1src/sage/algebras/free_algebra_element.py:1
>  2src/sage/algebras/free_algebra_quotient_element.py:1
>  3src/sage/algebras/quatalg/quaternion_algebra.py:3
>  4src/sage/arith/multi_modular.pyx:1
>  5src/sage/categories/examples/semigroups_cython.pyx:1
>  6src/sage/categories/functor.pyx:1
>  7src/sage/categories/homset.py:1
>  8src/sage/categories/map.pyx:1
>  9src/sage/categories/pushout.py:15
> 10src/sage/coding/binary_code.pyx:1
> 11src/sage/combinat/combinat.py:2
> 12src/sage/combinat/constellation.py:1
> 13src/sage/combinat/crystals/affine.py:1
> 14src/sage/combinat/crystals/affinization.py:1
> 15src/sage/combinat/crystals/alcove_path.py:1
> 16src/sage/combinat/crystals/fast_crystals.py:1
> 17src/sage/combinat/crystals/subcrystal.py:1
> 18src/sage/combinat/e_one_star.py:1
> 19src/sage/combinat/free_module.py:2
> 20src/sage/combinat/integer_list_old.py:1
> 21src/sage/combinat/misc.py:1
> 22src/sage/combinat/posets/elements.py:1
> 23src/sage/combinat/rigged_configurations/kleber_tree.py:1
> 24src/sage/combinat/root_system/ambient_space.py:1
> 25src/sage/combinat/root_system/branching_rules.py:1
> 26src/sage/combinat/root_system/cartan_type.py:1
> 27src/sage/combinat/root_system/coxeter_group.py:1
> 28src/sage/combinat/root_system/fundamental_group.py:1
> 29src/sage/combinat/root_system/reflection_group_complex.py:1
> 30src/sage/combinat/root_system/root_system.py:1
> 31src/sage/combinat/root_system/type_dual.py:1
> 32src/sage/combinat/root_system/type_reducible.py:1
> 33src/sage/combinat/sloane_functions.py:1
> 34src/sage/combinat/species/series.py:1
> 35src/sage/combinat/species/species.py:1
> 36src/sage/combinat/words/abstract_word.py:1
> 37src/sage/combinat/words/word_char.pyx:1
> 38src/sage/combinat/yang_baxter_graph.py:1
> 39src/sage/crypto/boolean_function.pyx:1
> 40src/sage/crypto/mq/sbox.py:1
> 41src/sage/crypto/mq/sr.py:1
> 42src/sage/databases/findstat.py:2
> 43src/sage/data_structures/bounded_integer_sequences.pyx:1
> 44src/sage/doctest/control.py:1
> 45src/sage/doctest/parsing.py:1
> 46src/sage/doctest/sources.py:1
> 47src/sage/doctest/util.py:2
> 48src/sage/dynamics/flat_surfaces/strata.py:2
> 49src/sage/dynamics/interval_exchanges/labelled.py:2
> 50src/sage/dynamics/interval_exchanges/reduced.py:2
> 51src/sage/ext/fast_eval.pyx:1
> 52src/sage/finance/markov_multifractal.py:1
> 53src/sage/finance/stock.py:1
> 54src/sage/finance/time_series.pyx:1
> 55src/sage/games/sudoku.py:1
> 56src/sage/geometry/cone.py:2
> 57src/sage/geometry/fan.py:1
> 58src/sage/geometry/hyperplane_arrangement/arrangement.py:1
> 59src/sage/geometry/linear_expression.py:1
> 60src/sage/geometry/point_collection.pyx:1
> 61src/sage/geometry/polyhedron/base.py:1
> 62src/sage/geometry/polyhedron/face.py:1
> 63src/sage/geometry/polyhedron/representation.

Re: [sage-devel] Re: py3: what to do with cmp ?

[VulK]

Really weird, his is what I have:

$ cd $SAGE_ROOT/src
$ grep __cmp__ **/*.py* | grep def |  wc
6242538   48212
$ grep __cmp__ **/*.py* | wc
9154020   76837

(I am running zsh so **/*.py* is expanded to any file under $SAGE_ROOT/src
whose extension begin by py)
S.

* leif <not.rea...@online.de> [2016-08-14 15:41:51]:

> leif wrote:
> > VulK wrote:
> >> Getting rid of __cmp__ would be the cleaner way but a simple grep on
> >> $SAGE_ROOT/src gives 915 occurrences of __cmp__, 624 of which are
> >> definitions.
> 
> ?  I'm getting 339 definitions in 249 files.  (That's for 7.3.beta9, but
> shouldn't differ that much.)
> 
> 
> -leif
> 
> >> Is there any way we can automate the process?
> >> S.
> > 
> > I have to admit I fail to see the problem (perhaps Frédéric could
> > elaborate a bit more).
> > 
> > Deprecate cmp() and all __cmp__ methods (probably step by step), and
> > temporarily (re)implement cmp() in Python3.  Am I missing something?
> > 
> > 
> > Deprecating the methods could certainly be automated, but I doubt it's
> > worth the effort (at least to /fully/ automate that).
> > 
> > 
> > -leif
> > 
> > 
> >> * Frédéric Chapoton <fchapot...@gmail.com> [2016-08-14 05:41:01]:
> >>
> >>>As an intermediate step in our long way to python3, I would like to be
> >>>able to compile all the .pyx files in py3.
> >>>Except for #21246 (please review), the big remaining problem preventing
> >>>to reach this goal is the removal of the builtin "cmp" in py3.
> >>>One solution would be to have our own "cmp" that would boil down to py2
> >>>cmp in py2 and to something (but what ?) in py3.
> >>>Otherwise, one will have to get rid by hand of all the `__cmp__`
> >>>methods everywhere, that will become obsolete in python3.
> >>>Please step in and talk out loud if you have a good strategy for this
> >>>problem.
> 
> 
> -- 
> 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] py3: what to do with cmp ?

[VulK]

Getting rid of __cmp__ would be the cleaner way but a simple grep on
$SAGE_ROOT/src gives 915 occurrences of __cmp__, 624 of which are
definitions. Is there any way we can automate the process?
S.


* Frédéric Chapoton  [2016-08-14 05:41:01]:

>As an intermediate step in our long way to python3, I would like to be
>able to compile all the .pyx files in py3.
>Except for #21246 (please review), the big remaining problem preventing
>to reach this goal is the removal of the builtin "cmp" in py3.
>One solution would be to have our own "cmp" that would boil down to py2
>cmp in py2 and to something (but what ?) in py3.
>Otherwise, one will have to get rid by hand of all the `__cmp__`
>methods everywhere, that will become obsolete in python3.
>Please step in and talk out loud if you have a good strategy for this
>problem.
>Frédéric
> 
>--
>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 [1]sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to [2]sage-devel@googlegroups.com.
>Visit this group at [3]https://groups.google.com/group/sage-devel.
>For more options, visit [4]https://groups.google.com/d/optout.
> 
> References
> 
>1. mailto:sage-devel+unsubscr...@googlegroups.com
>2. mailto:sage-devel@googlegroups.com
>3. https://groups.google.com/group/sage-devel
>4. 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] Re: Sage on Bash on Ubuntu on Windows

[VulK]

* leif <not.rea...@online.de> [2016-08-03 11:03:38]:

> VulK wrote:
> > On the topic of performances I just came across this post on phoronix:
> > http://www.phoronix.com/scan.php?page=article=windows-10-lxcore=1
> > 
> > TL;DR: benchmarks give surprisingly good performances provided you do not
> > access the filesystem. At the moment, while running sage could be ok, this
> > would make compiling it on WSL a terrible nightmare.
> 
> This presumably also affects Sage's start-up time (and in general,
> Python imports), as it loads hundreds of .so's.

Yep! It is not really bad but it is not great either.

> 
> 
> For Windows 95 and 98[SE] IIRC, there existed an ext2 filesystem
> driver... ;-)
> 
> 
> -leif
> 
> 
> -- 
> 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] Re: Sage on Bash on Ubuntu on Windows

[VulK]

On the topic of performances I just came across this post on phoronix:
http://www.phoronix.com/scan.php?page=article=windows-10-lxcore=1

TL;DR: benchmarks give surprisingly good performances provided you do not
access the filesystem. At the moment, while running sage could be ok, this
would make compiling it on WSL a terrible nightmare.

S.




* Erik Bray  [2016-07-26 18:37:43]:

> On Tue, Jul 26, 2016 at 6:33 PM, William Stein  wrote:
> > On Tue, Jul 26, 2016 at 9:21 AM, leif  wrote:
> >>> OS bashing will not be tolerated.
> >>
> >> But company bashing will... ;-)
> >>
> >> Microsoft used to have a POSIX layer also; no idea what happened to that
> >> (and how usable it actually was/is).
> >>
> >> But it never made it into mainstream Windows AFAIK.
> >
> > In the interest of balance, last week Microsoft donated USD $5K to
> > support the Women in Sage Days conferences.
> 
> My point exactly :)
> 
> > This new Ubuntu in Windows initiative is really fantastic.   I'm glad
> > they (evidently) now support fork and pseudotty's -- they didn't when
> > somebody tried a few months ago, and I heard that this was their top
> > priority.
> 
> Yes. The fork support especially is going to be a big win--fork on
> Cygwin is a big ol' mess especially due to DLL rebasing.
> 
> > Regarding the above discussion about speed, what combination of
> > OS/Virtualization/Emulations/Native/etc. is actually fastest is not
> > something that can be determined by "pure thought", since there are
> > two additional factors (which I saw a lot in work of Bill Hart, Jason
> > Moxham and Brian Gladman on MPIR and FLINT):
> >
> >   1. Performance is multidimensional.   It can easily be that f(X) is
> > faster in one setting, whereas g(X) is slower.  Or even that the
> > relative speed of f depends on X.
> >
> >   2. Performance depends enormously on how much work has gone into
> > optimizing libraries for certain platforms.  E.g., once when I tested
> > using MPIR in Linux via VirtualBox on Windows, it was much faster than
> > just using MPIR natively built using MSVC (no claims about today).
> > Why?  Much more effort had gone into optimizing MPIR on Linux than on
> > native Windows.
> 
> Yes--this is why I hesitate to assume one way or the other.
> 
> -- 
> 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] Sage on Bash on Ubuntu on Windows

[VulK]

I am not proposing this as our final solution since, as you point out, it is
a suboptimal hack on many respects; I am just saying that we can use this
today (actually from Aug 2nd) to bring anyone running windows 10 on the sage
bandwagon with minimal effort on our side. If I am not mistaken Bash should
be available to anyone with Windows 10 Anniversary Update on that date not
just developers.

Clearly performance are not going to be good, native applications are the way
to go for this; on the other hand I am not sure it is much (or at all?)
slower than a virtual machine setup.

Best
S.



* Erik Bray <erik.m.b...@gmail.com> [2016-07-26 13:25:31]:

> On Tue, Jul 26, 2016 at 10:19 AM, VulK <etn45...@gmail.com> wrote:
> > Hi All,
> > Some time ago I briefly played with Bash on Ubuntu on Windows with some
> > limited success. The situation dramatically improved recently. I would risk
> > saying that our nightmares to support windows are nearly over.
> >
> >
> > Microsoft Windows [Version 10.0.14393]
> > (c) 2016 Microsoft Corporation. All rights reserved.
> >
> >     C:\Users\VulK>bash
> > root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# uname -a
> > Linux DESKTOP-U13FH0M 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 
> > x86_64 x86_64 x86_64 GNU/Linux
> > root@DESKTOP-U13FH0M:~# apt-add-repository -y ppa:aims/sagemath
> > root@DESKTOP-U13FH0M:~# apt-get update
> > ...
> > root@DESKTOP-U13FH0M:~# apt-get install sagemath-upstream-binary
> > ...
> > root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# sage
> >
> >  SageMath version 7.2, Release Date: 2016-05-15
> >  Type "notebook()" for the browser-based notebook interface.
> >  Type "help()" for help.
> >
> > sage: 2+2
> > 4
> > sage:
> >
> >
> > even the notebook seems to work just fine. I did not play with x11 yet.
> >
> > If I am not mistaken Bash should be available to everyone with the upcoming
> > windows update without the need to install a developer preview.
> > Best
> > S.
> >
> >
> > TLDR: there is no need to support windows directly any more: it can now run
> > executables compiled for Ubuntu
> 
> I disagree for a few reasons:
> 
> 1) This is not available to all Windows users.
> 2) Currently this feature is intended as a developer tool only;
> Microsoft has stated explicitly that it is not intended for end-user
> application distribution on Windows.  That said, I see no reason it
> couldn't be used that way, but there are limitations to its use for
> that purpose.  For example, it is a walled garden--it is not possible,
> for example, to run native applications within the "bash" environment
> 3) It's unclear what performance impact this has over a native
> application.  Less, certainly, than using Cygwin.
> 
> Probably others as well.
> 
> -- 
> 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] Sage on Bash on Ubuntu on Windows

[VulK]

Hi All,
Some time ago I briefly played with Bash on Ubuntu on Windows with some
limited success. The situation dramatically improved recently. I would risk
saying that our nightmares to support windows are nearly over.


Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\VulK>bash
root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# uname -a
Linux DESKTOP-U13FH0M 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 
x86_64 x86_64 x86_64 GNU/Linux
root@DESKTOP-U13FH0M:~# apt-add-repository -y ppa:aims/sagemath
root@DESKTOP-U13FH0M:~# apt-get update
...
root@DESKTOP-U13FH0M:~# apt-get install sagemath-upstream-binary
...
root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# sage

 SageMath version 7.2, Release Date: 2016-05-15 
 Type "notebook()" for the browser-based notebook interface.
 Type "help()" for help.

sage: 2+2
4
sage:


even the notebook seems to work just fine. I did not play with x11 yet.

If I am not mistaken Bash should be available to everyone with the upcoming
windows update without the need to install a developer preview.
Best
S.


TLDR: there is no need to support windows directly any more: it can now run
executables compiled for Ubuntu

-- 
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: Heavy-computation @property in Matrix class

[VulK]

An interested question: my example from before was not extremely far fetched:
I am working precisely on something of that sort. A is a Cluster algebra, S
are its seeds and current_seed is a pointer to the current seed. Would it be ok
for future  sage integration if I were to implement A.current_seed as a 
property or
should I stick to methods?
Thanks
S.


* Johan S. R. Nielsen <santaph...@gmail.com> [2016-04-27 14:24:33]:

> VulK writes:
> > sage: B = matrix()
> > sage: B.T.roo
> >
> > and get
> >
> > sage: B.T.rook_vector
> 
> I see, didn't know that.
> 
> Of course, the reason that IDEs follow this is the underlying convention
> that
> 
> a) Properties are blazingly fast to compute.
> b) Properties don't throw exceptions.
> 
> Neither of which are satisfied for Matrix.I. If B is a 1000x1000
> matrix over ZZ(x), then B.I.roo is going to hang your IDE for a
> while :-)
> 
> Best,
> Johan
> 
> -- 
> 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] Re: Heavy-computation @property in Matrix class

[VulK]

This example is dumb because it does not give any real benefit but it will
do. On the command line you could run something like

sage: B = matrix()
sage: B.T.roo

and get

sage: B.T.rook_vector

but 

sage: sage: B.transpose().roo

will complete to useless stuff.

Now as I said this does not make a lot of sense with matrices. On the other
hand suppose you have a mathematical structure A endowed with building blocks
S and a pointer to the current block. Suppose also that each building block
has some method defined. Then properties allow to autocomplete things like

sage: A.current_S.some_method()

The same example does not work if A.current_S is a method itself and not a 
property.

By this I do not imply that properties should be preserved in sage. I am only
answering your question on which benefit is there in omitting the
parenthesis.

Best
S.



* Johan S. R. Nielsen  [2016-04-27 13:46:08]:

> > One advantage of properties over methods is that they autocomplete
> 
> I don't understand? Tab-completion covers both methods and properties in
> all IDEs I'm aware of.
> 
> Best,
> Johan
> 
> -- 
> 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] Re: Heavy-computation @property in Matrix class

[VulK]

One advantage of properties over methods is that they autocomplete
S.

* Johan S. R. Nielsen  [2016-04-27 13:22:57]:

> > Would it be feasible to let properties return some kind of "Undefined"
> > or "NotImplemented" or "None", rather than throwing an exception?
> 
> That would side-step the entire purpose of exceptions: catching errors
> fast and where they occur. This is extremely bad for debugging, and yet
> another source of inconsistency that we should definitely not be
> teaching our prospective Sagesters.
> 
> And the benefit of this sidestepping is to omit an empty pair of
> parentheses?
> 
> > - I am -1 to deprecate properties in general (here I include lazy
> >   attributes, which I find handy).
> 
> Can you give me an example of a handy lazy attribute, to make it
> concrete for me?
> 
> Essentially, I find the use of properties to go directly against a
> general pattern in Sage (and OOP): that private fields are only
> accessible through methods. For instance, there is no Matrix.nrows --
> there is Matrix.nrows(). Why is this not a property? Consistency! In
> sage.coding, we also recently refactored everything so that length,
> dimension, etc. of a code is private fields, publicly accessible through
> method calls. Everywhere I look in Sage, we have methods, not
> properties. Why should these four examples in Matrix be so special?
> 
> Best,
> Johan
> 
> -- 
> 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] Re: LaurentPolynomialRing and PolynomialRing behave inconsistently -- Request For Comments

[VulK]

Dear All,
sorry for the late reply: my todo list came knocking at my door and required
immediate attention.

I did a small test and it appears that both Polynomial and LaurentPolynomial
behave in the same way with respect to coercion. On the other hand their
behavior under conversion is different. 

Do we want the behavior under conversion to also be the same? If so, which
one should it be?
Best
S.





* David Roe  [2016-04-09 11:08:51]:

>I think that this summary is right, including the explicit conversion
>that relies on the index in gens().
>David
> 
>On Sat, Apr 9, 2016 at 4:15 AM, Volker Braun <[1]vbraun.n...@gmail.com>
>wrote:
> 
>Let me try to summarize the expected behavior: If there is a coercion
>of the base rings, then there should be a coercion to the (laurent)
>polynomial ring with additional variables. The variables in the
>different rings are identified using their name (and not index in
>gens() or any other rule).Â
>sage: cm = get_coercion_model()
>sage: R. = QQ[]
>sage: S. = QQ[]
>sage: cm.explain(R, S, operator.add)
>Coercion on left operand via
>Â  Â  Conversion map:
>Â  Â  Â  From: Univariate Polynomial Ring in x over Rational Field
>Â  Â  Â  To: Â  Multivariate Polynomial Ring in x, t over Rational
>Field
>Arithmetic performed after coercions.
>Result lives in Multivariate Polynomial Ring in x, t over Rational
>Field
>Multivariate Polynomial Ring in x, t over Rational Field
>No coercion if variable names are not strict subsets:
>sage: T. = QQ[]
>sage: cm.explain(T, S, operator.add)
>Unknown result parent.
>But explicit conversion can still work, e.g. by falling back to the
>index in gens():
>sage: T(S.gen(0))
>x
>sage: T(S.gen(1))
>y
> 
>--
>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 [2]sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to [3]sage-devel@googlegroups.com.
>Visit this group at [4]https://groups.google.com/group/sage-devel.
>For more options, visit [5]https://groups.google.com/d/optout.
> 
> References
> 
>1. mailto:vbraun.n...@gmail.com
>2. mailto:sage-devel+unsubscr...@googlegroups.com
>3. mailto:sage-devel@googlegroups.com
>4. https://groups.google.com/group/sage-devel
>5. 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] LaurentPolynomialRing and PolynomialRing behave inconsistently -- Request For Comments

[VulK]

Dear All,
for some project I have been working on for some time I found myself interested
in comparing elements of two different LaurentPolynomialRing. Unfortunately,
at the moment this is somewhat broken. The current behaviour is this:


sage: L1 = LaurentPolynomialRing(ZZ, 'x0,x1,x2,y0,y1,y2')
sage: L2 = LaurentPolynomialRing(ZZ, 'y0,y1,y2')
sage: L2.gen(0) in L1
False
sage: L1(L2.gen(0))
---
TypeError Traceback (most recent call last)
...
TypeError: tuple key must have same length as ngens


On the other hand PolynomialRing behave differently:

sage: P1 = PolynomialRing(ZZ, 'x0,x1,x2,y0,y1,y2')
sage: P2 = PolynomialRing(ZZ, 'y0,y1,y2')
sage: P2.gen(0) in P1
True
sage: P1(P2.gen(0))
y0


I made a ticket to address this issue #19538 and in the discussion there many
more inconsistencies popped out. This e-mail is to ask the community which 
should
be the desired behavior of both PolynomialRing and LaurentPolynomialRing and how
to get them to agree.

I will use this function to prettyprint

sage: def printmap(target, source):
print(str(source) + " --> " + str(map(target,source)))


* PolynomialRing

  sage: P1 = PolynomialRing(ZZ, 'x,y')
  sage: P2 = PolynomialRing(ZZ, 'x,t')
  sage: P3 = PolynomialRing(ZZ, 't,x')
  sage: P4 = PolynomialRing(ZZ, 'x,t,y')
  # these behave somewhat predictably
  sage: printmap(P4, P1.gens())
  (x, y) --> [x, y]
  sage: printmap(P4, P3.gens())
  (t, x) --> [t, x]
  y
  sage: P1(P4('t'))
  Traceback (most recent call last):
  ...
  TypeError: Could not find a mapping of the passed element to this ring.
   these instead are not really behaving in the same way
  sage: printmap(P1, P3.gens()) # this maps the i-th generator to the i-th 
generator irregardless of their names (t to x and x to y)
  (t, x) --> [x, y]
  sage: printmap(P3, P2.gens()) # this instead maps x to x and t to t 
  (x, t) --> [x, t]

* LaurentPolynomialRing

  sage: L1 = LaurentPolynomialRing(ZZ, 'x,y')
  sage: L2 = LaurentPolynomialRing(ZZ, 'x,t')
  sage: L3 = LaurentPolynomialRing(ZZ, 't,x')
  sage: L4 = LaurentPolynomialRing(ZZ, 'x,t,y')
  sage: printmap(L4, L1.gens())
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: printmap(L4, L3.gens())
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: L1(L4('t'))
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: sage: printmap(L1, L3.gens())
  (t, x) --> [x, y]
  sage: sage: printmap(L3, L2.gens())
  (x, t) --> [t, x]

As you can see for LaurentPolynomialRing the maps currently work only if source
and target have the same number of variables. Moreover, whenever they do, the
behaviour is different from the one of PolynomialRing: in any case the map sends
the i-th generator to the i-th generator (arguably this could e seen as more 
consistent).

After the patch I wrote the situation is the following:

* patched LaurentPolynomialRing

  sage: R1 = LaurentPolynomialRing(ZZ, 'x,y')
  sage: R2 = LaurentPolynomialRing(ZZ, 'x,t')
  sage: R3 = LaurentPolynomialRing(ZZ, 't,x')
  sage: R4 = LaurentPolynomialRing(ZZ, 'x,t,y')
  sage: printmap(R4, R1.gens())
  (x, y) --> [x, y]
  sage: printmap(R4, R3.gens())
  (t, x) --> [t, x]
  sage: R1(R4('t'))
  ---
  ValueErrorTraceback (most recent call last)
  ...
  ValueError: tuple.index(x): x not in tuple
  sage: sage: printmap(R1, R3.gens())
  ---
  ValueErrorTraceback (most recent call last)
  ValueError: tuple.index(x): x not in tuple
  sage: sage: printmap(R3, R2.gens())
  (x, t) --> [x, t]

The patch maps a generator to the generator having the same name, if any (which
explain the failures). The error code should probably be improved.  Note that 

sage: R1(R3.gen(1))
x
 
works as expected. This patch, though, while making LaurentPolynomialRing behave
like PolynomialRing in most cases, makes the behaviour inconsistent in the
previous to last case.

A note on speed: I expect the patched code to be slower than the original one. I
did not make any test to gauge how much.


In view of the above examples, which do you think should be the behaviour of 
both
LaurentpolynomialRing and PolynomialRing? This is quite a central piece of code
in sage and it would be better if the decision about how to proceed is not 

Re: [sage-devel] The package system: redundancy

[VulK]

Sorry, apparently I am late to the patch by few minutes thanks for the
pointers though, I'll keep surfing trac for related work in progress.

As for gcc on my machine being reinstalled by sage I guess I do have an old
version:  4.7

Thanks
S.



* Jeroen Demeyer  [2016-03-04 11:44:09]:

> On 2016-03-04 11:21, Salvatore Stella wrote:
> > especially when you consider that
> > among the duplicated things there are some heavy package to compile like
> > gcc
> GCC is only installed if needed. If Sage installs GCC, it must be that 
> your system GCC is either outdated of incomplete (missing Fortran?).
> 
> > Is there any plan to remove this issue in the future?
> Eventually yes. In fact, http://trac.sagemath.org/ticket/20137 
> introduces a mechanism to skip building certain packages.
> 
> > If so, who do I talk to in order to contribute?
> If you really want to help, reviewing that ticket could be a good start.
> 
> Jeroen.
> 
> -- 
> 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] Re: Trac - internal error

[VulK]

Same here:
http://trac.sagemath.org/ticket/19667
S.


* Johan S. R. Nielsen  [2016-01-15 16:40:37]:

> Same thing here, #19251.
> 
> Johan
> 
> david.lu...@inria.fr writes:
> 
> > Hello,
> >
> > Same thing with some of tickets: #19653, #19666, #19722, #19422 and #19623
> >
> > David
> >
> > Le vendredi 15 janvier 2016 15:37:58 UTC+1, Clemens Heuberger a écrit :
> >>
> >> Trac detected an internal error: 
> >>
> >> OSError: [Errno 2] No such file or directory: '/tmp/tmp7BmVNV' 
> >>
> >> The action that triggered the error was: 
> >>
> >> GET: /ticket/19306 
> >>
> >>
> 
> -- 
> 
> -- 
> 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: Various issues with LaurentPolynomialRing

[VulK]

Here is a quick patch for one of the listed issues:
http://trac.sagemath.org/ticket/19538
S.


* Travis Scrimshaw  [2015-11-04 16:37:17]:

>Hey Salvatore,
> 
>  first of all thank you for your answer, it looks like you are one of
>  the
>  person I pester the most with these issues.
> 
>I think I'm the one who knows the most about this because I have made
>the most recent additions and fixes to that part of Sage (although I'm
>happy to be wrong on this point).Â
> 
>  As far as gcd business goes my point is not that the current
>  behaviour is
>  necessarily wrong but it is inconsistent. What I mean is that
>  sage: L = LaurentPolynomialRing(ZZ, 'x0,x1,y0,y1')
>  sage: R = LaurentPolynomialRing(LaurentPolynomialRing(ZZ, 'y0,y1'),
>  'x0,x1')
>  mathematically should be (almost) the same object but
>  sage: L.inject_variables()
>  Defining x0, x1, y0, y1
>  sage: (x0+1)/(x0+1)
>  1
>  sage: R.inject_variables()
>  Defining x0, x1
>  sage: (x0+1)/(x0+1)
>  (x0 + 1)/(x0 + 1)
>  Their fraction fields are indeed different but elements belonging to
>  both
>  should have the same properties. This is not the case at the moment:
>  sage: L = L.fraction_field()
>  sage: R = R.fraction_field()
>  sage: L.inject_variables()
>  Defining x0, x1, y0, y1
>  sage: (x0+1).gcd(x0+1)
>  x0 + 1
>  sage: R.inject_variables()
>  Defining x0, x1
>  sage: (x0+1).gcd(x0+1)
>  1
>  I agree with you that a rewrite might not be a good use of anyone's
>  time so
>  we should start bug hunting first. Â I will open a ticket with the
>  last of the
>  issues I pointed out in my previous e-mail as soon as I can find a
>  solution.
> 
>I suspect it all comes down to defining a gcd of the multivariate
>Laurent polynomial ring and this fixing the issues. Although this may
>not be the only problem because of the fact that these fraction fields
>are different. I think this is true even mathematically speaking as one
>is rational functions in x0, x1, y0, y0, with coefficients in ZZ and
>the rational functions in y0, y1 with coefficients in the Laurent
>polynomial ring x0, x1 over ZZ as (y0 + y1) / (y0 - y1) is not in the
>latter I believe.
> 
>  One design question: can someone explain to me the rationale of
>  having two
>  implementations for Laurent polynomials (one univariate and one
>  multivariate)
>  and then a wrapper factory function on top? If the idea is that some
>  methods
>  are defined only in special cases would it not be easier to add them
>  at
>  __init__ time with something like
>  self.mymethod = MethodType(mymethod, self, self.__class__)
>  This would allow to expose directly two classes
>  LaurentPolynomialRing and
>  LaurentPolynomial instead of a factory function.
> 
>Â Â  I see two big reasons. The first is speed and memory efficiency
>because the internal structure of the univariate is more simple than
>the multivariate. The second is there are more algorithms/methods for
>the univariate (which is an argument for subclassing, or at least
>possibly separating out common functionality into an ABC).
>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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] More LaurentPolynomialRing insanity

[VulK]

Dear all, 
I just noted the following:

sage: R = LaurentPolynomialRing(ZZ,'x,y')
sage: T = R.remove_var('x')
sage: T.inject_variables()
Defining y
sage: y in T
True
sage: y in R
True

As one should expect, now for a second try

sage: R = LaurentPolynomialRing(ZZ,'x,y,z')
sage: T = R.remove_var('x')
sage: T.inject_variables()
Defining y, z
sage: y in T
True
sage: y in R
False

And of course, you try R(y), hell break loose. 

At this point, at least in my experience, there are more issues with
LaurentPolynomialRing than features. Is there any plan to replace the
implementation with something less bug ridden in the near future? 

Should I decide to invest time in rewriting it, would anyone here be
interested to help? Do you have any suggestion/reference on how this should
be done properly?
Thanks
Salvatore

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] More LaurentPolynomialRing insanity

[VulK]

Thank you for the pointer,
I will move the discussion there.
S.


* Nicolas M. Thiery <nicolas.thi...@u-psud.fr> [2015-11-03 17:04:31]:

> On Tue, Nov 03, 2015 at 04:37:25PM +0100, VulK wrote:
> > I just noted the following:
> > 
> > sage: R = LaurentPolynomialRing(ZZ,'x,y')
> > sage: T = R.remove_var('x')
> > sage: T.inject_variables()
> > Defining y
> > sage: y in T
> > True
> > sage: y in R
> > True
> > 
> > As one should expect, now for a second try
> > 
> > sage: R = LaurentPolynomialRing(ZZ,'x,y,z')
> > sage: T = R.remove_var('x')
> > sage: T.inject_variables()
> > Defining y, z
> > sage: y in T
> > True
> > sage: y in R
> > False
> > 
> > And of course, you try R(y), hell break loose. 
> > 
> > At this point, at least in my experience, there are more issues with
> > LaurentPolynomialRing than features. Is there any plan to replace the
> > implementation with something less bug ridden in the near future? 
> > 
> > Should I decide to invest time in rewriting it, would anyone here be
> > interested to help? Do you have any suggestion/reference on how this should
> > be done properly?
> 
> Just a note: this would be better discussed on sage-devel.
> 
> Cheers,
>   Nicolas
> --
> Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
> http://Nicolas.Thiery.name/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-combinat-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-combinat-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-combinat-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Fast polynomial powers

[VulK]

Dear all,
As some of you might know I am trying to optimize the way in which cluster
algebras are implemented in sage. 

In my current implementation one of the biggest bottleneck happens when 
I take powers of polynomials in n variables (n is usually much smaller than
10) with integer coefficients and quite high degrees (few hundreds). 
The way I am computing things now is, probably, the dumbest possible:

sage: f in PolynomialRing(ZZ,'u0,u1,u2')
True
sage: f.degree()
159
sage: len(f.monomials())
18105
sage: %time foo = f**2
CPU times: user 4min 30s, sys: 5 ms, total: 4min 30s
Wall time: 4min 30

Is there some clever way to save some time here or it is just hopeless?
Thanks
S.




-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Fraction field elements are not simplified

[VulK]

Dear All,
here is a brief status update on this issue. TL;DR: Laurent Polynomial Ring
does not provide a gcd implementation.

Recall that we are in this situation:
sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'),'x')
sage: R = L.fraction_field()
sage: R.inject_variables()
Defining x
sage: x.gcd(x)
1

This is the implementation of gcd called by x.gcd(x)

@coerce_binop
def gcd(self, other):
P = self.parent()
try:
selfN = self.numerator()
selfD = self.denominator()
selfGCD = selfN.gcd(selfD)
otherN = other.numerator()
otherD = other.denominator()
otherGCD = otherN.gcd(otherD)
selfN = selfN // selfGCD
selfD = selfD // selfGCD
otherN = otherN // otherGCD
otherD = otherD // otherGCD
tmp = P(selfN.gcd(otherN))/P(selfD.lcm(otherD))
return tmp
except (AttributeError, NotImplementedError, TypeError, ValueError):
zero = P.zero()
if self == zero and other == zero:
return zero
return P.one()

clearly selfN is x and selfD is 1 as elements of L but

sage: selfN.gcd(selfD) 
...
NotImplementedError: Univariate Laurent Polynomial Ring in t over Integer Ring 
does not provide a gcd implementation for univariate polynomials

S.

PS: of course this is not just a problem with units: 

sage: (x+1).gcd(x+1)
1
sage: (x+1).numerator().gcd(1)
NotImplementedError: Univariate Laurent Polynomial Ring in t over Integer Ring 
does not provide a gcd implementation for univariate polynomials






* Travis Scrimshaw  [2015-10-10 05:57:20]:

>I think I slightly misspoke about the gcd. See the details on
>[1]http://trac.sagemath.org/ticket/16993.
>Best,
>Travis
>On Friday, October 9, 2015 at 4:12:12 PM UTC-5, Travis Scrimshaw wrote:
> 
>Hey Salvatore,
>Â Â  I would say this is the same problem as simplifying scalars of
>fraction fields of polynomials over QQ, that gcd(x, x) = 1 rather than
>x because x is a unit. I don't think we have a way around this
>currently other than doing some kind of explicit coercion.
>Best,
>Travis
>On Friday, October 9, 2015 at 1:40:22 PM UTC-5, Salvatore Stella wrote:
> 
>  Dear all,
>  I just noted the following odd behaviour:
>  sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field()
>  sage: L.inject_variables()
>  Defining x
>  sage: x/x
>  1
>  As one should expect but if we change the base ring then things get
>  messy:
>  sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'),
>  'x').fraction_field()
>  sage: L.inject_variables()
>  Defining x
>  sage: x/x
>  x/x
>  sage: _.denominator()
>  x
>  The fact that x/x is printed out as x/x is still ok if somewhat
>  annoying. But
>  the return value of denominator() is definitely not what I would
>  expect.
>  Is this intentional?
>  Thanks
>  Salvatore
> 
> References
> 
>1. http://trac.sagemath.org/ticket/16993

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Fraction field elements are not simplified

[VulK]

Dear all,
I just noted the following odd behaviour:

sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field()
sage: L.inject_variables()
Defining x
sage: x/x
1

As one should expect but if we change the base ring then things get messy:
sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'), 
'x').fraction_field()
sage: L.inject_variables()
Defining x
sage: x/x
x/x
sage: _.denominator()
x

The fact that x/x is printed out as x/x is still ok if somewhat annoying. But
the return value of denominator() is definitely not what I would expect.
Is this intentional? 
Thanks
Salvatore

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Root systems do not define variables correctly

[VulK]

Hi,
I guess injecting simple roots would be my choice.
If not possible, at least, it would be cleaner to remove inject_variables
from the auto completion list for A.
S.

* Nicolas M. Thiery nicolas.thi...@u-psud.fr [2012-07-12 23:47:34]:

 On Thu, Jul 12, 2012 at 11:08:54PM -0400, VulK wrote:
  I just noticed the following odd behaviour:
  
   sage: L=RootSystem(['A',2]).root_lattice()
   sage: L.inject_variables()
   ---
   ValueErrorTraceback (most recent call 
   last)
   ValueError: variable names have not yet been set using
  
  I am running Sage Version 5.1, Release Date: 2012-07-09 with combinat queue
  both compiled from sources today (I noticed the same behaviour on an old 4.8
  install and I upgraded to check if had already been addressed).
  I assume it will suffices to add _assign_names in the definition of
  root_lattice but I did not have time to check it.
 
 What would you want this method to do for root lattices?
 
   Nicolas
 --
 Nicolas M. Thiéry Isil nthi...@users.sf.net
 http://Nicolas.Thiery.name/
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sage-combinat-devel group.
 To post to this group, send email to sage-combinat-devel@googlegroups.com.
 To unsubscribe from this group, send email to 
 sage-combinat-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sage-combinat-devel?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sage-combinat-devel group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

[sage-combinat-devel] Root systems do not define variables correctly

[VulK]

Hi,
I just noticed the following odd behaviour:

 sage: L=RootSystem(['A',2]).root_lattice()
 sage: L.inject_variables()
 ---
 ValueErrorTraceback (most recent call last)
 
 /opt/sage/sage-5.1/ipython console in module()
 
 /opt/sage/sage-5.1/local/lib/python2.7/site-packages/sage/structure/category_object.so
 in sage.structure.category_object.CategoryObject.inject_variables
 (sage/structure/category_object.c:5146)()
 
 /opt/sage/sage-5.1/local/lib/python2.7/site-packages/sage/structure/category_object.so
 in sage.structure.category_object.CategoryObject.variable_names
 (sage/structure/category_object.c:4775)()
 
 ValueError: variable names have not yet been set using
 self._assign_names(...)

I am running Sage Version 5.1, Release Date: 2012-07-09 with combinat queue
both compiled from sources today (I noticed the same behaviour on an old 4.8
install and I upgraded to check if had already been addressed).
I assume it will suffices to add _assign_names in the definition of
root_lattice but I did not have time to check it.
Thanks
Salvatore Stella

-- 
You received this message because you are subscribed to the Google Groups 
sage-combinat-devel group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

Re: [sage-combinat-devel] B-matrix class of finite type cluster algebras

[VulK]

Sorry I meant there are problem applying
trac_6588-categories-root_systems-review-nt.patch
S.

* Christian Stump christian.st...@gmail.com [2012-03-10 18:43:30]:

 Dear Salvatore,
 
         sage: S=ClusterSeed(['E',8])
         sage: T=S.principal_extension()
         sage: T.b_matrix_class()
 
 that was a bug in our code (that was there actually from the beginning
 on). I hope I fixed it; I pushed the changes, could you please recheck
 that you get the right numbers (if that is actually possible!) in some
 small examples like
 
 S=ClusterSeed(X)
 T=S.principal_extension()
 T.b_matrix_class()
 
 for X in types A and B in rank 2 and 3?
 
 Thanks for reporting, Christian
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sage-combinat-devel group.
 To post to this group, send email to sage-combinat-devel@googlegroups.com.
 To unsubscribe from this group, send email to 
 sage-combinat-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sage-combinat-devel?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sage-combinat-devel group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.