On 9/5/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
>
> I think that when it comes to logos that simple is good. It should
> look good and be recognizable when scaled down. This pretty much
> eliminates ones with actual words. It'd be good to have one that can
> be easily separated from the word/
I think that when it comes to logos that simple is good. It should
look good and be recognizable when scaled down. This pretty much
eliminates ones with actual words. It'd be good to have one that can
be easily separated from the word/letters SAGE. I like the idea of a
sage leaf. Maybe a vari
I agree that we should have an iconic logo to go next to the word SAGE, and
this is my first attempt at making one. Comments? The SVG has some junk
around the edges that I haven't bothered to clean up yet, ignore it. The
leaves are of a sage plant... (ok, not really -- it's a tracing based on
On 9/5/07, Bill Hart <[EMAIL PROTECTED]> wrote:
> Are you asking me? I'm not even sure I understand all the different
> options Magma offers yet!!
>
> Basically I don't see any problem with doing the computation the way
> Pari does it, whatever that equates to in Magma.
I'm specifically asking yo
Are you asking me? I'm not even sure I understand all the different
options Magma offers yet!!
Basically I don't see any problem with doing the computation the way
Pari does it, whatever that equates to in Magma.
*IF* I understand it correctly, from Magma's point of view, Pari uses
the bound Bac
On Sep 5, 8:15 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 9/5/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
>
> > What version are we working from tomorrow? Is there a tarball available?
>
> Bug day 2 will start tomorrow at 10am sharp. We will start
> working from sage-2.8.3.4, which
Degree 5 class group timings Pari vs Magma:
5, 5, 1000 : 23-40s 22-31s
x^5 + 816*x^4 + 515*x^3 + 551*x^2 - 594*x - 475 : 3.21s 67.9s
x^5 + 210*x^4 + 1017*x^3 + 763*x^2 - 701*x + 672 : 0.469s 1.57s
x^5 - 832*x^4 + 452*x^3 + 684*x^2 + 818*x + 67 : 3.87s 70.8s
x^5 - 2403*x^4 + 7461*x^3 + 1192*x^2 +
On 9/5/07, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> Degree 4:
>
> 4, 5, 1000 : 10s 10s
> 4, 10, 100 : 20-30s 21-30s
> x^4 - 19668*x^3 + 17560*x^2 + 26384*x + 30412 : 7.89s
> x^4 - 956*x^3 - 7384*x^2 + 2639*x - 17854 : 1.01s 100s
> x^4 - 1059*x^3 + 30230*x^2 + 10713*x + 25155 : 0.521s 13.5s
>
Degree 4:
4, 5, 1000 : 10s 10s
4, 10, 100 : 20-30s 21-30s
x^4 - 19668*x^3 + 17560*x^2 + 26384*x + 30412 : 7.89s
x^4 - 956*x^3 - 7384*x^2 + 2639*x - 17854 : 1.01s 100s
x^4 - 1059*x^3 + 30230*x^2 + 10713*x + 25155 : 0.521s 13.5s
x^4 + 27001*x^3 + 7255*x^2 + 16695*x + 23797 : 16.3s
x^4 - 2
Hi,
I've released sage-2.8.3.5 which fixes a couple of bugs and minor issues
that came up earlier today.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
--~--~-~--~~~---~--~~
To post to this
On the other hand the times for cubic fields are not changed by
calling SetClassGroupBounds("PARI");
This tells me that Magma likely uses BachBound(K)/40 for quadratic
fields too. There would be nothing wrong with this since Pari used to
do this itself but it slowed Pari down for large discrimina
Indeed Nils Bruin was correct. When timing the computation of class
groups in Magma you need to set the bound for both the factor base
*and* the class group checking. In fact I had not noticed that Magma
has a function SetClassGroupBounds("PARI"); which tries to emulate
the level of rigour that P
On Sep 5, 2007, at 4:48 PM, David Harvey wrote:
> On Sep 5, 2007, at 7:37 PM, Robert Bradshaw wrote:
>
>>> But I'm a bit concerned why doesn't Python do this itself? I
>>> just
>>> had a look at the implementations of some arithmetic operations on
>>> e.g. floats and strings in the python
On Sep 5, 2007, at 7:37 PM, Robert Bradshaw wrote:
>> But I'm a bit concerned why doesn't Python do this itself? I just
>> had a look at the implementations of some arithmetic operations on
>> e.g. floats and strings in the python source, and they never use this
>> trick.
>>
>> I would feel
On Sep 5, 2007, at 4:10 PM, David Harvey wrote:
> On Sep 5, 2007, at 6:27 PM, Robert Bradshaw wrote:
>
>>
>> Despite the potential speed increase (I've implemented some and it
>> can be considerable), SAGE has avoided almost all use of inplace
>> operators due to the fact that elements are suppos
Hi Nils,
Thanks for the information and encouragement. I do expect Magma to
come out ahead for large degree fields, since I recall timing it once
before and finding it ahead of Pari in such instances. That depends on
how much Pari has been improved recently of course.
I think you are right that
On Sep 5, 2007, at 6:27 PM, Robert Bradshaw wrote:
>
> Despite the potential speed increase (I've implemented some and it
> can be considerable), SAGE has avoided almost all use of inplace
> operators due to the fact that elements are supposed to be immutable,
> despite the fact that one does no
On 5-Sep-07, at 3:27 PM, Robert Bradshaw wrote:
>
> Despite the potential speed increase (I've implemented some and it
> can be considerable), SAGE has avoided almost all use of inplace
> operators due to the fact that elements are supposed to be immutable,
> despite the fact that one does not r
+1
On Wed, 5 Sep 2007, Robert Bradshaw wrote:
>
> Despite the potential speed increase (I've implemented some and it
> can be considerable), SAGE has avoided almost all use of inplace
> operators due to the fact that elements are supposed to be immutable,
> despite the fact that one does not re
Despite the potential speed increase (I've implemented some and it
can be considerable), SAGE has avoided almost all use of inplace
operators due to the fact that elements are supposed to be immutable,
despite the fact that one does not really need the "old" result
anymore. For example, if
Dear SAGE developers,
William and I are considering organizing SAGE days at Simon Fraser
University (Vancouver, Canada), probably somewhere in the summer of
2008, subject to securing the required funding. Both for the
effectiveness of the meeting and for the purposes of getting funding,
it is goo
I'm sure the overhead is tiny, but you are also calculating f' in each
iteration.
On 9/5/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 5, 2007, at 1:25 PM, John Voight wrote:
>
> > Wow Robert, thanks! Talk about real-time recreating the wheel--my
> > code is quite similar, though I
On Sep 5, 2007, at 1:25 PM, John Voight wrote:
> Wow Robert, thanks! Talk about real-time recreating the wheel--my
> code is quite similar, though I was using floats.
Well, it was pretty quick to write, and I was curious as to the
accuracy it would give. I wrote an mpfr-based root refiner too
Wow Robert, thanks! Talk about real-time recreating the wheel--my
code is quite similar, though I was using floats.
Three questions for ya:
(1) Is there a reason to use Py_ssize_t instead of int or even
unsigned int? If it's for length, I can't imagine we'd have
polynomials of that huge a degr
Congratulations on your result. This is a very useful project and I am
sure that nearly all computational number theorists will be very
interested in the outcomes. If you do it properly, you could even
considering submitting it to ANTS (it's not really mathematics,
because the objects of study are
Here's the promised posting to the LiDIA list about getting it to
compile under gcc 4.2.1. I have not yet tried it.
John
-- Forwarded message --
From: Martin Ettl <[EMAIL PROTECTED]>
Date: Aug 20, 2007 9:09 AM
Subject: [LiDIA] LiDIA 2.2.0 with g++-4.2.1
To: [EMAIL PROTECTED]
Hi
On 9/5/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
> What version are we working from tomorrow? Is there a tarball available?
Bug day 2 will start tomorrow at 10am sharp. We will start
working from sage-2.8.3.4, which I released last night, and
which is available here or from "sage -upgrade":
What version are we working from tomorrow? Is there a tarball available?
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this grou
Here are some times for cubic fields (I have already timed Pari for
fields of degree up to 25):
Degree, Bits, Iterations : Pari Magma
3, 5, 5000 : 15s 28s
3, 10, 1000 : 23s 26s
3, 15, 100 : 15-20s 14-39s
x^3 - 327878*x^2 - 1038886*x + 711300 : 1.12s 10.6s
x^3 + 244636*x^2 + 536860*x - 435475 : 0
They certainly did code their algorithms in the LiDIA package. What I
don't know is whether this code then became part of LiDIA or was just
built on top of it. I can't tell that from reading the LiDIA
documentation.
I particularly don't want to read their source code for this problem
until it is
It is certainly conceivable that LiDIA will be better. I seem to
remember that LiDIA has separate dedicated classes for quadratic
fields (as opposed to general number fields). And Buchmann had
students whose theses were all about computing class numbers for
quadratic fields of huge discriminants
I know some of Thomas Papanikolaou's contributions (he was the
originator of the LiDIA project) ended up (improved) in Pari. Some of
Victor Schoup's contributions also ended up in NTL (or it may have
been the other way around). And certainly there are your contributions
which have ended up in mwra
Well I just read all the Pari source code very carefully for the case
of a quadratic number field. The code is quite simple (less than 1000
lines) and about the only thing one needs to implement it is fast
composition and powering of binary quadratic forms (ultimately one
might want some Smith nor
On 9/5/07, William Stein <[EMAIL PROTECTED]> wrote:
> On 9/4/07, Jonathan Bober <[EMAIL PROTECTED]> wrote:
> > My memory could be wrong, but I feel that this exact problem has
> > occurred before. (The problem of running scripts on the command line not
> > working -- not necessarily the exact same
I certainly would not trust Magma's documentation to give an accurate
description of what pari does. Even if was accurate when written, it
would not have been updated since then (almost certainly) while pari
has seen continuous development and improvement.
Go to the source's source: ask Karim B
The LiDIA interpreter was an experiment really -- its development
stopped very quickly as the person who write it left. That was one
major problem with LiDIA -- most was written by people in Buchmann's
research group while they were there (as students or postdocs) and
that part was often not main
A difficult, but not insurmountable, problem seems to be that each
copyright holder would need to agree to GPL their code. The copyright
holders do seem to be listed, and there don't seem to be too many of
them. Some of them are certainly not going to complain, but someone
obviously believed stron
I've undertaken to do some timings of important functions in algebraic
number theory, to see where open source software is at compared with
say Magma.
The first problem to consider is computing the class group. I start
with quadratic number fields and a comparison of Pari and Magma.
Firstly, usi
I have been building LiDIA regularly over the years but not in the
last few months so (in particular) not with the latest gcc. I have
remained on the LiDIA mailing list though (which has been extremely
quiet for a long time) and know that people have been putting in the
patches necessary to make
39 matches
Mail list logo
