ded blas is for constructors: with
>> Intel's mkl blas, you can obtain the maximum possible performances of
>> tah machines when you use DGEMM (ie product of matrices), due to the
>> high arithmetic intensity of matrix vector products. On my 2x8 core
>> s
, 14.533391952514648)
(9, 130.57, 13.497469902038574)
(10, 123.67, 11.505426168441772)
[...]
(60, 779.12, 12.92886209487915)
(61, 875.74, 14.310442924499512)
(62, 869.82, 14.241307973861694)
(63, 813.99, 13.089143991470337)
(64, 728.52, 11.443121910095215)
On Tue, Oct 4, 2016 at 9:40 PM, Jonath
On Tue, Oct 4, 2016 at 9:03 PM, William Stein wrote:
> On Tue, Oct 4, 2016 at 12:58 PM, Jonathan Bober wrote:
> > No, in 7.3 Sage isn't multithreading in this example:
> >
> > jb12407@lmfdb1:~$ sage73
> > sage: %time M = ModularSymbols(5113, 2, -1)
> > CPU
nly R seems to be linked to libgomp (openmp) on my vanilla install.
> Curiosity: do you observe the same behaviour in 7.3?
>
> François
>
> > On 5/10/2016, at 07:26, Jonathan Bober wrote:
> >
> > See the following timings: If I start Sage with OMP_NUM_THREADS=1, a
>
See the following timings: If I start Sage with OMP_NUM_THREADS=1, a
particular computation takes 1.52 cpu seconds and 1.56 wall seconds.
The same computation without OMP_NUM_THREADS set takes 12.8 cpu seconds and
1.69 wall seconds. This is particularly devastating when I'm running with
@parallel
September 26, 2016 at 11:23:49 PM UTC+2, Jonathan Bober wrote:
>>
>> On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori
>> wrote:
>>
>>> I suspect that perhaps the copy I have the works is working because I
>>>> built it as sage 7.3 at some point with SAG
On Tue, Sep 27, 2016 at 8:34 PM, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:
>
>
> On Tuesday, 27 September 2016 20:53:28 UTC+2, Jonathan Bober wrote:
>>
>> On Tue, Sep 27, 2016 at 7:18 PM, 'Bill Hart' via sage-devel <
>
On Tue, Sep 27, 2016 at 8:02 PM, William Stein wrote:
> On Tue, Sep 27, 2016 at 11:53 AM, Jonathan Bober
> wrote:
> > On Tue, Sep 27, 2016 at 7:18 PM, 'Bill Hart' via sage-devel
> > wrote:
> >>
> >> I'm pretty sure the charpoly routine in F
I just noticed this thread because of your recent reply, and happened to
read through. (I haven't regularly read sage-devel for a while.)
As to your original email: I think there is a subtle python memory
management issue there. If you run
sage: BIG=myfunction(somevars)
sage: BIG=myfunction(somev
x27;t
check the version in Sage) and comments from Clement Pernet, I think that
Flint uses an explicit Hadamard bound to determine how many primes to use,
while Linbox just waits for the CRT'd polynomial to stabilize for a few
primes. I have no idea how much of a difference that makes in this case.
On Tue, Sep 27, 2016 at 4:18 AM, William Stein wrote:
> On Mon, Sep 26, 2016 at 6:55 PM, Jonathan Bober wrote:
> > On Mon, Sep 26, 2016 at 11:52 PM, William Stein
> wrote:
> >>
> >> On Mon, Sep 26, 2016 at 3:27 PM, Jonathan Bober
> wrote:
> >> > In
On Mon, Sep 26, 2016 at 11:52 PM, William Stein wrote:
> On Mon, Sep 26, 2016 at 3:27 PM, Jonathan Bober wrote:
> > In the matrix_integer_dense charpoly() function, there is a note in the
> > docstring which says "Linbox charpoly disabled on 64-bit machines, since
> it
In the matrix_integer_dense charpoly() function, there is a note in the
docstring which says "Linbox charpoly disabled on 64-bit machines, since it
hangs in many cases."
As far as I can tell, that is not true, in the sense that (1) I have 64-bit
machines, and Linbox charpoly is not disabled, (2)
c
On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori
wrote:
> I suspect that perhaps the copy I have the works is working because I
>> built it as sage 7.3 at some point with SAGE_ATLAS_LIB set and then rebuilt
>> it on the develop branch, which didn't get rid of the atlas symlinks that
>> were al
on, Sep 26, 2016 at 7:11 PM, Jonathan Bober wrote:
> I've rebuilt again from scratch, twice. Once after clearing all my
> possibly questionable environment variables (except for LD_LIBRARY_PATH,
> since that is needed for gcc-6.1.0, as set by module add gcc-6.1.0 for me).
> Th
I've rebuilt again from scratch, twice. Once after clearing all my possibly
questionable environment variables (except for LD_LIBRARY_PATH, since that
is needed for gcc-6.1.0, as set by module add gcc-6.1.0 for me). The second
time I did "CFLAGS=-mno-xop make". I can see that flag took effect by
ex
On Mon, Sep 26, 2016 at 1:50 PM, leif wrote:
> Jean-Pierre Flori wrote:
> >
> >
> > On Monday, September 26, 2016 at 11:47:00 AM UTC+2, Jonathan Bober wrote:
> >
> > On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik > > wrote:
> >
> >
&g
>
> On Monday, September 26, 2016 at 11:47:00 AM UTC+2, Jonathan Bober wrote:
>>
>> On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik wrote:
>>
>>>
>>>
>>> On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober wrote:
>>>>
>>>&g
On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik wrote:
>
>
> On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober wrote:
>>
>> I recompiled with gcc 6.1.0, and get the same segfault. I did a ./sage -i
>> gdb to get a better crash report, which is atta
On Mon, Sep 26, 2016 at 2:00 AM, Dima Pasechnik wrote:
surely one can mess everything up with env. vars :-)
>
Yes, of course, I should have been more specific. I mean 'standard'
environment variables (which users like me might use in wrong or 'hackish'
ways). e.g., something like
module add gc
on, Sep 26, 2016 at 2:06 AM, Dima Pasechnik wrote:
>
>
> On Sunday, September 25, 2016 at 10:48:51 PM UTC, Jonathan Bober wrote:
>>
>> That's a good point. It looks like 5.1.0. I will try rebuilding from
>> scratch with SAGE_INSTALL_GCC=yes, since that's easi
On Mon, Sep 26, 2016 at 1:54 AM, Dima Pasechnik wrote:
>
>
> On Monday, September 26, 2016 at 12:40:23 AM UTC, Jonathan Bober wrote:
>>
>> Is git still down, or do is the problem just that I don't know what I am
>> doing?
>>
>> jb12407@lmfdb5:/data/
Is git still down, or do is the problem just that I don't know what I am
doing?
jb12407@lmfdb5:/data/local/sage/sage-7.3$ git trac checkout 21596
Loading ticket #21596...
Newly created local branch:
t/21596/matrix_charpoly_algorithm__flint___destroys_the_polynomial_ring_generator
Traceback (most r
ent versions, you have to
reinstall GMP properly.
Error configuring GMP-ECM.
Is it possible that some environment variable I've set has messed something
up?
Also, I ran make distclean instead of really starting from scratch. Is that
relevant?
On Sun, Sep 25, 2016 at 11:48 PM, Jonathan Bober
) I will report
back in 90 minutes, unless I don't, in which case I'll report back in 10 to
24 hours.
On Sun, Sep 25, 2016 at 11:31 PM, Dima Pasechnik wrote:
> Most probably gcc version used to build Sage is also quite important...
>
>
> On Sunday, September 25, 2016 at
jb12407@lmfdb5:~$ uname -r
2.6.32-573.3.1.el6.x86_64
On Sun, Sep 25, 2016 at 11:03 PM, Dima Pasechnik wrote:
>
>
> On Sunday, September 25, 2016 at 9:33:42 PM UTC, Jonathan Bober wrote:
>>
>> I'm getting a segfault on the current development branch of sage (see
>&g
I'm getting a segfault on the current development branch of sage (see
below). Is this a known issue and/or effecting anyone else?
This does not happen for me in Sage 7.3, although it does happen if I try
to go "back in time" with a 'git checkout 7.3' and then rebuild. So just to
be certain I built
On Wed, Sep 21, 2016 at 4:41 PM, Jeroen Demeyer
wrote:
I tested this with a small stand-alone C program: the flags
> PROT_NONE | MAP_PRIVATE | MAP_ANONYMOUS
> allow to allocate huge amounts of virtual memory, even with overcommit=2.
I also tried this. And I alsoo found that the memory does coun
(I'm not completely sure I'm correct about all of that.)
I'm probably going to try to modify a clean copy of PARI to do this, or
just write some completely separate test code to check that an mmap call
with PROT_NONE will work like we think it will work.
On Tue, Sep 20, 2016 at 1
I think that the experimental trac server is getting hit by Baidu in
bad places, and it isn't behaving well. There should be a robots.txt
for trac, which should probably completely disallow the experimental
installation, and something probably needs to be fixed with the
experimental installation.
On Wed, Jun 13, 2012 at 10:38 PM, Minh Nguyen wrote:
> Hi Jeroen,
>
> On Thu, Jun 14, 2012 at 3:24 PM, Jeroen Demeyer
> wrote:
>>> Thank you very much for the report. The problem has been fixed now.
>> Do you know what happened before, what went wrong?
>
> It has to do with the memory consumpti
see http://trac.sagemath.org/sage_trac/ticket/13057
This seems to be a bad regression. On reasonable machines it can take
5 seconds to get the docstring of an object by using '?'. Does anyone
have any idea what happened? I don't see any changes to
sage/misc/sagedoc.py or sage/misc/sageinspect.py i
Perhaps you just had a flaky connection, and the fact that the same
file kept failing was just a coincidence?
There are some errors in the trac log like
[...]
File "/usr/lib/python2.5/cgi.py", line 691, in read_lines
self.read_lines_to_outerboundary()
File "/usr/lib/python2.5/cgi.py", lin
Whatever is going on, it has to do with trac, and not the database, it
seems. apache runs at 100% for a while before returning a response
whenever that page is loaded. I wonder if perhaps the issue is with
one of the plugins.
On Tue, Mar 20, 2012 at 4:40 PM, Maarten Derickx
wrote:
>
>
> Le mercre
On Tue, Mar 20, 2012 at 3:58 AM, leif wrote:
> On 20 Mrz., 10:45, P Purkayastha wrote:
>> On Tuesday, March 20, 2012 4:43:41 PM UTC+8, Jeroen Demeyer wrote:
>>
>> > On 2012-03-20 09:17, David Roe wrote:
>> > > What link is broken? I'm finding the link to
>>
>> >http://trac.sagemath.org/sage_trac
On Tue, Mar 20, 2012 at 10:28 AM, Keshav Kini wrote:
> I guess Purple Sage will have to switch to git when Sage does, since
> their code bases are deeply connected. lmfdb, which I hadn't heard of
> before, looks to be a separate codebase (like sagenb is). Is it
> switching to git too? If not, then
I just made a few more changes to the trac/apache configuration.
Apache now serves up (some) trac static files directly, instead of
having trac do it. This should give better performance, but I don't
know whether or not it will actually be anything noticeable.
I also decreased the maximum number o
ote:
> On Tue, Mar 6, 2012 at 12:11 PM, Jonathan Bober wrote:
> > I am going to be building a VM on sage.math for other purposes soon, so
> I'll
> > try to make one for this as well. I suppose we would want something like
> > Ubuntu 11.10 32-bit desktop edition?
> >
I am going to be building a VM on sage.math for other purposes soon, so
I'll try to make one for this as well. I suppose we would want something
like Ubuntu 11.10 32-bit desktop edition?
(Unfortunately, virtualbox on the *.math machines is really old, or at
least it was last time I checked, so usi
On Wed, Feb 29, 2012 at 10:12 AM, William Stein wrote:
>
> It's difficult for me because they are patch in hg format, but I can't
> export a patch out of git in hg format. It's possible to import the
> code in from the trac ticket, but then if I make changes I have to
> export them as a git diff
I didn't actually expect the following to work very well, but I definitely
did not expect the output that I did get:
sage: def IC9E(K, j, a, b, epsilon):
: g(t) = 2*pi*i * (a - i*a + 2*b*K + i*2*b*K)*(1+i)*t - (1+i)^2 *
2*i*b*t^2
: f(t) = t^j * exp(g(t))
: return integral(f
On Fri, Feb 10, 2012 at 10:58 AM, Justin C. Walker wrote:
>
> On 10 Feb, 2012, at 02:06 AM, Jonathan Bober wrote:
>
> > By "sage in terminal" I mean "not the notebook."
> >
> > In recent builds (maybe mostly in the sage-5.0-beta series, but maybe
By "sage in terminal" I mean "not the notebook."
In recent builds (maybe mostly in the sage-5.0-beta series, but maybe 4.8,
and maybe older -- I know that's not too helpful) I've occasionally noticed
weird things working with sage from the command line. Sometimes tab
completion has just completely
On Wed, Feb 8, 2012 at 4:00 PM, William Stein wrote:
>
> After following this whole thread, I still have absolutely no idea
> what this "non-trivial project" even is. What functionality is being
> proposed to add to the Sage build system?
>
> -- William
>
>
>
I have been wondering the same thin
On Tue, Feb 7, 2012 at 7:19 PM, Julien Puydt wrote:
> Le Tue, 7 Feb 2012 20:23:08 -0800 (PST),
> Jason a écrit :
> > One benefit of programs like matlab and mathematica is that not only
> > do they bring together many different functions with a common syntax,
> > but that they (presumably) have s
See http://trac.sagemath.org/sage_trac/ticket/12449
I made a patch to change the way that sage evaluates symbolic functions for
basic python types, and at the same time changed RDF to just use
math.gamma() instead of gsl's gamma function.
(Note: math.gamma() should be available in sage-5.0 (pytho
On Mon, Feb 6, 2012 at 3:05 PM, Dr. David Kirkby wrote:
> On 02/ 5/12 10:16 PM, Jonathan Bober wrote:
>
> Never mind all that: the gsl implementation is not very good at all,
>> whereas the libc implementation on my machine seems quite good. Old
>> (libc):
>>
>
lem, but maybe it will work well there.
On Sun, Feb 5, 2012 at 2:16 PM, Jonathan Bober wrote:
> See http://trac.sagemath.org/sage_trac/ticket/12449
>
> I'm in the middle of [hopefully] fixing this by calling the gsl gamma
> function. While I'm at it, I'll also make
See http://trac.sagemath.org/sage_trac/ticket/12449
I'm in the middle of [hopefully] fixing this by calling the gsl gamma
function. While I'm at it, I'll also make the evaluation on basic types
much faster, as it shouldn't go though Ginac. (Actually, I've already
mostly written a fix. I opened the
On Sat, Feb 4, 2012 at 2:11 PM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
>
> Note that what is broken[1] here is ARM's libc, if one types
> "gamma(6.0)" one gets "120." on all systems. It's a
> question about gamma(float(6.0)) which is explicitly requesting the
> (presuma
On Sat, Feb 4, 2012 at 8:13 AM, rjf wrote:
>
>
> > If there is a reasonable
> > implementation that can guarantee this behavior with no loss in speed and
> > no other significant trade-offs, then library designers should use it,
> but
> > I don't think that it is such a simple issue.
>
> I think
On Tue, Jan 31, 2012 at 3:52 PM, Dr. David Kirkby
wrote:
>
> But it makes the code unportable. What hope do we have with the Sun/Oracle
> compiler if idiots use non-standard C? What hope do we have if we try to
> build on Windows at some point in the future using a native compiler? All
> these GNU
On Thu, Feb 2, 2012 at 1:16 PM, Julien Puydt wrote:
>
> Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more than
> the 15,95.. that fit in 53 binary digits.
>
It is not that simple. 15.95 digits is more like a guideline. At issue is
whether the number in question can be exactly r
On Thu, Feb 2, 2012 at 3:05 PM, rjf wrote:
>
> I don't know about arithmetic on ARM specifically, but there is
> something
> wrong with a gamma() function that fails to return an integer (perhaps
> in float format) when it is
> given an integer argument (perhaps in float format), and the answer i
On Thu, Feb 2, 2012 at 11:23 AM, Julien Puydt wrote:
>
> Let us consider :
> #include
> #include
>
> int
> main ()
> {
> long double x;
> x=6.0;
> printf ("%.20Lf\n", tgammal(x));
> x=10.0;
> printf ("%.20Lf\n", tgammal(x));
> return 0;
> }
>
> On an x86_64 box, I get :
> $ ./test
> 119.99
I've just been looking at this trying to figure out what was going on and I
was just going to say exactly the same thing.
I don't really know anything about the whole glibc vs eglibc thing, but I
bet the implementation is the same as
glibc-2.14.1/sysdeps/ieee754/dbl-64/e_gamma_r.c:
double
__ieee7
"Instantly" makes sense. [Maybe everyone knows this.] If a process creates
a file, and that file is deleted (either by the original process or by some
other process), that file still exists and can be written to by that
process until it is closed, and it takes up space on the file system. (I'm
not
On Tue, Jan 10, 2012 at 7:17 AM, William Stein wrote:
>
> On Jan 10, 2012 12:50 AM, "Dima Pasechnik" wrote:
> >
> >
> >
> > On Tuesday, 10 January 2012 03:06:14 UTC+8, William wrote:
> >>
> >> > coLinux looks promising. What does stop one from putting Sage on it
> >> > presently?
> >> >
> >> > D
;, line 28, in init sage.libs.ntl.ntl_ZZ
(sage/libs/ntl/ntl_ZZ.cpp:6238)
File "integer_ring.pyx", line 1063, in
sage.rings.integer_ring.IntegerRing (sage/rings/integer_ring.c:9618)
NameError: ZZ
On Tue, Dec 13, 2011 at 2:35 AM, Fredrik Johansson <
fredrik.johans...@gmail.com> wrote:
Does anyone happen to know why this happens? I have a feeling it is going
to annoy my sometime soon.
Look how long it takes to import mpmath:
$ time sage -python -c "import mpmath; print mpmath.__version__"0.17
real 0m0.809s
user 0m0.708s
sys 0m0.076s
compared to the time it takes to import the
Well, here is Dale's install.log:
http://sage.math.washington.edu/home/bober/dale-amon-20111203-install.log
I don't know what's going wrong.
On Sun, Dec 4, 2011 at 4:34 AM, Dale Amon wrote:
> On Sun, Dec 04, 2011 at 03:26:23AM -0800, Jonathan Bober wrote:
> > On Sat
Yes, I had seen some reference to something like that. I think there is
also an option to set the cpuid. Unfortunately, these features do not seem
to be very well documented. For example, when I search google for
"virtualbox synthcpu" I get your mailing list post on the first page of
results, even
On Sat, Dec 3, 2011 at 3:56 PM, Jonathan Bober wrote:
> Would it be enough to do
>
> export SAGE_FAT_BINARY="yes"
> export SAGE_BINARY_BUILD="yes"
> export SAGE_ATLAS_ARCH="base"
>
> before building?
>
I don't know if this will wor
ht also check the md5 sum of your source download, and make sure
that nothing went wrong there.)
On Sat, Dec 3, 2011 at 5:04 PM, Dale Amon wrote:
> On Sat, Dec 03, 2011 at 04:04:48PM -0800, Jonathan Bober wrote:
> > On Sat, Dec 3, 2011 at 3:56 PM, Jonathan Bober
> wrote:
> > &g
On Sat, Dec 3, 2011 at 3:56 PM, Jonathan Bober wrote:
>
> Are other people really having problems building on Ubuntu 11.10? I've had
> no problems building sage 4.8.2 on 64-bit Ubuntu 11.10. Also, I just tried
> on 32-bit 11.10 in a virtual machine, and sage built wit
It's a shame this has gone unreplied to for so long. (Unless I missed a
reply in another thread. I'm may be confused by the various threads, which
is why I'm only replying on sage-devel.)
Are other people really having problems building on Ubuntu 11.10? I've had
no problems building sage 4.8.2 on
On Tue, Nov 8, 2011 at 3:09 AM, Julien Puydt wrote:
>
> You'll find here http://clefagreg.dnsalias.org/ a distribution aimed at
> them. And in fact, several distributions, to be installed on a usb key and
> booted, precisely because the students may not have administrative rights
> on the machine
On Sun, Nov 6, 2011 at 5:59 AM, Julien Puydt wrote:
> Le 05/11/2011 21:24, Justin C. Walker a écrit :
>
> There are so many different versions of each library and system (for
>> Linux, in particular)
>> that it's a practical impossibility to produce a package like Sage that
>> will work on the sy
I just looked at a few machines where I run sage and found that one of them
has this problem. It is also the one where I've used @parallel the most.
I see at most one subdirectory per host in my .sage directory on *.math, so
there's not much of a problem there. I have use @parallel a fair amount
t
On Thu, Aug 18, 2011 at 9:02 PM, Jeroen Demeyer wrote:
> Hello sage-devel,
>
> Can somebody explain the rationale for the following lines in
> $SAGE_ROOT/sage:
> if [ "$SAGE_ROOT" = "." ]; then
>SAGE_ROOT=`readlink -n "$0" 2> /dev/null` || \
>SAGE_ROOT=`realpath"$0" 2> /dev/null`
> > back).
> > They affect multi polynomial rings used by elliptic curves.
> >
> > Finally it might be worth having a look at 5949, but I would say it is
> > not related.
> >
> > On 25 juil, 09:55, Jonathan Bober wrote:
> >
> >
> >
> &g
I just found the following memory leak:
def leak():
K. = NumberField(x^2 - x - 1)
m = get_memory_usage()
for n in xrange(10):
E = EllipticCurve(K, [3,4,5,6,7])
if n % 1000 == 0:
print get_memory_usage() - m
sage: leak()
0.0
0.5
1.0
1.0
1.5
2.0
2.0
2.5
3
Hi all. I think there's a problem with the following:
sage: K. = NumberField(x^2 - x - 1)
sage: I = K.ideal(2 * a - 1)
sage: I2 = I.factor()[0][0]
# I is a prime ideal, so its only factor is itself:
sage: print I, I2, I == I2
Fractional ideal (2*a - 1) Fractional ideal (2*a - 1) True
# also, the
I should have been a little less lazy before I posted this, I guess. I
found out where the leak is (the fpLLL wrapper) on my first try. I
don't know what is causing it, though. This is now at
http://trac.sagemath.org/sage_trac/ticket/10179
On Wed, 2010-10-27 at 14:24 -0400, Jonathan
Dear all,
There seems to be a memory leak in some code below, in at least versions
4.5 and 4.5.3. For example, if I call it with
sage: L = find_candidates_for_large_value(5000)
It prints something like:
current memory usage: 836.73046875
current memory usage: 836.73046875
current memory usage:
On Sun, 2010-09-19 at 08:12 -0700, rjf wrote:
> Any program that computes a quadrature by evaluating the integral at
> selected points cannot provide
> a rigorous error bound. I don't know what a rigorous "error estimate"
> is, unless it is an
> estimate of what might be a rigorous bound. And thu
On Thu, 2010-09-16 at 15:48 -0700, maldun wrote:
> Hi all!
>
> I'm currently found some time to work again on ticket #8321 again, and
> have added some numerical integration tests.
Hi Maldun,
I think that improvement of numerical integration would be excellent.
I've been somewhat disappointed wi
Running these tests gives some information, but it is probably a little
hard to interpret. On a fresh boot, sage will take roughly 18 seconds to
start up on my machine. Subsequent runs, however, take roughly 1.8
seconds, typically.
This is all dependent on many things that the operating system doe
At least some errors probably come from the file
sage/algebras/quatalg/quaternion_algebra_cython.pyx
and I think they should be easily fixable without any knowledge of what
is going on by just changing the code to make a copy of the zero matrix.
However, I really wonder whether this fix is neces
The Sage README.txt contains the text:
"On Linux, if you get this error message:
" restore segment prot after reloc: Permission denied "
the problem is probably related to SELinux."
I got this error on a machine on which I don't have root access, so I
couldn't try the suggested workarounds.
I just posted http://trac.sagemath.org/sage_trac/ticket/7918 but I
thought I would also send an email here to catch the attention of
whomever made the change that caused this slowdown. Hopefully this will
be easy to fix.
Somewhere between sage 4.1 and sage 4.3, log(x) got really slow when x
is a f
This might not be too relevant to OS X, since I am running Ubuntu, but
I'll put it here for the record anyway, in case it is useful to someone:
At some point when the virtualbox image wasn't working for me I
recompiled the kernel module this way. I think that I did it after
getting a more informa
I've just been trying this on Ubuntu and had the same problem.
Increasing the video ram in the virtual machine from 4 to 16 MB fixed
it, and now it works. (At least, I'm pretty sure that was the change
that fixed it.)
On Fri, 2009-10-23 at 14:01 -0700, mhampton wrote:
> I haven't tried it on Wind
I'm not sure why you are getting different results from sagenb.com and
from the "shell", but I would guess that you must be using two different
versions of Sage. Either way...
The problem is that when you divide two integers, the result is always a
rational number, whether or not that rational nu
On Mon, 2008-06-09 at 10:19 -0700, mabshoff wrote:
>
> [...]
> No clue. Can you actually compare the gp binary from Sage directly
> with the timings from your self builid binary to eliminate the problem
> that libPari is involved here? If the gp binary in Sage is slower by a
> factor of three com
Since no one else has responded, I'll go ahead and say that I don't know
anything about this. Maybe this email will be a reminder to someone who
does know. (Or maybe any questions have already been taken care of off
list?)
On Fri, 2008-05-23 at 17:12 -0700, William Stein wrote:
> On Fri, May 23,
I'm not sure exactly what the speed differences are, but I think that
they are quite significant. When writing the partition counting code,
which uses quaddouble, I recall that things ran much slower if "sloppy"
multiplication and division were not enabled. (However, I have no hard
benchmarks to b
Does anyone know what's going on in the following example? I can't seem
to reproduce this with a simple example. Basically, I create a few
'callable symbolic expressions', and then define a lambda function that
calls a one of them.
Ultimately, I have a function
Q = lambda x : RR(bound(15000, 15
I just realized a source of my confusion. The docstring that I quoted
was not actually wrong in the way that I thought is was, but was
apparently deceptive (to me). Perhaps some people are already aware of
this, but GF(5), GF(25), and GF(5^100) are all different types, and so
have different docstr
Ok, I was wrong. I'm convinced that sage has the correct behavior, which
I think is:
GF(q).gen() returns an element x of GF(q) such that the smallest
subfield of GF(q) containing x is GF(q).
In this case, the docstring needs to be corrected, because the statement
that "All elements x of self are
I don't like the behavior illustrated below. Briefly, my problem is that
GF(p).gen() gives a generator for the additive group of GF(5), while
GF(p^n).gen() gives a generator for for multiplicative group of GF(p^n)
(n > 1).
I would file this 'complaint' directly as a trac bug report, but the
docum
I don't know the answer to this for certain, but (assuming you mean eq.
5.1.53 on page 231 - http://www.math.sfu.ca/~cbm/aands/page_231.htm ) it
looks to me like this might just a 5th degree polynomial interpolation
(in which case, it's of course not something that you can compute to
arbitrary pre
Hi all. I just opened ticket #1457 (see below)
http://trac.sagemath.org/sage_trac/ticket/1457
The following is hopefully pretty self explanatory:
---
The following took place on an Intel Core Duo (32 bit) running Ubuntu
7.10. Hopefully the cause is obvious for s
On Sat, 2007-10-27 at 17:03 -0500, William Stein wrote:
> I think the public free Sage notebook should be configured so that
> the sageXX accounts cannot open sockets to the outside world. Period.
> If I knew how to configure this in < 30 minutes, I would have done it already.
I think that thi
abshoff wrote:
>
>
> On Oct 23, 6:04 pm, Jonathan Bober <[EMAIL PROTECTED]> wrote:
> > > Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg-
> > > open' with and without sourcing sage-env. If you add an 'echo
> > >
> Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg-
> open' with and without sourcing sage-env. If you add an 'echo
> LD_LIBRARY_PATH' right before xdg-open is called in P.show()
>
> >From the name of the symbol I would guess that it is a libz
> incompability. There was a pat
Hi folks.
I tried to send the following email a few hours ago (but I put the email
address in wrong) and I don't feel like rewriting it all. So I should
add to it now that I have upgraded sage (so I am running 2.8.8.1) and
the error still occurs.
Perhaps I should open a ticket for this, but perh
On Sun, 2007-10-14 at 15:13 -0700, William Stein wrote:
> On 10/14/07, Jonathan Bober <[EMAIL PROTECTED]> wrote:
> >
> > I'm not sure right now, but I'm thinking about it.
>
> OK, your new code on x86_64 gets essentially every single
> number_of_parti
use the long double type
when you use GCC 4.0 or later to develop or in programs targeted at Mac
OS X versions earlier than 10.4.
I'll probably be back looking at this in a little while.
On Sun, 2007-10-14 at 14:53 -0700, William Stein wrote:
> On 10/14/07, Jonathan Bober <[EMAIL PROTEC
I'm not sure right now, but I'm thinking about it.
You could try setting
long_double_precision = double_precision
wherever it is initialized. (This is around line 140 somewhere.) If you
do this it will just skip the part of the computation where it uses long
doubles (For
1 - 100 of 141 matches
Mail list logo
