The answer is, I believe, yes. Should it rely on the check flag to
decide whether or not to try and factor?
- Robert
On Oct 31, 2007, at 11:58 PM, William Stein wrote:
Robert,
You massively sped up quadratic field arithmetic, which is really
awesome.
Unfortunately the following is
On Wed, 31 Oct 2007 23:41:46 -0700, Robert Bradshaw [EMAIL PROTECTED] wrote:
On Oct 31, 2007, at 8:40 PM, Carl Witty wrote:
I'm not sure if _rmul_c_impl is actually allowed to assume that _c is
Rational. I think it may be, because the bad _rmul call is made by
LeftModuleAction.__init__, and
Right now we have (not counting the _c and _impl variants)
_rmul_, _irmul_
_lmul_, _ilmul_
_rmultiply_by_scalar_
_lmultiply_by_scalar_
_r_action_
_l_action_
This seems to be redundant. What I am envisioning is:
_rmul_, _lmul_, _irmul_, _ilmul_ MUST be called with an element of
the basering,
On Thu, 01 Nov 2007 00:00:57 -0700, Robert Bradshaw [EMAIL PROTECTED] wrote:
The answer is, I believe, yes. Should it rely on the check flag to
decide whether or not to try and factor?
Wait, is there a good reason to ever compute the discriminant in order to
represent elements of the field?
On Thu, 01 Nov 2007 00:04:52 -0700, Robert Bradshaw [EMAIL PROTECTED] wrote:
Right now we have (not counting the _c and _impl variants)
_rmul_, _irmul_
_lmul_, _ilmul_
_rmultiply_by_scalar_
_lmultiply_by_scalar_
_r_action_
_l_action_
This seems to be redundant. What I am envisioning is:
On Nov 1, 2007, at 12:14 AM, William Stein wrote:
On Thu, 01 Nov 2007 00:04:52 -0700, Robert Bradshaw
[EMAIL PROTECTED] wrote:
Right now we have (not counting the _c and _impl variants)
_rmul_, _irmul_
_lmul_, _ilmul_
_rmultiply_by_scalar_
_lmultiply_by_scalar_
_r_action_
_l_action_
On Nov 1, 2007, at 12:11 AM, William Stein wrote:
On Thu, 01 Nov 2007 00:00:57 -0700, Robert Bradshaw
[EMAIL PROTECTED] wrote:
The answer is, I believe, yes. Should it rely on the check flag to
decide whether or not to try and factor?
Wait, is there a good reason to ever compute the
Hi,
This is the video from Mike Hansen's talk *today* introducing Sage and
symmetric functions, etc., during the Univ of Washington combinatorics
seminar:
http://video.google.com/videoplay?docid=5844171987660560906hl=en
--
William Stein
Associate Professor of Mathematics
University of
In my opinion construction of the field, in order to able to do basic
arithmetic in it, should not require any checking other than that the
defining polynomial is irreducible -- in this case, whether D is a
square. Only if you need the ring of integers should it be necessary
to do the extra work
On 11/1/07, John Cremona [EMAIL PROTECTED] wrote:
In my opinion construction of the field, in order to able to do basic
arithmetic in it, should not require any checking other than that the
defining polynomial is irreducible -- in this case, whether D is a
square. Only if you need the ring
ok, I'm happy!
On 01/11/2007, William Stein [EMAIL PROTECTED] wrote:
On 11/1/07, John Cremona [EMAIL PROTECTED] wrote:
In my opinion construction of the field, in order to able to do basic
arithmetic in it, should not require any checking other than that the
defining polynomial is
Many thanks William and Mike for recording and
uploading these!
On 11/1/07, William Stein [EMAIL PROTECTED] wrote:
Hi,
This is the video from Mike Hansen's talk *today* introducing Sage and
symmetric functions, etc., during the Univ of Washington combinatorics
seminar:
I have released 2.8.11.alpha0 at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar
It passes testall on sage.math, but I would like to get some build
feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit
Linux. I plan to release 2.8.11 final by late Friday night
Dear Dr. Dumas,
I've encountered a build problem in Givaro 3.2.6 on MacOS X 10.5. The
uint type used in src/kernel/zpz/givzpz32std.inl for example is not
available unless sys/types.h is included. The following patch fixes
the problem for me:
--- src/kernel/system/givbasictype.h.ORIG
mabshoff wrote:
I have released 2.8.11.alpha0 at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar
It passes testall on sage.math, but I would like to get some build
feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit
Linux. I plan to release 2.8.11
On 11/1/07, mabshoff [EMAIL PROTECTED] wrote:
I have released 2.8.11.alpha0 at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar
It passes testall on sage.math, but I would like to get some build
feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit
Linux.
On Thu, 01 Nov 2007 09:03:23 -0700, David Joyner [EMAIL PROTECTED] wrote:
On 11/1/07, mabshoff [EMAIL PROTECTED] wrote:
I have released 2.8.11.alpha0 at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar
It passes testall on sage.math, but I would like to get some build
On 01 Nov 2007 12:54:00 -0500, Gabriel Dos Reis wrote:
Bill Page [EMAIL PROTECTED] writes:
| new sites now. They can be found at:
|
| http://axiom-wiki.newsynthesis.org
|
| and
|
| http://axiom-portal.newsynthesis.org
What will happen to the email [EMAIL PROTECTED]
Right now
Hi there,
I gave my talk to the PhD seminar here at Royal Holloway today and I stressed
the fact that Sage is a unified interface to many math packages quite a lot.
This provoked the follow feature request/suggestion I was quick to turn down.
However, this should forward to all Sage
This doesn't exactly answer your question, but I think it would be
useful (or at least interesting) if setting some global flag would
cause Sage to report which external (or internal 3rd party) packages
were used in reaching a result. But perhaps that is unrealistic since
a long computation
On Nov 1, 12:20 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
2.8.11.alpha0 builds and seems to run fine on my gentoo 32-bit machine.
However, I have this one failed doc-test (which appears to basically be a
precision issue):
sage -t devel/sage-main/sage/lfunctions/lcalc.py
On 11/1/07, Martin Albrecht [EMAIL PROTECTED] wrote:
Usually, if we choose an implementation for a particular functionality, we try
to make sure to always pick the best implementation available. However, this
choice only applies to those systems we ship (singular, gap, pari ...) and
not to
mabshoff wrote:
I have released 2.8.11.alpha0 at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar
It passes testall on sage.math, but I would like to get some build
feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit
Linux. I plan to release 2.8.11
On Oct 31, 11:41 pm, Robert Bradshaw [EMAIL PROTECTED]
wrote:
On Oct 31, 2007, at 8:40 PM, Carl Witty wrote:
2) The automatic detection of possible actions scares me. It seems
fragile and overly magical. Would it be possible to disable this
(which would presumably slow things back down),
On Nov 1, 2007, at 12:11 AM, William Stein wrote:
On Thu, 01 Nov 2007 00:00:57 -0700, Robert Bradshaw
[EMAIL PROTECTED] wrote:
The answer is, I believe, yes. Should it rely on the check flag to
decide whether or not to try and factor?
Wait, is there a good reason to ever compute the
On 10/28/07, Bobby Moretti [EMAIL PROTECTED] wrote:
Sorry, accidentally hit send before I wrote anything :).
When upgrading to 2.8.9, the upgrade halts with the output
/bin/sed: can't read /home/bob/sage-2.8.7/local/lib/libgmp.la: No such
file or directory
Having the same problem here. In
On Nov 1, 2007, at 1:26 PM, Carl Witty wrote:
On Oct 31, 11:41 pm, Robert Bradshaw [EMAIL PROTECTED]
wrote:
On Oct 31, 2007, at 8:40 PM, Carl Witty wrote:
2) The automatic detection of possible actions scares me. It seems
fragile and overly magical. Would it be possible to disable this
Maybe doesn't need a trac ticket?
Nick
Observe the mistaken comma:
sage: factor(next_prime(ZZ(2)**45), next_prime(ZZ(3)**30))
---
type 'exceptions.OverflowError' Traceback (most recent call
last)
On Nov 1, 2007, at 1:52 PM, Nick Alexander wrote:
Maybe doesn't need a trac ticket?
Nick
Observe the mistaken comma:
sage: factor(next_prime(ZZ(2)**45), next_prime(ZZ(3)**30))
--
--
---
type
On Tuesday 30 October 2007, John Cremona wrote:
I agree about not rewriting for the sake of it -- but this was on the
to-do list for SD5, wasn't it? Perhaps the to-do is to implement over
GF(q) what we already have over GF(p).
*only* because I did not have access to other finite fields in
[This is still somehow attached to the off-list thread Sage Days 6 --
but I don;t know how to change that other than by starting a new
thread!]
NTL has a class ZZ_p for integers modulo (a prime) p, which I use in
mwrank for various classes which implement elliptic curve arithmetic
over those
Pardon my replying to myself...
It is also true that I implemented much the same in gp, and that
*does* have a sage interface. For example,
sage: EllipticCurve(GF(10007),[1,2,3,4,5]).abelian_group()
(Multiplicative Abelian Group isomorphic to C5038 x C2,
((9698 : 153 : 1), (8590 : 2742 :
On 11/1/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
Maybe doesn't need a trac ticket?
Nick
Observe the mistaken comma:
sage: factor(next_prime(ZZ(2)**45), next_prime(ZZ(3)**30))
--
--
---
type
Hello SAGEists.
We're having a Python and free software seminar here at CIMAT (http://
www.cimat.mx unfortunately Spanish-only at the moment), and it would
be very nice if we could invite someone prominent within SAGE
development to give us a talk, if only to wash away the bad aftertaste
of the
I have released 2.8.11.rc1 (sorry, I skipped rc0, by the time I
realized the problem I had already called it rc1 in trac) at
http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.rc1.tar
It passes testall on sage.math, but I would like to get some build
feedback on OSX 10.4, both PPC and
On Oct 29, 6:13 am, mabshoff [EMAIL PROTECTED]
dortmund.de wrote:
Hello folks,
BugDay5 is now planned for Saturday, November 3rd, 2007. Official
start will be 10am PST, but as usual people from European time zones
or the east coast might start earlier and finish a little sooner.
I you
The expected output is incorrect; the actual output is correct.
On Thu, 1 Nov 2007, mabshoff wrote:
I have released 2.8.11.rc1 (sorry, I skipped rc0, by the time I
realized the problem I had already called it rc1 in trac) at
On Nov 2, 5:29 am, [EMAIL PROTECTED] wrote:
Hello boothby,
The expected output is incorrect; the actual output is correct.
Okay, I am fixing the doctest then.
We are planning an rc2 in a couple hours if William and I get it to
compile on 10.5 without the need for manual interaction. We are
On 11/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The expected output is incorrect; the actual output is correct.
From irc:
20:24 mabshoff Sucks, but also re #750:
20:24 mabshoff File permgroup_element.py, line 323:
20:24 mabshoff sage: g([0,1,2,3,4])
20:24 mabshoff Expected:
In particular, how does applying (1,2,3)(4,5) to [0,1,2,3,4]
result in what you claim, i.e., in [1, 2, 0, 4, 3]?
It should either be an error, or maybe:
[2,0,1,3,4]
if say (1,2,3)(4,5) sends the first entry, i.e., 0th position
to the 1st, the 1st to 2nd, etc,
That's what is going on --
On Thu, 1 Nov 2007, William Stein wrote:
On 11/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
In particular, how does applying (1,2,3)(4,5) to [0,1,2,3,4]
result in what you claim, i.e., in [1, 2, 0, 4, 3]?
It should either be an error, or maybe:
[2,0,1,3,4]
if say (1,2,3)(4,5)
On 11/1/07, [EMAIL PROTECTED]
Under the way I've implemented this, the
action on the list [1,...,n] is trivially
isomorphic to the group structure. You
seem to be using a left-action which
^^^
I am using a left action.
doesn't really go well with the notation
On Thu, 1 Nov 2007, William Stein wrote:
Applying the permutation (1,2,3)(4,5) to [0,1,2,3,4]
should either move the entry in position 1 (which happens
to be called 0) to position 2, so that the output looks like
[*,0,*,*,*]
or if we do some weird 1-based thing, it would always
fix
43 matches
Mail list logo
