> Thanks for the pointer to that ticket, which explains the change in the the
> "is_unit()" behavior.
>
> Why should the inverse of "four" succeed when the result is not in K?
>
> sage: four^-1 in K
> False
The order K is analogous to the ring of integers inside QQ. So even
though the inverse of
On Sun, Aug 12, 2012 at 12:51 PM, Volker Braun wrote:
> For comparison, here is sage-5.1.rc1. It looks like the notebook update
> pulled in two slow modules: flaskext.babel and pytz. And we now have a
> longer sys.path (from 26 to 39 entries), which makes module loading overall
> slower. Especiall
For comparison, here is sage-5.1.rc1. It looks like the notebook update
pulled in two slow modules: flaskext.babel and pytz. And we now have a
longer sys.path (from 26 to 39 entries), which makes module loading overall
slower. Especially since the filesystem is 4x slower than on my laptop for
s
This still needs review. I would like to point out that this fixes no
less than 6 other tickets, so I think it would be really good to get
this into sage-5.3.
On 2012-08-03 08:42, Jeroen Demeyer wrote:
> In ticket #13237, I have upgraded Singular to version 3-1-5 (with
> various upstream patches)
I want to point out that the ticket also makes certain explicit
CONVERSIONS to SR impossible, which in my opinion is bad. (And
backward incompatible so it may break existing user code.)
It would be nice to hear more thoughts and opinions on that ticket.
Thank you,
Andrey
On Aug 11, 2:44 pm, Timo
Second measurement, best-out-of-10 on sage.math (less loaded than
previous time), using /home:
sage-4.6: 2.4s
sage-4.7: 2.5s
sage-4.8: 2.4s
sage-5.0.1: 2.0s
sage-5.1: 2.1s
sage-5.2: 2.7s
So, I would say there was a measurable speed-up in sage-5.0 and a more
serious slow-down in sage-5.2
On Saturday, August 11, 2012 1:22:05 PM UTC-7, Marco Streng wrote:
>
> These outputs look fine to me. See also
> http://trac.sagemath.org/sage_trac/ticket/11673
>
Dear Marco,
Thanks for the pointer to that ticket, which explains the change in the the
"is_unit()" behavior.
Why should the inv
I have created updated versions of the MPC and PARI packages. Both
upgrades are fairly straight-forward, and they both have been tested
successfully on the buildbots. So the review is just a matter of
looking at the patches and (hopefully) approving them.
Please review:
MPC: http://trac.sagemath
I've patched sage -startuptime to report and sort by time excluding
children, see http://trac.sagemath.org/13361 (needs review):
== Slowest module imports (excluding / including children) ==
exclude/ms include/ms #parents module name
1.737 1.795 2 sage.libs.ppl
1.749
Best-out-of-30 startup times for various versions on sage.math in /home
(mounted over NFS):
sage-4.6: 2.4s
sage-4.7: 2.5s
sage-4.8: 2.5s
sage-5.0.1: 2.2s
sage-5.2: 2.7s
It seems sage-5.0 saw an improvement (I guess due to Python-2.7), but it
got worse again. I'll try to add some data points betw
I also tried to replace core2-*-* with core*-*-* in configure:4494 (of v.
2.5.1) and add "core | " to various cases in the following two "case $host_cpu
in" statements so that the configure step works, but then I always get errors
like these
$ ABI=32 ../../repos/mpir-2.5.1/configure --...
... (
Am Freitag, 13. Juli 2012 09:37:25 UTC+2 schrieb Jeroen Demeyer:
> On 2012-07-12 22:56, Jeremy Fehr wrote:
>
> > Trying to build sage 5.1 on Debian Wheezy i686, Intel Core Duo T2400 (32
>
> > bit). Relevant log files are attached.
>
> I have no idea how this happened:
>
> configure: error: ABI=
On Sunday, August 12, 2012 3:29:16 AM UTC+2, ancienthart wrote:
>
> Daniel, on the old version of sage (5.2 before I replaced pyOpenSSL), when
> I try this, I get:
Hm, right, it keeps 0.12 for me too, I must have tested this after deleting
0.12 from $SAGE_ROOT/local. However `easy_install -U
13 matches
Mail list logo
