Re: [sage-devel] redefinition of sage_malloc

[Jeroen Demeyer]

The minimal fix is to add

include "sage/ext/stdsage.pxi"

However, you better use check_allocarray() instead, for which you also 
need to add


from sage.ext.memory import check_allocarray

and then replace

c_values = sage_malloc(sizeof(double)*len(values))

by

c_values = check_allocarray(len(values), sizeof(double))

Also, use sage_free() instead of free().

--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] redefinition of sage_malloc

[mmarco]

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


cdef extern from "stdlib.h":
void free(void* ptr)


cdef extern from "homotopyPath.h":
double* homotopyPath (int degree, double *_coef, double _y0R, double 
_y0I)


def contpath(deg,values,y0r,y0i):
cdef double* rop
c_values = sage_malloc(sizeof(double)*len(values))
#cdef int clen =  len(values)
for i,v in enumerate(values):
c_values[i] = values[i]
cdef double y0R = y0r
cdef double y0I = y0i
rop = homotopyPath (int(deg), c_values, y0R, y0I)
n=int(rop[0])
l=[0 for i in range(n)]
for i in range(n):
l[i]=(rop[3*i+1],rop[3*i+2],rop[3*i+3])
free(rop)
free(c_values)
return l

But when i try to load it i get the error:

Compiling ./my_library.pyx...
Error compiling cython file:
Error compiling ./my_library.pyx:
running build
running build_ext
building '_home_mmarco_integrado_my_library_pyx_16' extension
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/home/
mmarco/sage/local/include/csage -I/home/mmarco/sage/local/include -I/home/
mmarco/sage/local/include/python2.7 -I/home/mmarco/sage/local/lib/python/
site-packages/numpy/core/include -I/home/mmarco/sage/src/sage/ext -I/home/
mmarco/sage/src -I/home/mmarco/sage/src/sage/gsl -I. -I/home/mmarco/sage/
local/include/python2.7 -c _home_mmarco_integrado_my_library_pyx_16.c -o 
build/temp.linux-x86_64-2.7/_home_mmarco_integrado_my_library_pyx_16.o -w -
O2


_home_mmarco_integrado_my_library_pyx_16.c:1183:28: error: redefinition of 
'sage_malloc'
 static CYTHON_INLINE void *sage_malloc(size_t __pyx_v_n) {
^
In file included from /home/mmarco/sage/local/include/csage/stdsage.h:36:0,
 from _home_mmarco_integrado_my_library_pyx_16.c:230:
/home/mmarco/sage/local/include/csage/memory.h:29:21: note: previous 
definition of 'sage_malloc' was here
 static inline void* sage_malloc(size_t n)
 ^
_home_mmarco_integrado_my_library_pyx_16.c:1245:28: error: redefinition of 
'sage_realloc'
 static CYTHON_INLINE void *sage_realloc(void *__pyx_v_ptr, size_t 
__pyx_v_size) {
^
In file included from /home/mmarco/sage/local/include/csage/stdsage.h:36:0,
 from _home_mmarco_integrado_my_library_pyx_16.c:230:
/home/mmarco/sage/local/include/csage/memory.h:49:21: note: previous 
definition of 'sage_realloc' was here
 static inline void* sage_realloc(void *ptr, size_t size)
 ^
_home_mmarco_integrado_my_library_pyx_16.c:1307:28: error: redefinition of 
'sage_calloc'
 static CYTHON_INLINE void *sage_calloc(size_t __pyx_v_nmemb, size_t 
__pyx_v_size) {
^
In file included from /home/mmarco/sage/local/include/csage/stdsage.h:36:0,
 from _home_mmarco_integrado_my_library_pyx_16.c:230:
/home/mmarco/sage/local/include/csage/memory.h:36:21: note: previous 
definition of 'sage_calloc' was here
 static inline void* sage_calloc(size_t nmemb, size_t size)
 ^
_home_mmarco_integrado_my_library_pyx_16.c:1369:27: error: redefinition of 
'sage_free'
 static CYTHON_INLINE void sage_free(void *__pyx_v_ptr) {
   ^
In file included from /home/mmarco/sage/local/include/csage/stdsage.h:36:0,
 from _home_mmarco_integrado_my_library_pyx_16.c:230:
/home/mmarco/sage/local/include/csage/memory.h:43:20: note: previous 
definition of 'sage_free' was here
 static inline void sage_free(void* ptr)
^
error: command 'gcc' failed with exit status 1


I have no idea why it complains about sage_malloc being redefined. Any clue?

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Referring to 'self' in the documentation

[Simon King]

Hi Eric,

On 2015-04-03, Eric Gourgoulhon  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 in doc strings.

I am not very consistent here, myself. Sometimes I write "self",
sometimes I write "this element" (or whatever is appropriate).

Best regards,
Simon

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Referring to 'self' in the documentation

[Volker Braun]

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 document self as one of the INPUT: arguments



On Friday, April 3, 2015 at 3:49:53 PM UTC+2, Eric Gourgoulhon wrote:
>
> 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 Python, this might be confusing.
>
> It seems that the current documentation is not homogeneous in this respect:
>
> sage: n=2
> sage: n.is_prime?
>   Test whether "self" is prime.
>
> sage: n.is_unit?
>Returns "true" if this integer is a unit, i.e., 1 or -1.
>
> Thank you for your advice.
>
> Eric. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Referring to 'self' in the documentation

[Daniel Krenn]

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 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 Python, this might be confusing.
> 
> In the html-documentation "self" is not shown for methods. 
> 
> 
> Yes it is: see the example is_prime above; another random example is the
> method algebra() of
> SymmetricGroup.
> 

What I meant is, that in the html documentation in the headline
announcing this function, "self" is not included:

E.g. "algebra(base_ring)" in your example. Therefore *I* avoid it in the
docstring. (But among the existing documentation, this is not consistent).

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Referring to 'self' in the documentation

[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 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 Python, this might be confusing. 
>
> In the html-documentation "self" is not shown for methods. 


Yes it is: see the example is_prime above; another random example is the 
method algebra() of 
SymmetricGroup. 


Eric. 

Therefore I 
> always try to avoid it. 
>
> Daniel 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Referring to 'self' in the documentation

[Daniel Krenn]

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 clear. But for a Sage user not
> familiar with Python, this might be confusing.

In the html-documentation "self" is not shown for methods. Therefore I
always try to avoid it.

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Referring to 'self' in the documentation

[Eric Gourgoulhon]

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 Python, 
this might be confusing.

It seems that the current documentation is not homogeneous in this respect:

sage: n=2
sage: n.is_prime?
  Test whether "self" is prime.

sage: n.is_unit?
   Returns "true" if this integer is a unit, i.e., 1 or -1.

Thank you for your advice.

Eric. 

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: more links between functions/methods/modules

[Ralf Stephan]

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 presumably why the three random
tutorials I picked (calculus, p-adics, combinatorics) had not a single link 
to
the reference manual.

Regards,

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: more links between functions/methods/modules

[Daniel Krenn]

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 flags, so there would otherwise
> be no difference with SEEALSO.

Done. See trac.

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: more links between functions/methods/modules

[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 flags, so there would otherwise
be no difference with SEEALSO.

Thanks,

Nathann

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: more links between functions/methods/modules

[Daniel Krenn]

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 required.
> 
> Marking it as "highly recommended", however, seems fine to me. In any
> case, what really matters is whether referees would set a ticket to
> "needs work" if a SEEALSO is missing.

The intention of #18120 is to remove this "optional", but not making it
explicitly manadatory. "highly recommended" sounds like a good phrase.

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: more links between functions/methods/modules

[Nathann Cohen]

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 turn the 'optional' in the list into a
'recommended'. Right now all the entries are 'mandatory by default',
i.e. INPUT/EXAMPLES are not flagged with anything, and in particular
not with 'mandatory', which is thus assumed.

Nathann

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: more links between functions/methods/modules

[Simon King]

Hi John,

On 2015-04-03, John Cremona  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 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 required.

Marking it as "highly recommended", however, seems fine to me. In any
case, what really matters is whether referees would set a ticket to
"needs work" if a SEEALSO is missing.

Best regards,
Simon


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: more links between functions/methods/modules

[John Cremona]

On 3 April 2015 at 12:36, Nathann Cohen  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 do you think about this topic? How can we make our documentation
>> linked better together?
>
>
> 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 too far, and my instinct tells
me that removing "optional" and replacing with "strongly recommended
wherever appropriate" would be more productive than making it
literally mandatory for all functions, as Nathann suggests.

John

>
> Nathann
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: more links between functions/methods/modules

[Nathann Cohen]

>
> 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 
> linked better together? 
>

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.

Nathann

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] more links between functions/methods/modules

[Daniel Krenn]

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

http://www.sagemath.org/doc/developer/coding_basics.html#documentation-strings

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
linked better together?

Best wishes

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: proprecation ? sandbox ?

[Amit Jamadagni]

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  wrote:

> Hi Karl-Dieter,
>
> On 2015-04-02, kcrisman  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 lack of some outside reviewer, but for which one would need to
> know
> > a fair amount about knot theory to review properly.)
>
> It is a while ago, but around my PhD I did knot theory.
>
> So, can you give me a pointer towards the to-be-reviewed tickets on knot
> theory?
>
> Best regards,
> Simon
>
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-flame] Re: [sage-devel] For french readers

[Francesco Biscani]

Hello Bill,

On 2 April 2015 at 18:06, Bill Hart  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, staged
> functions, C++ interface support, including inline C++, many speedups and
> bug fixes). We have numerous local hacks so that we can keep working
> through all the chaos.
>

I just went to take a look at Cxx.jl, and it looks very promising! There's
not much documentation about it though, so I was wondering if you know
about the following:

- does it support templates?
- can you define julia structs/classes (if it makes any sense) on top of
the C++ ones (that is, I would like to be able to expose C++ classes and
their methods/operators, and to be able to call them from julia)? Or does
it support only functions?
- is the REPL stuff going to be basically an interactive C++ interpreter?
It seems to reference in some places Cling (
https://root.cern.ch/drupal/content/cling), which I had read about
previously.

Cheers,

  Francesco.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: ipython-notebook: show picture in notebook (e.g. latex-tikz)

[Volker Braun]

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 
 transducers.GrayCode() re-implements plotting, just in a less flexible way.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: ipython-notebook: show picture in notebook (e.g. latex-tikz)

[Daniel Krenn]

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
> should go with the program and

Actually, it is a short for

  view(latex(transducers.GrayCode()))

also works with

  view(latex(transducers.GrayCode()))

So it is the LaTeX output (which is a TikZ-picture) which I want to show.
IMHO...showing any latex-output should work as in the sagenb (i.e. inplace)

> * Have plot() produce a Graphics object that contains all of the desired
> output

This works for the transducers, but gives a different represetnation
(using graphs). The nicly formatted output comes from latex(...)

> * There should be a plot(format='tikz'), or maybe plot(viewer='tikz')
> etc, that produces tikz+latex from the Graphics object. 

Ok.

Daniel

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] ipython-notebook: show picture in notebook (e.g. latex-tikz)

[Daniel Krenn]

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

http://trac.sagemath.org/ticket/18116

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: proprecation ? sandbox ?

[Simon King]

Hi Karl-Dieter,

On 2015-04-02, kcrisman  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 lack of some outside reviewer, but for which one would need to know 
> a fair amount about knot theory to review properly.) 

It is a while ago, but around my PhD I did knot theory.

So, can you give me a pointer towards the to-be-reviewed tickets on knot
theory?

Best regards,
Simon


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.