Re: [sage-devel] Re: documentation of external packages, versionned online Sage doc

[TB]

On 17/02/2021 23:22, Matthias Koeppe wrote:
On Wednesday, February 17, 2021 at 12:58:40 PM UTC-8 Thierry 
(sage-googlesucks@xxx) wrote:


Regarding Sage's own documentation, a useful feature, while not related
to the release process, would be to keep online documentation of each
release, that is having:

https://doc.sagemath.org/VERSION/ for each release, and having
https://doc.sagemath.org/current/ pointing to the doc of the last
release.


+1


The Python docs at https://docs.python.org and Read the Docs, e.g. 
https://ipywidgets.readthedocs.io, have a version menu. How did they 
configured their Sphinx build or theme layout for that?


--
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/03231354-9f31-3453-fa42-322c0aa84155%40gmail.com.

Re: [sage-devel] Re: documentation of external packages, versionned online Sage doc

[Matthias Koeppe]

On Wednesday, February 17, 2021 at 12:58:40 PM UTC-8 Thierry 
(sage-googlesucks@xxx) wrote:

> Regarding Sage's own documentation, a useful feature, while not related 
> to the release process, would be to keep online documentation of each 
> release, that is having: 
>
> https://doc.sagemath.org/VERSION/ for each release, and having 
> https://doc.sagemath.org/current/ pointing to the doc of the last 
> release. 
>

+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/8d8775d4-c2a1-47cc-ada1-8002d55b55d0n%40googlegroups.com.

Re: [sage-devel] Re: documentation of external packages, versionned online Sage doc

[Thierry]

Hi,

On Tue, Feb 16, 2021 at 04:30:34PM -0800, Matthias Koeppe wrote:
[...]
> For a proposal for packaging of the documentation of Sage itself - please
> see https://trac.sagemath.org/ticket/29868 (pip-installable packages
> sagemath-doc-src, sagemath-doc-inventory, sagemath-doc-html,
> sagemath-doc-pdf) - comments and help with the implementation are welcome
> here too.

Regarding Sage's own documentation, a useful feature, while not related
to the release process, would be to keep online documentation of each
release, that is having:

https://doc.sagemath.org/VERSION/ for each release, and having
https://doc.sagemath.org/current/ pointing to the doc of the last
release.

Currently some links on the web (e.g. on ask.sagemath.org) are outdated
as the discussion does not correspond to the current state of the doc.

Ciao,
Thierry

> Matthias
>
>
> --
> 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/dc6ab03f-2ef2-4ba1-9929-a8061e30dcf6n%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/20210217205835.vdw7tpwfsu5vhwpf%40metelu.net.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Matthias Koeppe]

On Wednesday, February 17, 2021 at 3:01:28 AM UTC-8 Dima Pasechnik wrote:

> No current sage dev knows pynac code, and it is a can of worms. [...]
>

At some point pynac and ginac diverged, and while ginac continues to 
> be maintained and developed, 
> we cannot draw on the expertise there. 
>

https://trac.sagemath.org/ticket/31092 proposes to investigate the 
feasibility of merging pynac and ginac.



>

-- 
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/c3e3384c-0af3-4adc-a00b-aeece1c5804fn%40googlegroups.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Dima Pasechnik]

On Wed, Feb 17, 2021 at 11:52 AM Dima Pasechnik  wrote:
>
> On Wed, Feb 17, 2021 at 11:14 AM Emmanuel Charpentier
>  wrote:
> >
> > BTW : I checked that both Maxima and Sympy are exempt of the problem I 
> > reported...
> >
> > Did someone bisect https://trac.sagemath.org/ticket/30688, 
> > https://trac.sagemath.org/ticket/31411 and/or 
> > https://trac.sagemath.org/ticket/31337 to point to the possible origin ? I 
> > don't know (yet) how to do this...
>
> one needs to bisect pynac code. E.g. by grabbing older release and
> rebuilding Sage with it.
>
> But I am not too hopeful here, as we cannot just go back to previous
> releases, which fixed equally ugly bugs,
> and it's not obvious that the change that broke this was not fixing
> some other ugly bug.

in fact, with 3 years old Pynac 0.7.19 (the oldest release on
https://github.com/pynac/pynac),
the bug is still/already there.

>
>
>
> >
> > Le mercredi 17 février 2021 à 12:09:39 UTC+1, Emmanuel Charpentier a écrit :
> >>
> >> Any obvious ways to entice former pynac developers out of retirement ?
> >>
> >> Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :
> >>>
> >>> No current sage dev knows pynac code, and it is a can of worms.
> >>> All of the following are worrysome tickets:
> >>>
> >>> https://trac.sagemath.org/ticket/30688
> >>> https://trac.sagemath.org/ticket/31411
> >>> https://trac.sagemath.org/ticket/31337
> >>>
> >>> At some point pynac and ginac diverged, and while ginac continues to
> >>> be maintained and developed,
> >>> we cannot draw on the expertise there.
> >>>
> >>> Any obvious ways to replace pynac with something that works and does
> >>> not contain crazy C++ undocumented stuff?
> >>>
> >>> On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier
> >>>  wrote:
> >>> >
> >>> > I forgot the link to the ticket...
> >>> >
> >>> > Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a 
> >>> > écrit :
> >>> >>
> >>> >> A question on ask.sagemath.org showed a bug leading to situations 
> >>> >> where foo.expand() is mathematically different of foo, which seems 
> >>> >> both sufficiently frequent and sufficiently nasty to warrant calling 
> >>> >> your attention to it.
> >>> >>
> >>> >> This may be in pynac territory, where I am unable to help you...
> >>> >
> >>> > --
> >>> > 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 view this discussion on the web visit 
> >>> > https://groups.google.com/d/msgid/sage-devel/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/5e6c91ad-2e48-4f2d-a22d-662e14fb07f0n%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/CAAWYfq2VyUKx9tndBqLPcgNSJA9zcev%2BCBoLDcyMioo1vnjUQQ%40mail.gmail.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

This is also discussed in this thread 
 (which seems to have 
somewhat derived...)

Le mercredi 17 février 2021 à 13:17:52 UTC+1, Emmanuel Charpentier a écrit :

> Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :
>
>> No current sage dev knows pynac code, and it is a can of worms. 
>> All of the following are worrysome tickets: 
>>
>> https://trac.sagemath.org/ticket/30688 
>> https://trac.sagemath.org/ticket/31411 
>> https://trac.sagemath.org/ticket/31337 
>>
>> At some point pynac and ginac diverged, and while ginac continues to 
>> be maintained and developed, 
>> we cannot draw on the expertise there. 
>>
>> Any obvious ways to replace pynac with something that works and does 
>> not contain crazy C++ undocumented stuff? 
>>
>
> Well... I stumbled on symengine , 
> but I'm not able to emit a sound advice on it... 
>  
> HTH,
>
>

-- 
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/aa7bcae1-9933-4ca5-8854-9787a7032706n%40googlegroups.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :

> No current sage dev knows pynac code, and it is a can of worms. 
> All of the following are worrysome tickets: 
>
> https://trac.sagemath.org/ticket/30688 
> https://trac.sagemath.org/ticket/31411 
> https://trac.sagemath.org/ticket/31337 
>
> At some point pynac and ginac diverged, and while ginac continues to 
> be maintained and developed, 
> we cannot draw on the expertise there. 
>
> Any obvious ways to replace pynac with something that works and does 
> not contain crazy C++ undocumented stuff? 
>

Well... I stumbled on symengine , 
but I'm not able to emit a sound advice on it... 
 
HTH,

-- 
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/4821cba4-1f41-4850-b41b-16d25c4e33d9n%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

[Dima Pasechnik]

On Sunday, January 24, 2021 at 9:17:14 PM UTC rjf wrote:

> Just a note to point out that infix  like a+b*c  in a conventional 
> programming language
> is not helpful if a,b,c  are symbolic expressions..  Writing it as  add(a, 
> mul(b,c)) is not
> a big deal,  nor is writing it in lisp  (add a (mul b c)).  Of course you 
> need to write programs
> add and mul,  but you have to do that regardless.  Languages that are 
> primarily oriented
> to provide arithmetic on fixed-length integers or double-float numbers, 
> mostly have to be
> covered over by macros etc to do computer algebra.  Languages like 
> FORTRAN, Algol, C.
>
> You could look at RLISP used for Reduce, if you want to see a version of 
> lisp with "syntactic sugar"
> to look "infix" ish. And that is used for a computer algebra system, 
> Reduce.
>
>  There is something of a tradition, to hand to someone, perhaps someone
> who prefers infix, a project to "Write a scanner/parser/code generator  
> for an infix language
> of your design [ or pick one, say Pascal]" in Lisp.
>  I've done this with programming language/compiler
> undergraduate classes at Berkeley for decades, with probably thousands of 
> students.
> It takes 10 weeks, assuming you know no lisp, nothing about lexical 
> analysis,
> nothing about parsing, nothing about intermediate code generation. and 
> maybe
> nothing about Pascal.
>
> At the completion of the project, most students prefer Lisp's 
> parenthesized prefix.
> They also understand Pascal better, having written an interpreter and 
> compiler for it.
>

Mind you, the initial versions of an alive and kicking computational group 
theory system GAP was mostly written by maths
students in RWTH Aachen 25-30 years ago. 

One could ask why human-years of relatively good quality LISP coders coding 
time were wasted doing the same
lab projects, and not something more creative, like impoving Maxima code. :P

LISP enthousiasts, including many US academics, have mostly themselves to 
blame for  the present sorry state of 
computer algebra in LISP...
 

>
> Often they choose to use Lisp for other projects, given a choice.
>
> Most criticisms of Lisp come from people who have never used it, and it 
> shows.
> Complaints about too many parentheses. No, there are just exactly enough, 
> and
> your editor helps.  Or indentation (hi Pythonistas). Editors indent for 
> you, exactly right.
> Not webby enough (see cl-http or other packages).
> Too slow (uh, faster than Python, some excellent optimizing compilers for 
> Lisp).
> Too hard to learn.   Think about how much time you spent in learning your 
> current
> favorite language on the precedence of operators. Or what the operators 
> meant.
> Or what happens when integers "overflow".
>
> Consider learning Lisp.
>
>
>
> Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp 
> (circa 1959).
> James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a 
> substantial section explaining Lisp,
> which was quite new at the time .
>
>
> On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote:
>
>> I (almost) do not code C++ myself, probably 99% of my code is C-style, 
>> but I'm using a C++ compiler, that way I can link to the C++ standard 
>> template library and benefit of features like operator overload. Doing so, 
>> I do not have screens of error messages.
>>
>> Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :
>>
>>> On Thu, Jan 21, 2021 at 8:04 PM parisse  
>>> wrote: 
>>> > 
>>> > Well, searching for "lisp infix notation" is not very convincing 
>>> (unless I missed something?), compared to built-in infix support. You might 
>>> prefer Lisp to C/C++, it's your choice, but I don't see any objective 
>>> reason that one should stay away from C/C++. And Giac is a proof that one 
>>> can actually write a CAS in C/C++, that compares very well with the 
>>> Lisp-based CAS Maxima. 
>>>
>>> Maxima is ~40 years old with a bit of work done since then, but the 
>>> core is that old, as far as I know: 
>>> https://en.wikipedia.org/wiki/Macsyma 
>>>
>>> As for staying away from C++, most people who might be trying to do 
>>> something with supposedly state of the art library like boost, 
>>> would run away screaming, closely followed by 100 screens of error 
>>> messages :-) 
>>> Or, now mostly gone (?), iterator_traits (my closest encounter with 
>>> C++, contributing to CGAL, 20 years ago, where these had to be 
>>> generated by a script for some classes, otherwise compilers kept 
>>> crashing...) 
>>>
>>>
>>>
>>>
>>>
>>> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit : 
>>> >> 
>>> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
>>> wrote: 
>>> >> > 
>>> >> > As the author of a CAS, I can state that you need much more than 2 
>>> weeks to learn a programming language to make a CAS, and much much more if 
>>> you want to be fast. Life is short, therefore choose your programming 
>>> language carefully! I don't regret m

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Dima Pasechnik]

On Wed, Feb 17, 2021 at 11:14 AM Emmanuel Charpentier
 wrote:
>
> BTW : I checked that both Maxima and Sympy are exempt of the problem I 
> reported...
>
> Did someone bisect https://trac.sagemath.org/ticket/30688, 
> https://trac.sagemath.org/ticket/31411 and/or 
> https://trac.sagemath.org/ticket/31337 to point to the possible origin ? I 
> don't know (yet) how to do this...

one needs to bisect pynac code. E.g. by grabbing older release and
rebuilding Sage with it.

But I am not too hopeful here, as we cannot just go back to previous
releases, which fixed equally ugly bugs,
and it's not obvious that the change that broke this was not fixing
some other ugly bug.



>
> Le mercredi 17 février 2021 à 12:09:39 UTC+1, Emmanuel Charpentier a écrit :
>>
>> Any obvious ways to entice former pynac developers out of retirement ?
>>
>> Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :
>>>
>>> No current sage dev knows pynac code, and it is a can of worms.
>>> All of the following are worrysome tickets:
>>>
>>> https://trac.sagemath.org/ticket/30688
>>> https://trac.sagemath.org/ticket/31411
>>> https://trac.sagemath.org/ticket/31337
>>>
>>> At some point pynac and ginac diverged, and while ginac continues to
>>> be maintained and developed,
>>> we cannot draw on the expertise there.
>>>
>>> Any obvious ways to replace pynac with something that works and does
>>> not contain crazy C++ undocumented stuff?
>>>
>>> On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier
>>>  wrote:
>>> >
>>> > I forgot the link to the ticket...
>>> >
>>> > Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a 
>>> > écrit :
>>> >>
>>> >> A question on ask.sagemath.org showed a bug leading to situations where 
>>> >> foo.expand() is mathematically different of foo, which seems both 
>>> >> sufficiently frequent and sufficiently nasty to warrant calling your 
>>> >> attention to it.
>>> >>
>>> >> This may be in pynac territory, where I am unable to help you...
>>> >
>>> > --
>>> > 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 view this discussion on the web visit 
>>> > https://groups.google.com/d/msgid/sage-devel/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/5e6c91ad-2e48-4f2d-a22d-662e14fb07f0n%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/CAAWYfq0BYc1gtwkBeWcPdxzCsbak79N6CxPDJYRhSzEs0bT1sw%40mail.gmail.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Dima Pasechnik]

On Wed, Feb 17, 2021 at 11:09 AM Emmanuel Charpentier
 wrote:
>
> Any obvious ways to entice former pynac developers out of retirement ?

the only (relatively) recently active pynac developer was Ralf
Stephan, who last month handed over maintainership to pynac over to us
- there was a message about this here.
As to Burcin Erocal, the primary pynac author, he hasn't done anything
on Sage for many years, and probably has no time, either.




>
> Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :
>>
>> No current sage dev knows pynac code, and it is a can of worms.
>> All of the following are worrysome tickets:
>>
>> https://trac.sagemath.org/ticket/30688
>> https://trac.sagemath.org/ticket/31411
>> https://trac.sagemath.org/ticket/31337
>>
>> At some point pynac and ginac diverged, and while ginac continues to
>> be maintained and developed,
>> we cannot draw on the expertise there.
>>
>> Any obvious ways to replace pynac with something that works and does
>> not contain crazy C++ undocumented stuff?
>>
>> On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier
>>  wrote:
>> >
>> > I forgot the link to the ticket...
>> >
>> > Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a écrit 
>> > :
>> >>
>> >> A question on ask.sagemath.org showed a bug leading to situations where 
>> >> foo.expand() is mathematically different of foo, which seems both 
>> >> sufficiently frequent and sufficiently nasty to warrant calling your 
>> >> attention to it.
>> >>
>> >> This may be in pynac territory, where I am unable to help you...
>> >
>> > --
>> > 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 view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/sage-devel/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/7616edf6-905f-4275-8cb9-68dbaef8f89fn%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/CAAWYfq3eBh%3Dzjj4p6dtB%3D6dioUS2Ddkw-khq1eNKzoUfA8n4%3Dw%40mail.gmail.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

BTW : I checked that both Maxima and Sympy are exempt of the problem I 
reported...

Did someone bisect https://trac.sagemath.org/ticket/30688, 
https://trac.sagemath.org/ticket/31411 and/or 
https://trac.sagemath.org/ticket/31337 to point to the possible origin ? I 
don't know (yet) how to do this...

Le mercredi 17 février 2021 à 12:09:39 UTC+1, Emmanuel Charpentier a écrit :

> Any obvious ways to entice former pynac developers out of retirement ?
>
> Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :
>
>> No current sage dev knows pynac code, and it is a can of worms. 
>> All of the following are worrysome tickets: 
>>
>> https://trac.sagemath.org/ticket/30688 
>> https://trac.sagemath.org/ticket/31411 
>> https://trac.sagemath.org/ticket/31337 
>>
>> At some point pynac and ginac diverged, and while ginac continues to 
>> be maintained and developed, 
>> we cannot draw on the expertise there. 
>>
>> Any obvious ways to replace pynac with something that works and does 
>> not contain crazy C++ undocumented stuff? 
>>
>> On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier 
>>  wrote: 
>> > 
>> > I forgot the link to the ticket... 
>> > 
>> > Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a 
>> écrit : 
>> >> 
>> >> A question on ask.sagemath.org showed a bug leading to situations 
>> where foo.expand() is mathematically different of foo, which seems both 
>> sufficiently frequent and sufficiently nasty to warrant calling your 
>> attention to it. 
>> >> 
>> >> This may be in pynac territory, where I am unable to help you... 
>> > 
>> > -- 
>> > 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/5e6c91ad-2e48-4f2d-a22d-662e14fb07f0n%40googlegroups.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

Any obvious ways to entice former pynac developers out of retirement ?

Le mercredi 17 février 2021 à 12:01:28 UTC+1, dim...@gmail.com a écrit :

> No current sage dev knows pynac code, and it is a can of worms.
> All of the following are worrysome tickets:
>
> https://trac.sagemath.org/ticket/30688
> https://trac.sagemath.org/ticket/31411
> https://trac.sagemath.org/ticket/31337
>
> At some point pynac and ginac diverged, and while ginac continues to
> be maintained and developed,
> we cannot draw on the expertise there.
>
> Any obvious ways to replace pynac with something that works and does
> not contain crazy C++ undocumented stuff?
>
> On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier
>  wrote:
> >
> > I forgot the link to the ticket...
> >
> > Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a 
> écrit :
> >>
> >> A question on ask.sagemath.org showed a bug leading to situations 
> where foo.expand() is mathematically different of foo, which seems both 
> sufficiently frequent and sufficiently nasty to warrant calling your 
> attention to it.
> >>
> >> This may be in pynac territory, where I am unable to help you...
> >
> > --
> > 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/7616edf6-905f-4275-8cb9-68dbaef8f89fn%40googlegroups.com.

Re: [sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Dima Pasechnik]

No current sage dev knows pynac code, and it is a can of worms.
All of the following are worrysome tickets:

https://trac.sagemath.org/ticket/30688
https://trac.sagemath.org/ticket/31411
https://trac.sagemath.org/ticket/31337

At some point pynac and ginac diverged, and while ginac continues to
be maintained and developed,
we cannot draw on the expertise there.

Any obvious ways to replace pynac with something that works and does
not contain crazy C++ undocumented stuff?

On Wed, Feb 17, 2021 at 10:39 AM Emmanuel Charpentier
 wrote:
>
> I forgot the link to the ticket...
>
> Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a écrit :
>>
>> A question on ask.sagemath.org showed a bug leading to situations where 
>> foo.expand() is mathematically different of foo, which seems both 
>> sufficiently frequent and sufficiently nasty to warrant calling your 
>> attention to it.
>>
>> This may be in pynac territory, where I am unable to help you...
>
> --
> 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/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%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/CAAWYfq0U1AGiikdhuGK4n-t6TmoCDDC0Ky4wV_B5%3DqwBK1r1OQ%40mail.gmail.com.

[sage-devel] Re: root systems and weight lattices, rho and the symmetric_form

['Martin R' via sage-devel]

done, ready for review!

Martin R schrieb am Mittwoch, 17. Februar 2021 um 10:42:13 UTC+1:

> Cool, thank you, I'll try to provide a fix today.  
> https://trac.sagemath.org/ticket/31410
>
> Martin
>
> Travis Scrimshaw schrieb am Mittwoch, 17. Februar 2021 um 10:04:01 UTC+1:
>
>> Hi Martin,
>>Yes, there is a bug here. The issue comes from the diagonalization:
>>
>> sage: cm = 
>> CartanMatrix(['B',3])
>>  
>>  
>> sage: 
>> cm.is_symmetrizable(True)
>>   
>>  
>> [1, 1, 1/2]
>> sage: 
>> CartanMatrix(['F',4]).is_symmetrizable(True) 
>>   
>>  
>> [1, 1, 1/2, 1/2]
>>
>> The diagonal matrix is built from the integer valued version. This 
>> accounts for the factor of 2. So in _symmetric_form_matrix, the 
>> cm.symmetrizer() should be used instead of cm.is_symmetrizable(True) (or 
>> copy the scalar factor from the symmetrizer() implementation).
>>
>> Best,
>> Travis
>>
>> On Wednesday, February 17, 2021 at 8:11:27 AM UTC+10 axio...@yahoo.de 
>> wrote:
>>
>>>
>>> Dear Lie experts!
>>>
>>> I'm afraid I have yet another, probably basic question.  Is the 
>>> following a bug or am I overlooking something:
>>>
>>> def s1(ct):
>>>L = RootSystem(ct).weight_space()
>>>P = L.positive_roots()
>>>rho = L.rho()
>>>return [beta.symmetric_form(rho) for beta in P]
>>>
>>> def s2(ct):
>>>R = RootSystem(ct).root_space()
>>>P = R.positive_roots()
>>>rho = 1/2*sum(P)
>>>return [beta.symmetric_form(rho) for beta in P]
>>>
>>> sage: cartan_types = 
>>> sage.databases.findstat._finite_irreducible_cartan_types_by_rank
>>> sage: [(ct, s1(ct), s2(ct)) for n in range(1,9) for ct in 
>>> cartan_types(n) if s1(ct) != s2(ct)]
>>> [['B', 2], ['B', 3], ['B', 4], ['F', 4], ['B', 5], ['B', 6], ['B', 7], 
>>> ['B', 8]]
>>>
>>> Specifically, for these it seems that I have to multiply everything by 2 
>>> if I am computing in the weight lattice.
>>>
>>> sage: ct = CartanType(["B", 2]); [2*x for x in s1(ct)] == s2(ct)  
>>> True 
>>> sage: ct = CartanType(["F", 4]); [2*x for x in s1(ct)] == s2(ct) 
>>> True
>>>
>>> Thanks for all your help,
>>>
>>> Martin
>>>
>>

-- 
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/7d6818d6-7adb-4734-ab4c-08a6d532fb9en%40googlegroups.com.

[sage-devel] Re: A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

I forgot the link to the ticket ...

Le mercredi 17 février 2021 à 11:30:47 UTC+1, Emmanuel Charpentier a écrit :

> A question on ask.sagemath.org showed a bug leading to situations where 
> foo.expand() is *mathematically different* of foo, which seems both 
> sufficiently frequent and sufficiently nasty to warrant calling your 
> attention to it.
>
> This may be in pynac territory, where I am unable to help you...
>

-- 
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/18920b2d-7cba-4a54-ad72-6526cbea3ba0n%40googlegroups.com.

[sage-devel] A possibly nasty bug : expand() isn't absorbing.

[Emmanuel Charpentier]

A question on ask.sagemath.org showed a bug leading to situations where 
foo.expand() is *mathematically different* of foo, which seems both 
sufficiently frequent and sufficiently nasty to warrant calling your 
attention to it.

This may be in pynac territory, where I am unable to help you...

-- 
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/d2779a2b-42bc-41af-8e3b-63c619ccbff1n%40googlegroups.com.

Re: [sage-devel] documentation of external packages

[E. Madison Bray]

On Wed, Feb 17, 2021 at 3:31 AM Michael Orlitzky  wrote:
>
> On Tue, 2021-02-16 at 19:43 +0100, Vincent Delecroix wrote:
> > Dear all,
> >
> > I think we reached a consensus that we should have more and more
> > of the sage source code made as independent Python packages. This
> > effort has already started with cysignals, cypari2, pplpy and
> > gappy.
> >
> > However, this externalizations comes with some inconvenience and
> > I would like to discuss one issue with documentation that was
> > raised in ticket #31404. Namely, the problem is that we want
> > something like `:mod:cypari2.gen` inside sage documentation to be
> > resolved by sphinx to what it should be (that could be: a link
> > to the documentation in SAGE_SHARE, to the local system
> > documentation on the computer or to online documentation).
>
> Sphinx creates inventory files that can be used for cross-referencing:
>
> https://www.sphinx-doc.org/en/1.5/ext/intersphinx.html#module-sphinx.ext.intersphinx
>
> The trick is then to inform the sage build system of all the various
> locations where those inventory files might be hidden. It wouldn't be
> pretty, but we could probably just "try them all" in spkg-configure.m4
> if there are no smarter ideas. This would only need to be done for the
> packages that are referenced externally.
>
> Failure to locate the docs should be nonfatal in my opinion. If I have
> gone out of my way to install a system package without the
> documentation, I'd rather sage not second-guess me and waste time/space
> building it anyway for the sake of a cross-reference.

I think by default we should just be using the online intersphinx
links (I am surprised to learn we didn't do this already).
Intersphinx mappings can also be made to local copies of docs for
different projects, most of which Sage does not even build or install
(e.g. the Python docs, which we should have intersphinx mappings to).

By default the conf.py could use the URLs for online versions of the
docs, but provide an environment variable or something to provide
alternate paths to each of the third-party docs, so that it can easily
be customized by packagers to link to local docs where available, or
disable them entirely.

-- 
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/CAOTD34b17fit7B6NBExpxt%3D_sBiN0O-kXOLy5B5%3DN48Vi2h23w%40mail.gmail.com.

[sage-devel] Re: root systems and weight lattices, rho and the symmetric_form

['Martin R' via sage-devel]

Cool, thank you, I'll try to provide a fix today.  
https://trac.sagemath.org/ticket/31410

Martin

Travis Scrimshaw schrieb am Mittwoch, 17. Februar 2021 um 10:04:01 UTC+1:

> Hi Martin,
>Yes, there is a bug here. The issue comes from the diagonalization:
>
> sage: cm = 
> CartanMatrix(['B',3]) 
> 
>  
> sage: 
> cm.is_symmetrizable(True) 
>  
>  
> [1, 1, 1/2]
> sage: 
> CartanMatrix(['F',4]).is_symmetrizable(True)  
>  
>  
> [1, 1, 1/2, 1/2]
>
> The diagonal matrix is built from the integer valued version. This 
> accounts for the factor of 2. So in _symmetric_form_matrix, the 
> cm.symmetrizer() should be used instead of cm.is_symmetrizable(True) (or 
> copy the scalar factor from the symmetrizer() implementation).
>
> Best,
> Travis
>
> On Wednesday, February 17, 2021 at 8:11:27 AM UTC+10 axio...@yahoo.de 
> wrote:
>
>>
>> Dear Lie experts!
>>
>> I'm afraid I have yet another, probably basic question.  Is the following 
>> a bug or am I overlooking something:
>>
>> def s1(ct):
>>L = RootSystem(ct).weight_space()
>>P = L.positive_roots()
>>rho = L.rho()
>>return [beta.symmetric_form(rho) for beta in P]
>>
>> def s2(ct):
>>R = RootSystem(ct).root_space()
>>P = R.positive_roots()
>>rho = 1/2*sum(P)
>>return [beta.symmetric_form(rho) for beta in P]
>>
>> sage: cartan_types = 
>> sage.databases.findstat._finite_irreducible_cartan_types_by_rank
>> sage: [(ct, s1(ct), s2(ct)) for n in range(1,9) for ct in cartan_types(n) 
>> if s1(ct) != s2(ct)]
>> [['B', 2], ['B', 3], ['B', 4], ['F', 4], ['B', 5], ['B', 6], ['B', 7], 
>> ['B', 8]]
>>
>> Specifically, for these it seems that I have to multiply everything by 2 
>> if I am computing in the weight lattice.
>>
>> sage: ct = CartanType(["B", 2]); [2*x for x in s1(ct)] == s2(ct)  
>> True 
>> sage: ct = CartanType(["F", 4]); [2*x for x in s1(ct)] == s2(ct) 
>> True
>>
>> Thanks for all your help,
>>
>> Martin
>>
>

-- 
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/dc3e063f-d3d3-4c8a-9433-a27ad53c1f18n%40googlegroups.com.

[sage-devel] Re: root systems and weight lattices, rho and the symmetric_form

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   Yes, there is a bug here. The issue comes from the diagonalization:

sage: cm = 
CartanMatrix(['B',3])   
  
 
sage: 
cm.is_symmetrizable(True)   
   
 
[1, 1, 1/2]
sage: 
CartanMatrix(['F',4]).is_symmetrizable(True)
   
 
[1, 1, 1/2, 1/2]

The diagonal matrix is built from the integer valued version. This accounts 
for the factor of 2. So in _symmetric_form_matrix, the cm.symmetrizer() 
should be used instead of cm.is_symmetrizable(True) (or copy the scalar 
factor from the symmetrizer() implementation).

Best,
Travis

On Wednesday, February 17, 2021 at 8:11:27 AM UTC+10 axio...@yahoo.de wrote:

>
> Dear Lie experts!
>
> I'm afraid I have yet another, probably basic question.  Is the following 
> a bug or am I overlooking something:
>
> def s1(ct):
>L = RootSystem(ct).weight_space()
>P = L.positive_roots()
>rho = L.rho()
>return [beta.symmetric_form(rho) for beta in P]
>
> def s2(ct):
>R = RootSystem(ct).root_space()
>P = R.positive_roots()
>rho = 1/2*sum(P)
>return [beta.symmetric_form(rho) for beta in P]
>
> sage: cartan_types = 
> sage.databases.findstat._finite_irreducible_cartan_types_by_rank
> sage: [(ct, s1(ct), s2(ct)) for n in range(1,9) for ct in cartan_types(n) 
> if s1(ct) != s2(ct)]
> [['B', 2], ['B', 3], ['B', 4], ['F', 4], ['B', 5], ['B', 6], ['B', 7], 
> ['B', 8]]
>
> Specifically, for these it seems that I have to multiply everything by 2 
> if I am computing in the weight lattice.
>
> sage: ct = CartanType(["B", 2]); [2*x for x in s1(ct)] == s2(ct)  
> True 
> sage: ct = CartanType(["F", 4]); [2*x for x in s1(ct)] == s2(ct) 
> True
>
> Thanks for all your help,
>
> Martin
>

-- 
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/cef974be-357b-4833-a0d0-b0d212ea0054n%40googlegroups.com.