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

2020-05-02 Thread John H Palmieri
On Saturday, May 2, 2020 at 11:37:57 AM UTC-7, Sébastien Labbé wrote: > > > > On Saturday, May 2, 2020 at 7:55:25 PM UTC+2, John H Palmieri wrote: >> >> >> >> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote: >>> >>> >>> I feel the same way about functions like search_src() tha

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

2020-05-02 Thread Sébastien Labbé
On Saturday, May 2, 2020 at 7:55:25 PM UTC+2, John H Palmieri wrote: > > > > On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote: >> >> >> I feel the same way about functions like search_src() that badly >>> reimplement grep (even if they still work). >>> >> >> I am fine with ge

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

2020-05-02 Thread Matthias Koeppe
On Saturday, May 2, 2020 at 11:23:34 AM UTC-7, Matthias Koeppe wrote: > > I meant to suggest doing this for 9.2, right after 9.1 is released. > I have added a link to this thread to https://wiki.sagemath.org/ReleaseTours/sage-9.2 -- You received this message because you are subscribed to the G

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

2020-05-02 Thread Matthias Koeppe
On Saturday, May 2, 2020 at 9:02:05 AM UTC-7, vdelecroix wrote: > > If anything is broken, removing is fine with me. > > Otherwise, *each* class/function in each of these modules must > be endowed with a very explicit deprecation warning pointing to > the better upstream equivalent. I do not see

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

2020-05-02 Thread Dima Pasechnik
On Sat, May 2, 2020 at 7:16 PM Matthias Koeppe wrote: > > On Saturday, May 2, 2020 at 10:55:25 AM UTC-7, John H Palmieri wrote: >> >> >> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote: I am fine with getting rid of the log_* functions, but I definitively want s

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

2020-05-02 Thread Matthias Koeppe
On Saturday, May 2, 2020 at 10:55:25 AM UTC-7, John H Palmieri wrote: > > > On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote: >> >> I am fine with getting rid of the log_* functions, but I definitively >>> want search_src(), search_def() and search_doc() to stay. Shame on me, bu

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

2020-05-02 Thread Matthias Koeppe
On Saturday, May 2, 2020 at 10:28:52 AM UTC-7, Julien Puydt wrote: > > > indeed : > > > https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03 > > > and it shows : > - cygwin patches ; > - modifications for Python detection ; > > all of which shouldn't make

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

2020-05-02 Thread John H Palmieri
On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote: > > > I feel the same way about functions like search_src() that badly >> reimplement grep (even if they still work). >> > > I am fine with getting rid of the log_* functions, but I definitively want > search_src(), search_de

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

2020-05-02 Thread Julien Puydt
Hi, Le samedi 02 mai 2020 à 14:03 +0100, Dima Pasechnik a écrit : > > you can recreate a patch from > https://github.com/mkoeppe/pynac/releases > indeed : https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03 and it shows : - cygwin patches ; - modificat

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

2020-05-02 Thread Sébastien Labbé
> I feel the same way about functions like search_src() that badly > reimplement grep (even if they still work). > I am fine with getting rid of the log_* functions, but I definitively want search_src(), search_def() and search_doc() to stay. Shame on me, but I use them when I need from the

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

2020-05-02 Thread Vincent Delecroix
If anything is broken, removing is fine with me. Otherwise, *each* class/function in each of these modules must be endowed with a very explicit deprecation warning pointing to the better upstream equivalent. I do not see why there should be any exception with our deprecation policy. Le 02/05/202

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

2020-05-02 Thread Michael Orlitzky
On 5/2/20 9:20 AM, kcrisman wrote: > > Also, search_def is the one I found most useful when learning Sage > properly, and the GUI manager method requires people to know the "def" > is the word, not "definition" or even "function" or whatever. > Learning the word "def" is no harder than learning

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

2020-05-02 Thread kcrisman
On Saturday, May 2, 2020 at 7:12:42 AM UTC-4, Michael Orlitzky wrote: > > On 5/1/20 1:36 PM, John H Palmieri wrote: > > > > So before deprecating, consider points of view of users from different > > backgrounds. We hope that mathematicians are using Sage, and we > > shouldn't require them to

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

2020-05-02 Thread Dima Pasechnik
On Sat, May 2, 2020 at 1:58 PM Dima Pasechnik wrote: > > On Sat, May 2, 2020 at 1:41 PM Julien Puydt wrote: > > > > Hi, > > > > I'm maintaining pynac in Debian, with the goal of keeping sagemath > > packaged in Debian. > > > > According to : > > https://git.sagemath.org/sage.git/tree/build/pkgs/p

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

2020-05-02 Thread Dima Pasechnik
On Sat, May 2, 2020 at 1:41 PM Julien Puydt wrote: > > Hi, > > I'm maintaining pynac in Debian, with the goal of keeping sagemath > packaged in Debian. > > According to : > https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop > > the version in sage is now 0.7.26.s

[sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

2020-05-02 Thread Julien Puydt
Hi, I'm maintaining pynac in Debian, with the goal of keeping sagemath packaged in Debian. According to : https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop the version in sage is now 0.7.26.sage-2020-04-03, while upstream is 0.7.26. Is there some patch I coul

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

2020-05-02 Thread Sébastien Labbé
At least, I know that module sage/finance/stock.py is completely broken. A warning was added in trac ticket #25473 in the top of the page of http://doc.sagemath.org/html/en/reference/finance/sage/finance/stock.html For the doctests to pass, tag "known bug" was a

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

2020-05-02 Thread Michael Orlitzky
On 5/1/20 1:36 PM, John H Palmieri wrote: > > So before deprecating, consider points of view of users from different > backgrounds. We hope that mathematicians are using Sage, and we > shouldn't require them to know about "grep". Don't get me wrong, grep is > great and I use it all the time, but I

Re: [sage-devel] Re: Want to add generalised Newton's method for solving a nonlinear systems of equations to Sage

2020-05-02 Thread Thierry Dumont
Hello, The question is : what sort of problem do you want to solve ? with what method ? Is this a pure Newton-(Raphson) method? A) If yes: 1) If you compute in RDF floats (that is: your machine floating points numbers, aka "double" in C), the best you have to do is to use the scipy implementa

[sage-devel] Re: Want to add generalised Newton's method for solving a nonlinear systems of equations to Sage

2020-05-02 Thread jplab
Hello Daniel, I am not very familiar with the numerical newton methods in Sage. Have you looked in numpy? Concerning the contribution process, you may appreciate the following answer given on AskSage https://ask.sagemath.org/question/50630/how-to-contribute-to-sage-in-less-than-20-easy-steps/

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

2020-05-02 Thread Dima Pasechnik
On Sat, May 2, 2020 at 12:46 AM John H Palmieri wrote: > > Did you mean 9.2? It's too late to add deprecations to 9.1, in my opinion. > be it 9.1 or 9.2, it's certainly a good idea to deprecate and remove. > > On Friday, May 1, 2020 at 2:19:32 PM UTC-7, Matthias Koeppe wrote: >> >> These modules