Last commit made on 2014-02-03
Get this branch:
git clone -b ratsimpexpons-default-true https://git.launchpad.net/~peterpall/maxima/+git/maxima.code

Branch merges

Branch information


Recent commits

65daa29... by Robert Dodier <email address hidden> on 2014-01-31

Change default value of ratsimpexpons to true, per discussion on mailing list.
However, that causes a lot of errors in the test suite, so I have put this
change on a branch. I have not figured out if the test suite discrepancies
are fixable in some way.

3604602... by Robert Dodier <email address hidden> on 2014-01-31

Merge branch 'master' of ssh://git.code.sf.net/p/maxima/code

fb94c9a... by Rupert Swarbrick on 2014-01-30

Fix bug number in test

It turns out I can't drive SourceForge's bug system. This patch just
makes the comment on a test point at the right bug...

d58d379... by Rupert Swarbrick on 2014-01-30

Trivial change to fix some subscripted integration

$DEFINT used STRIPDOLLAR to make a temporary integration variable when
you passed it a subscripted variable. This turns out to be less than
brilliant... The first example in #2676 hit this bug because it was
using x[1]. It turns out that X is the dummy variable used in the
integral lookup table (and (STRIPDOLLAR $X) => X).

Gensyms seem a saner way to make symbols...

2f9ae60... by Rupert Swarbrick on 2014-01-30

Document SUM-OF-INTSP & make it a bit more efficient

I was trying to track down another bug and had to think hard to work out
what this function was doing, so I figure I may as well leave the
documentation for the next visitor...

e61b215... by Jorge Barros de Abreu on 2014-01-29

Adding an example for commutative in Simplification.texi

ee204b4... by Jorge Barros de Abreu on 2014-01-29

Adding an example for combine in Simplification.texi

cab0b12... by Jorge Barros de Abreu on 2014-01-29

pt_BR update. Conclusion year estimated: 2015.

f40454a... by Jorge Barros de Abreu on 2014-01-29

pt_BR update. **passes** translation note.

250f80f... by Rupert Swarbrick on 2014-01-28

Deal more robustly with floating point errors

When we would have got a floating point exception, build the relevant
bigfloat instead.

  (%i180) 1000! * 0.01;

  (%o180) 4.023872600770938b2565
  (%i181) 1000! + 0.01;

  (%o181) 4.023872600770938b2567

This works on every supported lisp except Allegro, where handling a
type-error doesn't work. I intend to push this (which doesn't make
things worse on Allegro). If the missing functionality is annoying an
Allegro user, maybe someone with more experience of Franz lisps can
figure out a patch.

This fixes bug 2680 on non-Allegro lisps and, I suspect, helps lots of
other confused users. Searching the web for the strings that SBCL gives
on floating point overflow returns hits that include up Sage and
Launchpad bug reports about Maxima!

My logic for why this is "clearly the right thing to do" is that Lisp
has arbitrary sized integers. Maxima also has arbitrary sized floats, so
we should try to use them to avoid things exploding. I was a little
worried that there would be a massive performance hit, but was
pleasantly surprised.

Test suite timings slow down slightly on GCL (4%), CMUCL (3%). On the
other implementations, there doesn't seem to be a dramatic
difference. Bizarrely, CCL seems to get 2% faster! On those lisps that
report it, the number of bytes consed usually goes down with the patch,
by 0.5% or so.

Note that the "after patch" row doesn't include tests 251-253 of
rtest15.mac which I removed (because eg. 2*foo is no longer NaN), but I
hardly think they take 13 seconds...