Hi all,
So we're currently working on a long-overdue release of Cython with
all kinds of snazzy new features. However, our automated testing
system seems to keep turning up sporadic segfaults when running the
sage doctest suite. This is obviously bad, but we're having a hard
time reproducing this
Hi all,
I just hit this zinger:
{{{
sage: polygen(GF(49, 'a')) ; polygen(GF(9, 'a'))
x
x
sage: x = polygen(GF(49, 'a'))
sage: -x
2*x
sage: x + 0
x
sage: -x
6*x
}}}
This is definitely still present in sage-4.5 (at least, William tried
it on his laptop and said he hit it). The underlying issue is
[1] http://wiki.wstein.org/10/480b
[2] http://wstein.org/edu/2010/480b/projects/
Thanks.
What distribution license is used for the lecture notes and projects?
As far as the notes/assignments/anything else I wrote up there, it's
cc-by-sa.
-cc
--
To post to this group, send an email to
Please let us know if you run into *any* examples of this--our goal is
to always produce standard compliant C89 or C++ code (or C99 if the
user has requested C99 complex support). Of course most Cython users
are using gcc or MSVC.
And just as important -- make sure to post some
I can see now:
=== python-2.6.4.p4 (Craig Citro, Jan 17, 2010) ===
* Move MACOSX_DEPLOYMENT_TARGET fix to sage-env, so that it's
used for all python-related spkgs. (This was leading to a
build issue with numpy and scipy on 10.4.)
we use very ancient build system in femhub, so we don't
Hi Ondrej,
Let me know if you have any hints what to try.
For sage, the issue was that Python was getting built with
MACOSX_DEPLOYMENT_TARGET set to 10.4, which is no longer valid in
10.6. This was leading to some issues with version mismatch issues
between libraries -- in particular, it was
And I'll fix this this weekend if nobody else does. It is probably a
problem doing a multi modular matrix multiply and not having enough
primes. I designed and mostly implemented the cycle linalg
algorithms in sage, so this is my fault, probably.
I helped with the cyclo linalg code, so I
And I'll fix this this weekend if nobody else does. It is probably a
problem doing a multi modular matrix multiply and not having enough
primes. I designed and mostly implemented the cycle linalg
algorithms in sage, so this is my fault, probably.
... and a fix is up. Robert Bradshaw
Thank you for the very long email.
I got an email off-list from someone else, which I believe rather put
your email into perspective.
I'm really sorry if anything in my email was offensive -- I knew the
thread was already fairly heated, and definitely didn't want to add to
that. (And I still
Hi David,
As one of the people William mentioned who'd complained about the
volume of Solaris email on sage-devel, I thought I should weigh in.
For reference, I actually stopped getting email from sage-devel and
switched to reading on the web because I felt like I couldn't handle
the volume. Mind
It would be nice to have an automatic build-farm where you can just
run tests
on all the needed platforms, and fix the results, but this would, for
instance, seem to
require a central repository with a current snapshot of Sage,
something hardly
feasible in any moment, except, perhaps,
The author should be nthiery and not newvalueoldvalue. You can find other
instance of this bug in eg. in [2],[3]. Is it known ? Should it be reported
somewhere ? Should I open a ticket about it ? Any idea where it is coming
from ? Is is sufficiently harmless so that it should be ignored ?
If this is confirmed, I don't mind using a more sane parent for the
tests. On the other hand, getting a segfault with an (admittedly ill)
piece of pure Python code is not good. Could any expert of the arcanes
of Integer comparison have a look?
Yep, using ZZ as a parent for something which
Hi Alexandre,
The problem is that I get the following messages (repeated about a
thousand of times) :
WARNING: display latex u'{\\rm SL}_2(\\ZZ)': latex exited with error:
[stderr]
dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib
Referenced from: /opt/local/bin/latex
Reason:
So it can't find libmpir.so.8. But I don't see why.
echo $LD_LIBRARY_PATH
/usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs
Total random guess: could it be that you need this to be in your
DYLD_LIBRARY_PATH, too?
-cc
--
To post to this group, send an email to sage-devel@googlegroups.com
To
I'm happy to change the question to something easier once people agree
on a reasonable question.
Does anybody know what sort of math a typical spammer would know? I
don't personally know any spammers :-)
How many wiki accounts are there? Could we switch to just having a
pool of people who
The single bad account can be deleted. Our text captcha system seems to work
well enough--the above doesn't seems to happen very often. It would be nice
if it was on account creation rather than every edit.
+1. (I accidentally typed '+21' at first -- which is probably closer
to my real
So the error seems to be coming from this command:
building 'sage.schemes.elliptic_curves.descent_two_isogeny' extension
/usr/local/gcc-4.4.1-sun-linker/bin/gcc -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -fPIC
-I/export/home/drkirkby/sage-4.3.1.rc0/local/include/FLINT/
[X] Yes, I don't use DSage (don't even know what it is...), and
think it should be removed from Sage.
I'm in this group, but I do know one (possibly the only?) DSage user
-- John Voight. Does anyone know if he still uses it?
-cc
--
To post to this group, send an email to
So I have no idea what's causing this, but here are at least some
reasonable things to try:
building 'sage.libs.fplll.fplll' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wall -g -Wall -g -fPIC -
I/mnt/usb1/scratch/rlm/sage-4.3.1.alpha3/local/include/fplll -I/mnt/
This could all be avoided if before changing a variable to maxima we
prepended it with _sage_var_ (say), and stripped those off when moving
from maxima back to Sage. This is worth considering...
I think we'll have to do something along these lines.
Basically, right now, any time that one
1) Kill the -O3, and see if the file compiles. If so, start bumping it
back up until you see the hang.
With -O2, it compiles fine. With -O3, it seems to hang.
Well, this means we've got an easy workaround for the time being.
Glancing at the two sets of warning messages below, I don't see
I think we do. Maxima sessions can have so much state that it's nice to keep
them separate to ensure consistency of the calculus modules. Also, that
means you won't be accidently clobbering your calculus variables, functions,
etc.
I think I agree in principle, but maybe not in practice. For
(2) making the
assume() command available at top-level point to
sage.calculus.calculus.maxima.assume *would* make it so that the user
could easily compute the integral that's frustrating them.
Again, (2) *was* the case since the beginning, and if it isn't now, it
is because somebody
Well, I think there is a neater way to go about it, which is
to exploit the Lisp package (i.e. namespace) machinery.
In summary, one can define groups of symbols at run time.
To quote the Zen of Python:
Namespaces are one honking great idea -- let's do more of those!
-cc
--
To post to this
Hey all,
Just wanted to mention that I'm pretty sure I've managed to stomp that
pesky OSX 10.6 bug (the Abort trap one). I'll mention more details
on the ticket (#7095), but the long and the short of it is that we
were having issues where we were confusing which system libraries were
getting
Yeah, this is wacky. I can tell you why it's happening, though someone
who's ever used Maxima before should really think about the right fix.
Here's the issue: in sage.calculus.calculus, there's an instance of
Maxima that gets created and passed the argument 'load(simplify_sum)'.
This causes the
time 1m5.56s).
Exiting spawned Maxima process.
Exiting spawned Maxima process.
[boxen ~] $
Notice the two spawned Maxima processes in the second one ...
-cc
On Jan 14, 2010 9:56 PM, kcrisman kcris...@gmail.com wrote:
On Jan 15, 12:14 am, Craig Citro craigci...@gmail.com wrote: Yeah
If you work on getting this merged upstream as a bug that's a good
selling point for us. We can produce a patched ebuild and possibly
get it accepted.
Do you have a bug tracking number of some kind for it?
I just submitted the bug:
http://bugs.python.org/issue7689
I'll let you know as I
Why is that too many? I like being able to type g.tab and see every
single
method that is available. If one is interested in trees,
g.treetab[tab]
gives a smaller subset. Or read the documentation.
I'm +.9 on this, because I do have one caveat: most of the sage
objects with half a million
Having thought about it more, there could be a problem with my original
approach. IF someone typed
$ export MAKE=/my/favorite/make -j 200
$ make
then my approach, and your suggestion for sage-env would work.
You've also got trouble if they do
$ export MAKE='/my/favorite/path with
basename does the trick, doesn't it?
Yep, seems like exactly what we want. The man page also tells me about
dirname, which seems to be the complementary utility we'd want in some
situations.
-cc
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this
Any ideas?
Totally just spitballing here, but should this line:
/opt/sunstudio12.1/bin/cc -o libpari-gmp.so.2.3.3 -G -h libpari-gmp.so.2
mp.o mpinl.o Flx.o Qfb.o RgX.o alglin1.o alglin2.o arith1.o arith2.o base1.o
base2.o base3.o base4.o base5.o bibli1.o bibli2.o buch1.o buch2.o
I did think through whether these things should be cached or not and am
prepared to write down my reasons for wanting them cached if anybody asks.
Putting at least some notes about this in docstrings/comments while
it's still in your head would probably be a good idea. (I haven't
looked at the
Hi John -- the offending character is the mu for microseconds. There are
probably classier fixes, but I edit the ipython source file in my sage
install. It's one of the ones in the traceback -- I'm on my phone and can't
look right now.
-cc
On Dec 16, 2009 10:36 AM, John Cremona
Hi John -- the offending character is the mu for microseconds. There are
probably classier fixes, but I edit the ipython source file in my sage
install. It's one of the ones in the traceback -- I'm on my phone and can't
look right now.
Line 1778 of
OK, so there's a python (or ipython) source code file which causes
problems when running ipython on some machines. Should that be
reported as a bug to the python people?
This could probably go upstream to IPython -- I've been meaning to do
it once I sit down and figure out whether it's just
What do you guys think about doing something similar for new standard
spkg's for Sage? I think 5 years is too long, given how new Sage is.
1 year or 2 years might be more reasonable, given the youth of Sage.
+1 to SageTex
+1 to 2 year maintenance commitment for new packages, though I
Hi David,
First, I want to thank you for all the work you've been doing to get
Sage to play nicely on Sun and HP-UX recently. I think that's really
helpful, and in particular, I think some of the comments you make
below are definitely things that will help Mike (or anyone else) make
lcalc better.
The question is what, exactly, makes actually
getting releases out so difficult? Is most of the time spent getting
things working on uncommon (presumably little-tested) systems? Are the
obstructions typically due to patches that were not actually ready to
go in (despite positive reviews) or
I wonder if it would also be good to archive bdists for one specific
Linux release, e.g., 32-bit x86 Ubuntu 8.04 LTS? Since then one can
easily get a virtual machine and drop our binary in it.
I think this would be a really good idea -- tar xjf on sage.math is a
*much* lower barrier to
And, let's be honest, no
release cycle is really going to be much shorter than that.
Are you sure? I personally did 100% of the releases for 3 years with
an average of 1-week for the release cycle.
Who knows -- maybe I'm wrong? Do you want to test it? Try doing
sage-4.2 in a week. Or
Hey Jason,
This one is likely to be funded by the NSA:
* (tentative!) [[daysbug2|Sage Days 19]] -- Seattle, WA (TBA); theme:
fixing bugs
Are the dates for this one totally open, or is there some date range
that we are working within?
Roughly speaking, we were thinking maybe over the
I would go so far as to recommend
that we auto-email the logs each day to sage-devel.
Note that typically less than 20 people are logged into #sage-devel at
any time, and there is no posted log, so the people that benefit from
#sage-devel are about 2% of the subscribers to the sage-devel
The question is, do we want this case to also raise an error, or the
function n() to iterate over the argument when it's iterable?
Why is there list comprehension in Python? I am -1 concerning
iteration over the argument.
Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
My preference would be that factor works for all integers. It's not
like it's hard to factor 0 or anything. We just return the
factorization object [(0,1)].
I'm pretty indifferent on this, though mildly against -- so -0, I think.
I think I would prfer the empty list of primes and a unit
Okay, that seems like a valid point, though I still disagree. I think
that we have two levels of consistency here: consistency with the
function and consistency with the concept of interval arithmetic. I
think that in this case, the interval arithmetic requirement is more
specific, so you
I speak from a programmatic point of view, though. I'd like to not be
surprised that the following doesn't work:
a=sin(floor(RIF( (1.1,1.2) )))
a.lower()
a.upper()
versus
a=sin(floor(RIF((1.5,2.5
a.lower()
a.upper()
I'm a little confused -- *neither* of those would work. The
I propose, but I'm perhaps missunderstanding.
a.lower().floor()
a.upper().ceil()
a.center().round()
I know about those and always eventually end up using them. But I
don't consider them easy.
Maybe include them and call them something like ilower and iupper?
I'm modeling this on isqrt:
So there are two things people could want from an interval i:
1) { floor(x) for x in i }
2) min { floor(x) for x in i }
I think that David's unhappy with floor doing (2). The other proposal
is to have x.floor() return the unique element in (1) when it's a
singleton, and raise an exception
I really think that floor, ceil, and round should return intervals when
they are fed intervals. I thought that was the whole point of interval
arithmetic. Shouldn't sin(floor(interval)) be an interval? It won't
be if floor automatically converts things to integers. Why should
floor,
I am going to start replying to messages that don't quote with good
netiquette.
+1. More power to you.
-cc
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
Perhaps a function get_help() (or help()) could print a link to
sage-support, could print the needed technical data, *and* could print
a brief introduction on how to post a good request (i.e., odds are
that we understand what the user means):
I much prefer something along these lines to any
There is such a search right here:
http://groups..google.com/group/sage-devel
http://groups.google.com/group/sage-devel
Yes. I meant I love that Sage has a google search. I wish the nauty
list had a google search, but I can't seem to find any search for their
archives at all!
When you build packages in parallel, it is possible that a build
failure is due to race conditions. That is a known problem with the
current parallel build system of Sage. The relevant ticket is #6374
http://trac.sagemath.org/sage_trac/ticket/6374
Actually, #6374 only fixes a race
On a fresh attempt to build from source, everything went fine. For
the first attempt, the only difference I can discern is that I had set
declare -x MAKE=make -j4
which in the past has smoothly allowed the build to use both
processors. Is this the cause of my failure?
No idea
What's the status on this one? I though that the bottom line of the
discussion at SD15 for this one (not to be mixed up with #5986) was that:
- Apart from importing the cPickle sources into the Sage tree, the
patch was essentially trivial (a 5 lines change to the cPickle
code) and
What about http://trac.sagemath.org/sage_trac/ticket/6374? There is a
patch up from 3 weeks ago, craigcitro (I guess) considers it a
blocker. Is it a blocker?
I think I labeled that a blocker simply so it got noticed and merged
in the next release cycle. It causes an annoying Heisenbug --
I found a situation when calling GF(2) returned the tuple
(TypeError, error coercing to finite field)
Nice find. Thanks for fixing this. See my comments on the ticket.
Indeed, there are several more -- this will find them, but also
produce some noise:
sage: search_src(return, Error)
Perhaps this facility exists. If not, do others thinks it would be worth
adding?
Yep, this is very handy -- and indeed already exists. Try sage -f -m
foo.spkg. (I have no idea what m stands for ... maybe William does?)
This will leave everything in $SAGE_ROOT/spkg/build after building the
The SPKG.txt for mpir-1.2.p4 shows:
== Changelog ==
=== mpir-1.2.p3 (Nick Alexander, June 9, 2009) ===
* Update to latest MPIR 1.2 final release.
=== mpir-1.2.p2 (William Stein, June 4, 2009) ===
* Update to latest MPIR 1.2 pre-release
Shall this just be ignored?
Do we want a trac
Hi David,
I've got a build running on my laptop at the moment, and I was
wondering: why does the install script not run the Flint test suite?
I'm puzzled by this since it did run Flint tests when I installed
4.0.2, which was actually the same Flint spkg version
(flint-1.3.0.p1.spkg)
We
Btw: would it be easy to extract from the current automated release
tools a python function that given a ticket number would return the
url's of the corresponding patches on trac?
See the first two functions in $SAGE_ROOT/local/bin/sage-apply-ticket.
-cc
Should the strings extra1, etc., be searched for only in the source
code, or should they be searched for both in the source code and the
file name?
I've definitely used the search path too behavior on purpose at
various times. In particular, doing things like adding matrix to the
search
I used to include a commit message when I did not use MQs. With MQs I
make the patch using sage -hg export qtip blah.patch and do not
get prompted for a commit message. Thelast one I did then ended up
with [mq]: intpts where the commit message would be, so perhaps that
is the commit
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the use for it either, but it's not a huge issue for me.
I want to weigh
It still seems rather dull to be honest. I'd appreciate any input.
You could always try walking them through the process by fixing a bug live
during the talk. I think William did this in his class last quarter, with
mixed results. It'd definitely be exciting, though. I don't know if you're
Hi Georg,
The root cause was the patch for trac #2513 which was incorporated in
Sage-4.0.2.alpha4, concerning the setting (or not ...) of the variable
LANG in the sage-env script.
I'll prepare a nice patch with some explanations for the R.spkg's
spkg-install script to use 'LANG=en_US.UTF-8
Interesting ... that means that the call to sys.exit(0) is generating
an exception that's getting caught in the except: clause. Can you file
a ticket for this? I'll happily review it. :)
I created a ticket #6364, without a patch though since it's outside
SAGE_ROOT/devel.
Actually, there's
Yes, the parallel build code was reworked for 4.0.1. Not sure why
we're seeing this, but still.
Well, the parallel build code in 4.0.1 *should* be contained to the
sage build itself (it's in sage's setup.py, and it's a separate
builder that one has to instantiate). I won't say it's
All seemed well with that test (all etsts passed, etc), but the final
lines of output are
All tests passed! Popping patches from queue ...
cd /home/jec/sage-4.0.2/devel/sage hg qpop -a
cd /home/jec/sage-4.0.2/devel/sage hg qdelete trac_5307.patch
Building failed with SystemExit: 0
--
Similar error with any other sage -merge command. Am I doing
something wrong?
I think I had this problem based on the current directory. Could you
try in a different directory? (I think this is a sage-wide problem
but I can't say with certainty.)
Yep, I remember Nick saying something
That did the trick -- ran fine and no failure line at the end. (I
moved that line to the end as suggested)
Interesting ... that means that the call to sys.exit(0) is generating
an exception that's getting caught in the except: clause. Can you file
a ticket for this? I'll happily review it.
Curiously enough, I think you will need very little hand-holding.
(But I'm willing to answer whatever questions I can.) Hopefully you
won't have a whole lot of spkgs to update, and merging new code is
very easy with Craig's apply_ticket.py program. (Check ~ncalexan/bin
for an hg
Hi all,
Here's rc3, which *should* be the last rc for this release cycle. I've
tested it on my laptop and the build farm, and I've had no troubles at
all, and it's currently going on a few other machines, so hopefully
that'll turn out fine, too. Please test it and let me know if you run
into
My most important debugging tool is logical deduction using my brain.
Someone want to open a trac ticket for including that in Sage? ;)
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group,
Hi all,
So everyone probably that we remembers that we won in the Science
category in the Trophees du Libre back in 2007. The 2009 awards have
been announced here:
http://www.trophees-du-libre.org/
Tim Abbott (who's the man behind sage being packaged for Debian) has
founded a startup called
All tests passed on 64-bit Ubuntu 9.04 and 32-bit Fedora 10. All tests
passed on bsd.math, except that #6242 is still a problem; the
birds_other.rst doctests segfault between a quarter and a third of the
time.
Yep, this is a known issue. This is the same as #6304, which David
Harvey had
Right now, the coercion section of Developer's guide starts off by
saying
**September 2008:** Much of this material is out of date. We are
working on a revised version.
(The relevant ticket is http://trac.sagemath.org/sage_trac/ticket/
4196.)
I think that this patch does a large part
Yes: #4196 talks about the developer's guide, while #5454 deals with
the reference manual.
True, but the new section in the reference manual has a fair bit of
exposition at the top. What else would you want in the developer's
guide that isn't already in the reference manual? Or a note saying
That's exactly what my original question was about...
Sorry, apparently I can't read at all this morning. Wow ...
In that case, I vote for (1). And, then, (5) of course. :)
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to
No, it is not deliberate. There is now an rc2 with this fixed an some other
things fixed:
http://sage.math.washington.edu/home/wstein/farm/src/sage-4.0.2.rc2.tar
Craig just made the above, by the way.
Actually, this isn't going to be the final rc2 -- I had added a
handful of fixes, and
In alpha2, m4ri fails to build on OS X 10.5 PPC (the computer in Craig
Citro's office). I'm trying rc0 now:
checking mm_malloc.h presence... no
checking for mm_malloc.h... no
checking for a sed that does not truncate output... /usr/bin/sed
checking the number of available CPUs... 1
In alpha2, m4ri fails to build on OS X 10.5 PPC (the computer in Craig
Citro's office). I'm trying rc0 now:
Ah, I really need to get an account on that machine one day. (I'm not
kidding -- I don't actually have one.) Also, I should find out the
hostname so I can ssh in. William, do you have
Hi David,
atlas-3.8.3.p2 (needed hack suggested by ATLAS developer)
Note blas is not in that list. But linbox is trying to build, which
claims to need blas
Actually, isn't ATLAS providing our BLAS? So maybe somehow the linbox
script can't find it after whatever changes were made to the
My vote is for arcsin.
+1
+1
+1
+1
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at
Merged in Sage 4.0.1.rc3:
#6179: John Palmieri: html -- doctest failure in sage-4.0.1.alpha0
[Reviewed by Mike Hansen]
#6217: Mike Hansen: fix issues with sorting in formal_sum [Reviewed by
William Stein]
#6230: Mike Hansen: Fix numerical noise and dictionary sorting issues
in 4.0.1.rc2.
Could we make the intel/powerpc split more obvious, or add
instructions, or make just one directory with both?
I vote a big +1 on one directory with both -- I think that'd be way easier.
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to
I've been
thinking about writing something like this up for a while now, but
there's never enough time to do everything one wants to in Sage :)
For the record, I'm in the process of writing a first system for doing
this right now. It's mostly done (I can automatically get a string of
patches
Trying an equivalent Cython NumPy test file yields the following error:
tar...@tarbox-laptop:$ python setup.py build_ext --inplace
Just to confirm here: are you running from a sage shell (i.e. by
running sage -sh)? Otherwise my first thought would be to try sage
-python ...
-cc
Should this be changed so that m.change_ring(R) always returns a copy?
Yes, I think so.
+1
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
How do you generally use the matrix after you call change_ring()? It
seems like the normal thing to do would be to change the matrix in
some
way. In that case, it is a huge bonus to have consistency between
returning the original object and returning a copy.
I usually use change_ring on
Maybe I'm just hung up on the word assign, since it does most of
what I would want, it just seems pushy.
I put the relevant usernames in the cc: box, presuming that they might
take the hint. Do they? I haven't collected data :)
Indeed, I think what Nick's describing is a really good
Perhaps the class definition for Element should be loaded initially.
It's there, it's just not imported into the top-level namespace:
sage: sage.structure.element.Element?
Type: type
Base Class: type 'type'
String Form: type 'sage.structure.element.Element'
Namespace:
Your comment about the sum function suggests to me that something
similar might be behind the weird thing I reported yesterday.
Yep, this is exactly the cause. If you look at rational.pyx, it
includes libs/pari/decl.pxi, which contains a declaration for Pari's
sum function. This then takes
I'm currently building/doctesting with (1) in place, and I'll report
back soon. gen.pyx passes all tests, so I suspect we're probably safe.
Doctesting is done, and no troubles -- so I've posted a patch here:
http://trac.sagemath.org/sage_trac/ticket/6039
-cc
This is the right fix. Looks good--are you sure we don't use pari's
sum anywhere else?
Well, I'm not 100% sure ... but given that the Python and pari ones
accept *different* numbers of arguments, I suspect we're okay. I tried
using search_src to find cases with two or more commas in a call to
Just out of curiosity, could you comment on my proposal that order
be removed, and replaced
by *only* additive_order and multiplicative_order? I personally never
use order anymore, since I'm
always scared it is the wrong order.
I'm definitely +1 on this -- I always resort to the methods
It'd also be helpful for someone to volunteer to say watch IRC and
relay any questions from there to the live event.
Good point! Thanks for volunteering! :P
(Sorry, couldn't resist.)
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to
Worse still:
sage: x = polygen(QQ)
sage: h = 4*x
sage: h%3
0
Over QQ[x], isn't 4*x = 3 * (4/3*x) ? Over ZZ, it's fine:
sage: x = polygen(ZZ)
sage: h = 4*x
sage: h%3
x
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to
1 - 100 of 187 matches
Mail list logo
