sage 2.8.13.alpha1 is out!

[mabshoff]

Hello folks,

alpha0->alpha1:

Get the tarball at

http://sage.math.washington.edu/home/mabshoff/sage-2.8.13.alpha1.tar
[161MB]

Remarks:

- merged updated libfplll (#1188) [this is still open until I merge
the
doctest by malb, but there is still discussion between wjp and malb
going on]
- merged numpy & scipy after Josh fixed the upgrade issue (#1198)
- merge various patches with positive reviews. For a complete list
see

http://www.sagetrac.org/sage_trac/query?status=closed&milestone=sage-2.8.13&order=id

For the open tickets see

http://www.sagetrac.org/sage_trac/query?status=new&status=assigned&status=reopened&milestone=sage-2.8.13&order=id

There are roughly 12 tickets with patches that need reviews, so if you
have some
time please have a look and comment on the ticket. Bonus if you
meniton if it
applies cleanly against alpha1 :)

Remarks:

- if I revert to the old sqlite.spkg the database.py segfault goes
away.
- the flint doctest failure is still there :(
- trouble with tickets:
* 1107 - doesn't apply cleanly any more

- tickets that should be invalidated:

* 391 - unless Nick replies to William's comment
* 787 - Soroosh's code, i.e. #1029 got merged
* 1130 - see discussion between John, David and Martin in the alpha0
thread
* 1143 - see the comment by William and Paul

- an oddity from sage/libs/cremona/homspace.pyx: it prints
"transposing..."

sage -t devel/sage-main/sage/libs/cremona/homspace.pyx
transposing...
[2.2 s]

The plan is to do an rc0 soon, i.e. about 12-18 hours after the alpha1
release. That
should include fixes for the flint doctest, more reviewed patches and
any other
issue that pops up with alpha1.

Thanks to all the reviewers, and please send me patches for the
doctest failures.

Cheers,

Michael


##################################################################

Comments from alpha0:

alpha0 took ages longer than planned and I mostly blame this on the
fact that
I build 2.8.12 from source seven or eight times for various reasons.
It is a
long story, let's just leave it at that. So far alpha0 contains mostly
updated
spkgs and the spelling fixes by Paul and one modular symbols fix. I am
pushing
alpha0 out and keep working at alpha1, first merging Josh's updated
sympy and
numpy spkgs and then merging more refereed fixes. Alpha0 is at

http://sage.math.washington.edu/home/mabshoff/sage-2.8.13.alpha0.tar

at it is about 2 mb smaller since I removed some outdated spkgs :)

##################################################################


Merged spkgs:

#563: linbox-20070915.p2.spkg (Michael Abshoff)
#1029: flint-0.9.p0.spkg (Robert Bradshaw, Michael Abshoff)
#1188: libfplll-2.1.3-20071117.spkg (Martin Albrecht, Michael Abshoff,
Willem Jan Palenstijn, also #1126)
#1152: sqlite-3.5.2.p1.spkg (Yi Qiang) [this might still get backed
out]
#1177: mpfr-2.3.0.p0.spkg (Michael Abshoff)
#1189: sympy-0.5.7.spkg (Ondrej Certik) [only the spkg, the patch has
been backed out]
#1197: cremona-20071116.spkg (John Cremona, William Stein, Ralf-Philip
Weinmann)
#1198: scipy-20071020-0.6.spkg (Josh Kantor)
#1198: numpy-20071020-1.0.3.1.spkg (Josh Kantor)
#1199: cvxopt-0.9.p1.spkg (Josh Kantor, Michael Abshoff, also #1121,
#1161)

Removed old spkgs:

pari-2.3.2.p3.spkg
gmp-4.2.1.p10.spkg
libpng-1.2.22.spkg

Things to check:

http://www.sagetrac.org/sage_trac/ticket/957 - is this still an issue?

##################################################################

Failing doctests:

devel/sage-main/build/sage/databases/database.py
[sqlite update is most likely to blame]
devel/sage-main/sage/libs/flint/fmpz_poly.pyx
[Robert's flint-9.spkg didn't build of for me, so I fixed the NTL link
issue in p0]

##################################################################
In detail:

sage -t devel/sage-main/sage/libs/flint/fmpz_poly.pyx
**********************************************************************
File "fmpz_poly.pyx", line 271:
sage: g / f
Exception raised:
Traceback (most recent call last):
File "/tmp/Work-mabshoff/release-cycles/sage-2.8.13.alpha0/local/
lib/python2.5/doctest.py", line 1212, in __run
compileflags, 1) in test.globs
File "<doctest __main__.example_13[3]>", line 1, in <module>
g / f###line 271:
sage: g / f
TypeError: unsupported operand type(s) for /:
'sage.libs.flint.fmpz_poly.Fmpz_poly' and
'sage.libs.flint.fmpz_poly.Fmpz_poly'
**********************************************************************

./sage -t devel/sage-main/build/sage/databases/database.py
sage -t devel/sage-main/build/sage/databases/database.py sh: line
1: 18385 Segmentation fault /tmp/Work-mabshoff/release-cycles/
sage-2.8.13.alpha0/local/bin/python .doctest_database.py >.doctest/out
2>.doctest/err


------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).
------------------------------------------------------------


A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
[1.6 s]
exit code: 256

----------------------------------------------------------------------

[Nick Alexander]

> * 391 - unless Nick replies to William's comment

At some point I will resubmit -- I'm just too busy right now. I
don't know what invalidate means but I'd appreciate it if the ticket
(and the patch!) stayed in TRAC.

Nick

[mabshoff]

No problem. I added your comment to the ticket in trac so that nobody
accidentally closes it.

> Nick

There is more trouble with flint-0.9. It fails to build on OSX 10.5. I
am looking into this later, but I might need to catch some sleep
first.

Cheers,

Michael

[mabshoff]

On Nov 20, 12:02 am, mabshoff <Michael.Absh...@fsmath.mathematik.uni-

I fixed the doctest:

diff -r 4cc57dcfd20b sage/libs/flint/fmpz_poly.pyx
--- a/sage/libs/flint/fmpz_poly.pyx Mon Nov 19 14:35:11 2007 -0800
+++ b/sage/libs/flint/fmpz_poly.pyx Mon Nov 19 15:48:05 2007 -0800
@@ -268,7 +268,7 @@ cdef class Fmpz_poly(SageObject):
sage: f = Fmpz_poly([3,4,5])
sage: g = f^5; g
11 243 1620 6345 16560 32190 47224 53650 46000 29375
12500 3125
- sage: g / f
+ sage: g // f
9 81 432 1404 2928 4486 4880 3900 2000 625
sage: f^4
9 81 432 1404 2928 4486 4880 3900 2000 625

So, any idea why we need "//" in this case?

>
> Cheers,
>
> Michael

Cheers,

Michael

[mabshoff]

On Nov 20, 12:48 am, mabshoff <Michael.Absh...@fsmath.mathematik.uni-

And probably also correct the description to "//" instead of "/".

On OSX 10.5 we should also make gfortran mandatory - see #1212. At the
moment the only issue left it reverting sqlite and fixing the compile
of flint-0.9 on 10.5

I am catching some sleep, cu all in about 8 hours.

Cheers,

Michael

[Bill Hart]

Can someone please send me a copy of the file in SAGE which sets up
the build environment for FLINT, i.e. it sets FLINT_GMP_LIB_DIR etc.,
and does various other platform specific things which fix build issues
on various platforms.

I've spent over an hour looking for the file in my sage installation
and I have to admit, I have absolutely no idea where it is. It isn't
in the flint spkg as far as I can tell.

If there are build issues on various platforms which get fixed in
SAGE, it would be great to fix them upstream.

By the way, FLINT 0.9 breaks on Core 2 Duo (this is not a build issue,
but a real live corner case bug in the FLINT C code). I've added a new
revision 1071 to the FLINT SVN repository at
https://flint.svn.sourceforge.net/svnroot/flint/trunk/ but I'm still
waiting to find out if this fixed the fmpz_poly-test failure on the
Core 2 Duo. Can one of the SAGE developers with a Core 2 check out
FLINT rev 1071 and report on whether fmpz_poly-test passes and then
let me know about it.

I spent a couple of days completely rewriting a couple of thousand
lines of code to try and fix this problem, so I'm really quite keen to
find out whether it now works. When it does I will make another
revision which reverts the test code to short tests and then FLINT 0.9
will be OK to go.

After that happens it would also be great if SAGE developers with
other platforms and OS's could run the test code in FLINT. In
particular the following tests should be run:

ZmodF-test
ZmodF_poly-test
fmpz_poly-test
fmpz-test
mpn_extras-test
ZmodF_mul-test

Perhaps we should think about whether these tests should be made part
of SAGE's make test.

Optionally I'd like to hear about any failures in:

long_extras-test

though this one is not directly relevant to the upcoming release of
FLINT 1.0 and shouldn't be tested directly by SAGE at this point
(otherwise new versions of FLINT will keep breaking SAGE, which we
don't want).

Bill.

On 20 Nov, 00:39, mabshoff <Michael.Absh...@fsmath.mathematik.uni-

[William Stein]

Hi,

On OSX ppc the sage alpha1 build fails with this. Unfortunately, I
can't work on fixing this since
I have committee work to do right now. If we can't fix this, a
reasonable option is to just comment
out building the cremona code in setup.py for now, and put some
nodoctests in the top
of the pyx files in devel/sage/sage/libs/cremona/*.pyx. This would
be OK for now.

sage/plot/plot3d/shapes.pyx -->
/Users/was/sage-2.8.13.alpha1/local//lib/python/site-packages//sage/plot/plot3d/shapes.pyx
running install
running build
running build_py
running build_ext
building 'sage.libs.cremona.homspace' extension
g++ -bundle -undefined dynamic_lookup
build/temp.macosx-10.3-ppc-2.5/sage/libs/cremona/homspace.o
-L/Users/was/sage-2.8.13.alpha1/local//lib -lcsage -lg0nntl -ljcntl
-lgmpxx -lntl -lgmp -lm -lstdc++ -lstdc++ -lntl -o
build/lib.macosx-10.3-ppc-2.5/sage/libs/cremona/homspace.so
/usr/bin/ld: warning can't open dynamic library: libpari-gmp.dylib
referenced from:
/Users/was/sage-2.8.13.alpha1/local//lib/libcsage.dylib (checking for
undefined
symbols may be affected) (No such file or directory, errno = 2)
/usr/bin/ld: warning can't open dynamic library: libcurvesntl.dylib
referenced from:
/Users/was/sage-2.8.13.alpha1/local//lib/libg0nntl.dylib (checking for
undefine
d symbols may be affected) (No such file or directory, errno = 2)
/usr/bin/ld: Undefined symbols:
_GENtostr referenced from libjcntl expected to be defined in libpari-gmp.dylib
_Z_factor referenced from libjcntl expected to be defined in libpari-gmp.dylib
_avma referenced from libjcntl expected to be defined in libpari-gmp.dylib
_bot referenced from libjcntl expected to be defined in libpari-gmp.dylib
_isprime referenced from libjcntl expected to be defined in libpari-gmp.dylib
_pari_init referenced from libjcntl expected to be defined in libpari-gmp.dylib
_strtoi referenced from libjcntl expected to be defined in libpari-gmp.dylib
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1
sage: There was an error installing modified sage library code.

real 0m21.464s
user 0m9.699s
sys 0m11.626s
ERROR installing SAGE

real 21m33.408s
user 19m45.068s
sys 1m44.815s
sage: An error occurred while installing sage-2.8.13.alpha1
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Users/was/sage-2.8.13.alpha1/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/Users/was/sage-2.8.13.alpha1/spkg/build/sage-2.8.13.alpha1 and type 'make'.

[William Stein]

On Nov 19, 2007 5:13 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> By the way, FLINT 0.9 breaks on Core 2 Duo (this is not a build issue,
> but a real live corner case bug in the FLINT C code). I've added a new

In the current alpha 1 the *build* of flint fails:

ops -fexpensive-optimizations -fPIC -funroll-loops -O3
ZmodF_poly-test.o test-support.o -o ZmodF_poly-test mpn_extras.o
mpz_extras.o memory-manager.o ZmodF.o Zmo
dF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o
mpz_poly.o ZmodF_poly.o long_extras.o
-L/Users/was/sage-2.8.13.alpha1/local/lib/ -L/Users/was/sage
-2.8.13.alpha1/local/lib/
-L/Users/was/sage-2.8.13.alpha1/local/include -lgmp -lpthread -lm
-lntl
gcc -std=c99 -I/Users/was/sage-2.8.13.alpha1/local/include/
-I/Users/was/sage-2.8.13.alpha1/local/include
-I/Users/was/sage-2.8.13.alpha1/local/include -funroll-lo
ops -fexpensive-optimizations -fPIC -funroll-loops -O3 -c
ZmodF_mul-test.c -o ZmodF_mul-test.o
ZmodF_mul.h:169: warning: inline function
â~@~X_ZmodF_mul_threeway_reduce2â~@~Y declared but never defined
ZmodF_mul.h:166: warning: inline function
â~@~X_ZmodF_mul_threeway_reduce1â~@~Y declared but never defined
ZmodF_mul.h:169: warning: inline function
â~@~X_ZmodF_mul_threeway_reduce2â~@~Y declared but never defined
ZmodF_mul.h:166: warning: inline function
â~@~X_ZmodF_mul_threeway_reduce1â~@~Y declared but never defined
gcc -std=c99 -I/Users/was/sage-2.8.13.alpha1/local/include/
-I/Users/was/sage-2.8.13.alpha1/local/include
-I/Users/was/sage-2.8.13.alpha1/local/include -funroll-lo
ops -fexpensive-optimizations -fPIC -funroll-loops -O3
ZmodF_mul-test.o test-support.o -o ZmodF_mul-test mpn_extras.o
mpz_extras.o memory-manager.o ZmodF.o ZmodF
_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o
mpz_poly.o ZmodF_poly.o long_extras.o
-L/Users/was/sage-2.8.13.alpha1/local/lib/ -L/Users/was/sage-2
.8.13.alpha1/local/lib/ -L/Users/was/sage-2.8.13.alpha1/local/include
-lgmp -lpthread -lm -lntl
Undefined symbols:
"__ZmodF_mul_threeway_reduce1", referenced from:
_test__ZmodF_mul_threeway_reduce in ZmodF_mul-test.o
"__ZmodF_mul_threeway_reduce2", referenced from:
_test__ZmodF_mul_threeway_reduce in ZmodF_mul-test.o
ld: symbol(s) not found

collect2: ld returned 1 exit status

make[2]: *** [ZmodF_mul-test] Error 1
Failed to build FLINT dylib.

real 0m28.796s
user 0m16.183s
sys 0m1.335s
sage: An error occurred while installing flint-0.9.p0

-----

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Bill Hart]

On 19 Nov, 23:48, mabshoff <Michael.Absh...@fsmath.mathematik.uni-

dortmund.de> wrote:

> sage: f = Fmpz_poly([3,4,5])
> sage: g = f^5; g
> 11 243 1620 6345 16560 32190 47224 53650 46000 29375
> 12500 3125
> - sage: g / f
> + sage: g // f
> 9 81 432 1404 2928 4486 4880 3900 2000 625
> sage: f^4
> 9 81 432 1404 2928 4486 4880 3900 2000 625
>
> So, any idea why we need "//" in this case?

I tried to figure this out, but encountered lots of problems.

Using // on objects of type ZZ['x'] ungracefully dumps me to the
command line.

Typing:

help()
topics
OPERATORS

tells me the help file is missing.

Typing:

??f.__div__

complains:

Docstring [source file open failed]:

When I found a function which did return source code, much of it was
black text on black background, so it just looked like gibberish. For
the longest time I thought this was actually python, so I had vowed
never to learn the language.

Working over ZZ['x'] if I accidentally type:

mul(f,f)

it amusingly multiplies f by 6.

If I use FLINT polynomials and type the same thing, it sits there
forever and there is no way to stop it. Of course the semantically
correct f.__mul__(f) works fine.

In answer to your question, I think // is divrem, which FLINT
implements.

FLINT also implements div in ZZ['x'], which is not the same thing as
div in SAGE. For example 3/4 returns 3/4, but 6/3 returns 2. At
present there is no function in FLINT which returns the quotient if
division is exact and nothing at all if it is not (in which case SAGE
seems to return a symbolic expression f/g). NTL has such a function,
but it isn't implemented in FLINT yet.

Instead polynomial division always returns something in ZZ['x'] in
FLINT. Basically it returns the same thing as what Magma returns when
you type f div g. It's a kind of normalised division, which just
happens to be the quotient when the division is exact.

Bill.

[Bill Hart]

It built fine on Robert's laptop the other night. Have I got the
architecture of Robert's laptop wrong? It is Core 2 Duo right?

Bill.

On 20 Nov, 02:38, "William Stein" <wst...@gmail.com> wrote:

> >https://flint.svn.sourceforge.net/svnroot/flint/trunk/but I'm still

[William Stein]

On Nov 19, 2007 6:56 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> It built fine on Robert's laptop the other night. Have I got the
> architecture of Robert's laptop wrong? It is Core 2 Duo right?

The build failure below is on a Xeon quad-core Mac Pro running OS X
10.5, i.e., bsd.math.washington.edu.

If you want to try building and testing FLINT on it, let me know off
list and I'll create an account for you.

[William Stein]

On Nov 19, 2007 6:47 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> > sage: f = Fmpz_poly([3,4,5])
> > sage: g = f^5; g
> > 11 243 1620 6345 16560 32190 47224 53650 46000 29375
> > 12500 3125
> > - sage: g / f
> > + sage: g // f
> > 9 81 432 1404 2928 4486 4880 3900 2000 625
> > sage: f^4
> > 9 81 432 1404 2928 4486 4880 3900 2000 625
> >
> > So, any idea why we need "//" in this case?

In python // means "floor divisions". It's the same semantics as \ in
PARI. It means divide and
forget the remainder. E.g.,
5 // 3 == 1

> Typing:
>
> ??f.__div__

// is not "__div__". You should just look at the relevant source file
anyways, which is in
SAGE_ROOT/devel/sage/sage/libs/flint/

> When I found a function which did return source code, much of it was
> black text on black background, so it just looked like gibberish. For
> the longest time I thought this was actually python, so I had vowed
> never to learn the language.

Didn't anybody mention to you that Python is a language where only
whitespace is significant?
For example, here is a Python program to factor integers in polynomial time:

> Working over ZZ['x'] if I accidentally type:
>
> mul(f,f)
>
> it amusingly multiplies f by 6.

Which is completely correct if you read the docs for mul, which
multiplies together the
elements of a list or list-like object. What it is doing is
multiplying together the
entries of f, but starting the product with f itself:

sage: R.<x> = ZZ[]
sage: f = R([3,4,5])
sage: mul(f,f)
300*x^2 + 240*x + 180
sage: 3*4*5 * f
300*x^2 + 240*x + 180

You can't just type random things you make up into a computer algebra
system and expect
them to behave like you want at the moment.

> If I use FLINT polynomials and type the same thing, it sits there
> forever and there is no way to stop it. Of course the semantically
> correct f.__mul__(f) works fine.

That's because it is trying to turn your FLINT poly into a list, and getting
an infinite list (since the default implementation for making a list
for something
hasn't been overridden yet for FLINT polys).

If you want to use functional notation for arithmetic use the operator module:

sage: operator.[tab]

sage: operator.mul(f, f)
25*x^4 + 40*x^3 + 46*x^2 + 24*x + 9
sage: operator.floordiv(f,f)
1

>
> In answer to your question, I think // is divrem, which FLINT
> implements.

No, it's floor division.

sage: operator.floordiv?
floordiv(a, b) -- Same as a // b.

> FLINT also implements div in ZZ['x'], which is not the same thing as
> div in SAGE. For example 3/4 returns 3/4, but 6/3 returns 2. At
> present there is no function in FLINT which returns the quotient if
> division is exact and nothing at all if it is not (in which case SAGE
> seems to return a symbolic expression f/g).

Sage doesn't return a symbolic expression from elements of ZZ['x']. It returns
an element of the fraction field, Frac(ZZ['x']). Maybe I'm being
confused though,
since there is a SymbolicExpression class in the calculus module, and that's
probably not what you're thinking of.

> NTL has such a function,
> but it isn't implemented in FLINT yet.
>
> Instead polynomial division always returns something in ZZ['x'] in
> FLINT. Basically it returns the same thing as what Magma returns when
> you type f div g. It's a kind of normalised division, which just
> happens to be the quotient when the division is exact.

That's like integer division in python, where:

>>> 2/3
0

This is definitely the *wrong* semantics for Sage, since it is not
mathematically correct.

That I think completely answers Michael Abshoff's question that
started this thread.

William

>
> Bill.

[Bill Hart]

Some kind of compiler bug. I've made changes in rev 1072 of FLINT
which should fix the problem. If not, we'll have to wait for Mabshoff
to awaken. I've no other ideas, so there's no point in setting me up
with an account on the machine at this point.

Bill.

On 20 Nov, 03:21, "William Stein" <wst...@gmail.com> wrote:

> > > >https://flint.svn.sourceforge.net/svnroot/flint/trunk/butI'm still

[William Stein]

On Nov 19, 2007 7:46 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> Some kind of compiler bug. I've made changes in rev 1072 of FLINT
> which should fix the problem. If not, we'll have to wait for Mabshoff
> to awaken. I've no other ideas, so there's no point in setting me up
> with an account on the machine at this point.

Whatever you did in rev 1072, it *DOES* fix the problem (I just tested it).
Great work!

William

[Bill Hart]

On 20 Nov, 03:30, "William Stein" <wst...@gmail.com> wrote:

> In python // means "floor divisions". It's the same semantics as \ in
> PARI. It means divide and
> forget the remainder. E.g.,
> 5 // 3 == 1
>
> > Typing:
>
> > ??f.__div__
>
> // is not "__div__". You should just look at the relevant source file
> anyways, which is in
> SAGE_ROOT/devel/sage/sage/libs/flint/

The reason I surmised what I did is because of this trace:

sage: from sage.libs.flint.fmpz_poly import Fmpz_poly
sage: f=ZZ['x'](3*x^2+2*x+1)
sage: g=ZZ['x'](2*x+1)
sage: f//g
DivRem: quotient not defined over ZZ
/home/was/s/local/bin/sage-sage: line 210: 15784
Aborted sage-ipython -c "$SAGE_STARTUP_COMMAND;" "$@"
wbhart@sage:~/flint/trunk$

The message "DivRem: quotient not defined over ZZ" is precisely what
the function DivRem in NTL outputs, not the function div. It gives
this error if one tries to divide one polynomial by another in ZZ['x']
when the leading coefficient of b is not +/-1, we aren't doing a
division by a degree zero poly, the division is not exact, the degree
of a is not less than b and where pseudo division fails to return a
result which indicates a quotient and remainder in ZZ['x']. NTL
apparently just aborts when none of the possible conditions are met,
and SAGE apparently doesn't catch that.

My assumption was that the correct function for floordiv in ZZ['x']
would be some derivative of NTL's div function, not DivRem.

The function div in NTL computes only q not r (the same thing as
computing q and r and forgetting r, except faster). It still requires
one of the conditions above to hold though, otherwise it returns an
error. The NTL documentation appears to be wrong if the NTL source
code is anything to go by since there are situations other than "b
with lead coefficient +/- 1" where the function will return a result
without raising an error. The NTL documentation says otherwise.

Either way, neither DivRem nor div in NTL has the same semantics as
Pari's \ operator.

Also, at one point I did type ?mul, but thought that this wasn't
relevant to polynomials, since it only talks about lists and gives
some examples including tuples and factorizations.

I did read the documentation for mul, but:

mul((),f) returns f
mul((f),f) doesn't return f^2 (I now see why)
mul((f,f),f) returns f^3
mul((f,f,f),f) returns f^4

I incorrectly guessed that mul(f,f) was doing something else entirely
and that I hadn't been able to figure out what. It's rather funny (and
completely coincidental) that the examples I tried all returned 6*f.
The two candidates I had in mind were m_whack(f) = nthprime(3)*f and
s_whack(f) = len(f)!*f.

:-)

Sorry to have taken the thread off course.

Bill.

[Bill Hart]

Replaced four occurrences of:

inline

with the python version:



:-)

Apparently that machine mangles function prototypes preceded by inline
only.

Bill.

On 20 Nov, 03:56, "William Stein" <wst...@gmail.com> wrote:

[Nick Alexander]

Check trac -- I just added this a few hours ago!

Nick