Differences between revisions 48 and 51 (spanning 3 versions)

Sage Documentation Project

This is the main community website of the Sage Documentation Project. This page is used as a central point to organize the efforts to create new help pages, tutorials, examples and similar documentation efforts. To add a documentation page to this category, add a link to this page on the last line of the page. Click on "subscribe" above to be posted about changes.

Published Documents

Pages in this wiki (should belong to the category "DocumentationProject").

Title/URL	lang	Abstract	Author	Released/Updated
Netbeans	en	help for coding Python/Sage with Netbeans GUI	harald.schilly@gmail.com	2009-01-18/-
WubiGuide	en	Newbie Wubi Linux Sage install under Windows	merlinson2@yahoo.com	2009-05-17
Cantor	en	Cantor is a GUI front-end for many mathematical software applications like Sage, Maxima, R and KAlgebra	-	2010-01-25
Graph Theory Methods	en	Comparison of Mathematica vs. Sage Graph Theory Methods

External Documents

Not in this wiki (i.e. PDF or website).

Title/URL	lang	Abstract	Author	Released/Updated
Sage and Cython: A Brief Introduction html	en	This is a quick introduction to Sage,[...] One thing I will highlight is using Cython in Sage to make very fast code in an easy way.	Marshall Hampton	-/2008-05-09
Number Theory and the RSA Public Key Cryptosystem pdf	en	This tutorial uses Sage to study elementary number theory and the RSA public key cryptosystem. A number of Sage commands will be introduced that help us to perform basic number theoretic operations such as greatest common divisor and Euler’s phi function. We then introduce the RSA cryptosystem and use Sage’s built-in commands to encrypt and decrypt data via the RSA algorithm.	Minh Van Nguyen	2008-11-04/2009-07-25
Linear error-correcting codes pdf	en	This tutorial introduces some of Sage's functionality in the theory of error-correcting codes.	David Joyner and Robert Miller	2008-05
Group Theory and SAGE: A Primer pdf sws tex	en	This is a compilation of Sage commands useful for a student studying group theory for the first time. The SAGE worksheet version has executable cells.	Rob Beezer	2008-11-05/2009-01-30
ImageJ in a Sage notebook, an example of Python calling Java	en	This blogpost explains how to call Java programs from Sage via Jpype Python module	Frédéric Morain-Nicolier	2009-11-10
Sage in practice at Mendelu link	en/cz	Sage html refcard (en) and worksheets from lectures (en/cz)	Robert Marik	2009-12

Documents in the Work

Title/URL	lang	Author	Progress/Status/Need Help
Sage Wikibook Project	en	-	open for anyone

Wish List

This is a list of requested documentations.

Type	Priority	lang	Purpose and Direction
HowTo	high	en	Setup Sage in a classroom situation as a central server.
Examples	medium	en	Plotting of functions, examples how various kinds of functions can be plotted, explain parameters
Numbertypes and Conversation	high	en	Write a guide explaining the different types of numbers in Sage. What are they for (examples), how to convert, which modules are available (e.g. how works Sage->Python->Mpmath ?) and so on. Should target new Sage users, especially if they are used to simpler environments without different number types. Should be part of "Tutorial"

Types

Some definitions on what is what in the list above. (If someone has better definitions, please edit!)

Howto: Basic step-by-step guide with screenshots, easy to use, straightforward, probably often updated.
Tutorial: Explain a topic, how to do something, similar to howto...
Guide: More general than howto and tutorial. For example, explain background knowledge and connect the dots.
Examples: List examples on a particular topic. The levels "beginner", "advanced" and "pro" can be used to indicate the level of prior knowledge, where "pro" involves knowledge about programming with Sage, i.e. also Python, while "advanced" only requires an understanding of Sage's basic functionalities and an implicit knowledge about Python programming.
Teaching: Material used in teaching.

Writing Great Documentation

Jacob Kaplan-Moss has written a series of three articles on how to write great documentation for any open source project. Here is a list of his articles:

What to write --- Various types of documents that a project should have, including reference manual, tutorials, brief feature tours, development guidelines, etc.
Technical style --- good technical styles to follow.
You need an editor -- on the importance of having an editor to look after the project's documentation.

Darrell Anderson has some tips on technical writing that are well worth a read:

Bigshot Words --- some words to avoid. Dilbert also has some tips.
A Proofreader’s Checklist --- common grammatical and spelling mistakes to look out for.
Technical Writing Tips --- numerous points to keep in mind in technical writing.

Other resources

It also helps to use a spell checker.
Documentation issues in open source from OSS Watch.
How to Write Documentation that Will Lead to New Users by Jack Herrington.
Open-source documentation: in search of user-driven, just-in-time writing by Erik Berglund and Michael Priestley. In "SIGDOC '01: Proceedings of the 19th Annual International Conference on Computer Documentation", ACM, pages 132--141, 2001.
S Van der Walt. The SciPy Documentation Project (Technical Overview). In Proceedings of the 7th Python in Science conference (SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.27--28.
J Harrington. The SciPy Documentation Project. In Proceedings of the 7th Python in Science conference (SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.33--35.
J Harrington et al. Progress Report: NumPy and SciPy Documentation in 2009. In Proceedings of the 8th Python in Science conference (SciPy 2009), G Varoquaux, S van der Walt, J Millman (Eds.), pp.84--87.
Documentation by [insert doc type] covers what isn't documentation.

Worst-case scenario

Avoid the following scenario as much as possible. This is taken from "Lecture 12: FOSS Culture" of the ANU course COMP8440:

From: xxxxx
Date: Fri, 9 Feb 2001 21:07:09 +0900
To: rusty@rustcorp.com.au
Subject: Dear Sir,

I have always wanted to flame you, however I never really had any good reason
to do so. While your software creations were always egoistical and
underdocumented, nothing really pushed the mark, yet. Until today, when I
downloaded your "Linux 2.4" call graph utility. So, when is your next absolute-
next-to-worthless but oh-so-cool-because-it's-from-rusty-russell piece of software
coming out? Why the f*** don't you focus on documenting things instead of
writing useless shit that "takes about 8 hours to run on my mobile pII laptop" or
"generates about 180mb of vector postscript". How about another example. I
heard you were involved with that atrocity called "netfilter". Sure, it might have
nice features and I am still considering using it, but WRITE SOME F***ING DOCS
before you release complex shit like this for people to use! When I goto that
netfilter site, I don't give a flying raging f*** who submitted 31337 lines of code to
whatever f***ing netfilter module. That's your egoistical shit, and I could care less
about it.
...... (more rants delted)
... Uhm, that's all I can think of right now.

xxx (name deleted)

Documents by Category

DocumentationProject

-  ⇤ ← Revision 48 as of 2010-01-20 09:12:38 → 
  Size: 8656
  Editor: Minh Nguyen
  Comment: a worst-case scenario to avoid
+   ← Revision 51 as of 2010-05-17 16:49:18 → ⇥
  Size: 9752
  Editor: schilly
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 11:
-== Writing Great Documentation ==

Jacob Kaplan-Moss has written a series of three articles on how to write great documentation for any open source project. Here is a list of his articles:

 1. [[http://jacobian.org/writing/great-documentation/what-to-write/|What to write]] --- Various types of documents that a project should have, including reference manual, tutorials, brief feature tours, development guidelines, etc.

 1. [[http://jacobian.org/writing/great-documentation/technical-style/|Technical style]] --- good technical styles to follow.

 1. [[http://jacobian.org/writing/great-documentation/editors/|You need an editor]] -- on the importance of having an editor to look after the project's documentation.

Darrell Anderson has some tips on technical writing that are well worth a read:

 1. [[http://humanreadable.nfshost.com/howtos/bigshot_words.htm|Bigshot Words]] --- some words to avoid. [[http://www.dilbert.com/strips/comic/1992-12-21|Dilbert]] also has some tips.

 1. [[http://humanreadable.nfshost.com/howtos/proofreader.htm|A Proofreader’s Checklist]] --- common grammatical and spelling mistakes to look out for.

 1. [[http://humanreadable.nfshost.com/howtos/technical_writing_tips.htm|Technical Writing Tips]] --- numerous points to keep in mind in technical writing.


=== Other issues ===

 1. It also helps to use a spell checker.

 1. [[http://www.oss-watch.ac.uk/resources/documentation.xml|Documentation issues in open source]] from OSS Watch.

 1. [[http://www.devx.com/devx/Article/11839/0/page/2|How to Write Documentation that Will Lead to New Users]] by Jack Herrington.

 1. [[http://portal.acm.org/citation.cfm?id=501543|Open-source documentation: in search of user-driven, just-in-time writing]] by Erik Berglund and Michael Priestley. In "SIGDOC '01: Proceedings of the 19th Annual International Conference on Computer Documentation", ACM, pages 132--141, 2001.

 1. [[http://www.grillbar.org/wordpress/?p=264|Documentation by [insert doc type]]] covers what isn't documentation.


=== Worst-case scenario ===

Avoid the following scenario as much as possible. This is taken from "Lecture 12: FOSS Culture" of the ANU course [[http://cs.anu.edu.au/students/comp8440/lectures.php | COMP8440]]:

{{{
From: xxxxx
Date: Fri, 9 Feb 2001 21:07:09 +0900
To: rusty@rustcorp.com.au
Subject: Dear Sir,

I have always wanted to flame you, however I never really had any good reason
to do so. While your software creations were always egoistical and
underdocumented, nothing really pushed the mark, yet. Until today, when I
downloaded your "Linux 2.4" call graph utility. So, when is your next absolute-
next-to-worthless but oh-so-cool-because-it's-from-rusty-russell piece of software
coming out? Why the f*** don't you focus on documenting things instead of
writing useless shit that "takes about 8 hours to run on my mobile pII laptop" or
"generates about 180mb of vector postscript". How about another example. I
heard you were involved with that atrocity called "netfilter". Sure, it might have
nice features and I am still considering using it, but WRITE SOME F***ING DOCS
before you release complex shit like this for people to use! When I goto that
netfilter site, I don't give a flying raging f*** who submitted 31337 lines of code to
whatever f***ing netfilter module. That's your egoistical shit, and I could care less
about it.
...... (more rants delted)
... Uhm, that's all I can think of right now.

xxx (name deleted)
}}}
-Line 80:
+Line 19:
+|| [[Cantor]] || en || Cantor is a GUI front-end for many mathematical software applications like Sage, Maxima, R and KAlgebra || - || 2010-01-25 ||
|| [[http://trac.sagemath.org/sage_trac/wiki/GraphTheoryRoadmap|Graph Theory Methods]] || en || Comparison of Mathematica vs. Sage Graph Theory Methods || || ||
-Line 123:
+Line 64:
+== Writing Great Documentation ==

Jacob Kaplan-Moss has written a series of three articles on how to write great documentation for any open source project. Here is a list of his articles:

 1. [[http://jacobian.org/writing/great-documentation/what-to-write/|What to write]] --- Various types of documents that a project should have, including reference manual, tutorials, brief feature tours, development guidelines, etc.

 1. [[http://jacobian.org/writing/great-documentation/technical-style/|Technical style]] --- good technical styles to follow.

 1. [[http://jacobian.org/writing/great-documentation/editors/|You need an editor]] -- on the importance of having an editor to look after the project's documentation.

Darrell Anderson has some tips on technical writing that are well worth a read:

 1. [[http://humanreadable.nfshost.com/howtos/bigshot_words.htm|Bigshot Words]] --- some words to avoid. [[http://www.dilbert.com/strips/comic/1992-12-21|Dilbert]] also has some tips.

 1. [[http://humanreadable.nfshost.com/howtos/proofreader.htm|A Proofreader’s Checklist]] --- common grammatical and spelling mistakes to look out for.

 1. [[http://humanreadable.nfshost.com/howtos/technical_writing_tips.htm|Technical Writing Tips]] --- numerous points to keep in mind in technical writing.


=== Other resources ===

 1. It also helps to use a spell checker.

 1. [[http://www.oss-watch.ac.uk/resources/documentation.xml|Documentation issues in open source]] from OSS Watch.

 1. [[http://www.devx.com/devx/Article/11839/0/page/2|How to Write Documentation that Will Lead to New Users]] by Jack Herrington.

 1. [[http://portal.acm.org/citation.cfm?id=501543|Open-source documentation: in search of user-driven, just-in-time writing]] by Erik Berglund and Michael Priestley. In "SIGDOC '01: Proceedings of the 19th Annual International Conference on Computer Documentation", ACM, pages 132--141, 2001.

 1. S Van der Walt. [[http://conference.scipy.org/proceedings/SciPy2008/paper_5 | The SciPy Documentation Project (Technical Overview)]]. In Proceedings of the 7th Python in Science conference (!SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.27--28.

 1. J Harrington. [[http://conference.scipy.org/proceedings/SciPy2008/paper_7 | The SciPy Documentation Project]]. In Proceedings of the 7th Python in Science conference (!SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.33--35.

 1. J Harrington et al. [[http://conference.scipy.org/proceedings/SciPy2009/paper_14 | Progress Report: NumPy and SciPy Documentation in 2009]]. In Proceedings of the 8th Python in Science conference (!SciPy 2009), G Varoquaux, S van der Walt, J Millman (Eds.), pp.84--87.

 1. [[http://www.grillbar.org/wordpress/?p=264|Documentation by [insert doc type]]] covers what isn't documentation.


=== Worst-case scenario ===

Avoid the following scenario as much as possible. This is taken from "Lecture 12: FOSS Culture" of the ANU course [[http://cs.anu.edu.au/students/comp8440/lectures.php | COMP8440]]:

{{{
From: xxxxx
Date: Fri, 9 Feb 2001 21:07:09 +0900
To: rusty@rustcorp.com.au
Subject: Dear Sir,

I have always wanted to flame you, however I never really had any good reason
to do so. While your software creations were always egoistical and
underdocumented, nothing really pushed the mark, yet. Until today, when I
downloaded your "Linux 2.4" call graph utility. So, when is your next absolute-
next-to-worthless but oh-so-cool-because-it's-from-rusty-russell piece of software
coming out? Why the f*** don't you focus on documenting things instead of
writing useless shit that "takes about 8 hours to run on my mobile pII laptop" or
"generates about 180mb of vector postscript". How about another example. I
heard you were involved with that atrocity called "netfilter". Sure, it might have
nice features and I am still considering using it, but WRITE SOME F***ING DOCS
before you release complex shit like this for people to use! When I goto that
netfilter site, I don't give a flying raging f*** who submitted 31337 lines of code to
whatever f***ing netfilter module. That's your egoistical shit, and I could care less
about it.
...... (more rants delted)
... Uhm, that's all I can think of right now.

xxx (name deleted)
}}}

Diff for "DocumentationProject"