+1 for a separate repo.
I think that initially the default format for SymPEPs should be markdown
as it renders well in github. Markdown has some serious limitations, so
their may be reasons to change this later.
Regards,
Jonathan
On 10/12/20 5:06 PM, Aaron Meurer wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
I'd like to restart discussion on SymPEPs.
Here are the documents outlining the processes for PEPs, MEPs
(Matplotlib Enhancement Proposals), and NEPs (NumPy Enhancement
Proposals)
https://www.python.org/dev/peps/pep-0001/
https://matplotlib.org/3.1.1/devel/MEP/template.html
https://numpy.org/neps/nep-0000.html
The MEP and NEP templates are both very similar to PEPs.
So I think we should start with SymPEP 1, which would be the outline
of the SymPEP process. The first meta question that needs to be
answered, though, is where should SymPEPs live, and where should the
discussions on them take place? A natural place would be the wiki, but
I actually think the wiki isn't the best place. The wiki doesn't have
any discussion features, and it also doesn't have any way to do pull
requests. Also the wiki allows anyone to edit it without permission,
which might not be what we want for SymPEPs.
So I would suggest either including them in the main SymPy repo, or
creating a new SymPEPs repo for them. Any preference on which would be
better? I think I would prefer a separate repo, unless we want to have
the rendered documents included in the SymPy documentation, in which
case that will be easier if they are in the SymPy repo. In either
case, I would suggest for the discussions for any SymPEP to take place
on issues or pull requests on the respective repo.
Once we decide this, we can start with an actual start for SymPEP 1
and the discussion of what it should look like.
Aaron Meurer
On Thu, Aug 6, 2020 at 2:08 PM Aaron Meurer <asmeu...@gmail.com> wrote:
I think the documentation stuff is a bit off topic here. We can
improve documentation and have SymPEPs. In fact, if improving
documentation requires a large concerted effort, that could itself be
a SymPEP. However, I will note that on this front:
- We are participating in Google Season of Docs (GSoD, not to be
confused with GSoC), which is a program that pays technical writers to
work on open source documentation. The GSoD results will be announced
in a couple of weeks, so watch this space.
- I agree that we should have a concerted effort to improve
documentation. A documentation sprint is one way. Getting funding to
improve things is another.
- We have a documentation style guide, which was developed as part of
last year's GSoD. However, only a small subset of SymPy actually
conforms to the guide
https://docs.sympy.org/latest/documentation-style-guide.html.
Aaron Meurer
On Thu, Aug 6, 2020 at 1:48 PM Nikhil Maan <nikhilmaa...@gmail.com> wrote:
On Thursday, August 6, 2020 at 9:39:43 PM UTC+5:30 moore...@gmail.com wrote:
A nice thing for a GSoD student to do would be to organize a documentation
sprint.
This sounds like a great idea.
I also like the idea of SymPy Enhancement Proposals. Another project that I
think might benefit SymPEPs is Naman Gera's work on adding control systems to
SymPy. It will be a great place for folks who would like to help with/continue
this work in the future to find the motivations and other details about the
decision choices and future plans.
Looking at PEP-1 and seeing a large portion of the discussion in the thread is
regarding what kind of work should have a SymPEP and what they should include,
I think a good starting point for SymPEP-1 will be to describe what are
SymPEPs, why we are planning to add them, what kind of changes should have a
SymPEP, etc. Also, I like the sound of SymEP and SymPEP. +1 to calling them
SymPEP or SymEP instead of SEP.
Regards,
Nikhil Maan
Jason
moorepants.info
+01 530-601-9791
On Thu, Aug 6, 2020 at 5:32 PM Matthew Brett <matthe...@gmail.com> wrote:
Hi,
On Thu, Aug 6, 2020 at 4:10 PM David Bailey <da...@dbailey.co.uk> wrote:
On 06/08/2020 00:47, Nicolas Guarin wrote:
I agree that this would be good for the project but maybe it would be a good
idea to polish the documentation a bit. Some of the pages in the wiki are
somewhat outdated and they are on the first results in a web search.
Assuming you are talking about the user level documentation, I very much agree.
If you look up even the simplest function - e.g. Sin[] - in Mathematica, you
get a simple explanation, some examples showing that it can be used with real
numbers, and that it 'knows' about special arguments such as Pi/3.
It shows you the power series about zero and a plot of the function. It also
shows some properties of the function such as Sin[x] = -Sin[-x] etc etc.
It also shows that Sin can be applied to complex arguments, or even to
matrices, and that it can be applied to a high precision floating point number
to deliver a high precision result.
That same level of detail is provided for every function - right up to
complicated functions like MeijerG. Remember that for functions such as that,
the documentation is even more important because there are different
conventions as to the order,sign, etc of the arguments.
This might appear like overkill, but it means that wherever you start you will
realise a Mathemaica function is far more than just a numerical function. This
is also true for SymPy, but the information is harder to find. It is also easy
to cut/paste from the documentation into your own code.
Of course, the documentation is massively redundant, but I imagine that the
documentation for each function or operation would not be written from scratch,
but pulled from some kind of database of information.
Obviously the SymPy documentation can't jump to the Mathematica standard
overnight, but maybe a student could put together some sort of framework from
which such documentation of the standard maths functions could be generated,
and start the process off - then others could contribute information that would
fit into the same scheme.
I think that such documentation would make SymPy very much more user-friendly.
Just to say - that the Scipy Documentation Project took Numpy from
fairly woeful documentation, to very good documentation, in a few
months, and with a fairly small budget:
http://conference.scipy.org/proceedings/SciPy2008/paper_5/
https://ieeexplore.ieee.org/document/6879046
Cheers,
Matthew
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAH6Pt5q%3DN_Vb0Z_yM2w8nBKwFFJu8UPBO3_A0c1UeWhAKDBX%3Dg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/b977b777-52de-43af-81c9-445662ffef9bn%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6K114c9mbhXLVru4HCVB_M_-4wLdf7pHnz-ceHm97gAiQ%40mail.gmail.com.
--
Dr. Jonathan Gutow
Chemistry Department
UW Oshkosh
web: https://uwosh.edu/facstaff/gutow
e-mail: gu...@uwosh.edu
Ph: 920-424-1326
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/680e649c-f869-dcb4-f17f-7f5e977a17cd%40uwosh.edu.
