I was going to write an email saying essentially the same thing as
Nathann, so no point to repeat it. But he makes some *very important*
points.
You should really follow this advice, too many times these external
projects fail to become part of Sage because of not following proper
I think it would also be a good idea to get in contact with the matroids
folk who got a lot of code integrated into Sage some time ago.
Or even better with Eric Gourgoulhon whos currently writing a lot of code
for his project and getting it integrated into Sage piece by piece.
On top of that
Hi sage-devel
This is to announce and get some feedback on the start of a Sage
software-development project.
This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for
hiring a full-time software developer for two years to work on extending
the coding theory functionality in
Let me add one more thing:
The goal should be to have code with *positive_review*, not just to have
code. There is no point in continuing to produce more code if there are
10 needs_work tickets.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
In C99 it's possible to do dynamic allocation of multidimensional arrays:
void blah(int n) {
int a[n][n];
...}
but this does not seem to be supported in Cython. If I try
sage -cython on
def t(int n):
cdef int a[n][n]
cdef int i, j
for i in range(n):
for j in range(n):
C99 VLA are not dynamically allocated, they exhaust the static stack rather
quickly. If you are writing the C part of the code yourself it is in the
long run almost certainly better to put matrices on the heap. If you have a
maximal size for arrays you could use that as static bound. Or replace
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
C99 VLA are not dynamically allocated, they exhaust the static stack rather
quickly. If you are writing the C part of the code yourself it is in the
long run almost certainly better to put matrices on the heap. If you have a
maximal
On 2014-10-16, Dima Pasechnik dimp...@gmail.com wrote:
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
C99 VLA are not dynamically allocated, they exhaust the static stack rather
quickly. If you are writing the C part of the code yourself it is in the
long run almost certainly
It would be easy enough to use a matrix class instead of VLAs, e.g. slap on
#include boost/numeric/ublas/matrix.hpp
using namespace boost::numeric::ublas;
and replace int a[n][n] with matrixint a(n, n) and a[i][j] with a(i,j).
If you just want to pass in an array into your C99 code
Thanks for the feedback everyone! I'll try to comment on some of the things
mentioned.
Indeed. I do not know if what you have in mind about coding theory somehow
overlaps with combinatorial designs (in particular orthogonal arrays/BIBD
:-P) but it would be nice to shake those areas of Sage
On Thu, Oct 16, 2014 at 8:37 AM, Johan S. R. Nielsen
santaph...@gmail.com wrote:
Once more: please, don't try to shortcut the review process. Play it fair.
Don't develop everything in your office only to come back later expecting us
to merge everything at once without reviewing it. Please
Repost from sage-coding-theory, by Daniel Augot:
This is great news! Is there any plan to implement semaphore codes in the
near future (see the book by Jean Berstel
http://www.goodreads.com/author/show/399140.Jean_Berstel, Dominique
Perrin
On 2014-10-16 17:37, Johan S. R. Nielsen wrote:
Totally agree! But there might well be 10 needing_review tickets :-)
That would not be good either, but you cannot blame the author if that
happens (unless reviewers actually post comments and they are ignored).
Jeroen.
--
You received this
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
It would be easy enough to use a matrix class instead of VLAs, e.g. slap on
#include boost/numeric/ublas/matrix.hpp
using namespace boost::numeric::ublas;
and replace int a[n][n] with matrixint a(n, n) and a[i][j] with
On Thursday, October 16, 2014 8:31:20 PM UTC+1, Dima Pasechnik wrote:
Strange that Cython does not allow a proper cast, to (int (*)[])).
Considering that Cython doesn't allow VLAs its probably not surprising.
Just make a C macro for the cast. Or lie to Cython
ctypedef int* vlamatrix (int
See http://stackoverflow.com/questions/26409854/ My sense is that NaN isn't
real, but maybe it is in an IEEE 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
sage: RR('nan')
NaN
Its one of the possible elements of RR, but not ZZ.
On Thursday, October 16, 2014 9:55:05 PM UTC+1, kcrisman wrote:
See http://stackoverflow.com/questions/26409854/ My sense is that NaN
isn't real, but maybe it is in an IEEE framework?
--
You received this message
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
On Thursday, October 16, 2014 8:31:20 PM UTC+1, Dima Pasechnik wrote:
Strange that Cython does not allow a proper cast, to (int (*)[])).
Considering that Cython doesn't allow VLAs its probably not surprising.
Just make a C macro for
On 2014-10-16, Dima Pasechnik dimp...@gmail.com wrote:
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
On Thursday, October 16, 2014 8:31:20 PM UTC+1, Dima Pasechnik wrote:
Strange that Cython does not allow a proper cast, to (int (*)[])).
Considering that Cython doesn't allow
Ok, the ctypedef is the wrong thing. Declaring a fake function that is a
cast on the C side is the way to go:
cdef extern from foo.h:
int* vla_cast (int (*)[]) (int*)
int foo(int n, int* a)
cpdef pyfoo():
cdef int data[9]
print foo(3, vla_cast(data))
On Thursday, October
20 matches
Mail list logo
