[sage-devel] Re: FGb - Gröbner basis computation code

Le mercredi 4 mai 2016 23:00:23 UTC+2, john_perry_usm a écrit : > > > Unfortunately Roman doesn't mention on that page whether he used > Singular's std() or dstd(). The numbers look vaguely std()ish to me (i.e., > when I compute the GB of Cyclic-8 using std(), it takes about 40 seconds; >

Re: [sage-devel] Sage failes to compile on Arch Linux

Looking at the log his base gcc is 5.3. The only reason for sage to attempt building gcc 4.9.3 is if he is missing g++ or gfortran. François > On 5/05/2016, at 15:21, Nils Bruin wrote: > > I noticed this line in your log: > > ar: >

[sage-devel] Re: Sage failes to compile on Arch Linux

I noticed this line in your log: ar: /home/kjs/Software/sage/local/var/tmp/sage/build/gcc-4.9.3.p1/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so) I've run into this

Re: [sage-devel] Re: FGb - Gröbner basis computation code

On Wed, May 4, 2016 at 5:17 PM, Luca De Feo wrote: >> Can you also ask him about the license? > > > You can read here http://www-polsys.lip6.fr/~jcf/FGb/Maple/tutorial-fgb.pdf > that "FGb is freely distributed for academic use only". The question has > been asked

[sage-devel] Re: FGb - Gröbner basis computation code

> > Can you also ask him about the license? > You can read here http://www-polsys.lip6.fr/~jcf/FGb/Maple/tutorial-fgb.pdf that "FGb is freely distributed for academic use only". The question has been asked often: publishing the sources is out of question. -- Luca -- You received this

[sage-devel] Re: sage -i database_gap fails to install

this most probably means that you are trying to use a binary release, and it is broken... Build Sage from source instead. On Wednesday, May 4, 2016 at 8:55:13 PM UTC+1, Graham Gerrard wrote: > > Attempted to install the GAP database for 16.04 version of Sage-7.1, > 16.04 Ubuntu, and produced

[sage-devel] Re: FGb - Gröbner basis computation code

On Wednesday, May 4, 2016 at 3:14:16 PM UTC-5, parisse wrote: > > > Perhaps you should have a look at the link I've posted, there is a > comparison of mgb with magma, singular and my own system giac (for which > there is an optional package in sage), mgb is not open source while > singular and

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 1:07 PM, Johan S. R. Nielsen wrote: > Michael Orlitzky writes: >> I have a matrix m... how come, >> >> * m.rank gives me bullshit >> * m.rank() works >> * m.T() crashes >> * m.T works? > > This is in my mind the most compelling reason to phase

[sage-devel] Re: FGb - Gröbner basis computation code

Le mercredi 4 mai 2016 12:05:04 UTC+2, mmarco a écrit : > > Can you also ask him about the license? > > Also, has somebody done timing comparisons with singular? > > Perhaps you should have a look at the link I've posted, there is a comparison of mgb with magma, singular and my own system

[sage-devel] Deprecate the use of properties in all public API

Michael Orlitzky writes: > I have a matrix m... how come, > > * m.rank gives me bullshit > * m.rank() works > * m.T() crashes > * m.T works? This is in my mind the most compelling reason to phase out properties in Sage. I think Erik makes many good points, but ultimately I think

[sage-devel] sage -i database_gap fails to install

Attempted to install the GAP database for 16.04 version of Sage-7.1, 16.04 Ubuntu, and produced error ImportError: /home/graham/SageMath/local/lib/python2.7/site-packages/sage/rings/complex_double.so: undefined symbol: gsl_complex_sin Log attached. Graham -- You received this message

[sage-devel] default 3d plot implementation of vector

I'm sure there is a specific reason that line3d is used here: https://github.com/sagemath/sage/blob/master/src/sage/modules/free_module_element.pyx#L2307, but from what I can tell arrow would also work. Using arrow would allow for the option of arrowsize, among other arrow specific options,

[sage-devel] Deprecate the use of properties in all public API

William Stein writes: > Unless the above messed up dichotomy is fixed in every possible way > people might use Sage interactively, I'm personally 100% against using > properties for objects users interact with at the top level. They > have only snuck in in a couple of places because I wasn't

[sage-devel] Re: symbolic_poly(matrix) : bug report in linear algebra quickref!

Well, it might have worked in 2011! ;-) I guess this QuickRef could use a review and update. Even better would be a way to doctest these and have them routinely tested as part of the usual development process. I'll give the later some thought if/when I tackle the former. Rob On Wednesday,

[sage-devel] symbolic_poly(matrix) : bug report in linear algebra quickref!

It (column 2 of [1]) says this should work (see [2] below also), but it doesn't: A = matrix(QQ, [[1,2],[3,4]]) f(x) = x^3 - 2*x + 1 f(A) # FAIL -- this is maybe a bug though (the quickref says it should work) Making f an actual polynomial (not symbolic) works. [1]

[sage-devel] Re: Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

Johan S. R. Nielsen wrote: > [X] Phase out properties that might (expectedly) throw exceptions, such > as Matrix.I. Condone the use of properties as "getters" of derived > information, such as Matrix.T (transpose). -- Marc -- You received this message because you are subscribed to the

Re: [sage-devel] Deprecate the use of properties in all public API

On May 4, 2016 5:49 PM, "Erik Bray" wrote: > > On Wed, May 4, 2016 at 4:28 PM, William Stein wrote: > > On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote: > >> On Wed, May 4, 2016 at 4:06 PM, William Stein wrote: >

Re: [sage-devel] Deprecate the use of properties in all public API

On Wednesday, May 4, 2016 at 3:13:21 PM UTC+2, Erik Bray wrote: > > I don't think it's just "syntactic sugar". If anything it's setter > and *especially* getter methods that are backwards, but unfortunately > necessary in languages like Java that don't have a natural way to > interpose in

Re: [sage-devel] Deprecate the use of properties in all public API

I see. However, as I said before, there are good reasons why that is not the default behaviour. El miércoles, 4 de mayo de 2016, 17:50:41 (UTC+2), Volker Braun escribió: > > On Wednesday, May 4, 2016 at 5:26:03 PM UTC+2, mmarco wrote: >> >> Overall, I think that the problem with documentation

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 5:26 PM, mmarco wrote: > That is a good example of why using @property might fit bad with the usual > sage workflow. On the other hand, there are other examples that could show > how it actually might fit better: > > > sage: n = matrix(QQ, 2) > sage:

Re: [sage-devel] Deprecate the use of properties in all public API

On Wednesday, May 4, 2016 at 5:26:03 PM UTC+2, mmarco wrote: > > Overall, I think that the problem with documentation is worse than the > gain with tab-completion, but it would be so nice if we could do something > like: > sage: n.transpose().[tab] > You can do that already: sage: n =

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 4:28 PM, William Stein wrote: > On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote: >> On Wed, May 4, 2016 at 4:06 PM, William Stein wrote: >>> On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote:

Re: [sage-devel] Deprecate the use of properties in all public API

That is a good example of why using @property might fit bad with the usual sage workflow. On the other hand, there are other examples that could show how it actually might fit better: sage: n = matrix(QQ, 2) sage: n.T.[tab] And the user gets the list of the methods he can call on the traspose

Re: [sage-devel] Deprecate the use of properties in all public API

On 05/04/2016 09:13 AM, Erik Bray wrote: > > I call it premature encapsulation. > We can agree there. But when you're programming on a team, the hardest part is making sure everyone else doesn't do anything stupid. And in the Java/C# world, half of the team is 22 years old and writing their

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote: > On Wed, May 4, 2016 at 4:06 PM, William Stein wrote: >> On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote: >> [...] >>> Anyways we can agree to disagree on this, and even within the

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 4:06 PM, William Stein wrote: > On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote: > [...] >> Anyways we can agree to disagree on this, and even within the Python >> community you'll find different opinions, especially regarding

Re: [sage-devel] Deprecate the use of properties in all public API

On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote: [...] > Anyways we can agree to disagree on this, and even within the Python > community you'll find different opinions, especially regarding things > like how much calculation should be done in the getter of a property, > or

Re: [sage-devel] Re: FGb - Gröbner basis computation code

Hi, On Wed, May 04, 2016 at 03:05:03AM -0700, mmarco wrote: > Also, has somebody done timing comparisons with singular? According to the following ask question, it is much slower at least on a given concrete example

Re: [sage-devel] Deprecate the use of properties in all public API

On Tue, May 3, 2016 at 4:25 PM, Michael Orlitzky wrote: > On 05/03/2016 09:22 AM, Erik Bray wrote: >> >> You seem to have this view that the sole purpose of getter and setter >> methods is to update a private member of some object. Am I >> understanding that correctly?

[sage-devel] Re: On development workflows for sharing (experimental) code

Thank you Nicolas for this page which is very instructive. I've added some comments on SageManifolds workflow. Best wishes, 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

[sage-devel] Re: FGb - Gröbner basis computation code

Can you also ask him about the license? Also, has somebody done timing comparisons with singular? El miércoles, 4 de mayo de 2016, 10:25:42 (UTC+2), Luca De Feo escribió: > > I was also thinking about writing an interface to FGb. Maple uses this > library via the C API to compute Gröbner bases.

[sage-devel] Re: FGb - Gröbner basis computation code

Le mercredi 4 mai 2016 10:25:42 UTC+2, Luca De Feo a écrit : > > I was also thinking about writing an interface to FGb. Maple uses this > library via the C API to compute Gröbner bases. As far as I know Magma uses > an older version of this code too. So it must be doable. > > > Maple will

[sage-devel] Re: FGb - Gröbner basis computation code

I was also thinking about writing an interface to FGb. Maple uses this library via the C API to compute Gröbner bases. As far as I know Magma uses an older version of this code too. So it must be doable. I spoke to the author, and he is positive about an interface into Sage. If we find