Hello again,
I read your comments and answered some of them. Let's make it simple:
- William, who works at making people confuse Sage with his product
SageMathCloud (making promotional videos ...)
- Nicolas and his team, who I haven't actually working on trac for a
while but build their career on
Thanks for the bug reports. I don't think I will have time to work on these
this week, so maybe someone else?
Regards,
--
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 emai
Definitely +1. Thanks for all your work, Nathann.
Jason
On Tue, Feb 23, 2016, 17:12 Nicolas M. Thiery
wrote:
>
>
> On Mon, Feb 22, 2016 at 06:28:46PM -0800, kcrisman wrote:
> >...Though in open source development (at least in open development
> >projects like this one) meaning that some
On 2016-02-23 17:29, Clemens Heuberger wrote:
> I try to pinpoint the other examples and will then report those.
Here is the next issue which I encountered:
$ sage-6.9/sage -c "print bool((x^2 - 1 - (x+1)*(x-1)) != 0)"
False
$ sage-6.10/sage -c "print bool((x^2 - 1 - (x+1)*(x-1)) != 0)"
True
I s
> the latter gets evaluated by making coercing 2 into R and then trying to
> raise to an element of R (which fails). Should we even be trying this? I
> would think most valid cases of exponentiating are covered by actions. The
> cases where it can be read as a binary operation on a single stru
On Mon, Feb 22, 2016 at 06:28:46PM -0800, kcrisman wrote:
>...Though in open source development (at least in open development
>projects like this one) meaning that sometimes people will hit the road
>over disagreements, everyone should definitely thank Nathann for loads
>and loads
This is fixed in #19984 (needs review)
On Tuesday, February 23, 2016 at 7:36:35 PM UTC+1, kcrisman wrote:
>
> [...] what is the desired behavior of this script in this scenario? I
> really don't care but wanted to alert anyone who does.
>
Obviously it is not: Tripping over an old tarball and pr
> On 2016-02-23 19:36, kcrisman wrote:
>> > To wit, I still have a sqlalchemy tar in upstream/
>>
>> That's the "problem"... don't put stuff in upstream if you don't want it
>> handled by sage-fix-pkg-checksums.
>>
>
> I think the question is, to what extent are users responsible for cleaning
On Tuesday, February 23, 2016 at 10:46:28 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2016-02-23 19:36, kcrisman wrote:
> > To wit, I still have a sqlalchemy tar in upstream/
>
> That's the "problem"... don't put stuff in upstream if you don't want it
> handled by sage-fix-pkg-checksums.
>
I thin
On 2016-02-23 19:36, kcrisman wrote:
To wit, I still have a sqlalchemy tar in upstream/
That's the "problem"... don't put stuff in upstream if you don't want it
handled by sage-fix-pkg-checksums.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
When doing ./sage --fix-pkg-checksums:
cat: /Users/.../sage/build/pkgs/sqlalchemy/package-version.txt: No such
file or directory
Maybe this has been resolved or is unimportant, but anyway I thought I
would point it out. To wit, I still have a sqlalchemy tar in upstream/
despite http://trac.sa
On 2016-02-23 17:10, Nils Bruin wrote:
> sage: R.=QQ[]
> sage: 2^t
>
> the latter gets evaluated by making coercing 2 into R and then trying to
> raise to an element of R (which fails). Should we even be trying this? I
> would think most valid cases of exponentiating are covered by actions.
Yes,
Nathann,
Point taken, loud and clear. But consider boycotting the forum for a while
under protest and returning after a break.
Why sacrifice the things that you enjoy, just to make a point to others.
I'm pretty sure there are lots of people that value your contributions in
this community great
On Tue, Feb 23, 2016 at 9:37 AM, Eric Gourgoulhon
wrote:
> Hi,
>
> Le mardi 23 février 2016 16:39:20 UTC+1, William a écrit :
>>
>>
>> It seems to me that
>>
>> sage: x = var('x')
>> sage: bool(x!=infinity)
>> False
>>
>> *is* a newly introduced bug. I can't understand how the above
>> behavior c
Hi,
Le mardi 23 février 2016 16:39:20 UTC+1, William a écrit :
>
>
> It seems to me that
>
> sage: x = var('x')
> sage: bool(x!=infinity)
> False
>
> *is* a newly introduced bug. I can't understand how the above
> behavior could be justified
>
In the same vein, note that
sage: x = SR.var(
This smells like http://trac.sagemath.org/ticket/18877 ("better nonnumeric
comparisons with infinity", in particular).
--
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
Thank You for the answers. I guess that keeps me busy for a while. :-)
--
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
Given that the virtual appliance file formats seem to be somewhat
standardized so that different virtual machine running software can
export-import virtual appliances, the most hassle free solution for writing
scientific papers that use Sage might be the
http://files.sagemath.org/win/index.ht
A question for coercion experts:
Currently we have:
sage: cm=get_coercion_model()
sage: cm.explain(ZZ,QQ['t'],operator.pow)
Coercion on left operand via
Composite map:
From: Integer Ring
To: Univariate Polynomial Ring in t over Rational Field
Defn: Natural morphism:
On Tue, Feb 23, 2016 at 7:29 AM, Clemens Heuberger
wrote:
> On 2016-02-23 16:57, Jeroen Demeyer wrote:
>> On 2016-02-23 15:50, Clemens Heuberger wrote:
>>> It is also impossible to compile Sage 6.5 nowadays
>>
>> I assume this was a build from git? That's indeed not supported. A real
>> build-from
On 2016-02-23 16:57, Jeroen Demeyer wrote:
> On 2016-02-23 15:50, Clemens Heuberger wrote:
>> It is also impossible to compile Sage 6.5 nowadays
>
> I assume this was a build from git? That's indeed not supported. A real
> build-from-source-tarball should still work.
yes, I tried to build from gi
Source tarball is online, go to http://files.sagemath.org and click on
"...source code of Sage (older versions)"
On Tuesday, February 23, 2016 at 3:50:29 PM UTC+1, Clemens Heuberger wrote:
>
> It turns out that the old code no longer works with Sage 7.0. It is also
> impossible to compile Sage
On 2016-02-23 15:50, Clemens Heuberger wrote:
It is also impossible to compile Sage 6.5 nowadays
I assume this was a build from git? That's indeed not supported. A real
build-from-source-tarball should still work.
Bottom line: I cannot reproduce 11 month old results anymore.
Personally, I
On Tue, Feb 23, 2016 at 6:50 AM, Clemens Heuberger
wrote:
> I am currently revising a paper that I submitted in March 2015. Parts of the
> results heavily rely on computations in Sage; at that time, Sage 6.5.
>
> It turns out that the old code no longer works with Sage 7.0. It is also
> impossible
I am currently revising a paper that I submitted in March 2015. Parts of the
results heavily rely on computations in Sage; at that time, Sage 6.5.
It turns out that the old code no longer works with Sage 7.0. It is also
impossible to compile Sage 6.5 nowadays because the infrastructure changed (it
Sir ,
I did not get the question. Can you explain it again?
I think you are asking why hyperplane
On Wednesday, February 17, 2016 at 12:24:27 AM UTC+5:30, mmarco wrote:
>
> Ops, i didn't see that.
>
> One question, what is the reason for defining a specific class for these
> algebras instead of
On 2016-02-22 23:18, Volker Braun wrote:
I think you just ran out of RAM
Most likely. Note the signal is "Killed", not "Segmentation Fault". So
it's probably the out-of-memory killer which killed your gcc.
--
You received this message because you are subscribed to the Google Groups
"sage-de
27 matches
Mail list logo
