Re: [sage-devel] Re: Hard time building sage to review a ticket
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'll have to make a nice ticket with a nice patch... Snark -- 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] How to handle an optional package that causes build crashes
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 helped us by making some tweaks to gambit that make things more straightforward: https://github.com/tturocy/gambit/tree/sage_integration). We have had another ticket reviewed regarding making Gambit an optional package for Sage (http://trac.sagemath.org/ticket/16466) which is also good *Our question:* In our current (very much working) branch (https://github.com/theref/sage-game-theory/tree/16333) we are importing Gambit so as to define the corresponding Sage class. This is all fine (although inheriting from the gambit game class wasn't straightforward) *but* an obvious issue occurs when building Sage without gambit installed. We're wondering what is the *best practice* for dealing with this is. Error handling in the new module is simple enough but doesn't feel like the right way to do it... I'm assuming that there is a way of including conditional build commands in a makefile somewhere (so that the particular piece of game_theory code only compiles if gambit is installed). Is the above the right way to go about this? If it is: could someone perhaps point us in the right direction? (There's very little experience on our side with regards to makefiles etc...). Thanks a lot, Vince -- 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: How to handle an optional package that causes build crashes
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 wrote: > > 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 helped us by making some tweaks to gambit that make > things more straightforward: > https://github.com/tturocy/gambit/tree/sage_integration). > > We have had another ticket reviewed regarding making Gambit an optional > package for Sage (http://trac.sagemath.org/ticket/16466) which is also > good > > *Our question:* > > In our current (very much working) branch ( > https://github.com/theref/sage-game-theory/tree/16333) we are importing > Gambit so as to define the corresponding Sage class. > This is all fine (although inheriting from the gambit game class wasn't > straightforward) *but* an obvious issue occurs when building Sage without > gambit installed. > > We're wondering what is the *best practice* for dealing with this is. > Error handling in the new module is simple enough but doesn't feel like the > right way to do it... > > I'm assuming that there is a way of including conditional build commands > in a makefile somewhere (so that the particular piece of game_theory code > only compiles if gambit is installed). > > Is the above the right way to go about this? > > If it is: could someone perhaps point us in the right direction? (There's > very little experience on our side with regards to makefiles etc...). > > Thanks a lot, > Vince > -- 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: How to handle an optional package that causes build crashes
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 conditionally. > Thanks! -- Dr Vincent Knight Cardiff School of Mathematics Senghennydd Road, Cardiff CF24 4AG (+44) 29 2087 5548 www.vincent-knight.com +Vincent Knight @drvinceknight Skype: drvinceknight -- 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: How to handle an optional package that causes build crashes
> > 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 may not even know that the features are available. That's no problem at all if all that you are caching is internal stuff, but if those classes contain a lot of things meant for users, well... No doc :-/ 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: How to handle an optional package that causes build crashes
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* appear in Sage's online doc. Which means that users may not even know that the features are available. That's no problem at all if all that you are caching is internal stuff, but if those classes contain a lot of things meant for users, well... No doc :-/ Very helpful: thanks. Is there another way to handle this and/or get around it? > > Nathann > > -- > You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/IPRJwPdkuW0/unsubscribe. > To unsubscribe from this group and all its topics, 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-devel] Re: How to handle an optional package that causes build crashes
> 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 solving specfic graph problem there is in every case a method of the Graph class (which appears in the doc). And it either raises an exception when it is called, saying that the package should be installed, or solves the problem in a different way. Whatever you do, add pieces of doc everywhere pointing toward the absent features and explaining how to install them. Nothing better. I would like a way to have the doc appear even in all functions raise an exception, but I don't. If you actually need to inherit from external code, I'm not very optimistic :-/ 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: Hard time building sage to review a ticket
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 adding the following line to build/pkgs/ppl/spkg-install: sed -i -e "s/ptrdiff_t/std::ptrdiff_t/g" `grep -r . -l -e "ptrdiff_t"` It fixes the problem, but leaves me wondering why it's necessary... Snark on #sagemath -- 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: Hard time building sage to review a ticket
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 é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 adding the following line to > build/pkgs/ppl/spkg-install: > sed -i -e "s/ptrdiff_t/std::ptrdiff_t/g" `grep -r . -l -e "ptrdiff_t"` > > It fixes the problem, but leaves me wondering why it's necessary... > > Snark on #sagemath > -- 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: Hard time building sage to review a ticket
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 patch for that too? Snark on #sagemath -- 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: How to handle an optional package that causes build crashes
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 there is in every
> case a method of the Graph class (which appears in the doc). And it
> either raises an exception when it is called, saying that the package
> should be installed, or solves the problem in a different way.
>
> Whatever you do, add pieces of doc everywhere pointing toward the
> absent features and explaining how to install them.
>
Cool, will keep this in mind.
>
> Nothing better. I would like a way to have the doc appear even in all
> functions raise an exception, but I don't. If you actually need to
> inherit from external code, I'm not very optimistic :-/
>
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:
https://github.com/theref/sage-game-theory/issues/48).
With regards to the optional compilation, I might have expressed myself
poorly. We've found another solution. Would adding the following to all.py
in our game_theory folder be 'acceptable' with regards to general Sage
etiquette etc:
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 inherits from gambit.
Thanks,
Vince
--
Dr Vincent Knight
Cardiff School of Mathematics
Senghennydd Road,
Cardiff
CF24 4AG
(+44) 29 2087 5548
www.vincent-knight.com
+Vincent Knight
@drvinceknight
Skype: drvinceknight
--
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: Hard time building sage to review a ticket
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: Make Sage (6.1.1/6.2.beta*) build with GCC 4.9 [http://gcc.gnu.org/gcc-4.9/ GCC 4.9.0] has been released on April 22nd 2014. Due to stricter conformance to the C++ standard, both the current stable release of Sage, 6.1.1, and the current development release, 6.2.beta8, won't build with GCC 4.9. Luckily only two Sage packages, namely Lcalc (1.23) and PPL (1.1), are affected, and small patches which don't change any functionality are sufficient to let Sage build with the new GCC. (The same patch(es) apply to both Sage 6.1.1 and 6.2.beta8.) URL: http://trac.sagemath.org/16208 Reported by: leif Ticket author(s): Leif Leonhardy Reviewer(s): Volker Braun On Friday, June 13, 2014 1:53:10 PM UTC+1, Snark wrote: > > 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 patch for that > too? > > Snark on #sagemath > -- 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: How to handle an optional package that causes build crashes
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:
> https://github.com/theref/sage-game-theory/issues/48).
Well, indeed if you just import functions from the gambit library
inside of your functions then you will have no problem with the doc
:-)
> With regards to the optional compilation, I might have expressed myself
> poorly. We've found another solution. Would adding the following to all.py in
> our game_theory folder be 'acceptable' with regards to general Sage etiquette
> etc:
>
> 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 inherits from gambit.
HMm... Well, I have no idea about Sage's etiquette on this respect :-D
It would be better to import the functions you need inside of each
function, but well.. If it is this or no doc, this is definitely
better ^^;
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: How to handle an optional package that causes build crashes
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 inherits from gambit.
>
You should try to use LazyImport in all.py to keep the startup time under
control. Not everybody is going to want to load the game theory shared
library all the time.
If you aim for a Cython wrapper that is generally useful then you could put
it into sage.libs.gambit and import from there. But if you just want to
import two functions from a big library then I'd hide it away in
sage.game_theory.normal_form_game.
--
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: Hard time building sage to review a ticket
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 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: Hard time building sage to review a ticket
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 something like this : I had misread and thought it was based on a 6.3beta. A simple rebase on 6.3.beta3 should set me straight on the review. Sometimes it shows that I haven't worked on sage in a big while... Snark on #sagemath -- 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: hash for algebraic field
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 > provide a "_cache_key_" method, use its value. > On second thought, doing this would come at significant cost. I was thinking about ArgumentFixer here, but that doesn't normally *recurse* along the arguments (it only reorders arguments between named and positional arguments, based on the function signature--one reason why cached functions should only be defined in module or class scopes: producing cached closures would involve running ArgumentFixer any time a closure is produced. This is going to be horribly expensive, because sage_getargspec will probably end up retrieving the source of the wrapped function. It's also unnecessary, because the closure that gets wrapped wouldn't normally change its signature at runtime anyway. Of course, we can make a version of ArgumentFixer that does walk its arguments, recursing through tuples and replacing entries v by v._cache_key_(), if that method is available, but doing that will be quite costly (although probably comparable in cost to the computation of the hash value for lookup in the cache and the comparison should a hit be found in the cache). In practice, interesting cached functions will have fairly simple inputs and outputs but an expensive computation process in between, so the cost may well be manageable. This is also where we see that FiniteEnumeratedSet is horrible for caching: its computation is totally trivial. All the complexity is in its arguments (which, modulo trivial wrapping, is also the result). UniqueRepresentation is clearly a poor fit for it. You should only use it if you absolutely must shoehorn the concept of a finite set into the coercion framework (it's the coercion framework for which the "unique parent" rule is important). -- 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: hash for algebraic field
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 provides an object that plays nicely with the rest of Sage and is a natural point at which to attach more functionality (which can then be costly to compute). Finitely presented groups are parents, construction is trivial, but investigating their properties is not. -- 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: PDF manual Vs proper documentation of categories
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 had to install chromium on my virtual ubuntu because firefox wouldn't show the tex at all). Other than this, I don't remember using the PDF manual for anything; I could imagine it being easier to search for specific keywords than the HTML manual (because e.g. all of sage-combinat is a single PDF file), but I guess that could be gotten for a better price. I agree that we shouldn't let the vagaries of LaTeX keep up Sage development. -- 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] Faster roots computation for Sparse Polynomial
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 [Len99], F_p [BiCheRo13] and R [Sag14]. For instance, the first two algorithms are polynomial-time algorithms in the sparse size of the polynomial. I have implemented the first algorithm (over Z). My implementation is certainly not be perfect, but at least I am able to compute the integer roots of polynomials of degree ~100 000 with ~5000 nonzero monomials in less than .1s (on my laptop). The current algorithms in Sage are totally unable to handle such polynomials. Now comes my question, which is basically: How to introduce this new code into Sage? More specifically, the "roots()" function is defined in rings/polynomial/polynomial_element.pyx where a selection of algorithm is made. If I understand correctly, for a polynomial over ZZ (be it sparse or not), the selection goes through the condition "K.is_integral_domain()" (line 5799) and then the roots are computing using "_roots_from_factorization" (line 5809). There, factoring the input polynomial is (in my cases) hopeless due to its degree. 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 to have somewhere a specific code for the sparse polynomials over ZZ, and there put a a function roots(self,multiplicities=True) to avoid going into the "big" roots function from rings/polynomial/polynomial_element.pyx. I have side questions, which may improve my code (or my tests): - S.random_element() for S a sparse_polynomial ring return by defaut a degree-2 polynomial. For sparse polynomials, wouldn't it make sense to return a polynomial of "high" degree (to be determined) but with "few" nonzero monomials? Again, I have a code for that that I can include. - How exactly is stored a Sparse Polynomial? I tried to follow the "__init__" functions but I was unable to finally understand the real representation of these objects. I suspect this is a dictionary (or something approaching) with the keys being the exponents and the values being the coefficients. In such case, what is the fastest way to access these elements? - The algorithm I implemented uses some auxiliary functions that are not of real interest outside the algorithm. How should I do to avoid this functions be available for the users? Thanks in advance! Bruno Grenet === References: [CuKoiSma99] F. Cucker, P. Koiran, and S. Smale. A polynomial time algorithm for Diophantine equations in one variable. /J. Symb. Comput./, 27(1):21--30, 1999. [Len99] H. Lenstra Jr. On the factorization of lacunary polynomials. In /Number theory in progress/, pages 277--291. De Gruyter, 1999. [BiCheRo13] J. Bi, Q. Cheng, and J. M. Rojas. /Sub-Linear Root Detection, and New Hardness Results, for Sparse Polynomials Over Finite Fields/. In Proc. ISSAC, 2013. arXiv:1204.1113. [Sag14] M. Sagraloff. A/Near-Optimal Algorithm for Computing Real Roots of Sparse Polynomials./ In Proc. ISSAC, 2014. arXiv:1401.6011 -- 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] vote: include pip with sage
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 perfectly
{{{
sage -sh
easy_install pip
pip install sqlalchemy==0.9.4
}}}
Vincent
--
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] Faster roots computation for Sparse Polynomial
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 > is made. If I understand correctly, for a polynomial over ZZ (be it > sparse or not), the selection goes through the condition > "K.is_integral_domain()" (line 5799) and then the roots are computing > using "_roots_from_factorization" (line 5809). There, factoring the > input polynomial is (in my cases) hopeless due to its degree. > > 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 > to have somewhere a specific code for the sparse polynomials over ZZ, > and there put a a function roots(self,multiplicities=True) to avoid > going into the "big" roots function from > rings/polynomial/polynomial_element.pyx. Right now there are several implementation for polynomials with integer coefficients... but only a very generic one is sparse. I guess a first start would be to add your implementation directly in "Polynomial_generic_sparse" in sage/rings/polynomial/polynomial_generic_element.py. There is no much data structure in a polynomial so it will be easy to switch from one place to another. Maybe, somebody might have a better idea here. > I have side questions, which may improve my code (or my tests): > > - S.random_element() for S a sparse_polynomial ring return by defaut a > degree-2 polynomial. For sparse polynomials, wouldn't it make sense to > return a polynomial of "high" degree (to be determined) but with "few" > nonzero monomials? Again, I have a code for that that I can include. It is possible to add extra arguments for random_element. In that case max_degree, density (a number between 0 and 1), distribution would make sense. That can be an independent prerequisite ticket "Improve random generation of sparse polynomial". > - How exactly is stored a Sparse Polynomial? I tried to follow the > "__init__" functions but I was unable to finally understand the real > representation of these objects. I suspect this is a dictionary (or > something approaching) with the keys being the exponents and the values > being the coefficients. In such case, what is the fastest way to access > these elements? Just have a look at the code of polynomial/polynomial_element_generic.py. You see that self.__coeffs is a dictionnary. But the code is rather old and, as far as I know, not much used. > - The algorithm I implemented uses some auxiliary functions that are not > of real interest outside the algorithm. How should I do to avoid this > functions be available for the users? Just do not import them in the global namespace. If they belong to some module in sage/rings/polynomial this is just fine. Vincent -- 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] Faster roots computation for Sparse Polynomial
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 to have > somewhere a specific code for the sparse polynomials over ZZ, and there put > a a function roots(self,multiplicities=True) to avoid going into the "big" > roots function from rings/polynomial/polynomial_element.pyx. Since your algorithm is specific to the ring Z your code should probably go there. A ring can define a method _roots_univariate_polynomial() which will be called by the generic method roots(). There you could check whether the polynomial is sparse and use the algorithm you implemented or the generic _roots_from_factorization(). > I have side questions, which may improve my code (or my tests): > > [...] > - The algorithm I implemented uses some auxiliary functions that are not of > real interest outside the algorithm. How should I do to avoid this functions > be available for the users? If you turn these auxiliary functions into methods of the ring Z, you can hide them by adding a single (or double but many people dislike this) underscore to the method name. If they are only used by your method to compute roots, you could probably name these methods _roots_from_factorization_method_name(). julian pgpNzbrQiU2nW.pgp Description: PGP signature
