Hello Bill,
On 2 April 2015 at 18:06, Bill Hart goodwillh...@googlemail.com wrote:
We are very deliberately targeting the leading/bleeding edge because there
is just so much amazing, useful stuff in the works that we really can't
ignore (dramatically improved gc, much better C struct support,
Hi Karl-Dieter,
On 2015-04-02, kcrisman kcris...@gmail.com wrote:
So if this is a solution to that problem, this seems very reasonable
indeed. How many uncaught bugs would we allow? (I'm thinking of the knot
theory code, for instance, which currently languishes due pretty much only
due to
Hello Simon,
Here is the ticket on Knot Theory
http://trac.sagemath.org/ticket/17030. There are some more tickets which
are related to the HOMFLY polynomial computation, which is being packaged
http://trac.sagemath.org/ticket/18047.
ᐧ
On Fri, Apr 3, 2015 at 1:16 PM, Simon King
Am 2015-04-02 um 21:52 schrieb Daniel Krenn:
The command
view(transducers.GrayCode())
produces tikz-output which can be show by latex. In sagenb this was
shown directly inside the notebook, while in the ipython-notebook this
opens a new pdf with the picture.
This is now
On Friday, April 3, 2015 at 9:56:40 AM UTC+2, Daniel Krenn wrote:
Actually, it is a short for
view(latex(transducers.GrayCode()))
I know. And who cares? The important point is to present a uniform user
interface for generating graphical output. The _latex_ method of
states an optional SEEALSO block for links to other functions, methods,
modules, etc. On step in more links could be to encourage people to use
this block more frequently (see http://trac.sagemath.org/ticket/18120).
What do you think about this topic? How can we make our documentation
Am 2015-04-03 um 01:27 schrieb Volker Braun:
I didn't even know that that was possible, yet another way to plot stuff
that is not accessible via plot()...
There is no ticket for refactoring view() into something consistent
except for the awfully vague #18033. IMHO the finite state machines
Hi John,
On 2015-04-03, John Cremona john.crem...@gmail.com wrote:
To be more accurate, the ticket at 18120 removes the 'optional' mention next
to the 'SEEALSO' section, thus implying that it is mandatory for all
functions to have a 'SEEALSO' section.
Being mandatory seems to me to be going
Am 2015-04-03 um 14:10 schrieb Simon King:
Being mandatory seems to me to be going too far,
I think Nathann did not suggest to make it explicitly mandatory, but
only to remove the explicit labelling as being optional. So, it is
implied that one should use SEEALSO, but it is not strictly
The intention of #18120 is to remove this optional, but not making it
explicitly manadatory. highly recommended sounds like a good phrase.
Then could you make it explicitly '(highly) recommended'? As you see
the mandatory fields have no specific flags, so there would otherwise
be no difference
Am 2015-04-03 um 14:24 schrieb Nathann Cohen:
The intention of #18120 is to remove this optional, but not making it
explicitly manadatory. highly recommended sounds like a good phrase.
Then could you make it explicitly '(highly) recommended'? As you see
the mandatory fields have no specific
On 3 April 2015 at 12:36, Nathann Cohen nathann.co...@gmail.com wrote:
states an optional SEEALSO block for links to other functions, methods,
modules, etc. On step in more links could be to encourage people to use
this block more frequently (see http://trac.sagemath.org/ticket/18120).
What
Hello,
I think Nathann did not suggest to make it explicitly mandatory, but
only to remove the explicit labelling as being optional. So, it is
implied that one should use SEEALSO, but it is not strictly required.
Marking it as highly recommended, however, seems fine to me.
+1. We could just
Dear all,
at the moment there are not that many links between functions, methods,
modules in the reference manual. It would be definitely good to have
much more links, so that exploring new functionality and finding related
stuff is much easier than now.
The developer guide
I am having some trouble writing a cython interface to a library. It does
something pretty simple: creates a malloc'ed array of values, passes it to
a external function in the library, and gets a malloc'ed array back.
In the past i made something similar to this work:
#clib homotopyPath
Le vendredi 3 avril 2015 15:58:53 UTC+2, Daniel Krenn a écrit :
Am 2015-04-03 um 15:49 schrieb Eric Gourgoulhon:
I would like some advice about the mention of the Python (conventional
pseudo-)keyword *self* when writing docstrings of new class methods:
shall we mention *self *or not ?
Am 2015-04-03 um 16:11 schrieb Eric Gourgoulhon:
Le vendredi 3 avril 2015 15:58:53 UTC+2, Daniel Krenn a écrit :
Am 2015-04-03 um 15:49 schrieb Eric Gourgoulhon:
I would like some advice about the mention of the Python
(conventional
pseudo-)keyword *self* when writing
See also:
https://groups.google.com/d/msg/sage-devel/zMWMBU7CNAo/nLRLgd0BYfcJ
In general, try to avoid self. We know already that the docstring refers
to the object being documented, no need to repeat that all the time.
Shorter is better:
sage: n.is_prime?
Test primality.
Definitely do not
Hi Eric,
On 2015-04-03, Eric Gourgoulhon egourgoul...@gmail.com wrote:
In the html-documentation self is not shown for methods.=20
Yes it is:
I think Daniel was referring to the fact that self is not shown in
the documentation in the list of arguments of a method. Of course
it is mentioned
Hi,
I would like some advice about the mention of the Python (conventional
pseudo-)keyword *self* when writing docstrings of new class methods: shall
we mention *self *or not ? Of course, from a technical point of view, this
is perfectly valid and clear. But for a Sage user not familiar with
Am 2015-04-03 um 15:49 schrieb Eric Gourgoulhon:
I would like some advice about the mention of the Python (conventional
pseudo-)keyword *self* when writing docstrings of new class methods:
shall we mention *self *or not ? Of course, from a technical point of
view, this is perfectly valid and
On Friday, April 3, 2015 at 12:54:00 PM UTC+2, Daniel Krenn wrote:
What do you think about this topic? How can we make our documentation
linked better together?
I think it would already be better if there wasn't this bug preventing
authors
from linking between document trees.That's
22 matches
Mail list logo
