[sage-devel] Re: Cython: passing a Python data structure as a void pointer
Hi Volker, On 2014-12-28, Volker Braun wrote: > When starting from scratch I would go with the first option. Cleaner code, > easier to write and debug, and if the coefficient is already a Python > object then the overhead is already bounded by a factor of 2. In fact, a year or two ago, I had experimental code where I did follow the aproach to use Python objects (of course cythoned). It tought me much (about theory), but it wasn't really competitive. > I would use > std::map (that is, a binary tree) instead of > std::list> as underlying data structure > though. Even if you don't want/need associative containers, why linked > lists? Because this is about computing Gröbner bases. So, there is a monomial ordering by which the terms of a polynomial are linearly ordered. That's at #17435. In the yet unpublished branch implementing Gröbner basis computations, I am using the geobucket data structure, which is a bit more complicated than just a linear list, but is better for the typical operations occurring when computing Gröbner bases. > Do you ever insert in the middle? Yes, as follows: > Presumably polynomials are immutable => arrays or std::vector Polynomials get reduced by generators of ideals, so, they aren't immutable, as the lead term will be replaced by other terms, that are inserted in the middle. > Though given that your implementation already exists and (presumably) works > and is well-debugged I wouldn't change it now. Finish it, and if you run > into any performance bottleneck you can explore other options. Yep, that was my plan. First, I had the above-mentioned experimental code, based on the experiments I came up with a paper describing the theory, and now I try to get a competitive implementation. 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] Mathematica interface
On 23 December 2014 at 00:55, Robert Jacobson wrote: > > > On Sunday, 21 December 2014 23:56:24 UTC-5, Dr. David Kirkby (Kirkby > Microwave Ltd) wrote: >> >> There is an open source command line interface to Mathematica. IIRC it >> uses curses so one can recall previous input, edit it and reevaluate. >> >> Dave > > > When I searched for one last week I was surprised not to find anything. Do > you have the link? In any case, such an interface wouldn't be too difficult > to write. I finally found it, after looking on the Wikipedia page for Mathematica, I found the link to "jmath". http://robotics.caltech.edu/~radford/jmath/ I have not used it recently, when when I did, it compiled easily and worked well. In fact, I guess I should use it more, as sometimes I fire Mathematica up just as a quick calculator, without the overhead of the GUI, and jmath does the trick. Dave Dr. David Kirkby Ph.D CEng MIET Kirkby Microwave Ltd Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, UK. Registered in England and Wales, company number 08914892. http://www.kirkbymicrowave.co.uk/ Tel: 07910 441670 / +44 7910 441670 (0900 to 2100 GMT only please) -- 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: Cython: passing a Python data structure as a void pointer
When starting from scratch I would go with the first option. Cleaner code, easier to write and debug, and if the coefficient is already a Python object then the overhead is already bounded by a factor of 2. If that is not fast enough then I would implement the polynomials as C++ templates and specialize to PyObject coefficients as needed. I would use std::map (that is, a binary tree) instead of std::list> as underlying data structure though. Even if you don't want/need associative containers, why linked lists? Do you ever insert in the middle? Presumably polynomials are immutable => arrays or std::vector Though given that your implementation already exists and (presumably) works and is well-debugged I wouldn't change it now. Finish it, and if you run into any performance bottleneck you can explore other options. -- 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: Cython: passing a Python data structure as a void pointer
Hi Nils, On 2014-12-28, Nils Bruin wrote: > That's not immediately clear. An array of pointers is a little more compact > than a linked list, and allocating an array at once should be a little more > efficient than allocating multiple nodes of a linked list. An array of fixed size is no option, because... > The big > advantage of a linked list is that insertion/deletion is fast. If you don't > do that then I think linked lists are not particularly efficient. ... I frequently insert into (and delete items from) the list. > Instantiating a cdef class might have some more overhead compared to simply > mallocing a struct, but that might not be huge. Especially if you > immediately extend PyList via "cdef class elem(list):" (or perhaps PyTuple) > then I'd expect the overhead to be not so big (since python needs > tuple/list instantiation to be lightning fast). I was talking about instantiating the *items* of the list, not the list itself. 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: Cython: passing a Python data structure as a void pointer
On Sunday, December 28, 2014 10:44:51 AM UTC-8, Simon King wrote: > > Hi! > > On 2014-12-28, Jeroen Demeyer > > wrote: > > The idea of Cython is really that you shouldn't need to know the C API > > to write good Cython code. If Cython knows the types of the objects, it > > will generate efficient code. > > Then I wonder what to do at #17435. > > Each term of an element of a path algebra can be encoded in a C struct. > The terms form a list (but I don't need direct access to the n-th item, > all operations either just look at the head of the list or go through all > items of the list). So, there are (at least) two possibilities: > 1. Wrap the C struct into a cdef class, and put the items (i.e., > instances of the class) into a cython list (or tuple). > 2. Do not wrap the C struct, but implement the list as a linked list. > > Am I right that the second approach would perform faster than the first, > since one saves the time to create instances of the cdef class, and > would also save memory? That's not immediately clear. An array of pointers is a little more compact than a linked list, and allocating an array at once should be a little more efficient than allocating multiple nodes of a linked list. The big advantage of a linked list is that insertion/deletion is fast. If you don't do that then I think linked lists are not particularly efficient. Instantiating a cdef class might have some more overhead compared to simply mallocing a struct, but that might not be huge. Especially if you immediately extend PyList via "cdef class elem(list):" (or perhaps PyTuple) then I'd expect the overhead to be not so big (since python needs tuple/list instantiation to be lightning fast). Would you say that taking the second appraoch was a bad idea, and I > should change everything to the first (which would involve a lot of > work, resulting in easier to read code, but I would only do it if the > performance would be competitive!). > I think it's worth an experiment. I think it would be a significant benefit if you can avoid dealing with memory management > 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: Cython: passing a Python data structure as a void pointer
Hi! On 2014-12-28, Jeroen Demeyer wrote: > The idea of Cython is really that you shouldn't need to know the C API > to write good Cython code. If Cython knows the types of the objects, it > will generate efficient code. Then I wonder what to do at #17435. Each term of an element of a path algebra can be encoded in a C struct. The terms form a list (but I don't need direct access to the n-th item, all operations either just look at the head of the list or go through all items of the list). So, there are (at least) two possibilities: 1. Wrap the C struct into a cdef class, and put the items (i.e., instances of the class) into a cython list (or tuple). 2. Do not wrap the C struct, but implement the list as a linked list. Am I right that the second approach would perform faster than the first, since one saves the time to create instances of the cdef class, and would also save memory? Or would you still recommend to take the first approach? At #17435, I took the second approach. One complication: Each term of a path algebra element involves a coefficient, which is a Python object. In the C struct, it appears as a pointer to PyObject, and I need to take care of the reference count. Anyway, prior to #17435, path algebra elements were implemented in Python based on CombinatorialFreeModuleElement, the terms being stored in a dictionary. The second approach above gives, of course, much faster arithmetics than the Python implementation. But the first approach would be faster than the Python implementation, too. Would you say that taking the second appraoch was a bad idea, and I should change everything to the first (which would involve a lot of work, resulting in easier to read code, but I would only do it if the performance would be competitive!). 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: where is the code for __eq__ (of ring elements)
> Nathann, if you're still tens of kilometers away from the nearest pub, you > might want to turn all the info here into proper documentation? Have you considered writing it yourself ? I am already a state employee from Monday to Friday, and with combinatorial designs and the developer's manual I have enough to fill my evenings and week-ends. 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: Place for "internal" documentation of a class
> Is it possible to make sphinx generate html code that is "hidden" with a > toggle button when it encounter a "Technical details::" section? That could > be a good compromise solution. Funny that you ask. This is what I wrote to Sphinx-devel 10 days ago: https://groups.google.com/d/topic/sphinx-users/iu23DxbJmc4/discussion 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: Cython: passing a Python data structure as a void pointer
On 2014-12-27 13:35, Volker Braun wrote: IMHO you should strive to never use direct CPython API in Cython programs. Almost all uses in Sage are just vestiges of older times where Cython wasn't able to do something. But Cython is much more capable nowadays, use it to write clear and expressive programs. +1 The idea of Cython is really that you shouldn't need to know the C API to write good Cython code. If Cython knows the types of the objects, it will generate efficient code. -- 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: python sum question
Sympy implements its own integer type with "math" division: sage: import sympy sage: type(sympy.factorial(int(12))) sage: int(1) / sympy.factorial(int(12)) 1/479001600 On Sunday, December 28, 2014 2:58:55 PM UTC+1, Ralf Stephan wrote: > > On Sunday, December 28, 2014 11:42:57 AM UTC+1, Volker Braun wrote: >> >> In a Python file, (-1)**k and factorial(k) are Python ints, so the >> quotient is C division. >> > > That explains the wrong result and helps me with the ticket, many thanks! > > Presumably, not importing works because there is pyc optimization going on > when factorial is defined in the same file. But it is still mysterious why > importing sympy.factorial will give the correct result. > > 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.
[sage-devel] Re: python sum question
On Sunday, December 28, 2014 11:42:57 AM UTC+1, Volker Braun wrote: > > In a Python file, (-1)**k and factorial(k) are Python ints, so the > quotient is C division. > That explains the wrong result and helps me with the ticket, many thanks! Presumably, not importing works because there is pyc optimization going on when factorial is defined in the same file. But it is still mysterious why importing sympy.factorial will give the correct result. 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.
[sage-devel] Re: where is the code for __eq__ (of ring elements)
Nathann, if you're still tens of kilometers away from the nearest pub, you might want to turn all the info here into proper documentation? On Sunday, December 28, 2014 1:45:26 AM UTC+1, Nils Bruin wrote: > > On Saturday, December 27, 2014 3:13:37 PM UTC-8, Simon King wrote: >> >> That's exactly what I meant: The use of __eq__, __lt__, etc. is >> deprecated in Sage, in favour of using __richcmp__ (of course __cmp__ is >> a different thing). >> > > There is no deprecating of __eq__ or __richcmp__. They appear in different > contexts (python classes vs. cdef classes to be precise). > > In a python class, __eq__, __lt__ etc. are the appropriate methods to > implement and __richcmp__ isn't a special method at all there, so > implementing it will not have much effect. > > In cython, the __eq__ and __lt__ methods aren't special. There, > implementing __richcmp__ does the right thing (cython recognizes the method > name and places it in the relevant slot--the slot that on a python class > would contain a routine that dispatches to __eq__, __lt__ methods). > > I haven't tested it, but I expect that if you put a "class" in a cython > file instead of a "cdef class", you would also find that you need to > implement __eq__ and __lt__, because cython wouldn't be in a position to > place any special routines into slots there. > > Python 3 indicates that in sage we *should* be moving entirely to these > methods. However, historically sage has preferred "cmp". It wouldn't > surprise me that for backwards compatibility one may still need to provide > it, until the remaining bits of sage have transitioned to make use of "rich > comparison". > > >If you implement with 2 underscores, then you bypass the (generic) >> > coercion implementation. You'd want to implement with a single >> underscore >> > to ensure common parents (i.e. _richcm_ or _cmp_). >> >> Is that so? The comments in structure.elements seem to tell something >> else. >> > > A brief browsing of the code indicates that there certainly is the > possibility of implementing these single underscore methods (which is a > sage API), and I would expect that those would indeed be hooks used by the > coercion framework. > -- 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: Place for "internal" documentation of a class
Is it possible to make sphinx generate html code that is "hidden" with a toggle button when it encounter a "Technical details::" section? That could be a good compromise solution. -- 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: python sum question
range() is a list of integers. In a Python file, (-1)**k and factorial(k) are Python ints, so the quotient is C division. On the Sage command line, -1 is preparsed to a Sage integer. So (-1)**k is a Sage integer and factorial(k) is a Python int, and coercion computes the quotient in QQ. On Sunday, December 28, 2014 11:27:45 AM UTC+1, Ralf Stephan wrote: > > Hello, > while working on a ticket I encountered different behaviour of python sum > in Sage regarding whether the sum (over a symbolic expression applied to a > range) > was given on the command line vs. in Sage-lib (python file) within a > function definition. > > Specifically, applying this one-line patch on top of develop: > diff --git a/src/sage/rings/arith.py b/src/sage/rings/arith.py > --- a/src/sage/rings/arith.py > > +++ b/src/sage/rings/arith.py > @@ -5336,6 +5336,7 @@ def subfactorial(n): > > - Jaap Spies (2007-01-23) > """ > +from sage.functions.other import factorial > return factorial(n)*sum(((-1)**k)/factorial(k) for k in range(n+1)) > > will show on the command line: > sage: subfactorial(8) > -120960 > which is wrong but when I define the same function there: > sage: from sage.functions.other import factorial > sage: def subf(n): > return factorial(n)*sum(((-1)**k)/factorial(k) for k in range(n+1 > )) > : > sage: subf(8) > 14833 > > This effect only happens with Python sum/prod. So, what difference does > using Python sum/prod on the command line make vs. in a py file? > > Please help, > > > -- 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] python sum question
Hello, while working on a ticket I encountered different behaviour of python sum in Sage regarding whether the sum (over a symbolic expression applied to a range) was given on the command line vs. in Sage-lib (python file) within a function definition. Specifically, applying this one-line patch on top of develop: diff --git a/src/sage/rings/arith.py b/src/sage/rings/arith.py --- a/src/sage/rings/arith.py +++ b/src/sage/rings/arith.py @@ -5336,6 +5336,7 @@ def subfactorial(n): - Jaap Spies (2007-01-23) """ +from sage.functions.other import factorial return factorial(n)*sum(((-1)**k)/factorial(k) for k in range(n+1)) will show on the command line: sage: subfactorial(8) -120960 which is wrong but when I define the same function there: sage: from sage.functions.other import factorial sage: def subf(n): return factorial(n)*sum(((-1)**k)/factorial(k) for k in range(n+1)) : sage: subf(8) 14833 This effect only happens with Python sum/prod. So, what difference does using Python sum/prod on the command line make vs. in a py file? Please help, -- 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: European H2020 DreamKit proposal around the Sage ecosystem and beyond
On Tue, Dec 23, 2014 at 05:57:15AM -0800, Bill Hart wrote: >I just noticed a spelling error in one of the diagrams (on page 8 of >0). Resources is misspelled ressources. Thanks! Still looking forward much feedback from the community! Note: the proposal file [1] went accidently missing lately. It's back online. Cheers, Nicolas [1] https://github.com/sagemath/grant-europe/raw/master/H2020/proposal.pdf -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- 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.
