Hi,
Le 12/06/2014 21:43, Julien Puydt a écrit :
(1) cvxopt and scipy fail to compile because linear algebra libs aren't
found ;
Point (1) is what bothered me enough with the git checkout to start the
thread, and I'll obviously need to investigate further.
I think I got that part down... I'
Hi all,
*Some background:*
For this ticket http://trac.sagemath.org/ticket/16333, we are working on
some new Sage features that inherit from classes from Gambit
(http://gambit.sourceforge.net/).
This is making good progress (Ted Turocy from gambit is very keen for this
integration and has hel
I take it you are trying to write a Cython class using a shared library
from the Gambit optional package?
Look at the bottom of src/module_list.py, there are already a number of
Cython extensions that are only compiled conditionally.
On Friday, June 13, 2014 11:32:41 AM UTC+1, Vincent Knight
On 13 June 2014 11:40, Volker Braun wrote:
> I take it you are trying to write a Cython class using a shared library
> from the Gambit optional package?
>
That's correct :)
>
>
Look at the bottom of src/module_list.py, there are already a number of
> Cython extensions that are only compiled co
>
> Look at the bottom of src/module_list.py, there are already a number of
>> Cython extensions that are only compiled conditionally.
>>
>
> Thanks!
>
Keep something in mind, however : all the documentation contained in those
files will *not* appear in Sage's online doc. Which means that users
On 13 Jun 2014 12:59, "Nathann Cohen" wrote:
>>>
>>> Look at the bottom of src/module_list.py, there are already a number of
Cython extensions that are only compiled conditionally.
>>
>>
>> Thanks!
>
>
> Keep something in mind, however : all the documentation contained in
those files will *not* ap
> Very helpful: thanks. Is there another way to handle this and/or get around
> it?
I cheated in all cases :
For the optinal LP solvers I don't mind as there is a standard LP
solver that exposes the features :
http://www.sagemath.org/doc/reference/numerical/index.html
For the C libraries solvin
Hi,
Le 12/06/2014 21:43, Julien Puydt a écrit :
(2) ppl compiled.
Point (2)... well... it's not a breakage if it compiles, but last time
it gave issues... so there's still something to understand.
I must say this "ptrdiff_t does not name a type" issue is interesting: I
got rid of it by addi
In C++11 it is unspecified whether ptrdiff_t (and other C typedefs) are
injected into the global namespace or not. GCC is not at fault for
restriciting its scope to only std::ptrdiff_t.
On Friday, June 13, 2014 1:27:34 PM UTC+1, Snark wrote:
>
> Hi,
>
> Le 12/06/2014 21:43, Julien Puydt a écri
Hi,
Le 13/06/2014 14:45, Volker Braun a écrit :
In C++11 it is unspecified whether ptrdiff_t (and other C typedefs) are
injected into the global namespace or not. GCC is not at fault for
restriciting its scope to only std::ptrdiff_t.
Sigh. Then I guess I'll need to open a ticket and write a pa
On 13 June 2014 12:21, Nathann Cohen wrote:
> I cheated in all cases :
>
> For the optinal LP solvers I don't mind as there is a standard LP
> solver that exposes the features :
>
> http://www.sagemath.org/doc/reference/numerical/index.html
>
> For the C libraries solving specfic graph problem th
I'm pretty sure you are on an old version of Sage...
$ git trac find b02fff52f6d55663af31343bfaf3e35c53a9bc14
Commit has been merged in 6.2.rc1.
commit ba423b1c343da22cd342102f6504df044691d0e7
Merge: 069e666 f6df279
Author: Release Manager
Date: Fri Apr 25 19:44:48 2014 +0200
Trac #16208:
Hello !!
> We've actually just thought of a completely different approach that we
> _might_ or _might not_ go with. There are advantages (which include not
> having to deal with this problem at all) and disadvantages that we need to
> carefully consider (if it's of interest the idea is here:
>
On Friday, June 13, 2014 1:52:58 PM UTC+1, Vincent Knight wrote:
>
> from sage.misc.package import is_package_installed
> from cooperative_game import CooperativeGame
> if is_package_installed('gambit'):
> from normal_form_game import *
>
> normal_form_game.py is the module that imports and inh
Le 13/06/2014 15:21, Volker Braun a écrit :
I'm pretty sure you are on an old version of Sage...
git clone git://git.sagemath.org/sage
git checkout -b testjava origin/u/jdemeyer/ticket/14364
How is that old?
Snark on #sagemath
--
You received this message because you are subscribed to the Go
Le 13/06/2014 15:57, Julien Puydt a écrit :
Le 13/06/2014 15:21, Volker Braun a écrit :
I'm pretty sure you are on an old version of Sage...
git clone git://git.sagemath.org/sage
git checkout -b testjava origin/u/jdemeyer/ticket/14364
How is that old?
Eh, that branch is based on 5.13 or s
On Thursday, June 12, 2014 7:05:12 PM UTC-7, Nils Bruin wrote:
>
> And since the arguments get processed already in order to get hashed, it
> would probably be quite doable to process them such that SageElement
> instances get replaced by (elt.parent(), elt), or perhaps better: if
> objects
> p
On Friday, June 13, 2014 6:18:19 PM UTC+1, Nils Bruin wrote:
>
> This is also where we see that FiniteEnumeratedSet is horrible for
> caching: its computation is totally trivial.
>
Thats generally the case for parents. The point is not that constructing a
parent is super-difficult, but that it p
FWIW, I also tend to use the PDF version of the reference manual to hunt
for LaTeX errors in the doc (not only those which break the compilation,
but also semantic ones). In my experience, they are much easier to spot in
the PDF than in the HTML (which also displays badly on older browsers -- I
Dear all,
I am new to Sage development and I'd like some help or advice for the
following task:
There is right now no specific algorithm for computing roots of Sparse
Polynomials in Sage. Such algorithms exist, at least for polynomials
over Z [CuKoiSma99], Q or any finite extension of Q [Len
Hello,
I just bumped into #8740 and remembered about this thread... this
ticket is about upgrading sqlalchemy 0.7.6 while 0.5.8 is the current
one. But the most recent version is 0.9.4. It does not make any sense
to release package for a library that evolves that fast. Instead the
following works
Salut Bruno,
Welcome!
> Now comes my question, which is basically: How to introduce this new
> code into Sage?
Did you already opened a ticket on trac for that?
> More specifically, the "roots()" function is defined in
> rings/polynomial/polynomial_element.pyx where a selection of algorithm
> i
Hello Bruno,
* Bruno Grenet [2014-06-12 13:47:59 +0200]:
> Now comes my question, which is basically: How to introduce this new code
> into Sage?
> [...]
> What I'd like to do is to branch a new algorithm there. So my more specific
> question: Where should the new algorithm go? A solution may be
23 matches
Mail list logo
