Maxima -- GPL CAS based on DOE-MACSYMA - Code Log

Commit Date  
[c09de6] (HEADmaster) by Kris Katterjohn Kris Katterjohn

Fix missing and misplaced parentheses in docs for bindtest and splice

2014-03-09 02:29:19 Tree
[f3938e] by Yasuaki Honda Yasuaki Honda

I have added two simple tests to rtest_tex.mac:
and found that these two tests did not pass. This was due to my
mistake on the treatment of character quoting for tex output.
I fixed the issue and resulted the attached patch file.

The issue was that character #\# needs to be quoted when used as an output of tex(). However, the function quote-% does not quote the char. In addition, the simple fix of making quote-% quotes #\# introduces an incompatibility with the existing maxima programs that uses tex() function.

My fix in this patch avoids such incompatibility passes all the regression tests and rtest_tex.mac test.

2014-03-04 12:24:48 Tree
[d5397c] by Jorge Barros de Abreu Jorge Barros de Abreu

pt_BR update. Conclusion year estimated: 2015.

2014-03-02 18:23:55 Tree
[b909b2] by Dan Gildea Dan Gildea

Fix limit(x^2*exp(-%i*x - x), x, inf)
Fixes bug #2675

o src/limit.lisp:
expfactor: pass zero from highest order term through to next iteration

o tests/rtest_limit.mac:
now get one more existing test case correct
add limit(x^2*exp(-%i*x - x), x, inf);

o tests/rtest16.mac:
syntactic change in result

2014-03-02 18:05:17 Tree
[ff1b0f] by Jorge Barros de Abreu Jorge Barros de Abreu

pt_BR update. Including promote_float_to_bigfloat

2014-03-02 17:16:05 Tree
[119007] by Yasuaki Honda Yasuaki Honda

Two test cases for tex() with lisp objects are added.
tex-atom treats array objects and other objects differently
for string conversion as it is done in msize-atom function in
quote-% is now a wrapping function for quote-chars. This does
not change the behavior of quote-% while we allow tex-atom
to quote additional chars #\#.

2014-03-01 03:55:57 Tree
[e6298b] by Kris Katterjohn Kris Katterjohn

Fix the single-label case for plotting option 'label'

When adding a single label to a plot, the form [label,"label",x,y]
should be equivalent to [label,["label",x,y]]. Previously no label
was being written in this case.

2014-02-27 06:11:05 Tree
[f334aa] by Kris Katterjohn Kris Katterjohn

Fix a reoccurring typo in plotting error messages (argumet -> argument)

2014-02-26 22:58:36 Tree
[c15b63] by Kris Katterjohn Kris Katterjohn

Re-add the plot_format "openmath" synonym for "xmaxima"

This synonym was silently dropped in Maxima v5.32.0, even though the
documentation says it should still work. I imagine this was accidental
since a lot of the plotting functions were redone prior to this release.
See in particular commit 3066cbd7.

This removal broke (at least) the Embedded plotting in XMaxima (fixed
separately as commit 0fe27e05).

2014-02-26 22:56:12 Tree
[0fe27e] by Kris Katterjohn Kris Katterjohn

Fix Embedded plotting (Options->Plot Windows->Embedded) in XMaxima

The plot format "openmath" has been a synonym for "xmaxima" since commit
33999182 in November 2009. During the more recent reworkings of the
plotting functions (in December 2013, appearing in Maxima v5.32), this
synonym seems to have been silently dropped even though the documentation
still states that it should work.

This commit simply updates XMaxima to use "xmaxima" instead of "openmath"
for the Embedded plotting.

2014-02-26 22:33:43 Tree
[2d01ab] by Volker van Nek Volker van Nek

bugfix: %pi is now correctly rounded with high probability, improvement: better timing results for gcl,ccl,ecl,cmucl,clisp

2014-02-22 18:13:52 Tree
[50ae20] by Rupert Swarbrick Rupert Swarbrick

Avoid erroring when computing 1000!^0.1

This was the original bug report that triggered all the discussion about
promotion to big floats. Unfortunately, I seem to be illiterate and
didn't realise that I'd misread it as 1000!*0.1 until rtoy pointed it

More stupidly still, my changes for the former case actually end up
breaking this example, where exptrl assumed that (addk r1 0.0) was
always a float.

Maybe there's a better fix than this, avoiding any bigfloat conversion
when the result is small enough to fit in a machine float, but here's a
quick fix that at least gives a useful answer rather than a lisp error.

2014-02-19 22:38:02 Tree
[08bf62] by Rupert Swarbrick Rupert Swarbrick

Fix for bug #2676

The thing that was actually being tickled by the subscript in this
example was ELEMXPT. Unfortunately, I think if you fix that to deal
correctly with subscripted variables... you get a bind stack
overflow. Eugh.

So I went for a stupider fix in SININT itself, where we replace

integrate (f(x[y]), x[y])


integrate (f(z), z)

(where z is a gensym, obviously) and then substitute back at the end. I
think this is probably a much more robust approach than playing
whack-a-mole with all the bits of the integration code that assume
variables are atomic.

I don't replace all non-atomic expressions in this way. Presumably this
replacement would already exist if there weren't some integration tricks
we can do that are cleverer than just substituting.

2014-02-19 21:16:36 Tree
[54f974] by Rupert Swarbrick Rupert Swarbrick

Fix possible bug in diag.mac

This was caused by the (dubious) fact that:

(%i30) matrix([1]) . matrix([1]);
(%o30) 1

I'm not convinced that this product should be a scalar, but there's an
easy workaround in diag.mac that stops it exploding in this case (in
hindsight, I should probably have tested it with 1x1 matrices before!)

2014-02-19 20:21:22 Tree
[c6c922] by Rupert Swarbrick Rupert Swarbrick

%e^^A should not simplify to %e^A

When A is a literal matrix, the simplification happened because of some
incorrect logic in SIMPNCEXPT. I think this logic is supposed to allow
simplifications like

u^^3 = u^3

when u is known to be a scalar. I guess that if u=v*w, with v and w
scalar, this is be useful. Unfortunately, it doesn't deal with the
possibility that ^^ is being used to raise by a matrix.

With this patch, the matrix example gives a noun form (which, although
not particularly helpful, does have the advantage of not being wrong!)

2014-02-19 19:59:19 Tree
[fe0777] by Yasuaki Honda Yasuaki Honda

lisp objects can be passed to tex()

2014-02-18 14:17:55 Tree
[9fafef] by Rupert Swarbrick Rupert Swarbrick

Add the promote_float_to_bigfloat option variable

This controls automatic promotion on floating point overflow. The patch
contains code that (I think!) makes everything work, together with a
simple test and some documentation.

While writing the documentation, I noticed the float2bf variable (that
I'd never noticed before). It occurred to me that maybe we should just
use that as a flag instead. "float2bf" is a generic enough name that it
describes this operation too, and maybe this is a good way to avoid yet
another flag. On the flip side, flags with multiple magic properties are

I'll push this for now, and copy the above to the mailing list for
discussion. Hopefully we can decide the best way to structure this
before the next release.

2014-02-18 21:33:26 Tree
[ecd223] by Rupert Swarbrick Rupert Swarbrick

Fix build of pt_BR docs

Since I don't speak a word of Portuguese, let alone a Brazilian flavour,
I'm a little wary about editing these... But all I've done is moved two
subsubsections up to subsection level. These were directly contained in
a section, which wouldn't compile with the version of texinfo I have

The German docs don't compile on my system at the moment. I do speak a
little German, but the torrent of error messages on the screen in front
of me suggests that fixing that might be rather more work!

2014-02-18 20:39:55 Tree
[2b18fd] by Volker van Nek Volker van Nek

improve power tables and introduce nth root in GF

2014-02-16 12:11:51 Tree
[793ed0] by Volker van Nek Volker van Nek

improve comppi and make sure that %e and %pi are correct up to one mio digits

2014-02-16 11:59:55 Tree
[702026] by Kris Katterjohn Kris Katterjohn

Add Wronskian tests for hankel_1 and hankel_2

These test the numerical value of hankel_1 and hankel_2 with real order
(both real and complex argument) and complex order (complex argument).

There doesn't seem to be any other test in the test suite for the Hankel
functions, and doesn't have an evaluation tool for
them like it does for the other Bessel functions.

2014-02-12 22:06:20 Tree
[4fd85e] by Kris Katterjohn Kris Katterjohn

Numerically evaluate hankel_1 and hankel_2 when the order is complex

While the Hankel functions are defined using the Bessel functions J and Y,
hankel_1 and hankel_2 didn't support numerical evaluation when the order
was complex even though bessel_j and bessel_y did.

Numerical evaluation of hankel_1 and hankel_2 with complex orders is now
done using the hypergeometric representation of bessel_j and bessel_y.

(Also, while updating the documentation for hankel_1 and hankel_2, the
script update_examples has been run on Special.texi)

The test suite runs fine.

2014-02-12 21:59:49 Tree
[8d0d11] by Kris Katterjohn Kris Katterjohn

Remove code duplication of the hypergeometric representation of the
Bessel functions.

The hypergeometric representation of the Bessel functions bessel_j,
bessel_y, bessel_i and bessel_k is used when the order is complex,
and it's also returned when hypergeometric_representation is true.
This commit removes the duplication that was present between these
two cases for each function.

The test suite runs fine.

2014-02-12 21:55:11 Tree
[910d55] by Kris Katterjohn Kris Katterjohn

Add some tests for Bessel functions with complex order

This adds tests for the numerical value of bessel_j, bessel_y, bessel_i
and bessel_k with complex order. The reference values were obtained from as with the existing tests.

2014-02-12 21:49:21 Tree
[b49bec] by Kris Katterjohn Kris Katterjohn

Fix some copy-and-paste mistakes (and typos) in rtest14.mac comments

2014-02-12 21:47:48 Tree
Older >

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks