Hi,
Le 20/02/2015 01:07, Volker Braun a écrit :
On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote:
Sage's libgap and cddlib are problems : they correspond to upstreams
That is not correct, there is no upstream library interface to gap. So
there is no conflict. However, Debian i
Am Donnerstag, 19. Februar 2015 21:40:05 UTC+1 schrieb Simon King:
>
> Hi François,
>
> On 2015-02-19, François Bissey <...> wrote:
> > I am fairly sure introspection is looking for files under SAGE_SRC
> > rather than where the sage library is installed and that experiment is
> > consistent wi
Seen on social media:
> Just got the surname "Math", to disambiguate with other Sages out there.
> Friends still call me "Sage", though
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani
wrote:
> On 19 February 2015 at 18:05, Julien Puydt wrote:
>>
>> All distributions have thousands of packages, and deps are not a big
>> issue. Sage-the-distribution has about a hundred, and it's a big issue.
>
>
> This is something I have faile
On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote:
>
> Sage's libgap and cddlib are problems : they correspond to upstreams
That is not correct, there is no upstream library interface to gap. So
there is no conflict. However, Debian invented a gap-library package.
--
You receive
Le 19/02/2015 22:15, Francois Bissey a écrit :
But some of us would like to be given some consideration.
+1
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,
On Thursday, February 19, 2015 at 1:22:12 PM UTC-8, Michael Orlitzky wrote:
>
> Libc was an extreme example -- gd/dvipng are more mundane. Sage ships a
> gd spkg, and sage uses dvipng but doesn't ship an spkg for it. The
> problem? dvipng links against gd. But since dvipng comes from my system,
On 02/19/2015 03:49 PM, Julien Puydt wrote:
> Le 19/02/2015 18:54, Michael Orlitzky a écrit :
>> This presupposes that the status quo is not madness. My sage builds work
>> for about two weeks before some invisible dependency update breaks them.
>> There's a line in sage beyond which we just don't
> On 20/02/2015, at 06:54, Michael Orlitzky wrote:
>
> On 02/19/2015 11:24 AM, Jeroen Demeyer wrote:
>> On 2015-02-19 16:55, Michael Orlitzky wrote:
>>> It's not incompatibility with Debian that's the problem. Having
>>> dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
>>>
Hi Nils,
On 2015-02-19, Nils Bruin wrote:
> Doesn't the second (local) ordering violate the "usual" part? You would
> have 1>x>x^2>... etc., which is not allowed according to, for instance, the
> definition in [Section 15.2 in Eisenbud, Commutative Algebra with a view
> towards Algebraic Geome
Le 19/02/2015 18:54, Michael Orlitzky a écrit :
This presupposes that the status quo is not madness. My sage builds work
for about two weeks before some invisible dependency update breaks them.
There's a line in sage beyond which we just don't care about
dependencies. We ship gcc, some utilities,
On Thursday, February 19, 2015 at 12:10:05 PM UTC-8, Simon King wrote:
>
> Hi Nils,
>
> On 2015-02-19, Nils Bruin > wrote:
> > Don't all term orderings (in the usual sense) produce the same ordering
> on
> > a univariate polynomial ring?
>
> No. You can have x>1 or x<1 (i.e., a global or a loc
Hi François,
On 2015-02-19, François Bissey wrote:
> I am fairly sure introspection is looking for files under SAGE_SRC
> rather than where the sage library is installed and that experiment is
> consistent with that.
When removing the source file one can not really expect that source
inspection
On 02/20/15 09:21, Simon King wrote:
Hi Antonio,
On 2015-02-19, Antonio Rojas wrote:
I tried with a downloaded binary package to make sure it's not caused by
our packaging, and can still reproduce:
- Remove src/sage/rings/finite_rings/finite_field_base.pyx
- Run:
sage: K=GF(5)
sage:
Hi Antonio,
On 2015-02-19, Antonio Rojas wrote:
> I tried with a downloaded binary package to make sure it's not caused by
> our packaging, and can still reproduce:
>
> - Remove src/sage/rings/finite_rings/finite_field_base.pyx
> - Run:
>sage: K=GF(5)
>sage: K.factored_order()
>
> does
Simon King wrote:
>
> In two experiments with Sage-6.5.beta4, I can not replicate the
> problem.
>
Hi,
I tried with a downloaded binary package to make sure it's not caused by
our packaging, and can still reproduce:
- Remove src/sage/rings/finite_rings/finite_field_base.pyx
- Run:
sage: K
Hi Simon,
Le 19/02/2015 20:44, Simon King a écrit :
Hi Bruno,
On 2015-02-19, Bruno Grenet wrote:
It would definitely make sense to me to have a simpler way to obtain the
same result as above, for instance with the simpler invocation:
sage: R. = PolynomialRing(QQ, order='neglex')
To me it wo
Hi Nils,
On 2015-02-19, Nils Bruin wrote:
> Don't all term orderings (in the usual sense) produce the same ordering on
> a univariate polynomial ring?
No. You can have x>1 or x<1 (i.e., a global or a local ordering).
Cheers,
Simon
--
You received this message because you are subscribed to t
Hi Antonio,
On 2015-02-19, Simon King wrote:
> On 2015-02-19, Antonio Rojas wrote:
> I could try to make some experiments (e.g., create a cython module with
> a cached method, recompile sage, and then remove the source of the
> module) in order to find out if there is a way around (and if I can
On 02/20/15 08:48, Simon King wrote:
Hi Antonio,
On 2015-02-19, Antonio Rojas wrote:
Version 6.5. Note the "if the cython source is not available" part, it works
OK if the .pyx source is installed (we currently package it separately in
Arch)
That makes sense to me. cached_method wraps a meth
On Thursday, February 19, 2015 at 10:29:08 AM UTC-8, Jakob Kroeker wrote:
>
> >If you want
> >to use different term orderings or a localisation, you should construct
> >a "multivariate polynomial ring with a single variable" (I know, this it
> >sounds silly and is not obvious).
>
> @Simon
> As
Hi Antonio,
On 2015-02-19, Antonio Rojas wrote:
> Version 6.5. Note the "if the cython source is not available" part, it works
> OK if the .pyx source is installed (we currently package it separately in
> Arch)
That makes sense to me. cached_method wraps a method, i.e., it replaces
it by somet
Hi Bruno,
On 2015-02-19, Bruno Grenet wrote:
> It would definitely make sense to me to have a simpler way to obtain the
> same result as above, for instance with the simpler invocation:
>
> sage: R. = PolynomialRing(QQ, order='neglex')
>
> To me it would make sense to return a libsingular multiv
Vincent Delecroix wrote:
> Which Sage version are you using? The following code is ok for me on
> sage-6.6.beta0
>
> sage: K=GF(5)
> sage: K.factored_order()
> 5
>
> Vincent
>
Version 6.5. Note the "if the cython source is not available" part, it works
OK if the .pyx source is installed (we c
On Feb 18, 2015, at 04:13 , William Stein wrote:
> Hi Sage Developers,
>
> Several people and events have suggested to me that the official name
> of "Sage" should be filled out to be "SageMath", like the website url
> (which is sagemath.org and has been since I bought it in 2006).One
> moti
Which Sage version are you using? The following code is ok for me on
sage-6.6.beta0
sage: K=GF(5)
sage: K.factored_order()
5
Vincent
2015-02-19 20:00 UTC+01:00, Antonio Rojas :
> Hi,
> Cached methods in cython modules don't work if the cython source is not
> available:
>
> sage: K=GF(5)
> sage
Hi,
Cached methods in cython modules don't work if the cython source is not
available:
sage: K=GF(5)
sage: K.factored_order()
---
AttributeErrorTraceback (most recent call last)
[...]
AttributeErr
Hi Simon,
PLEASE DON'T DO THIS, unless you know what you are doing! Reason: If you
use the various boilerplate polynomial ring constructors directly, you
might break the cache and create several distinct instances of "the
same" polynomial ring, which has a high probability of confusing the
coerc
Hi Jakob,
On 2015-02-19, Jakob Kroeker wrote:
> As state above, the ordering is _silently_ ignored. Thus it is a bug from
> my point of view.
Would it make sense to return a libsingular multivariate polynomial ring
whenever the number of variables is explicitly prescribed OR an ordering
is pres
Hi Bruno,
On 2015-02-19, Bruno Grenet wrote:
> My impression is that Enrique is right: in the constructor
> PolynomialRing, for univariate polynomial rings the argument `order`
> seem indeed to be ignored:
Yes, see my previous post.
> A possibility could be to define a *multivariate* polynomi
>If you want
>to use different term orderings or a localisation, you should construct
>a "multivariate polynomial ring with a single variable" (I know, this it
>sounds silly and is not obvious).
@Simon
As state above, the ordering is _silently_ ignored. Thus it is a bug from
my point of view.
Hi Enrique,
On 2015-02-19, Enrique Artal wrote:
>> >This is not really an issue, the problem is the fact that the=20
>> function=20
>> >accept the entry *order* but it ignores it silently.=20
>>
>> Ahm, why do you think it is ignored?=20
>>
> I have rechecked that =20
> *R.=3DPolynomialRi
Le 18/02/2015 18:35, Jeroen Demeyer a écrit :
On 2015-02-18 17:59, Bruno Grenet wrote:
It would be nice for both Debian and Sage to have Sage
included in Debian.
Nice, yes, but not at any cost. There are advantages, but we should
also consider the disadvantages.
Just to put it simply, I've h
Le 19/02/2015 19:14, Bruno Grenet a écrit :
Le 18/02/2015 18:35, Jeroen Demeyer a écrit :
On 2015-02-18 17:59, Bruno Grenet wrote:
It would be nice for both Debian and Sage to have Sage
included in Debian.
Nice, yes, but not at any cost. There are advantages, but we should
also consider the
On Thursday, February 19, 2015 at 9:53:18 AM UTC-8, Bruno Grenet wrote:
>
>
> And `PolynomialRing`s are *univariate* polynomial rings, without an order
> argument.
>
Indeed, because different term orders are generally uninteresting on
univariate polynomial rings, unless we're allowing term or
On 02/19/2015 11:24 AM, Jeroen Demeyer wrote:
> On 2015-02-19 16:55, Michael Orlitzky wrote:
>> It's not incompatibility with Debian that's the problem. Having
>> dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
>> UTC-5" leads to madness.
> Why madness?
If you try to have sa
Dear all,
> 2. When doing some test for the above problem I realize that
*R.=PolynomialRing(QQ,order='neglex')
>*does not take into account the order (the above *f* is not a
unit).
Yes, it is, since the ring is in fact localised.
>This is not really an issue,
On 19 February 2015 at 18:05, Julien Puydt wrote:
>
> All distributions have thousands of packages, and deps are not a big
> issue. Sage-the-distribution has about a hundred, and it's a big issue.
>
This is something I have failed to understand so far. What is it that makes
Sage require such spec
I did not know this ticket but it is a related problem. I guess, following
also Simon, that the best choice is to create something like
LocalPolynomialRing admitting local orderings since even if all the
algorithms can be performed inside the polynomials (as Singular does) the
actual rings are
Hi,
Le 19/02/2015 17:29, William Stein a écrit :
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer wrote:
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5"
On Thursday, February 19, 2015 at 8:46:19 AM UTC-8, Enrique Artal wrote:
>
> For the first one, it was already reported, with an open ticket, but I am
> worried about it since it produces wrong outputs. The problem appears
> working with polynomial rings with local orders, e.g.,
> *R.=Polynomial
Hi Simon,
Thanks for the feedback
El jueves, 19 de febrero de 2015, 18:23:27 (UTC+1), Simon King escribió:
>
> Hi Enrique,
>
> On 2015-02-19, Enrique Artal > wrote:
> >1. For the first one, it was already reported, with an open ticket,
> but
> >I am worried about it since it produces w
Hi Enrique,
On 2015-02-19, Enrique Artal wrote:
>1. For the first one, it was already reported, with an open ticket, but
>I am worried about it since it produces wrong outputs.
If there is an open ticket for it, then there is no need to report it
again. However, if it gives wrong result
Le 19/02/2015 15:21, Jeroen Demeyer a écrit :
On 2015-02-19 12:56, Julien Puydt wrote:
Well, examples exist where poor choices have been made which make(made)
it harder for other projects.
From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed
a two
On 2015-02-19, Michael Orlitzky wrote:
> On 02/19/2015 09:21 AM, Jeroen Demeyer wrote:
>>
>>> I don't think software was ever delayed for debian.
>> If people are against #16997 because it's not compatible with Debian,
>> then Debian is *already* slowing down Sage.
>>
>
> It's not incompatibili
Hi all,
I have found several small bugs. They are unrelated but since I am not
really able to solve them I put everything in the same message, hoping
someone smarter than me will find the solution.
1. For the first one, it was already reported, with an open ticket, but
I am worried about
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer wrote:
> On 2015-02-19 16:55, Michael Orlitzky wrote:
>>
>> It's not incompatibility with Debian that's the problem. Having
>> dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
>> UTC-5" leads to madness.
>
> Why madness?
>
> It
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5" leads to madness.
Why madness?
It has been done before (#9343) and it worked just fine.
Waiting forever unt
Le 19/02/2015 16:30, Volker Braun a écrit :
worked for me...
Sigh... still doesn't... so there's a problem on my end :-(
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,
Hi,
Regarding third-party packaging, etc., what's the status of the Sage
Ubuntu PPA from AIMS?
Because of SageMathCloud I regularly (try to) install a lot of big
complicated scientific software in other areas (not pure math), that
are in many ways similar to Sage. In many cases there is an Ubunt
On 02/19/2015 09:21 AM, Jeroen Demeyer wrote:
>
>> I don't think software was ever delayed for debian.
> If people are against #16997 because it's not compatible with Debian,
> then Debian is *already* slowing down Sage.
>
It's not incompatibility with Debian that's the problem. Having
dependen
worked for me...
On Thursday, February 19, 2015 at 3:02:46 PM UTC+1, Snark wrote:
>
> Hi,
>
> I'm having a hard time setting #17796 back to needs_review after I
> followed Jeroen's remarks : I keep getting disconnected!
>
> Whenever I click on login, it refreshes and I'm in. And afterwards,
>
On 2015-02-19 12:56, Julien Puydt wrote:
Well, examples exist where poor choices have been made which make(made)
it harder for other projects.
From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed
a two-line patch which did it programmatically from sa
Hi,
I'm having a hard time setting #17796 back to needs_review after I
followed Jeroen's remarks : I keep getting disconnected!
Whenever I click on login, it refreshes and I'm in. And afterwards,
whenever it refreshes, I'm off again... that includes refreshing because
I ask to modify the tic
+1 to SageMath
Jason
--
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@goo
Le 19/02/2015 10:19, Jeroen Demeyer a écrit :
On 2015-02-19 08:31, Marc Mezzarobba wrote:
On a perhaps related note, Sage used to be about "building the car",
didn't it?
I would say it still is about "building the car". I think this refers to
using dependencies where possible. Instead of writ
On Wednesday, February 18, 2015 at 1:13:46 PM UTC+1, William wrote:
>
> Hi Sage Developers,
>
> Several people and events have suggested to me that the official name
> of "Sage" should be filled out to be "SageMath", like the website url
> (which is sagemath.org and has been since I bought it in
> On 19/02/2015, at 22:19, Jeroen Demeyer wrote:
>
> On 2015-02-19 08:31, Marc Mezzarobba wrote:
>> On a perhaps related note, Sage used to be about "building the car",
>> didn't it?
> I would say it still is about "building the car". I think this refers to
> using dependencies where possible.
On 2015-02-19 08:31, Marc Mezzarobba wrote:
On a perhaps related note, Sage used to be about "building the car",
didn't it?
I would say it still is about "building the car". I think this refers to
using dependencies where possible. Instead of writing our own functions
to compute in number field
+1 to sagemath or SageMath. I'd prefer a short prompt (like sage:)
Martin
Am Mittwoch, 18. Februar 2015 13:13:46 UTC+1 schrieb William:
>
> Hi Sage Developers,
>
> Several people and events have suggested to me that the official name
> of "Sage" should be filled out to be "SageMath", like the
60 matches
Mail list logo
