On Tuesday, November 4, 2014 3:46:55 PM UTC-8, Robert Dodier wrote:
>
> I don't know a work-around for is(equal(1,exp(256*(x+1. As always,
> a bug report will be very helpful. http://sourceforge.net/p/maxima/bugs
>
I'm not so sure it's a bug or that something can be done about it, but you
c
In http://trac.sagemath.org/ticket/14630, I have a patch that adds a
simplify_real() method to symbolic expressions. Pretty much the only
thing it does is simplify,
sqrt(x^2) -> abs(x)
In the past, you could obtain this with simplify_radical(), even though
the variable `x` involved was assumed
On 10/31/2014 05:54 AM, Jean-Pierre Flori wrote:
> Dear all,
>
> Should we go on stripping down upstream tarballs from stuff we don't use
> when there is some substantial gain?
> See http://trac.sagemath.org/ticket/17169 (GCC) and
> http://trac.sagemath.org/ticket/15015 (MPIR).
> We can debate for
On 2014-11-04, Nils Bruin wrote:
> sage DOES call Maxima with
>
> is (equal(1,exp(256*(x+1;
>
> which indeed can take quite a while. In fact, profile data indicates nearly
> all time reported is spent on that statement.
A stack trace shows that Maxima is trying to factor 1 - exp(256*(x + 1)
On Tuesday, November 4, 2014 11:59:18 AM UTC-8, rjf wrote:
>
> For Sage, I think
> a better approach if you are going to use Maxima, might be to something
> like ..
>
> is(simplify(1-exp(256*(x+1)) = 0)
>
> where "simplify" is some particular simplification program, e.g. ratsimp,
> fullra
On Tuesday, November 4, 2014 11:38:33 AM UTC-8, Nils Bruin wrote:
>
> On Tuesday, November 4, 2014 10:54:51 AM UTC-8, rjf wrote:
>>
>>
>> Sage apparently does not call Maxima for this, since
>> is(equal(0,exp(512*(x+1; takes 0.05ms, even if one
>> provides the irrelevant declare(x,re
On Tuesday, November 4, 2014 10:54:51 AM UTC-8, rjf wrote:
>
>
> Sage apparently does not call Maxima for this, since
> is(equal(0,exp(512*(x+1; takes 0.05ms, even if one
> provides the irrelevant declare(x,real).
>
> Indeed, sage doesn't call Maxima with *that* statement because it wo
I don't relish the prospect of another article that essentially
says,
We love open source because (whatever you trot out as advantages).
People DO test and find bugs in closed source programs.
For example, running them on cases for which the answer is already
known (e.g. solving differential equa
On Monday, November 3, 2014 5:01:03 PM UTC-8, Dr. David Kirkby (Kirkby
Microwave Ltd) wrote:
...
snip
While I usually find Kirby's posts to be so self-cancelling under close
examination
that no response is required,
I think he has a point here.
In fact there used to be a newsgroup for
On Tuesday, November 4, 2014 9:52:03 AM UTC-8, kcrisman wrote:
>
> Interesting. Since this assumption stuff does something in Maxima,
> perhaps that is where the slowdown happens. I'm not sure that we ask
> Maxima to check for our equality, though perhaps it comes into play once
> that assum
>
>
> > I can see that there could be a number of follow up comments about
> > the article. But too much emphasis on Sage's ability to perform the
> > computation correctly would make it like a childish pi**ing contest.
> >
> > Agree. A reasonable article should
>
Yes.
> >
>
Interesting. Since this assumption stuff does something in Maxima, perhaps
that is where the slowdown happens. I'm not sure that we ask Maxima to
check for our equality, though perhaps it comes into play once that
assumption is made.
> Hi,
>
> I know that comparing symbolic expressions of
Obvious place to look:
http://trac.sagemath.org/ticket/17195
--
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 th
Hello all,
I might be doing something wrong with my setup, but it seems that
cycache stopped working some days ago:
$ ls -l ~/.cycache/ --sort=time --reverse |tail
-rw-r--r-- 1 jdemeyer jdemeyer 25980 Oct 27 21:44
module.c-c854ef50c2aae0236f381cde4a9a08b1.gz
-rw-r--r-- 1 jdemeyer jdemeyer 4
Hi,
I know that comparing symbolic expressions of a real variable is generally
an undecidable problem, but I've recently faced the following CPU time
issue on very simple symbolic expressions:
sage: assume(x, 'real')
sage: %time bool(exp(512*(x+1)) == 1)
CPU times: user 4min 46s, sys: 116 ms,
On Tuesday, November 4, 2014 12:18:22 PM UTC, Jeroen Demeyer wrote:
>
> So is it comparable to ccache then (caching all build output, not just
> from .c files)?
Yes except that ccache doesn't cache the building, tuning, and linking...
--
You received this message because you are subscribed to
On 11/4/14, 7:04, Volker Braun wrote:
I can see that there could be a number of follow up comments about
the article. But too much emphasis on Sage's ability to perform the
computation correctly would make it like a childish pi**ing contest.
Agree. A reasonable article should
a) giv
On 2014-11-03 10:23, Ralf Stephan wrote:
Thanks, I should use sage -f more often.
So, what became of Jeroen's idea of using the
"order only dependency" feature of GNU make?
I created
http://trac.sagemath.org/ticket/17286
--
You received this message because you are subscribed to the Google G
On 2014-11-03 12:15, Volker Braun wrote:
On Monday, November 3, 2014 9:44:10 AM UTC, Jeroen Demeyer wrote:
I don't know about hashdist, but I don't see how it could magically fix
the "compile time when switching branches" issue.
By caching properly, and using tarball + build script + v
On Tuesday, November 4, 2014 1:01:03 AM UTC, Dr. David Kirkby (Kirkby
Microwave Ltd) wrote:
>
> I can see that there could be a number of follow up comments about the
> article. But too much emphasis on Sage's ability to perform the computation
> correctly would make it like a childish pi**ing c
20 matches
Mail list logo
