Re: [sage-devel] Re: One year of Sage development on GitHub

[Sebastian Oehms]

> *By the way, an author of a PR needs also the ability to remove "needs
work". Hence the author needs to be in the Triage team anyway in our
workflow. *

Not necessarily! If the *synchronizing trigger* is enabled then the bot
would change needs work to  needs review on a non draft PR each time a new
commit is pushed to the branch.

On Wed, Feb 21, 2024 at 10:01 AM Kwankyu Lee  wrote:

>
>
> On Tuesday, February 20, 2024 at 12:26:50 PM UTC+9 Matthias Koeppe wrote:
>
> Can the status label sync workflow help with this transition, without
> getting in the way? For example, when the _author_ removes the "needs
> review" label (without setting "positive review"), set the PR to "draft"?
>
>
> sync workflow seems not yet ready for the transition because of the bug.
>
> By the way, an author of a PR needs also the ability to remove "needs
> work". Hence the author needs to be in the Triage team anyway in our
> workflow.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/sulCa-6EZRA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/268e5d1c-5ff4-4d88-8ea4-7aaef77973cfn%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/CAPEyD1C7Fi6AtuVDAjgLuiTLbHMJmUF3s6_j4vAMxg6SK3xZDA%40mail.gmail.com.

Re: [sage-devel] Re: missing docker images of sagemath

[Sebastian Oehms]

https://gitlab.com/sagemath/dev/trac/-/pipelines

On Mon, Dec 28, 2020 at 11:02 PM Sebastian Oehms  wrote:
>
> Thanks to you both for the hints! Yes, instead of develop I used the
> version tag directly. Running docker as you suggested solves the
> problem. But, the version tag works on a newer CPU (the one causing
> the crash was an i5 of the 2. generation), as well, and for 9.1.beta1
> even on the older CPU.
>
> What about my second point concerning the trac ticket branches, I mean this?
>
> On Mon, Dec 28, 2020 at 9:49 PM Frédéric Chapoton  
> wrote:
> >
> > did you run
> >
> > docker run -it sagemath/sagemath-dev:develop
> >
> > or something else ?
> >
> > Le lundi 28 décembre 2020 à 12:45:20 UTC+1, seb@gmail.com a écrit :
> >>
> >> It seems that there is still (or again) something broken. For the images 
> >> of the beta releases since the 8th of December Sage crashes if I try to 
> >> start it:
> >>
> >> Sage build/upgrade complete!
> >> make[1]: Leaving directory '/home/sage/sage'
> >> sage@8711c66abafe:~/sage$ ./sage
> >> ┌┐
> >> │ SageMath version 9.3.beta5, Release Date: 2020-12-27   │
> >> │ Using Python 3.8.5. Type "help()" for help.│
> >> └┘
> >> ┏┓
> >> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> >> ┗┛
> >> 
> >> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6b28)[0x7ff042b33b28]
> >> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6d08)[0x7ff042b33d08]
> >> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x93a0)[0x7ff042b363a0]
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7ff0523f9390]
> >> /home/sage/sage/local/lib/libgmp.so.10(__gmpz_sizeinbase+0x47)[0x7ff049df0597]
> >> /home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x1f78c)[0x7ff036e2978c]
> >> /home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x370d5)[0x7ff036e410d5]
> >> 
> >> /home/sage/sage/local/lib/libpython3.8.so.1.0(+0x185260)[0x7ff05278a260]
> >> /home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_FileExFlags+0x95)[0x7ff05278cb45]
> >> /home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_SimpleFileExFlags+0xf6)[0x7ff05278ccb6]
> >> /home/sage/sage/local/lib/libpython3.8.so.1.0(Py_RunMain+0x748)[0x7ff0527a7398]
> >> /home/sage/sage/local/lib/libpython3.8.so.1.0(Py_BytesMain+0x39)[0x7ff0527a77c9]
> >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ff05203e840]
> >> python3(_start+0x29)[0x400709]
> >> 
> >> Attaching gdb to process id 9075.
> >> Cannot find gdb installed
> >> GDB is not installed.
> >> Install gdb for enhanced tracebacks.
> >> 
> >> Unhandled SIGILL: An illegal instruction occurred.
> >> This probably occurred because a *compiled* module has a bug
> >> in it and is not properly wrapped with sig_on(), sig_off().
> >> Python will now terminate.
> >> 
> >> Illegal instruction (core dumped)
> >>
> >> Furthermore, all pipelines on individual branches since that date failed.
> >>
> >> Frédéric Chapoton schrieb am Dienstag, 8. Dezember 2020 um 09:33:03 UTC+1:
> >>>
> >>> the build for 9.3.beta3 has passed successfully, so there should be a 
> >>> docker for that, and a docker for develop that should point to the same.
> >>>
> >>> https://gitlab.com/sagemath/sage/-/pipelines
> >>>
> >>> Frédéric
> >>>
> >>> Le jeudi 15 octobre 2020 à 12:09:15 UTC+2, Sébastien Labbé a écrit :
> >>>>
> >>>> Bonjour,
> >>>>
> >>>> Thanks to Vincent, I learned recently how to use continuous integration 
> >>>> in gitlab

Re: [sage-devel] Re: missing docker images of sagemath

[Sebastian Oehms]

Thanks to you both for the hints! Yes, instead of develop I used the
version tag directly. Running docker as you suggested solves the
problem. But, the version tag works on a newer CPU (the one causing
the crash was an i5 of the 2. generation), as well, and for 9.1.beta1
even on the older CPU.

What about my second point concerning the trac ticket branches, I mean this?

On Mon, Dec 28, 2020 at 9:49 PM Frédéric Chapoton  wrote:
>
> did you run
>
> docker run -it sagemath/sagemath-dev:develop
>
> or something else ?
>
> Le lundi 28 décembre 2020 à 12:45:20 UTC+1, seb@gmail.com a écrit :
>>
>> It seems that there is still (or again) something broken. For the images of 
>> the beta releases since the 8th of December Sage crashes if I try to start 
>> it:
>>
>> Sage build/upgrade complete!
>> make[1]: Leaving directory '/home/sage/sage'
>> sage@8711c66abafe:~/sage$ ./sage
>> ┌┐
>> │ SageMath version 9.3.beta5, Release Date: 2020-12-27   │
>> │ Using Python 3.8.5. Type "help()" for help.│
>> └┘
>> ┏┓
>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>> ┗┛
>> 
>> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6b28)[0x7ff042b33b28]
>> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6d08)[0x7ff042b33d08]
>> /home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x93a0)[0x7ff042b363a0]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7ff0523f9390]
>> /home/sage/sage/local/lib/libgmp.so.10(__gmpz_sizeinbase+0x47)[0x7ff049df0597]
>> /home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x1f78c)[0x7ff036e2978c]
>> /home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x370d5)[0x7ff036e410d5]
>> 
>> /home/sage/sage/local/lib/libpython3.8.so.1.0(+0x185260)[0x7ff05278a260]
>> /home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_FileExFlags+0x95)[0x7ff05278cb45]
>> /home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_SimpleFileExFlags+0xf6)[0x7ff05278ccb6]
>> /home/sage/sage/local/lib/libpython3.8.so.1.0(Py_RunMain+0x748)[0x7ff0527a7398]
>> /home/sage/sage/local/lib/libpython3.8.so.1.0(Py_BytesMain+0x39)[0x7ff0527a77c9]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ff05203e840]
>> python3(_start+0x29)[0x400709]
>> 
>> Attaching gdb to process id 9075.
>> Cannot find gdb installed
>> GDB is not installed.
>> Install gdb for enhanced tracebacks.
>> 
>> Unhandled SIGILL: An illegal instruction occurred.
>> This probably occurred because a *compiled* module has a bug
>> in it and is not properly wrapped with sig_on(), sig_off().
>> Python will now terminate.
>> 
>> Illegal instruction (core dumped)
>>
>> Furthermore, all pipelines on individual branches since that date failed.
>>
>> Frédéric Chapoton schrieb am Dienstag, 8. Dezember 2020 um 09:33:03 UTC+1:
>>>
>>> the build for 9.3.beta3 has passed successfully, so there should be a 
>>> docker for that, and a docker for develop that should point to the same.
>>>
>>> https://gitlab.com/sagemath/sage/-/pipelines
>>>
>>> Frédéric
>>>
>>> Le jeudi 15 octobre 2020 à 12:09:15 UTC+2, Sébastien Labbé a écrit :

 Bonjour,

 Thanks to Vincent, I learned recently how to use continuous integration in 
 gitlab and the docker images of previous versions of sage posted 
 https://hub.docker.com/r/sagemath/sagemath-dev/ in order to test that my 
 optional package works with all those versions. It basically made me 
 realize that my package was broken on most versions of sage except the 
 most recent. And hopefully soon, I will be able to fix those issues. So 
 thanks to those involved in having these various docker images available.

 For the curious, the most recent run is available here:
 https://gitlab.com/seblabbe/slabbe/-/pipelines/202932270
 it shows that my package works for 9.1.rc5 but not 9.0 or earlier versions 
 (I need to work on it).

 Unfortunately, it seems the docker images of various versions of sage are 
 not uploaded since 4 months. Maybe it was too much energy to upload all 
 beta versions there. In fact, I don't really need all beta in there. What 
 I think is important to have are the final releases. 

[sage-devel] Interface to the KnotInfo and LinkInfo databases

[Sebastian Oehms]

Dear All,

a couple of months ago I started to implement an interface to the databases 
of knots and links provided at the web-pages KnotInfo 
 and LinkInfo 
.

The corresponding ticket #30352  is 
under review, right now. Criticism, discussion and all other kinds of 
contributions are welcome.

Best,
Sebastian

-- 
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/cc472642-069a-4f29-a53e-ffcaedc1f217o%40googlegroups.com.

[sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

[Sebastian Oehms]

>
> have to figure out a way to save the information in a version-independent 
> way asap and meanwhile keep using sage8.9. It doesn't sound easy to do.
>

Let me try to help: As I understood your test case consists of matrices 
over the integers, right? If you convert it into a pure Python dictionary 
over Python integers  before you save it to an sobj-file then you will have 
a much more stable format. From such a dictionary you can recover your 
matrix easily by Sage construction functionality:

sage: m = matrix(ZZ, [[1, 2], [3, 4]])
sage: mpy = {tuple(k):int(v) for k, v in m.dict().items()}
sage: mpy
{(0, 0): 1, (0, 1): 2, (1, 0): 3, (1, 1): 4}
sage: save(mpy, 'mpy.sobj')
sage: mpy_back = load('mpy.sobj')
sage: m == matrix(mpy_back)
True



If you still feel unsafe with that you shoud choose a readable format, for 
example json as suggested before. I prefer yaml since it can be easily used 
for dictionaries. But unfortunately it is not included in Sage per default. 
So you have to install it first:


sage -pip install ruamel.yaml




Now doing the same as above with YAML:


sage: from ruamel.yaml import YAML
sage: yaml = YAML()
sage: fp = open('mpy.yaml', "w")
sage: yaml.dump(mpy, fp)
sage: fp.close()
sage: fp = open('mpy.yaml', "r")
sage: mpy_back_yaml = yaml.load(fp)
sage: mpy_back_yaml
ordereddict([((0, 0), 1), ((0, 1), 2), ((1, 0), 3), ((1, 1), 4)])
sage: m == matrix(mpy_back_yaml)
True




The file looks like this:


cat mpy.yaml
? - 0
  - 0
: 1
? - 0
  - 1
: 2
? - 1
  - 0
: 3
? - 1
  - 1
: 4



In the first ticket I've linked to this thread I've uploaded a ipynb-file 
 to 
demonstrate more advanced applications of YAML with Sage.


On Wednesday, July 29, 2020 at 9:17:19 AM UTC+2, Udo Baumgartner wrote:
>
> Many thanks for your replies. I understand the problem now much better and 
> obviously have to figure out a way to save the information in a 
> version-independent way asap and meanwhile keep using sage8.9. It doesn't 
> sound easy to do.
>
> Those pointers to tickets #28302 und #28444 were particularly helpful. 
>
> Aside: It is disappointing that no secure method to store computed values 
> is available yet. One of my computations took half a year to complete and 
> on top of that loading some of the data used in those computations is also 
> not possible with sage9.1.
>
> seb@gmail.com schrieb am Dienstag, 28. Juli 2020 um 12:11:28 UTC+2:
>
>> Related tickets to this issue are #28302 
>>  and #28444! 
>> 
>>
>> Best,
>> Sebastian
>>
>>
>> On Saturday, July 25, 2020 at 12:03:07 AM UTC+2, Udo Baumgartner wrote:
>>>
>>> I have lots of precomputed data computed by sage8.9 and before that I 
>>> rely on. The reason I save that data is that it took a lot of computation 
>>> time to obtain it. The data is saved as .sobj-files. 
>>>
>>> Suddenly I get "invalid pickle data"-errors when trying to load some of 
>>> that data with the new version of sage. I am therefore unable to do 
>>> computations on top of the precomputed data. 
>>>
>>> I strongly suspect that this issue is due to basing sage9.x on Python3. 
>>>
>>> How do I convert the data so that I can use it in the new version of 
>>> sage?
>>>
>>> I'm using *sage-9.1-OSX_10.15.4-x86_64.app* now on a late 2013 
>>> MacBookPro running MacOSCatalina 10.15.6. A toy example of a sobj-file that 
>>> now produces the error is attached. The error messages are reproduced below.
>>>
>>>
>>> Help is greatly appreciated.
>>>
>>>
>>> Now, said error messages:
>>>
>>> ---RuntimeError
>>>   Traceback (most recent call 
>>> last) in ()> 1 DiGraph = 
>>> load('A3VuDiGraph')
>>> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>>>  in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2900)()
>>> 156 157 ## Load file by absolute filename--> 158 with 
>>> open(filename, 'rb') as fobj:159 X = loads(fobj.read(), 
>>> compress=compress, **kwargs)160 try:
>>> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>>>  in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2850)()
>>> 157 ## Load file by absolute filename158 with open(filename, 
>>> 'rb') as fobj:--> 159 X = loads(fobj.read(), compress=compress, 
>>> **kwargs)160 try:161 X._default_filename = 
>>> os.path.abspath(filename)
>>> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>>>  in sage.misc.persist.loads (build/cythonized/sage/misc/persist.c:7424)()   
>>> 10421043 unpickler = SageUnpickler(io.BytesIO(s), **kwargs)-> 1044  
>>>return unpickler.load()   1045

[sage-devel] Re: The PolynomialRing that isn't

[Sebastian Oehms]

Recently I made some suggestions about that in this thread 
.

Best,
Sebastian

On Monday, July 27, 2020 at 2:25:16 PM UTC+2, Ricardo Buring wrote:
>
> Dear sage-devel,
>
> I would like to drag up this old issue because it is a source of confusion 
> and frustration for new users. The problem is that PolynomialRing uses 
> (lib)Singular's ring without restricting the possible term orderings. 
> Singular's ring is a polynomial ring _only if_ it is passed a "global" term 
> ordering. If it is passed a "local" term ordering, then it is rather a 
> localization of a polynomial ring. It is easy to see how this can be 
> confusing when computing things that should be independent of the (global) 
> term ordering, such as dimension (https://trac.sagemath.org/ticket/10708) 
> or simply divisibility (
> https://ask.sagemath.org/question/52623/find-quotient-of-two-multivariate-polynomials-which-are-divisible/
> ).
>
> 1. Can we add a warning about this current situation, e.g. in the 
> PolynomialRing constructor?
> This was suggested on Ask SageMath: 
> https://ask.sagemath.org/question/52699/suggestion-for-documentation-of-multivariate-polynomials/
> The current documentation, "return the (...) polynomial ring (...)" is 
> incomplete.
>
> 2. How much SageMath functionality depends on localizations, and is 
> currently (ab)using PolynomialRing in this way?
> So far, I find: ToricIdeal, LetterplaceIdeal, InteractiveLPProblem, 
> GroebnerStrategy (in tests), PathAlgebra, PathAlgebraElement, 
> PathSemigroup, PowerSeriesRing, MPowerSeriesRing_generic, 
> PolynomialSequence_generic (for no particular reason), 
> AlgebraicScheme_subscheme_affine, MPolynomialIdeal (in tests).
> It's not that much, so it would (internally) not be that big a deal if 
> the interface (the way to construct localizations of polynomial rings) 
> changed.
>
> 3. How should these two functionalities of Singular (ideally) be exposed 
> in SageMath?
> Easy but ugly: add phrases like "(or a localization thereof)" to the 
> docs, and maybe add a localization flag to the PolynomialRing constructor 
> to explicitly allow local orderings.
> I think it would be better to somehow separate the two. I suppose 
> there should be a common base class, for simplicity of interaction with 
> (lib)Singular.
> Could we add a constructor like PolynomialRingLocalization? Let that 
> one accept the local orderings, and let PolynomialRing accept only global 
> orderings.
> I guess the difficulty is to make everything work out with the parents 
> and categories frameworks. Can somebody comment on that?
> By the way, it is a bit unfortunate that the interface to Singular's 
> ring is called MPolynomialRing_libsingular rather than just 
> Ring_libsingular (in view of this issue).
>
> Best regards,
> Ricardo
>

-- 
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/c5155a9a-8b0c-4322-8396-671392be2f45o%40googlegroups.com.

[sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

[Sebastian Oehms]

Related tickets to this issue are #28302 
 and #28444! 


Best,
Sebastian


On Saturday, July 25, 2020 at 12:03:07 AM UTC+2, Udo Baumgartner wrote:
>
> I have lots of precomputed data computed by sage8.9 and before that I rely 
> on. The reason I save that data is that it took a lot of computation time 
> to obtain it. The data is saved as .sobj-files. 
>
> Suddenly I get "invalid pickle data"-errors when trying to load some of 
> that data with the new version of sage. I am therefore unable to do 
> computations on top of the precomputed data. 
>
> I strongly suspect that this issue is due to basing sage9.x on Python3. 
>
> How do I convert the data so that I can use it in the new version of sage?
>
> I'm using *sage-9.1-OSX_10.15.4-x86_64.app* now on a late 2013 MacBookPro 
> running MacOSCatalina 10.15.6. A toy example of a sobj-file that now 
> produces the error is attached. The error messages are reproduced below.
>
>
> Help is greatly appreciated.
>
>
> Now, said error messages:
>
> ---RuntimeError
>   Traceback (most recent call 
> last) in ()> 1 DiGraph = 
> load('A3VuDiGraph')
> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>  in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2900)()
> 156 157 ## Load file by absolute filename--> 158 with 
> open(filename, 'rb') as fobj:159 X = loads(fobj.read(), 
> compress=compress, **kwargs)160 try:
> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>  in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2850)()
> 157 ## Load file by absolute filename158 with open(filename, 
> 'rb') as fobj:--> 159 X = loads(fobj.read(), compress=compress, 
> **kwargs)160 try:161 X._default_filename = 
> os.path.abspath(filename)
> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/misc/persist.pyx
>  in sage.misc.persist.loads (build/cythonized/sage/misc/persist.c:7424)()   
> 10421043 unpickler = SageUnpickler(io.BytesIO(s), **kwargs)-> 1044
>  return unpickler.load()   10451046 
> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/matrix/matrix0.pyx
>  in sage.matrix.matrix0.unpickle 
> (build/cythonized/sage/matrix/matrix0.c:39715)()   5874 A._cache = cache  
>  5875 if version >= 0:-> 5876 A._unpickle(data, version)   5877   
>   else:   5878 A._unpickle_generic(data, version)
> /Applications/SageMath-9.1.app/Contents/Resources/sage/local/lib/python3.7/site-packages/sage/matrix/matrix_integer_dense.pyx
>  in sage.matrix.matrix_integer_dense.Matrix_integer_dense._unpickle 
> (build/cythonized/sage/matrix/matrix_integer_dense.c:8217)()540   
>   self._unpickle_matrix_2x2_version0(data)541 else:--> 
> 542 raise RuntimeError("invalid pickle data")543 
> else:544 raise RuntimeError("unknown matrix version 
> (=%s)"%version)
> RuntimeError: invalid pickle data
>
>
>

-- 
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/9de447d2-c9dc-4c08-b690-93ca6bbc0feao%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Sebastian Oehms]

On Friday, May 8, 2020 at 11:37:03 AM UTC+2, Markus Wageringel wrote:
>
> Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
>>
>> But if we talk about users who are not interested in code and strings, 
>> wouldn't it be more useful for them to have a function that searches 
>> through the global name space? Do we have such a one?
>>
>
> We do indeed. It is an IPython feature. You can use
>
> sage: *poly*?
>
> which is equivalent to
>
> sage: %psearch *poly*
>
> The psearch magic also has options such as case-insensitivity
>
> sage: %psearch -i *poly*
>
>
Nice! I didn't know that. I think that should be in the tutorials (where *Tab 
complition* is explained) and on the SageMathCell-Page.

-- 
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/2e27ac09-0c22-4f66-99ef-4b6e2322516c%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Sebastian Oehms]

On Thursday, May 7, 2020 at 2:45:51 PM UTC+2, kcrisman wrote:

> ... and again many users may not even know there is a directory structure 
> at all.   This is not a "highly peculiar set of disabilities" - rather, the 
> skill set of people on sage-devel is a "highly peculiar set of abilities", 
> even among people doing math on a regular basis.
>

I have never used search_src/_def/_doc. But in general, I would not 
deprecate a well working functionality without a real need. Surely, there 
are users to whom this will be annoying. But if we talk about users who are 
not interested in code and strings, wouldn't it be more useful for them to 
have a function that searches through the global name space? Do we have 
such a one?
The tutorial mentions *Tab completion*. But that only helps if you already 
know the beginning of the word:

 
sage: def search_names(string):
: g = globals()
: for s in g.keys():
: if s.find(string)>=0:
: print(s)

sage: search_names('poly')
bell_polynomial
bernoulli_polynomial
characteristic_polynomial
charpoly
conway_polynomial
cyclotomic_polynomial
exists_conway_polynomial
hilbert_class_polynomial
hyperbolic_polygon
hyperbolic_regular_polygon
lattice_polytope
lfsr_connection_polynomial
minimal_polynomial
minpoly
polygen
polygens
polygon
polygon2d
polygon3d
polygon_spline
polygons3d
polylog
polymake
polytopes

BTW: How do you use *Tab completion* on SageMathCell?

-- 
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/660629e8-3985-494f-96dd-317762d7f554%40googlegroups.com.

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

[Sebastian Oehms]

I've opened ticket #29600. <https://trac.sagemath.org/ticket/29600#ticket>

Best,
Sebastian

On Monday, April 27, 2020 at 5:04:28 AM UTC+2, Travis Scrimshaw wrote:
>
> I also suspect it comes from some kind of rounding or precision issue, 
> likely in MPFR since nearly all of the computations are done there. At 
> least this is not super pressing since the Bober implementation is not the 
> default implementation, but it is definitely something that should be fixed.
>
> Best,
> Travis
>
>
> On Sunday, April 26, 2020 at 6:03:30 AM UTC+10, Sebastian Oehms wrote:
>>
>> see also #28549 <https://trac.sagemath.org/ticket/28549>.
>>
>> On Monday, April 20, 2020 at 9:23:52 AM UTC+2, Sebastian Oehms wrote:
>>>
>>> The existenz of the problem already appeared in Friedrich Wiemer's 
>>> status report 
>>> <https://groups.google.com/forum/#!searchin/sage-devel/Windows$20Subsystem/sage-devel/WoEWxYmwQnI/-LkPAc8VBAAJ>
>>>  
>>> on Sage under Windows 10 using the Windows Subsystem for Linux (WSL).
>>>
>>> Now, that I have my office equipment (including a Windows 10 machine) at 
>>> home, I took the occasion to install und play with WSL (using the Ubuntu 
>>> App). I build Sage version 9.1.rc0 and run all doctests (like Friedrich 
>>> did). The list of failing doctests (see the attached file) is not far from 
>>> the corresponding list in Friedrich's log-file. Some issues disappeared 
>>> while others remained and new ones have been added. But, the first issue in 
>>> both lists is remarkable:
>>>
>>> *On WSL:*
>>>
>>> sage: number_of_partitions(241, algorithm='bober')
>>> 114540884553039
>>> sage: number_of_partitions(241)
>>> 114540884553038
>>>
>>>
>>> *whereas on proper Ubuntu (same Sage version) or Cygwin on the same 
>>> machine (but stable 9.0):*
>>>
>>> sage: number_of_partitions(241, algorithm='bober')
>>> 114540884553038
>>> sage: number_of_partitions(241)
>>> 114540884553038
>>>
>>> I think, that is an issue which can damage trust even thought it 
>>> probably is not caused by Sage. Shouldn't we trace that back? To me it 
>>> looks like a rounding problem via MPFR.
>>>
>>>

-- 
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/54e33646-de38-4c5b-88ac-a0af4e441166%40googlegroups.com.

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

[Sebastian Oehms]

see also #28549 <https://trac.sagemath.org/ticket/28549>.

On Monday, April 20, 2020 at 9:23:52 AM UTC+2, Sebastian Oehms wrote:
>
> The existenz of the problem already appeared in Friedrich Wiemer's status 
> report 
> <https://groups.google.com/forum/#!searchin/sage-devel/Windows$20Subsystem/sage-devel/WoEWxYmwQnI/-LkPAc8VBAAJ>
>  
> on Sage under Windows 10 using the Windows Subsystem for Linux (WSL).
>
> Now, that I have my office equipment (including a Windows 10 machine) at 
> home, I took the occasion to install und play with WSL (using the Ubuntu 
> App). I build Sage version 9.1.rc0 and run all doctests (like Friedrich 
> did). The list of failing doctests (see the attached file) is not far from 
> the corresponding list in Friedrich's log-file. Some issues disappeared 
> while others remained and new ones have been added. But, the first issue in 
> both lists is remarkable:
>
> *On WSL:*
>
> sage: number_of_partitions(241, algorithm='bober')
> 114540884553039
> sage: number_of_partitions(241)
> 114540884553038
>
>
> *whereas on proper Ubuntu (same Sage version) or Cygwin on the same 
> machine (but stable 9.0):*
>
> sage: number_of_partitions(241, algorithm='bober')
> 114540884553038
> sage: number_of_partitions(241)
> 114540884553038
>
> I think, that is an issue which can damage trust even thought it probably 
> is not caused by Sage. Shouldn't we trace that back? To me it looks like a 
> rounding problem via MPFR.
>
>

-- 
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/6936f91b-03ec-4b4e-b023-91c1e32c1b9d%40googlegroups.com.

[sage-devel] Re: Segmentation fault factoring a multivariate polynomial over IntegerModRing

[Sebastian Oehms]

>
> It looks like this problem is going to be fixed by the upgrade to Singular 
> 4.1.3 (#25993).
>
Indeed! Thanks for pointing this out!
 

> There is another segmentation fault related to the non-commutative 
> subsystem Plural, though, causing a doctest failure on the upgrade branch. 
> See https://trac.sagemath.org/ticket/25993#comment:22 for details. Any 
> help with this is appreciated.
>
I fear I'm not familiar enought with that, but I will do an attempt. 

On Tuesday, April 14, 2020 at 7:54:03 PM UTC+2, Markus Wageringel wrote:
>
> It looks like this problem is going to be fixed by the upgrade to Singular 
> 4.1.3 (#25993).
>
> sage: R. = Integers(7)[]
> sage: p = x**2-1
> sage: p.factor()
> (x + 1) * (x + 6)
>
> There is another segmentation fault related to the non-commutative 
> subsystem Plural, though, causing a doctest failure on the upgrade branch. 
> See https://trac.sagemath.org/ticket/25993#comment:22 for details. Any 
> help with this is appreciated.
>
>

-- 
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/91e7fe98-33aa-498f-95c5-6fb3bcf33c05%40googlegroups.com.

[sage-devel] Segmentation fault factoring a multivariate polynomial over IntegerModRing

[Sebastian Oehms]

There have been several tickets on segmentation faults concerning the 
singular interface. Since they are all closed, I think this must be an 
unknown case:

sage: R. = Integers(7)[]
sage: p = x**2-1
sage: p.factor()


Trying the same with GF works fine:

sage: R. = GF(7)[]
sage: p = x**2-1
sage: p.factor()
(x - 1) * (x + 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/151bf5dd-151b-4fa3-93e8-5a8c92ad36c1%40googlegroups.com.

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Sebastian Oehms]

The history of discussions about this issue reaches back over many years, 
see #10708  and this sage-devel 
thread 

 
and it seems that they all broke down even though good suggestions where 
made. So let me do another attempt by gathering and rephrasing those 
suggestions, which I think should be realizable with a manageable effort. 
May we can do that in three steps:

1. Change the default implementation if the user chooses a *local term 
order*. The default implementation can't be longer *Singular* in this case, 
since *Singular *operates on a different mathematical object (which is not 
a polynomial ring), here. For example, this could be done in the following 
way (shown relative to 9.1.beta9):

diff --git a/src/sage/rings/polynomial/polynomial_ring_constructor.py b/src/
sage/rings/polynomial/polynomial_ring_constructor.py
index 98af2c4..afe6720 100644
--- a/src/sage/rings/polynomial/polynomial_ring_constructor.py
+++ b/src/sage/rings/polynomial/polynomial_ring_constructor.py
@@ -772,7 +772,7 @@ def _multi_variate(base_ring, names, sparse=None, order=
"degrevlex", implementat
 # yield the same implementation. We need this for caching.
 implementation_names = set([implementation])

-if implementation is None or implementation == "singular":
+if implementation is None and order.is_global() or implementation == 
"singular":
 from sage.rings.polynomial.multi_polynomial_libsingular import 
MPolynomialRing_libsingular
 try:
 R = MPolynomialRing_libsingular(base_ring, n, names, order)
diff --git a/src/sage/rings/polynomial/polynomial_singular_interface.py b/
src/sage/rings/polynomial/polynomial_singular_interface.py
index 74b8b82..8736c77 100644
--- a/src/sage/rings/polynomial/polynomial_singular_interface.py
+++ b/src/sage/rings/polynomial/polynomial_singular_interface.py
@@ -384,6 +384,10 @@ def can_convert_to_singular(R):
 if R.ngens() == 0:
 return False;

+if hasattr(R, 'term_order'):
+if R.term_order().is_local():
+return False;
+
 base_ring = R.base_ring()
 if (base_ring is ZZ
 or sage.rings.finite_rings.finite_field_constructor.is_FiniteField(
base_ring)

In the example of this thread, this would mean that an instance of 
MPolynomialRing_polydict_domain will be created:

sage: R. = PolynomialRing(QQ, order='negdeglex'); R
Multivariate Polynomial Ring in u, v over Rational Field
sage: type(R)

sage: f = 1 + x
sage: I = R.ideal(x^2)
sage: f.mod(I)
Traceback (most recent call last):
...
TypeError: Local/unknown orderings not supported by 'toy_buchberger' 
implementation.

If a user still likes to work over the localization of the polynomial ring 
via *Singular*, he has to give a corresponding *term order* and 
implementation='singular' explicitly (so that we can assume, that he knows 
what he is doing). In this case the representation string should make clear 
that this instance does not represent a polynomial ring:

sage: S. = PolynomialRing(QQ, order='neglex', implementation='singular'
); S
Multivariate Polynomial Ring in u, v over Rational Field localized at the 
maximal idead centered at the origin

sage: g = 1 + u
sage: J = S.ideal(u^2)
sage: g.mod(J)
1

2. Deprecate implementation='singular' for *local term orders* and replace 
it by a new construction function together with a new class inherited from 
MPolynomialRing_libsingular with an appropriate name (LocalPolynomialRing 
for instance).

3. Try to find a way, to use *Singular* again for applications according to 
1. I'm not sure if this will be possible, but maybe this can be done using 
a corresponding global order with *Singular* and perform transitions in 
_richcmp_, 
__reps__



On Monday, April 6, 2020 at 9:46:26 AM UTC+2, Yang Zhou wrote:
>
> Hi,
>
> I am trying to truncate a multi-variable polynomial by moding out higher 
> order term and found
> the following (simplified) example. I am wondering if it is a bug.
>
>
> *Reproducible Example: *
>
>> R. = PolynomialRing(QQ, order='negdeglex')
>>
> f = 1 + x
>> I = R.ideal(x^2)
>> f.mod(I)
>>
> *Expected output:*
>
>> 1 + x
>>
> *Actual output:*
>
>> 1
>>
>
>
> *Note: *
> The actual output will be 1+x when I omit the "order='negdeglex" parameter.
>
> *SageMath version:*
> SageMath version 9.0, Release Date: 2020-01-01
>
> *Operating system:*
> OS: Ubuntu 19.10 x86_64 
> Kernel: 5.3.0-45-generic 
>
> Best regards,
> Yang
>

-- 
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/a1c669d3-86da-4825-863a-4c1a9386c4a0%40googlegroups.com.

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Sebastian Oehms]

Enrique, you are right, that doesn't come from the interface, but directely 
from Singular. Above, I took the wrong ordering. Here the correction:

sage: R.=PolynomialRing(QQ,order='neglex')
sage: R._singular_init_()
polynomial ring, over a field, local ordering
// coefficients: QQ
// number of vars : 2
//block   1 : ordering ls
//  : namesx y
//block   2 : ordering C

 SINGULAR /  Development
 A Computer Algebra System for Polynomial Computations   /   version 4.1
.1
   0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \   Feb 2018
FB Mathematik der Universitaet, D-67653 Kaiserslautern\
> ring r = 0,(x, y),ls;
> poly f,g = 1+x, x^2;
> ideal I = (g);
> reduce(f,I);
1

BTW: The ticket you mentioned doesn't seem to adress that problem properly. 
The example which Simon inserted is now working. Therefore the ticket just 
consists of a doctest for that (I guess that has been made on the Sage Days 
in Zaragozza). The only reason that it isn't closed has been a merge 
confict, which has disappeared in the meantime.



On Thursday, April 9, 2020 at 9:28:07 AM UTC+2, Enrique Artal wrote:
>
> HI,
> I think it is related with ticket #17638 
> . There is a mathematical origin 
> in this situation. When considering a non local ordering, one is working in 
> a localized ideal, where any polynomial whose leading term is a non-zero 
> constant is invertible. Singular works silently in this new ring without 
> explicit declaration. I think that for Sage, a new structure should be 
> constructed, but I do not know how. Best, Enrique.
>
> El lunes, 6 de abril de 2020, 9:46:26 (UTC+2), Yang Zhou escribió:
>>
>> Hi,
>>
>> I am trying to truncate a multi-variable polynomial by moding out higher 
>> order term and found
>> the following (simplified) example. I am wondering if it is a bug.
>>
>>
>> *Reproducible Example: *
>>
>>> R. = PolynomialRing(QQ, order='negdeglex')
>>>
>> f = 1 + x
>>> I = R.ideal(x^2)
>>> f.mod(I)
>>>
>> *Expected output:*
>>
>>> 1 + x
>>>
>> *Actual output:*
>>
>>> 1
>>>
>>
>>
>> *Note: *
>> The actual output will be 1+x when I omit the "order='negdeglex" 
>> parameter.
>>
>> *SageMath version:*
>> SageMath version 9.0, Release Date: 2020-01-01
>>
>> *Operating system:*
>> OS: Ubuntu 19.10 x86_64 
>> Kernel: 5.3.0-45-generic 
>>
>> Best regards,
>> Yang
>>
>

-- 
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/2d4fa6e0-d819-4c9b-bd19-c73910096779%40googlegroups.com.

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Sebastian Oehms]

I consider this as a bug, too. My guess is, that it comes from the Singular 
interface:

sage: R. = PolynomialRing(QQ, order='negdeglex')
sage: f = 1 + x
sage: I = R.ideal(x^2)
sage: import sage.libs.singular.function_factory
sage: reduce = sage.libs.singular.function_factory.ff.reduce
sage: reduce(f, I)
1

but:

 SINGULAR /  Development
 A Computer Algebra System for Polynomial Computations   /   version 4.1
.1
   0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \   Feb 2018
FB Mathematik der Universitaet, D-67653 Kaiserslautern\
> ring r = 0,(x, y),lp;
> poly f,g = 1+x, x^2;
> ideal I = (g);
> reduce(f,I);
x+1

Note, that in Sage f.reduce(I) returns 1, as well, even though is not 
implemented as above, but using the Singular kernel function kNF. Anyway, 
this seems to be a task for Singular experts.


On Monday, April 6, 2020 at 9:46:26 AM UTC+2, Yang Zhou wrote:
>
> Hi,
>
> I am trying to truncate a multi-variable polynomial by moding out higher 
> order term and found
> the following (simplified) example. I am wondering if it is a bug.
>
>
> *Reproducible Example: *
>
>> R. = PolynomialRing(QQ, order='negdeglex')
>>
> f = 1 + x
>> I = R.ideal(x^2)
>> f.mod(I)
>>
> *Expected output:*
>
>> 1 + x
>>
> *Actual output:*
>
>> 1
>>
>
>
> *Note: *
> The actual output will be 1+x when I omit the "order='negdeglex" parameter.
>
> *SageMath version:*
> SageMath version 9.0, Release Date: 2020-01-01
>
> *Operating system:*
> OS: Ubuntu 19.10 x86_64 
> Kernel: 5.3.0-45-generic 
>
> Best regards,
> Yang
>

-- 
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/f1c2216c-23d9-438c-a587-7f4b92848974%40googlegroups.com.

[sage-devel] Re: Method is_unit of QuotientRingElement and PolynomialQuotientRingElement could return True in more cases

[Sebastian Oehms]

This is ticket #29469 <https://trac.sagemath.org/ticket/29469>, now!

On Monday, March 30, 2020 at 8:41:40 AM UTC+2, Sebastian Oehms wrote:
>
> in the former case it raises a NotImplementedError  even if inversion is 
> possible:
>
> sage: P. = QQ[]
> sage: Q = P.quo([1-x*y])
> sage: Q.inject_variables()
> Defining xbar, ybar
> sage: ybar.is_unit()
> Traceback (most recent call last):
> ...
> NotImplementedError:
>
> but:
>
> sage: ~ybar
> xbar
>
> This is marked as a TODO in the docstring:
>
>Return True if self is a unit in the quotient ring.
>
>TODO: This is not fully implemented, as illustrated in the example
>below.  So far, self is determined to be unit only if its
>representation in the cover ring R is also a unit.
>
> In the latter case the NotImplementedError is raised even if the preimage 
> in the cover is a unit. 
>
> sage: Z16x. = Integers(16)[]
> sage: S. =  Z16x.quotient(x^2 + x + 1)
> sage: S(3).is_unit()
> Traceback (most recent call last):
> ...
> NotImplementedError: The base ring (=Ring of integers modulo 16) is not a 
> field
>
>
> Here accordingly, inversion is not possible in such cases.
>
> If there is no special reason why this hasn't been done, I will open a 
> ticket to fill that in!
>
>

-- 
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/1b6e24ee-9679-409d-b523-3d6259279fd5%40googlegroups.com.

[sage-devel] Method is_unit of QuotientRingElement and PolynomialQuotientRingElement could return True in more cases

[Sebastian Oehms]

in the former case it raises a NotImplementedError  even if inversion is 
possible:

sage: P. = QQ[]
sage: Q = P.quo([1-x*y])
sage: Q.inject_variables()
Defining xbar, ybar
sage: ybar.is_unit()
Traceback (most recent call last):
...
NotImplementedError:

but:

sage: ~ybar
xbar

This is marked as a TODO in the docstring:

   Return True if self is a unit in the quotient ring.

   TODO: This is not fully implemented, as illustrated in the example
   below.  So far, self is determined to be unit only if its
   representation in the cover ring R is also a unit.

In the latter case the NotImplementedError is raised even if the preimage 
in the cover is a unit. 

sage: Z16x. = Integers(16)[]
sage: S. =  Z16x.quotient(x^2 + x + 1)
sage: S(3).is_unit()
Traceback (most recent call last):
...
NotImplementedError: The base ring (=Ring of integers modulo 16) is not a 
field


Here accordingly, inversion is not possible in such cases.

If there is no special reason why this hasn't been done, I will open a 
ticket to fill that in!

-- 
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/6cb24adb-9ea4-49d4-a7d2-cc866ca55216%40googlegroups.com.

[sage-devel] Re: Power series do not distinguish between different precisions!

[Sebastian Oehms]

On Wednesday, January 22, 2020 at 2:07:18 PM UTC+1, Marc Mezzarobba wrote:
>
> [re-posting a reply from a week ago that apparently did not go through 
> because gmane was moving] 
>
> Nils Bruin wrote: 
> > This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns 
> > true, as one would expect mathematically. 
>
> Do you mean it has the advantage that cos(sin(tan(t^2)) - 
> tan(sin(t^2))) == 1 returns True, as one would expect mathematically? 
> ;-) 
>

This is a good example, too. Here, even comparison using the predefined 
default precision wouldn't help. As I said before: It's impossible to avoid 
such wrong answers. The question is how we can make that transparent to the 
user and that question is independent on what realization of comparison has 
more advantages.

Let me say just this without thinking about the work and annoyance for 
users practice that would cause: The cleanest solution would be to print a 
warning the first time a user applies `==` or `!=` to elements of non-exact 
rings (once per session or once per instance of such a ring). In addition a 
second pair of comparison operators (using infix operator) should be 
supplied giving according results but without warning. These new operators 
should be used in the doctests.

But comparison is only one part of the irritations. The original issue 
(printing `O(u) + O(t)` as `O(u)`) has another reason, which can be 
explained by a look at the behavior in Nemo. Nemo does comparison in the 
same way as we do:

julia> R, t = PowerSeriesRing(ZZ, 100, "t")
(Univariate power series ring in t over Integer Ring, t+O(t^101))
julia> O(t) == 0
true


But there seems to be a principle difference: Sage allows the coexistence 
of exact (prec = infinity) and non-exact (prec = integer) elements, while 
Nemo seems to do not. Thus, in Nemo you have:

julia> R(0)
0+O(t^100)


while in Sage:

sage: R. = PowerSeriesRing(ZZ, default_prec=100)
sage: R.zero()
0
sage: R.zero().prec()
+Infinity



Accordingly:

julia> S, u = PowerSeriesRing(R, 20, "u")
(Univariate power series ring in u over Univariate power series ring in t 
over Integer Ring, u+O(u^21))

julia> O(u) + O(t)
0+O(t^100)+O(u^1)

but:

sage: S.  = PowerSeriesRing(R)
sage: O(u) + O(t)
O(u^1)


On the one hand, this coexistence is reasonable, since mathematically 
polynomials are special power series. But since there are principle 
differences between exact and non-exact rings in computer algebra, this is 
another source of irritations.
 

-- 
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/d9409ee4-af17-42f5-ad03-738ff0e59bc1%40googlegroups.com.

Re: [sage-devel] Power series do not distinguish between different precisions!

[Sebastian Oehms]

>
> ... This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns 
> true, as one would expect mathematically.  (insisting equality up to the 
> default precision would have to lead to false, because the arithmetic on 
> the LHS leads to precision loss)
>

Your example is convincing and I'm not going to mistrust the ball design. 
The truth is that we can't say whether O(t) is zero or not. But since the 
answer is a boolean we have to make a decision (giving an "exact" answer 
for an "inexact" question). Independend on how this decision is made cases 
of irritations will be left. For example, if a user defines 
R.=PowerSeriesRing(ZZ, 
default_prec=100) and types in p + O(21) with some polynomial p of degree 
20 than he would not expect `p + O(21) == p` to be True since that looks as 
if we have lost something (similar as in Bill Harts example).

Indeed, but I think the actual bug there is: Power series rings over 
> non-exact base rings don't work properly. This is a problem that you should 
> expect: algebra algorithms normally designed to work with exact base rings 
> will have problems with non-exact ones, and usually for the reason you see 
> here: to work properly with power series over exact rings, you eliminate 
> (exact) zeros, but the inexact zeros that you encounter in power series 
> rings should probably be kept for precision tracking reasons (also the ones 
> up to default precision!). But keeping them around indiscriminately would 
> lead to impractical results very quickly. Special care is needed. You might 
> try working with ZZ[['t','u']] instead.
>

So, what should we do than? Print a warning if somebody tries to define 
them (and suggest to use multivariate power series in cases that would lead 
to an alternative)?




On Thursday, January 16, 2020 at 12:09:13 AM UTC+1, Nils Bruin wrote:
>
>  
> On Wednesday, January 15, 2020 at 12:45:10 PM UTC-8, Sebastian Oehms wrote:
>>
>> My expectation is that two power series are considered to be equal if 
>> there polynomials agree, but also their individual precisions as long as 
>> one of them is below the default precision of the ring. Accordingly the 
>> `is_zero` method should not return True if the individual precision is 
>> below the default precision.
>>
>
> The default precision is just that: a default. It's used to get a finitely 
> presented result in cases where a computation could normally lead to a 
> non-finite one. The setting of the default doesn't affect the mathematical 
> properties of the elements. In particular, whether elements are equal or 
> not is determined by their direct properties, not by the default set in the 
> parent ring. Therefore, your expectation is not compatible with the design 
> (as you discovered). But perhaps by seeing how it was designed and why, 
> you'll warm to the design decisions made :-).
>
> The arithmetic model used is basically one of "interval" or "ball" 
> arithmetic: In terms of actual power series rings, an element like 
> 1+t+O(t^2) stands for the set of all power series with initial part 1+t. In 
> that model, "equality" gets translated to "have non-empty intersection".
>
> This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns true, as 
> one would expect mathematically.
>
> (insisting equality up to the default precision would have to lead to 
> false, because the arithmetic on the LHS leads to precision loss)
>  
>
>>
>> But this doesn't help for the following irritating answer (which was the 
>> original issue pointed out to me by Bill Hart):
>>
>> sage: R.=PowerSeriesRing(ZZ)
>> sage: S.=PowerSeriesRing(R)
>> sage: 0 + O(t) + O(u)
>> O(u^1)
>>
>>
>>
> Indeed, but I think the actual bug there is: Power series rings over 
> non-exact base rings don't work properly. This is a problem that you should 
> expect: algebra algorithms normally designed to work with exact base rings 
> will have problems with non-exact ones, and usually for the reason you see 
> here: to work properly with power series over exact rings, you eliminate 
> (exact) zeros, but the inexact zeros that you encounter in power series 
> rings should probably be kept for precision tracking reasons (also the ones 
> up to default precision!). But keeping them around indiscriminately would 
> lead to impractical results very quickly. Special care is needed. You might 
> try working with ZZ[['t','u']] instead.
>
> (and indeed, power series rings with p-adic coefficients need a whole set 
> of extra care too -- and usually convergence properties on the coefficients 
> anyway to make meaningful arithmetic possible)
>

-- 
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/bb9e4728-e20e-467f-bd21-28e69befef11%40googlegroups.com.

Re: [sage-devel] Power series do not distinguish between different precisions!

[Sebastian Oehms]

>
> For example, suppose you want to do some long computation and determine 
> whether you get 1 at the end.  At the end of your computation, you find the 
> answer 1 + O(t^33).  I think it's more useful to say that this is equal to 
> 1 than that it's not.
>

Sorry, that I was not clear enought about which precision I was referring 
to. I didn't mean the default precision of the ring, as you seem to do, but 
the individual precision of elements which can be set using the add_bigoh 
method (or global O function). In my examples the default precision has 
been:

sage: R
Power Series Ring in t over Integer Ring
sage: R.default_prec()
20


But the individual precisions of the elements where below that.

I'm not sure what kind of equality you would imagine, but if we defined 
> equality by something like "equal absolute precision and equal value modulo 
> that absolute precision" then you no longer have additive and 
> multiplicative inverses.  For example, if x = 1 + O(3^18) then there is no 
> value of y so that x+y == 0.  That's pretty devastating for thinking about 
> algebraic operations.
>

My expectation is that two power series are considered to be equal if there 
polynomials agree, but also their individual precisions as long as one of 
them is below the default precision of the ring. Accordingly the `is_zero` 
method should not return True if the individual precision is below the 
default precision.

If you want to be more careful with the precision of your equality testing 
> you can use the `is_equal_to` method.
>

But this doesn't help for the following irritating answer (which was the 
original issue pointed out to me by Bill Hart):

sage: R.=PowerSeriesRing(ZZ)
sage: S.=PowerSeriesRing(R)
sage: 0 + O(t) + O(u)
O(u^1)


BTW: There is an inconsistency in the representation string which doesn't 
look very nice:


sage: O(t)
O(t^1)
sage: 1+O(t)
1 + O(t)

Best,
Sebastian


On Wednesday, January 15, 2020 at 4:09:29 PM UTC+1, David Roe wrote:
>
> We only store power series and p-adics to finite precision, so it's 
> impossible to tell whether the mathematical objects underlying two elements 
> in Sage are actually equal.  In practice, the goal of a p-adic or power 
> series computation is to determine some result approximately, since that's 
> all that's possible.  In this context, the notion of equality implemented 
> in Sage is the right choice.  For example, suppose you want to do some long 
> computation and determine whether you get 1 at the end.  At the end of your 
> computation, you find the answer 1 + O(t^33).  I think it's more useful to 
> say that this is equal to 1 than that it's not.
>
> I'm not sure what kind of equality you would imagine, but if we defined 
> equality by something like "equal absolute precision and equal value modulo 
> that absolute precision" then you no longer have additive and 
> multiplicative inverses.  For example, if x = 1 + O(3^18) then there is no 
> value of y so that x+y == 0.  That's pretty devastating for thinking about 
> algebraic operations.
>
> If you want to be more careful with the precision of your equality testing 
> you can use the `is_equal_to` method.
>
> sage: x = 1 + O(3^14)
> sage: y = 1 + O(3^16)
> sage: x.is_equal_to(y, absprec=10)
> True
> sage: x.is_equal_to(y, absprec=15)
> PrecisionError (most recent call last):
> ...
> PrecisionError: Elements not known to enough precision
>
> Finally, I'll note that there a bunch of precision models in Sage for 
> p-adics (they all apply in a power series context as well but haven't been 
> implemented there because it's a lot of work).  The tutorial 
> <http://doc.sagemath.org/html/en/reference/padics/sage/rings/padics/tutorial.html>
>  
> is still missing some of the newer ones (floating point precision and the 
> two lattice precisions), but you can pick out the details from the reference 
> manual 
> <http://doc.sagemath.org/html/en/reference/padics/sage/rings/padics/factory.html>
>  
> if you're willing to wade through a bunch of text.
> David
>
> On Wed, Jan 15, 2020 at 3:07 AM Sebastian Oehms  > wrote:
>
>> Dear all,
>>
>>
>> obviously Sage does not distinguish between precisions of power series:
>>
>> sage: R. = PowerSeriesRing(ZZ)
>> sage: O(t).is_zero()
>> True
>> sage: O(t) == O(t**2)
>> True
>>
>> Similarly for p-adics:
>>
>> sage: O(3).is_zero()
>> True
>> sage: O(3) == O(3^2)
>> True
>> sage:
>>
>> This seems to be explicitly intended:
>>
>>
>>def __nonzero__(self):
>> """
>> Return True if this power series is not equal to 0.
>>
>> EXAMPLES::
>>
>>  

[sage-devel] Power series do not distinguish between different precisions!

[Sebastian Oehms]

Dear all,


obviously Sage does not distinguish between precisions of power series:

sage: R. = PowerSeriesRing(ZZ)
sage: O(t).is_zero()
True
sage: O(t) == O(t**2)
True

Similarly for p-adics:

sage: O(3).is_zero()
True
sage: O(3) == O(3^2)
True
sage:

This seems to be explicitly intended:


   def __nonzero__(self):
"""
Return True if this power series is not equal to 0.

EXAMPLES::

sage: R. = ZZ[[ ]]; R
Power Series Ring in q over Integer Ring
sage: f = 1 + 3*q + O(q^10)
sage: f.is_zero()
False
sage: (0 + O(q^2)).is_zero()
True
sage: R(0).is_zero()
True
sage: (0 + O(q^1000)).is_zero()
True
"""
return not not self.polynomial()

Why?

-- 
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/10981ee0-efea-4885-850c-7e4dcd0e4d32%40googlegroups.com.

[sage-devel] Localization of integral domains

[Sebastian Oehms]

Since there isn't any Sage-class for localization of integral domains at a 
set of its elements so far, I've opened ticket #28862 
 for its realization. Furthermore, 
I made an initial attempt based on the following example given in the 
reference pages on coercion: coercion example 


Suggestions, criticism and corrections are welcome!

-- 
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/a7c0e5b7-9af5-4541-a991-6abf2a8e414e%40googlegroups.com.

[sage-devel] Coxeter matrix of certain real reflection groups broken!

[Sebastian Oehms]

Hi,

is the following a known bug?


sage: RH3 = ReflectionGroup(['H', 3])
sage: RH3.coxeter_matrix()
Traceback (most recent call last):
...
TypeError: 'NotImplementedType' object is not callable


This already occurs on stable 8.5 but still was working on 8.1:

sage: RH3.coxeter_matrix()
[1 3 2]
[3 1 5]
[2 5 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 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 much do we support the casual user

[Sebastian Oehms]

Hello,

This topic is a good example, that wrong names can be worse than wrong code.

Only the user knows what he has in mind using the adjective "prime":

1) prime in a "narrower sense": being a prime number
2) prime in a "broader sense":  being a prime element of a unital 
commutative ring 

Therefore, the user must have the possibility to solve this ambiguity.

If we will do that by an optional argument (as suggested by Erik Bray), 
then we have to fix a default! Taking the default to be 1) would prefer the 
casual user and keep track with popular CAS. 

WolframAlpha answers the question "is 3/1 prime?" in the sense of 1) with 
"true". If you have 2) in mind this seems to be a bug. But to be fair: The 
result "true" matches the explanation WolframAlpha gives for the adjective 
"prime" (namely according to 1)). If you ask "is 3/1 a prime element?" then 
it shows you the definition of "prime element" but does not calculate any 
thing.

Now, Sage can calculate this, and accordingly gives the answer in the sense 
of 2) like mathematicians would expect. Does it so, always?

sage: is_prime(I)
---
TypeError Traceback (most recent call last)

TypeError: Unable to coerce I to an integer


This looks as if even Sage is trying to give the answer according to 1), as 
well!

Nevertheless, taking 2) as default would raise less compatibility problems 
(and seems to be the favorite in most of the contributions of this thread).

But anyway, IMHO the best thing would be to follow the suggestion of Eric 
Gourgoulhon, solving the ambiguity by separated function names. But if the 
name "is_prime" should survive, you will have to make a "default"-decision, 
as well.


As a newcomer to sage-devel I cannot really say, how painful the most 
transparent solution would be, but I think it should be taken into account, 
too:

Deprecation of "is_prime" as function (not as method!!! since there is no 
ambiguity here) and replace it by two new functions "is_prime_number" and 
"is_prime_element" (according to the corresponding Wikipedia articles). The 
first function should try to coerce the input into ZZ and raise an error if 
this it not possible or not positive. The second one should raise an error 
if the input is not an element of a unital commutative ring and a warning 
in the case the ring is a field (according to 
https://trac.sagemath.org/ticket/25046). In cases as for the SymbolicRing 
above a NotImplementedError should be raised.

If you think deprecation of "is_prime()" would be to painful, then which of 
both ("is_prime_number" or "is_prime_element") should keep the name 
"is_prime"? I found contributions for both possibilities!

Best,
Sebastian

-- 
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: BUGS in tensor products of algebras

[Sebastian Oehms]

Hi Travis,

please don't take my poste as a suggestion. I'm not close enough to the
subject that I really could do that. I just wanted to point out where the
confusion comes from (hoping you have I good Idea what we can do against
it).

Best,
Sebastian


2018-02-26 12:04 GMT+01:00 Travis Scrimshaw :

>
>
>> I had that confusion about the pbw_basis method, as well. From my (non
>> expert) point of view I would have expected the following:
>>
>> What is now your L.pbw_basis() I expected to be
>> L.universal_enveloping_algebra(). This would match what the
>> representation string is telling you:
>>
>> sage: L.pbw_basis()
>> Universal enveloping algebra of Lie algebra of ['A', 2] in the Chevalley
>> basis in the Poincare-Birkhoff-Witt basis
>>
>>
>>
>> What is now your L.universal_enveloping_algebra() is just another
>> (isomorphic) realization. Therefore it could be accessed in this way:
>>
>> L.universal_enveloping_algebra().as_nc_polynomial_ring()
>>
>> matching what the representation string is telling you:
>>
>> sage: L.universal_enveloping_algebra()
>> Noncommutative
>>  Multivariate Polynomial Ring in b0, b1, b2, b3, b4, b5, b6, b7 over
>> Rational Field, nc-relations: {b5*b0: b0*b5 - b4, b6*b3: b3*b6 + 2*b6,
>> .
>>
>> Furthermore, conversion maps between these two realization (in both
>> directions) are desirable. The access to the PBW-basis would be
>>
>> L.universal_enveloping_algebra().basis()
>>
>> for which a shorthand L.pbw_basis() maybe be implemented (or not).
>>
>> That is both horrible to work with and practically impossible to do. You
> require *every* implementation returned of UEA to know how to go to a PBW
> basis (and in principle, from). There is no reasonable way to expect the
> Lie algebra to know how to do this, and you would have to (IMO needlessly)
> subclass, e.g., NC poly ring, which is generally not a UEA. Also, while NC
> poly ring is generic, it would only work for finite-dimensional Lie
> algebras. We could do this with a category for UEAs, but I do not see any
> benefit to having this overhead and complications. Also, what about the
> cases where the only reasonable implementation of the UEA is the PBW basis?
> What about when there are multiple realizations*? Why should the UEA
> require anything special about the implementation? For the places where I
> do need the specialized things, that is why there is the separate
> pbw_basis().
>
> Also, by being in the category of ModulesWithBasis(), the .basis() must
> return the distinguished basis object, not an isomorphic algebra (since we
> consider categories to be like abstract classes and defining the API).
>
> Also, think about it this way, say we have a global function PBWBasis. It
> would naturally take in a Lie algebra (and optional ordering of the basis)
> as input. Now in many ways L.pbw_basis() is equivalent to pbw_basis(L) and
> the PBW basis is strongly correlated to the Lie algebra. So it is natural
> IMO to have such a method and as a primary entry point.
>
> Best,
> Travis
>
> * - Although to be fair, this is currently something that will need to be
> addressed with the current framework. However, there is a possible
> approaches by returning an algebra that has multiple realizations.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/sage-devel/XK-RxN3_qvY/unsubscribe.
> To unsubscribe from this group and all its topics, 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: BUGS in tensor products of algebras

[Sebastian Oehms]

Hi Travis,

I had that confusion about the pbw_basis method, as well. From my (non 
expert) point of view I would have expected the following:

What is now your L.pbw_basis() I expected to be 
L.universal_enveloping_algebra(). This would match what the representation 
string is telling you:

sage: L.pbw_basis()
Universal enveloping algebra of Lie algebra of ['A', 2] in the Chevalley 
basis in the Poincare-Birkhoff-Witt basis



What is now your L.universal_enveloping_algebra() is just another 
(isomorphic) realization. Therefore it could be accessed in this way:

L.universal_enveloping_algebra().as_nc_polynomial_ring()

matching what the representation string is telling you:

sage: L.universal_enveloping_algebra()
Noncommutative
 Multivariate Polynomial Ring in b0, b1, b2, b3, b4, b5, b6, b7 over 
Rational Field, nc-relations: {b5*b0: b0*b5 - b4, b6*b3: b3*b6 + 2*b6, 
.

Furthermore, conversion maps between these two realization (in both 
directions) are desirable. The access to the PBW-basis would be

L.universal_enveloping_algebra().basis()

for which a shorthand L.pbw_basis() maybe be implemented (or not).

Best,
Sebastian


Am Freitag, 23. Februar 2018 23:28:21 UTC+1 schrieb Travis Scrimshaw:
>
>
> No, it is not. The keys for the basis of the PBW are different than those 
>>> for the algebra generators. See the output:
>>>
>>> sage: PBW.basis()
>>> Lazy family (Term map from Free abelian monoid indexed by {alpha[1], 
>>> alphacheck[1], -alpha[1]} to Universal enveloping algebra of Lie 
>>> algebra of ['A', 1] in the Chevalley basis in the Poincare-Birkhoff-Witt 
>>> basis(i))_{i in Free abelian monoid indexed by {alpha[1], alphacheck[1], 
>>> -alpha[1]}}
>>> sage: PBW.algebra_generators()
>>> Finite family {-alpha[1]: PBW[-alpha[1]], alpha[1]: PBW[alpha[1]], 
>>> alphacheck[1]: PBW[alphacheck[1]]}
>>>
>>> It clearly indicates that the basis keys should be an element of a free 
>>> abelian monoid. LBYL. Now in this case, if we did try to convert the input 
>>> into the keys, it should work. See 
>>> https://trac.sagemath.org/ticket/18750. Actually, it is not as bad as I 
>>> remembered in terms of outright timings, but there are some other technical 
>>> issues.
>>>
>>>
>> Oh. Sorry. I admit that I have trouble parsing the Lazy family 
>> description.
>>
>
> Yea, I agree it is a bit heavy. There are some ways it could be simplified 
> by saying the function is something like "the monomial map".
>  
>
>> Free abelian monoid... Hmmm... What free abelian monoid?
>>
>> sage: PBW.basis().keys().an_element()
>>
>> PBW[alpha[1]]^2*PBW[alphacheck[1]]^2*PBW[-alpha[1]]^3
>>
>>
>> So PBW.basis() is _indexed_ by elements of the basis of PBW? I am sorry 
>> for all these stupid questions but (as you can clearly see) I am confused 
>> as hell.
>>
>
> No, they are just have the same names. A good parallel would be the 
> polynomial ring R = ZZ[x,y] in the natural basis. Here, R is the ZZ-algebra 
> of the abelian monoid A = , and subsequently, the basis elements are 
> indexed by elements in A. We can call the elements in the monoid , but 
> that induces undue overhead on the programmer. For the PBW case, granted it 
> is not a monoid algebra, so we cannot simply *coerce* in things from the 
> indexing monoid (but of course, conversion is allowed), but the design is 
> there. I would just be taking products of the algebra generators anyways 
> and not worrying about constructing elements via the basis.
>  
>
>> I looked at the ticket and I have no idea what it is about. 
>>
>
> Right now, if we are trying to construct a monomial, we do not convert it 
> into the indexing set of the basis and instead trust the user to do it. The 
> ticket #18750 is about changing that. 
>
>>  
>>
>  
>>
>>>
  

> sage: C.basis()
> Lazy family (Term map from Subsets of {0, 1} to The Clifford algebra 
> of the Quadratic form in 2 variables over Rational Field with 
> coefficients: 
> [ 1 0 ]
> [ * 1 ](i))_{i in Subsets of {0, 1}}
>
> So it is expecting subsets and that the user will not input bad data. 
> There is no reason for it to simplify and not a bug. Granted, we could 
> put 
> a check on the user input here, but there is a speed penalty as this can 
> be 
> a well-used code path internally. Moreover, ducktyping can also be 
> useful. 
> So we are fairly permissive here, but not without due cause IMO.
>
>
 Pardon my ignorance, but If there is no simplification then what is all 
 this good for? It does simplify for universal enveloping algebra and so it 
 should do it for Clifford algebras as well. Also I have a big issue with 
 naming convention here. The method basis() does not produce a basis!

>>>
>>> it is *bad input*. It does produce a basis, one indexed by *subsets*, 
>>> not words/multisets. In math terms, if you have a sequence (x_i)_{i \in I}, 
>>> then want x_j, where j \notin I, then you have an 

Re: [sage-devel] 8.2.beta5: compile error in gfortran-7.2.0 on LinuxMint 17.3 / 18

[Sebastian Oehms]

Hi Francois,

thanks for the immediate reply! Checking out the ticket solved the problem 
(at least on my ThinkPad, the others I will try later on)!


Am Sonntag, 11. Februar 2018 21:19:21 UTC+1 schrieb François Bissey:
>
> Hi, 
>
> I am responsible for this bug, it happens when you do an incremental build 
> of sage (i.e. you are upgrading a prior version of sage rather than 
> building 
> from scratch). It doesn’t happen on build from scratch or when you are 
> using 
> compilers from the system. 
> A fix is being reviewed at https://trac.sagemath.org/ticket/24694 
> Note that if you want to try it you’ll need autotools and related packages 
> to 
> be installed. 
>
> François 
>
> > On 12/02/2018, at 07:28, Sebastian Oehms <seb@gmail.com 
> > wrote: 
> > 
> > Hello, 
> > 
> > since I am new in this fore, let me introduce myself: 
> > 
> > My name is Sebastian Oehms and I worked as a mathematician in the 90th. 
> I finished my mathematical career already in 1997 (after PhD), but in my 
> leisure time, I still like to think about mathematics. My favorites belong 
> to algebra and topology, especially algebras and groups being connected to 
> the Artin braid groups and questions about polynomial link invariants. 
> > 
> > The principal opportunity to do this, is on my daily rides on the subway 
> where I used to carry a (almost seven years old but mint colored) Acer 
> ASpire AO-Happy net-book. In 2016 I installed LinuxMint 17.3 on it in order 
> to work more with sage. Comfortably I can work on it with version 6.9 but 
> 8.2 is still usable. 
> > 
> > Since that time I learned much about sage and surely I need to learn 
> much more in order to help to improve it. But I think it's time to start 
> with this attempt, right now. 
> > 
> > Currently, I have problems to build version 8.2.beta5 on three systems 
> on which I am using sage: On each I got the following error: 
> > 
> > [gfortran-7.2.0] Host system: 
> > [gfortran-7.2.0] Linux SebaThinkPad 4.4.0-103-generic #126-Ubuntu SMP 
> Mon Dec 4 16:23:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 
> > [gfortran-7.2.0]  
> > [gfortran-7.2.0] Error: gcc is already installed 
> > 
> > [gfortran-7.2.0] Host system: 
> > [gfortran-7.2.0] Linux SonyVAIO 3.19.0-32-generic #37~14.04.1-Ubuntu SMP 
> Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 
> > [gfortran-7.2.0]  
> > [gfortran-7.2.0] Error: gcc is already installed 
> > 
> > 
> > [gfortran-7.2.0] Host system: 
> > [gfortran-7.2.0] Linux tchiboix 3.19.0-32-generic #37~14.04.1-Ubuntu SMP 
> Thu Oct 22 09:37:25 UTC 2015 i686 i686 i686 GNU/Linux 
> > [gfortran-7.2.0]  
> > [gfortran-7.2.0] Error: gcc is already installed 
> > 
> > 
> > On the first host (ThinkPad on LinuxMint 18 Mate) the previous 
> successful build was 8.2.beta4. But already for this I needed 2 attempts 
> since I had the problem with giac-1.4.9.45 described before by David 
> Coudert: 
> > 
> > https://groups.google.com/forum/#!topic/sage-devel/CHAgwg0spMg 
> > 
> > and which I could solve by the hint given by Francois Bissey (running 
> "sage -f gcc" before running make again). 
> > 
> > On the second host (LinixMint 17.3 Cinnamon) the previous successful 
> build was 8.2.beta2. Here I didn't do any attempts in the meantime. 
> > 
> > The third host is the Acer AO Happy (LinuxMint 17.3 Mate). The previous 
> successful build here was 8.2.beta3. When I tried to build beta4 on this 
> machine, I had the same problem as on the 
> > ThinkPad. The hint of Francois did not work here. 
> > 
> > The attached log-file belongs to the attempts on the ThinkPad! 
> > 
> > 
> > What can I do to run make successfully? 
> > 
> > 
> > 
> > -- 
> > 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.

[sage-devel] 8.2.beta5: compile error in gfortran-7.2.0 on LinuxMint 17.3 / 18

[Sebastian Oehms]

Hello,

since I am new in this fore, let me introduce myself:

My name is Sebastian Oehms and I worked as a mathematician in the 90th. I 
finished my mathematical career already in 1997 (after PhD), but in my 
leisure time, I still like to think about mathematics. My favorites belong 
to algebra and topology, especially algebras and groups being connected to 
the Artin braid groups and questions about polynomial link invariants.

The principal opportunity to do this, is on my daily rides on the subway 
where I used to carry a (almost seven years old but mint colored) Acer 
ASpire AO-Happy net-book. In 2016 I installed LinuxMint 17.3 on it in order 
to work more with sage. Comfortably I can work on it with version 6.9 but 
8.2 is still usable.

Since that time I learned much about sage and surely I need to learn much 
more in order to help to improve it. But I think it's time to start with 
this attempt, right now.

Currently, I have problems to build version 8.2.beta5 on three systems on 
which I am using sage: On each I got the following error:

[gfortran-7.2.0] Host system:
[gfortran-7.2.0] Linux SebaThinkPad 4.4.0-103-generic #126-Ubuntu SMP Mon 
Dec 4 16:23:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[gfortran-7.2.0] 
[gfortran-7.2.0] Error: gcc is already installed

[gfortran-7.2.0] Host system:
[gfortran-7.2.0] Linux SonyVAIO 3.19.0-32-generic #37~14.04.1-Ubuntu SMP 
Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[gfortran-7.2.0] 
[gfortran-7.2.0] Error: gcc is already installed


[gfortran-7.2.0] Host system:
[gfortran-7.2.0] Linux tchiboix 3.19.0-32-generic #37~14.04.1-Ubuntu SMP 
Thu Oct 22 09:37:25 UTC 2015 i686 i686 i686 GNU/Linux
[gfortran-7.2.0] 
[gfortran-7.2.0] Error: gcc is already installed


On the first host (ThinkPad on LinuxMint 18 Mate) the previous successful 
build was 8.2.beta4. But already for this I needed 2 attempts since I had 
the problem with giac-1.4.9.45 described before by David Coudert:

https://groups.google.com/forum/#!topic/sage-devel/CHAgwg0spMg

and which I could solve by the hint given by Francois Bissey (running "sage 
-f gcc" before running make again).

On the second host (LinixMint 17.3 Cinnamon) the previous successful build 
was 8.2.beta2. Here I didn't do any attempts in the meantime.

The third host is the Acer AO Happy (LinuxMint 17.3 Mate). The previous 
successful build here was 8.2.beta3. When I tried to build beta4 on this 
machine, I had the same problem as on the
ThinkPad. The hint of Francois did not work here.

The attached log-file belongs to the attempts on the ThinkPad!


What can I do to run make successfully?


-- 
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.
Found local metadata for gfortran-7.2.0
Using cached file /home/sebastian/develop/sage/upstream/gcc-7.2.0.tar.xz
gfortran-7.2.0

Setting up build directory for gfortran-7.2.0
Finished extraction
No patch files found in ../patches

Host system:
Linux SebaThinkPad 4.4.0-103-generic #126-Ubuntu SMP Mon Dec 4 16:23:28 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=/home/sebastian/develop/sage/local/bin/gcc
COLLECT_LTO_WRAPPER=/home/sebastian/develop/sage/local/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --prefix=/home/sebastian/develop/sage/local 
--with-local-prefix=/home/sebastian/develop/sage/local 
--with-gmp=/home/sebastian/develop/sage/local 
--with-mpfr=/home/sebastian/develop/sage/local 
--with-mpc=/home/sebastian/develop/sage/local --with-system-zlib 
--disable-multilib --disable-nls --enable-languages=c,c++,fortran 
--disable-libitm  
Thread model: posix
gcc version 7.2.0 (GCC) 

Error: gcc is already installed

real0m0.005s
user0m0.000s
sys 0m0.000s

Error installing package gfortran-7.2.0

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the log file
  /home/sebastian/develop/sage/logs/pkgs/gfortran-7.2.0.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yo