On Aug 20, 12:32 pm, William Stein wst...@gmail.com wrote:
Number fields defined by polynomials that are not monic *and* integral
are not supported by PARI.
OK, thanks for the explanation.
It would probably be a 2-3 day project for somebody to make Sage fully
support fields
Hmm, I don't
Thanks for the sleuthing and ideas, John. Yes, I should have used a
monic polynomial in my example since the original problem I have is
with factors of a characteristic polynomial (and get similar
behavior).
I also get
sage: M._gens is None
True
The eigenspace code (and probably eigenvalues,
On Sat, Aug 20, 2011 at 10:58 AM, Rob Beezer goo...@beezer.cotse.net wrote:
Thanks for the sleuthing and ideas, John. Yes, I should have used a
monic polynomial in my example since the original problem I have is
with factors of a characteristic polynomial (and get similar
behavior).
I also
Also Rob, the real name for the field is M._NumberField_relative__gens
(or similar).
John
On Sat, Aug 20, 2011 at 8:32 PM, William Stein wst...@gmail.com wrote:
On Sat, Aug 20, 2011 at 10:58 AM, Rob Beezer goo...@beezer.cotse.net wrote:
Thanks for the sleuthing and ideas, John. Yes, I should
Despite my earlier comment I am not proposing automatic coercion
between isomorphic number fields since there is (often, not always!)
more than one isomorphism.
Surely a number field + embedding is a richer structure than an
abstract number field, so the coercion should go from the former to
the
On Nov 24, 10:34 pm, Simon King simon.k...@uni-jena.de wrote:
Hi!
When defining a number field, it is optional to provide a canonical
embedding into the real lazy field.
If two number fields are defined by the same polynomial and the same
generator name, they are still considered different,
Hi John!
On 25 Nov., 10:30, John Cremona john.crem...@gmail.com wrote:
Surely a number field + embedding is a richer structure than an
abstract number field, so the coercion should go from the former to
the latter as a forgetful functor.
To the contrary, it seems to me that a coercion should
Hi Luis!
On 25 Nov., 10:34, luisfe lftab...@yahoo.es wrote:
Suppose the following:
sage: K.r4 = NumberField(x^4-2)
sage: L1.r2_1 = NumberField(x^2-2, embedding = r4**2)
sage: L2.r2_2 = NumberField(x^2-2, embedding = -r4**2)
sage: K.has_coerce_map_from(L1)
True
sage:
On Nov 25, 11:27 am, Simon King simon.k...@uni-jena.de wrote:
Hi Luis!
On 25 Nov., 10:34, luisfe lftab...@yahoo.es wrote:
Suppose the following:
sage: K.r4 = NumberField(x^4-2)
sage: L1.r2_1 = NumberField(x^2-2, embedding = r4**2)
sage: L2.r2_2 = NumberField(x^2-2, embedding = -r4**2)
Hi Luis,
On 25 Nov., 11:45, luisfe lftab...@yahoo.es wrote:
As long as you construct L1 with a specified embedding to K, from a
user point of view you are stating I am working on this subfield L1
of K, but I want a subfield representation in terms of powers of
r2_1. In that sense yes, K would
I think I am out of my depth already, but I just wanted to make sure
that you knew of the composite_fields() method for number fields. In
Luis's example, you can do all of L1.composite_fields(K),
L2.composite_fields(K), K.composite_fields(L1),
K.composite_fields(L2), in each case it reurns a
Hi John,
On 25 Nov., 12:45, John Cremona john.crem...@gmail.com wrote:
I think I am out of my depth already, but I just wanted to make sure
that you knew of the composite_fields() method for number fields. In
Luis's example, you can do all of L1.composite_fields(K),
L2.composite_fields(K),
Hi Luis,
With merging as I proposed in my previous post, one gets
sage: K.r4 = NumberField(x^4-2)
sage: L1.r2_1 = NumberField(x^2-2, embedding = r4**2)
sage: L2.r2_2 = NumberField(x^2-2, embedding = -r4**2)
sage: from sage.categories.pushout import pushout
sage: pushout(L1,L2)
Number Field in r4
On Nov 25, 1:53 pm, Simon King simon.k...@uni-jena.de wrote:
Hi Luis,
With merging as I proposed in my previous post, one gets
sage: K.r4 = NumberField(x^4-2)
sage: L1.r2_1 = NumberField(x^2-2, embedding = r4**2)
sage: L2.r2_2 = NumberField(x^2-2, embedding = -r4**2)
sage: from
Hi Luis,
On 25 Nov., 14:01, luisfe lftab...@yahoo.es wrote:
mmm, with a clean sage 4.6 I get
sage: pushout(L1,L2)
Exception RuntimeError: 'maximum recursion depth exceeded while
calling a Python object' in type 'exceptions.TypeError' ignored
...
RuntimeError: maximum recursion depth
Hi Simon,
On 25 nov, 13:53, Simon King simon.k...@uni-jena.de wrote:
Now I'm puzzled where the ERROR comes from.
I might be wrong, since coercion still looks magic like me. But it
seems that before trying pushout of the objects, Sage tries
L1.coerce_map_from(L2)
Now, it seems that, whenever
Hi Luis!
On 25 Nov., 15:43, luisfe lftab...@yahoo.es wrote:
I might be wrong, since coercion still looks magic like me. But it
seems that before trying pushout of the objects, Sage tries
L1.coerce_map_from(L2)
That's correct, and in fact this is where things go boom.
The infinite bucle
On 25 Nov., 17:04, Simon King simon.k...@uni-jena.de wrote:
Well, let's see what debugging reveals.
Got it!
In NumberField_absolute._coerce_map_from_, an
EmbeddedNumberFieldMorphism is constructed. The optional argument
(namely the ambient field) is constructed, but it was forgotten to
pass it
Hi John!
On 24 Nov., 22:40, John Cremona john.crem...@gmail.com wrote:
I never use these canonical embeddings, and cannot think of a reason
for defining one field twice in this way...
Well, it is imaginable that some automatic constructions (say, in
pushout) create such a situation. And if it
On 24 Nov., 23:56, Simon King simon.k...@uni-jena.de wrote:
I never use these canonical embeddings, and cannot think of a reason
for defining one field twice in this way...
Well, it is imaginable that some automatic constructions (say, in
pushout) create such a situation. And if it occurs,
On Sep 28, 9:04 am, Bill Hart [EMAIL PROTECTED] wrote:
It would truly be interesting to do a profile of a complex interval
approach against a purely algebraic approach. It sounds like a
question begging to be answered.
Yes. (Along with a purely interval approach, with the root separation
Ah, OK, now I understand.
It would truly be interesting to do a profile of a complex interval
approach against a purely algebraic approach. It sounds like a
question begging to be answered.
I notice that in the example William gave, defining complex intervals
as AA[x]/(x^2+1) he was able to
On Sep 25, 4:37 pm, Bill Hart [EMAIL PROTECTED] wrote:
Here is my second question (one looks doubly smart if one has two
difficult questions and still no clue): is it true that one can easily
tell if two algebraic numbers are *not* equal in this system, but to
check if they are equal, one
On Sep 25, 6:40 pm, Bill Hart [EMAIL PROTECTED] wrote:
I still have a question about how one computes an approximate
polynomial for a + b for algebraic a and b, given approximate
polynomials for a and b, using interval arithmetic.
I don't. :-)
There are several possible representations for
Well that answered my next question, which is whether this method
could be used for Qbar.
Carl, what language is your code in. I would be interested in taking a
look.
Bill.
On 23 Sep, 20:15, William Stein [EMAIL PROTECTED] wrote:
On 9/23/07, cwitty [EMAIL PROTECTED] wrote:
Here's one
On Sep 25, 8:02 am, Bill Hart [EMAIL PROTECTED] wrote:
Well that answered my next question, which is whether this method
could be used for Qbar.
The biggest obstacle to handling Qbar directly is that I haven't found
a good way of isolating the roots of a complex polynomial (that is,
finding
I thought this had been solved some time ago, and was implemented in
pari. Or is that only for real roots of real polynomials?
John
On 9/25/07, cwitty [EMAIL PROTECTED] wrote:
On Sep 25, 8:02 am, Bill Hart [EMAIL PROTECTED] wrote:
Well that answered my next question, which is whether this
Could the version for complex numbers use polar coordinates?
Bill.
On 25 Sep, 18:55, cwitty [EMAIL PROTECTED] wrote:
On Sep 25, 9:28 am, John Cremona [EMAIL PROTECTED] wrote:
I thought this had been solved some time ago, and was implemented in
pari. Or is that only for real roots of real
I don't think that would help. It would make mult/div nicer, but
addition/subtraction more of a mess. I think the best analogue of an
interval is a ball--addition and subtraction of open balls yield open
balls, and multiplication/division of open balls are almost open
balls (for inputs
On Sep 25, 10:10 am, Bill Hart [EMAIL PROTECTED] wrote:
Actually, someone sent me some very good code for doing complex root
approximation in FLINT. But I've been too damned lazy to properly
incorporate it in FLINT. I will get around to it soon.
Carl if you can give me a specific interface
On Sep 25, 11:24 am, Bill Hart [EMAIL PROTECTED] wrote:
Actually, to make it work, it might have to switch between polar
coordinates and rectangular coordinates, always ensuring the point you
are talking about is inside the region, regardless of whether it is a
polar rectangle or a right
Qbar means different things to different people (or to the same people
at different times).
Carl's view is to have Qbar fixed as a subfield of C so that an
element of Qbar is represented as a (necessarily approximate) complex
value together with its minimal polynomial.
Number theorists and
Carl and Robert, I presume that in the system you are proposing, an
algebraic number would be specified as a specific root of a polynomial
f with coefficients in Qbar. But f would be *represented* by a
polynomial whose coefficients were complex intervals. The root alpha
of f of interest would be
Carl, I needed to read your response above more carefully!! Now that I
have the questions, I see you have already written the answers. :-)
You can ignore my questions about dropping back to algebraic methods
and the advantages of interval arithmetic.
But I guess there are still my other
On 9/23/07, cwitty [EMAIL PROTECTED] wrote:
Here's one (heavily biased) example:
sage: sum([sqrt(AA(i)) for i in range(1, 1000)])
[21065.833110879048 .. 21065.833110879056]
I'm pretty sure that doing computations with this number algebraically
requires dealing with polynomials of degree at
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED]
wrote:
On Sep 19, 2007, at 9:20 PM, Bill Hart wrote:
My personal opinion is that SAGE should distinguish between an abstact
number field and an embedded number field right from the start.
I agree, and like David Harvey's suggestion of
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED]
wrote:
To define an abstract number field, something like K =
number_field(QQ, x^3-3*x^2+1) could work. Eventually one will want to
be able to do adjoin(K, y^5+7*y-1), compositum(L, M), etc.
Would/could these functions return lists
On Sep 19, 2007, at 11:39 PM, Bill Hart wrote:
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Personally, I like the notation f.roots(K), where f.roots() ==
f.roots
(f.base_ring())
Yes, some of my notation is a bit unintuitive. It's the general idea
that I'm presenting here
On 20 Sep, 08:22, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Yeah perhaps radicals should just be meaningless unless you have a
number field embedded in C, in which case they should just return the
root with the least argument.
I think it should give something, but the choice might be
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Carl Witty did an implementation of the Algebraic Reals by letting
every element be specified by a polynomial and an interval containing
a single root. I've been wondering if the same approach could be
feasible for Qbar, the
The two things that Allan's method seems to allow that the embedding
into C won't directly allow are:
1) Return an absolute number field which contains all the elements
defined so far.
2) Compute a splitting field of a given field.
Numbers 1 and 2 could be implemented independently though.
I was intending to make the same suggestion myself (concerning Allan
Steele's method). When I read Allan's paper on this several years ago
I made a few suggestions to him on what I thought at the time might be
improvements -- which I will try to recover if this suggestion is
followed up.
On 9/19/07, John Cremona [EMAIL PROTECTED] wrote:
I was intending to make the same suggestion myself (concerning Allan
Steele's method). When I read Allan's paper on this several years ago
I made a few suggestions to him on what I thought at the time might be
improvements -- which I will
On 9/19/07, William Stein [EMAIL PROTECTED] wrote:
On 9/19/07, John Cremona [EMAIL PROTECTED] wrote:
I was intending to make the same suggestion myself (concerning Allan
Steele's method). When I read Allan's paper on this several years ago
I made a few suggestions to him on what I
On 9/19/07, John Cremona [EMAIL PROTECTED] wrote:
Just out of curiosity do you know anybody who has ever actually
made genuine use of Allan's QQbar implementation in Magma?
I've played around with it myself, but never found a way to use
it for anything interesting. I'm curious.
Answer:
I remember a few years ago (when working with Enrique Gonzales on some
modular form programs) spending ages finding a bug in a Magma program
which gave different results to an earlier Mathematica program. It
turned out that we were assuming that
sqrt(-1)*sqrt(-2)=sqrt(2)
but
My personal opinion is that SAGE should distinguish between an abstact
number field and an embedded number field right from the start.
An abstract number field should be basically a number field defined by
a polynomial with no embedding specified. If you like, it can be
thought of as David
Sorry, I had L(sqrt(x+1)[1]) above at a certain point. This should of
course be sqrt(L(x+1))[1].
Bill.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more
Ah, yeah, I only want an algebraic closure of Q. Of course an
algebraic closure of an algebraic number field K doesn't give you
something different, since K contains Q anyway. But hopefully some of
the rest of what I say still makes some sense.
Magma also offers the algebraic closure of a finite
On Sep 19, 2007, at 9:20 PM, Bill Hart wrote:
My personal opinion is that SAGE should distinguish between an abstact
number field and an embedded number field right from the start.
I agree, and like David Harvey's suggestion of how to handle this.
An abstract number field should be
On Sep 17, 2007, at 9:00 PM, William Stein wrote:
This is being cc'd to sage-devel, since no reason not to. It's me
and Robert Bradshaw working on reworking the algebraic number
theory code in Sage (we've done a lot now).
On 9/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
BTW, I've been
It's ok for sqrt(2).parent() to be an order, but what about
sqrt(1/2).parent() ? Would that be the field? Not very nice since it
will not be obvious from the form of the input whether or not the
symbolic expression is integral.
There is a whole can of worms here just waiting to be released,
On Sep 18, 2007, at 12:25 AM, John Cremona wrote:
It's ok for sqrt(2).parent() to be an order, but what about
sqrt(1/2).parent() ? Would that be the field? Not very nice since it
will not be obvious from the form of the input whether or not the
symbolic expression is integral.
sqrt(1/2) =
On Sep 18, 2007, at 12:00 AM, William Stein wrote:
I also want to make ZZ[a,b,c]
work, if a,b,c are algebraic integers.
Suppose that b and c are roots of x^3 - 2, but without any embedding
information given. How do you decide what Q[b, c] means? i.e. how do
you tell whether b and c are
On 9/18/07, David Harvey [EMAIL PROTECTED] wrote:
On Sep 18, 2007, at 12:00 AM, William Stein wrote:
I also want to make ZZ[a,b,c]
work, if a,b,c are algebraic integers.
Suppose that b and c are roots of x^3 - 2, but without any embedding
information given. How do you decide what Q[b,
Would someone be able to define a number field by supplying the value
of the klein j-function at a point in a quadratic order? E.g.
QQ[sqrt(-47), ellj((1+sqrt(-47))/2))]
What about:
f1(x) = eta(x/2,1)/eta(x,1)
K = QQ[abs(f1((1+sqrt(-47))/2))^2/sqrt(2)]
What about values of the exponential
On Sep 18, 2007, at 7:42 AM, Bill Hart wrote:
Would someone be able to define a number field by supplying the value
of the klein j-function at a point in a quadratic order? E.g.
QQ[sqrt(-47), ellj((1+sqrt(-47))/2))]
What about:
f1(x) = eta(x/2,1)/eta(x,1)
K =
For inspiration, it might be worth comparing to Allan Steel's
algebraically closed field construction:
http://magma.maths.usyd.edu.au/magma/htmlhelp/text702.htm
At no point is the field actually algebraically closed--it is just the
affine algebra on the elements that you've already
This is being cc'd to sage-devel, since no reason not to. It's me
and Robert Bradshaw working on reworking the algebraic number
theory code in Sage (we've done a lot now).
On 9/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
BTW, I've been working on quadratic number field elements...
That's
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
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
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
I believe Pari uses Buchmann's algorithm, which is apparently not
asymptotically slower as I stated. The paper I refer to is basically a
version of this algorithm based on the quadratic sieve and should be
much faster than Pari if implemented very well (in C).
Pari apparently implements
On 9/3/07, Bill Hart [EMAIL PROTECTED] wrote:
I tried to build LiDIA so I could do some timings. But it just doesn't
build. It's a standard Opteron machine with G++ and GMP on it. I'm
just doing a standard build, but it complains in ring_matrix.h that
some function is missing.
The last time
I looked at the LiDIA list. Christoff continues to promise the new
version is coming, this time before he goes on vacation.
Apparently the compile problems are to do with the new gcc. Some kind
person has posted the changes they made to get it working at length on
the LiDIA list.
I'll see if I
This conversation was off-list, but should be on-list, so I'm pushing it there.
Forwarded Conversation
Subject: number fields
From: William Stein [EMAIL PROTECTED]
To: David Roe [EMAIL PROTECTED], Joel B. Mohler
[EMAIL PROTECTED], Robert Bradshaw
[EMAIL PROTECTED],
On 9/1/07, Bill Hart [EMAIL PROTECTED] wrote:
I can't recall if I mentioned the following things related to
performance already, apologies if I did, and apologies if some of it
is out-of-date information to the SAGE group who've already been
working on this:
1) I'm told Magma uses some
Cool. Can I ask what if any profiles have been done of algebraic
number theory functions yet in Magma and other packages?
It might be interesting to look at LiDIA in the roundup too. I
understand a fair bit of effort went into that in the ANT area.
Since it is definitely an issue which
68 matches
Mail list logo
