maxima-discuss Mailing List for Maxima -- GPL CAS based on DOE-MACSYMA

On Fri, Oct 17, 2025 at 2:02 PM serge de marre <sde...@gm...> wrote:
>
> Strangely enough, when running imaxima (an emacs mode which immediately displays expressions using tex), the expressions are looking good and calling the tex() function doesn't have those \left( and \right).
Imaxima has its own TeX code, and redefines some of the stuff which is
also present in Maxima. In particular MMINUS (unary minus) is given
right binding power equal to 100. I think that was the value in Maxima
a long time ago, but it was changed maybe 10 or 15 years ago to solve
some other problem having to do with parentheses.
All the best,
Robert

On Fri, Oct 17, 2025 at 11:54 AM LÓPEZ MEDINA, DAVID JAVIER
<Dav...@up...> wrote:
> (%i1) -1-2*x-(-3*y)-4*z;
>
> leads to the output
>
> (%o1) - 4 z + 3 y - 2 x - 1
>
> (what is nice), but the tex output is strange
>
> (%i2) tex(%)$
> $$-\left(4,円z\right)+3,円y-2,円x-1$$
Placement of parentheses is governed by what is called right binding
power and left binding power -- these are essentially operator
precedence levels. The rbp and lbp for various operators have been
adjusted over the years to solve parentheses placement problems, in
particular, to ensure that there are parentheses to make the
expression unambiguous. This sometimes leads to excess parentheses, as
we see here.
A quick fix for this specific problem is
:lisp (setf (get 'mminus 'tex-rbp) 100)
which, for TeX output, reduces the right binding power from its
current value (134) to 100. This is enough to get the expected
behavior in the example shown -- after that, I get
tex (-1-2*x-(-3*y)-4*z);
 => $$-4,円z+3,円y-2,円x-1$$
Whether the different binding power is generally desirable would
depend on how it interacts with other operators such as "+", "*", "/",
and "^". I will open a bug report about to keep track of whatever I
(or anyone else) can figure out.
Robert

Strangely enough, when running imaxima (an emacs mode which immediately
displays expressions using tex), the expressions are looking good and
calling the tex() function doesn't have those \left( and \right).
Running it in a regular shell (under emacs) does show the behaviour as
described by David.
[image: image.png]
I immagine this means (parts of) the tex() function is modified when
running imaxima, and maybe those could be reused to create a less
"cluttered" tex output ?
Serge
On Fri, Oct 17, 2025 at 8:54 PM LÓPEZ MEDINA, DAVID JAVIER <
Dav...@up...> wrote:
> Hi. I'm new in this list, apologies if this topic has been previously
> discussed.
>
> I don't understand very well how maxima and the *tex* function deal with
> negative signs. Running maxima 5.48.1 (using Lisp SBCL 2.5.9) in a terminal
> the input
>
> *(%i1) -1-2*x-(-3*y)-4*z;*
>
> leads to the output
>
> *(%o1) - 4 z + 3 y - 2 x - 1*
>
> (what is nice), but the *tex* output is strange
>
> *(%i2) tex(%)$*
> *$$-\left(4,円z\right)+3,円y-2,円x-1$$*
>
> What's the point of the parenthesis in *4,円z*? And why only in the
> leading term *-4 z* and not in the similar term *-2 x*? In my opinion the
> *tex* function should return
>
> *$$-4,円z+3,円y-2,円x-1$$*
>
> or maybe with both parenthesis (a bit uglier in my opinion),
>
> *$$-\left(4,円z\right)+3,円y-\left(2,円x\right)-1$$*
>
> I don't understand why the first term *4,円z* is different to the rest.
>
> Things look stranger in the case of function definitions. The output of
>
> *(%i3) f(x,y,z):=-1-2*x-(-3*y)-4*z;*
>
> is
>
> *(%o3) f(x, y, z) := - 1 - 2 x - (- 3) y + (- 4) z*
>
> Why the parenthesis in *(- 4) z* and not in *- 2 x*? In my opinion
> neither of both terms should have parenthesis.
>
> The previous example showed that the strange behaviour appeared before
> using the * tex* function, so it is nor only related with it. The
> different behaviour of terms *-2*x* and *-4*z* remains after using the
> *tex* function
>
> *(%i4) tex(%)$*
> *\begin{verbatim}*
> *f(x,y,z):=-1-2*x-(-3)*y+(-4)*z;*
> *\end{verbatim}*
>
> -----
>
> I have checked in wxmaxima 25.04.0 and the outputs are
>
> *(%o1) -(4*z)+3*y-2*x-1*
>
> (more similar to the *tex* output than to the console output), and
>
> *(%o3) f(x,y,z):=-1-2*x--3*y+-4*z*
>
> which is extremely ugly, with double operator *--* and *+-* without
> parenthesis and again closer to the *tex* output than to the console
> output. I know this is not a wxmaxima forum, I include their results only
> in case they clarify the *tex* and output behaviour.
>
> I believe in previous versions of maxima the behaviour with minus signs
> and *tex* was different. Can you explain me why it works now the way it
> does? Is it possible to make the *tex* function work as the output *(%o1)
> *in the console?
>
> Thanks in anticipation,
>
> David.
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Hi. I'm new in this list, apologies if this topic has been previously discussed.
I don't understand very well how maxima and the tex function deal with negative signs. Running maxima 5.48.1 (using Lisp SBCL 2.5.9) in a terminal the input
(%i1) -1-2*x-(-3*y)-4*z;
leads to the output
(%o1) - 4 z + 3 y - 2 x - 1
(what is nice), but the tex output is strange
(%i2) tex(%)$
$$-\left(4,円z\right)+3,円y-2,円x-1$$
What's the point of the parenthesis in 4,円z? And why only in the leading term -4 z and not in the similar term -2 x? In my opinion the tex function should return
$$-4,円z+3,円y-2,円x-1$$
or maybe with both parenthesis (a bit uglier in my opinion),
$$-\left(4,円z\right)+3,円y-\left(2,円x\right)-1$$
I don't understand why the first term 4,円z is different to the rest.
Things look stranger in the case of function definitions. The output of
(%i3) f(x,y,z):=-1-2*x-(-3*y)-4*z;
is
(%o3) f(x, y, z) := - 1 - 2 x - (- 3) y + (- 4) z
Why the parenthesis in (- 4) z and not in - 2 x? In my opinion neither of both terms should have parenthesis.
The previous example showed that the strange behaviour appeared before using the tex function, so it is nor only related with it. The different behaviour of terms -2*x and -4*z remains after using the tex function
(%i4) tex(%)$
\begin{verbatim}
f(x,y,z):=-1-2*x-(-3)*y+(-4)*z;
\end{verbatim}
-----
I have checked in wxmaxima 25.04.0 and the outputs are
(%o1) -(4*z)+3*y-2*x-1
(more similar to the tex output than to the console output), and
(%o3) f(x,y,z):=-1-2*x--3*y+-4*z
which is extremely ugly, with double operator -- and +- without parenthesis and again closer to the tex output than to the console output. I know this is not a wxmaxima forum, I include their results only in case they clarify the tex and output behaviour.
I believe in previous versions of maxima the behaviour with minus signs and tex was different. Can you explain me why it works now the way it does? Is it possible to make the tex function work as the output (%o1) in the console?
Thanks in anticipation,
David.

On Tue, 2025年10月14日 at 08:30 -0700, Robert Dodier wrote:
> I would be interested to try other examples you encounter in the
> material you're working on. I wouldn't be too surprised if I've
> overlooked something fundamental.
> 
> HTH & all the best.
> 
> Robert
Robert,
Thank you for your detailed reply! I have used both of your solutions.
I also modified the first to allow the dot operator to move into sums.
Everything works well and I should now be able to extend my quantum
mechanics package to do more interesting things like derive the
standard perturbation theory formulas analytically. This will make a
great addition to the package.
I'll keep the list posted for any other problems I may run into here.
Thanks again for all your help.
-Eric M

Eric, this problem of distributing some function over a sum has come up a
few times over the years, not surprising, but there isn't a built-in way to
handle it.
As an aside, I think it is a pretty natural extension of foo(a + b + c) -->
foo(a) + foo(b) + foo(c) which is handled by declare(foo, additive). I
think a built-in way to handle foo(sum(...)) --> sum(foo(...), ...) makes a
lot of sense, but I won't try to tackle that today. Also in some contexts
it would make sense to do the reverse, sum(foo) --> foo(sum), something
akin to an extension of the existing function intosum, but again, I won't
work on that today.
Here's what I said about it on another occasion.
https://sourceforge.net/p/maxima/mailman/message/34179838/
There are at least a few different ways to handle the problem and this is
just one of them. I am working with Maxima 5.48.1.
(%i2) matchdeclare (ss, lambda ([e], not mapatom(e) and (op(e) = 'sum or
op(e) = nounify('sum))));
(%o2) done
(%i3) tellsimp (myfunc (ss), apply (op(ss), cons (myfunc (first(ss)),
rest(args(ss)))));
(%o3) [myfuncrule1, false]
(%i4) S: sum(c[i]*g(i),i,1,N);
 N
 ____
 ╲
(%o4) ⟩ c g(i)
 ╱ i
 ̅ ̅ ̅ ̅
 i = 1
(%i5) myfunc (S);
 N
 ____
 ╲
(%o5) ⟩ myfunc(c g(i))
 ╱ i
 ̅ ̅ ̅ ̅
 i = 1
(%i6) myfunc ('sum('sum('sum(a[i,j,k],i,1,m),j,1,n),k,1,o));
 o n m
 ____ ____ ____
 ╲ ╲ ╲
(%o6) ⟩ ⟩ ⟩ myfunc(a )
 ╱ ╱ ╱ i, j, k
 ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅
 k = 1 j = 1 i = 1
So far, so good. That rule applies only to myfunc. If you want to work with
multiple functions like that, you can define additional rules, or you can
define a suitable property and then get Maxima to simplify any function
having that property, via the relatively-new (less than 10 years!) function
define_opproperty. Here's what I said about that another time.
https://sourceforge.net/p/maxima/mailman/message/36316278/
(%i7) define_opproperty (distributes_over_sum,
simplify_distributes_over_sum);
(%o7) done
(%i8) simplify_distributes_over_sum(e):= if not atom (first (e)) then if op
(first (e)) = nounify ('sum) then block ([ss: first (e)],
apply(op(ss),cons(op(e)(first(ss)),rest(args(ss))))) else e else e;
(%o8) simplify_distributes_over_sum(e) :=
if not atom(first(e)) then (if op(first(e)) = nounify('sum)
 then block([ss : first(e)], apply(op(ss),
cons(op(e)(first(ss)), rest(args(ss))))) else e) else e
(%i10) declare ([f, g, h], distributes_over_sum);
(%o10) done
(%i11) [ f(S), g(S), h(S), g(f(S)), h(g(f(S))) ];
 N N N
 ____ ____ ____
 ╲ ╲ ╲
(%o11) [ ⟩ f(c g(i)), ⟩ g(c g(i)), ⟩ h(c g(i)),
 ╱ i ╱ i ╱ i
 ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅
 i = 1 i = 1 i = 1
 N N
 ____ ____
 ╲ ╲
 ⟩ g(f(c g(i))), ⟩ h(g(f(c g(i))))]
 ╱ i ╱ i
 ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅
 i = 1 i = 1
Note that the definition of simplify_distributes_over_sum is a little
clumsy, because it is replicating the kind of expression part manipulation
which is built into the rule stuff (tellsmp, defrule, etc). I wanted to use
defrule but it doesn't have any effect because the operator simplification
function is called with simp: false -- this is necessary to prevent
indefinite recursions.
I would be interested to try other examples you encounter in the material
you're working on. I wouldn't be too surprised if I've overlooked something
fundamental.
HTH & all the best.
Robert

I've been looking at https://sourceforge.net/p/maxima/bugs/4619/
Maxima has two functions simpinf and infsimp that simplify expressions that involve the extended real numbers (minf, zerob, zeroa, ind, inf, infinity, and und). The function simpinf handles more cases than does infsimp.
The one argument limit function generally calls first calls simpinf, I think, but then it sometimes also calls infsimp. I'm not sure what kinds of expressions infsimp is supposed to be able to handle.
It seems like simpinf and infsimp should be blended. Does anybody know exactly what kinds of expressions infsimp should be able to handle?
I collected all 59,000 (approx.) calls to infsimp from the testsuite. My guess is that all the inputs are affine expressions in minf or inf, but there are a few exceptions, for example exp(minf).
Having both function names simpinf and infsimp is an accident waiting to happen.
--Barton

Hi Robert,
you're right! My first thoughts were buggy and I misinterpreted the
order of execution... here is a way to put a matrix without borders in
a cell of a normal matrix. Code:
 to_lisp();
 (setf (get '$barematrix 'dimension) 'dim-$barematrix)
 (defun dim-$barematrix (form result)
 (let (($display_matrix_brackets nil))
 (dim-$matrix form result)))
 (to-maxima)
 M1 : barematrix([a,b],[c,d]);
 M2 : matrix([M1,e],[f,g]);
and output:
 (%i4) M1 : barematrix([a,b],[c,d]);
 a b
 (%o4)
 c d
 (%i5) M2 : matrix([M1,e],[f,g]);
 [ a b ]
 [ e ]
 (%o5) [ c d ]
 [ ]
 [ f g ]
 (%i6)
Cheers =),
 Eduardo
On 2025年10月12日 at 19:50, Robert Dodier <rob...@gm...> wrote:
> On Sun, Oct 12, 2025 at 3:16 PM Eduardo Ochs <edu...@gm...>
> wrote:
> > I don't see a way to put a matrix without brackets inside a matrix
> > with brackets.
>
> The display flags affect all expressions being displayed, so all
> matrices are displayed the same, all boxes displayed the same, all
> determinants the same too. So the only way (short of reorganizing the
> code) to get one expression displayed with one set of display flags
> and another displayed with a different set is to define different
> operators. This isn't a very satisfactory solution because any new
> operators won't have the same properties (algebraic and otherwise) as
> the existing built-in operators.
>

On Sun, Oct 12, 2025 at 3:16 PM Eduardo Ochs <edu...@gm...> wrote:
> Works here! Very neat!
Great, glad to hear it.
> I don't see a way to put a matrix without brackets inside a matrix
> with brackets.
The display flags affect all expressions being displayed, so all
matrices are displayed the same, all boxes displayed the same, all
determinants the same too. So the only way (short of reorganizing the
code) to get one expression displayed with one set of display flags
and another displayed with a different set is to define different
operators. This isn't a very satisfactory solution because any new
operators won't have the same properties (algebraic and otherwise) as
the existing built-in operators.
As an example one could define mymatrix1 and mymatrix2 and set up
display functions so they're displayed differently. But then they
won't be treated the same as existing matrix expressions in algebraic
functions.
One could, I guess, put display flags in the expression car, although
I'm not too crazy about the idea. It's not the most terrible idea in
the world, although I don't want to undertake it, and anyway I'm on
the fence as to whether it's a good idea or not.
Robert

Works here! Very neat!
I don't see a way to put a matrix without brackets inside a matrix
with brackets. Is that possible already? If not, can you consider that
a user request? =)
 Cheers,
 Eduardo =)
On 2025年10月12日 at 14:33, Robert Dodier <rob...@gm...> wrote:
> I've taken the liberty of extending the display flags for matrix,
> determinant, and box expressions. See commits 99a826..66001d on master.
>
> For matrix(...), display_matrix_brackets (default true) governs whether
> brackets are placed on either side of a matrix. Otherwise the matrix
> elements are displayed without brackets. This flag has the expected effect
> when display2d_unicode = true and display2d_unicode = false.
>

One good reason that *.* is binary and not syntactically n-ary is that
*. *isn't
associative if *dotassoc* is *false*.
I suppose we could define an n-ary instance of *.* to be left-associative
(say) if *dotassoc* is *false*.
I wonder much more complicated it would make the *.* simplification and
pattern-matching code if it had to handle both cases.
On Thu, Oct 2, 2025 at 2:46 PM Robert Dodier <rob...@gm...>
wrote:
> On Thu, Oct 2, 2025 at 9:56 AM Richard Fateman <fa...@gm...> wrote:
>
> > while the syntax extension facility in Maxima allows you to say
> > nary( foo);
> > and then type
> > a foo b foo c
> > all the plausible aspects of this are probably NOT supported.
>
> Agreed, to some extent; there are limits to everything. However, there
> is more that is possible in this case; read on.
>
> > Thus one can type
> > a foo b := a+b;
> > 3 foo 4 returns 7. great.
> > a foo b foo c := a+b-c
> > 3 foo 4 foo 1 returns 6. great
> > 3 foo 4 returns 'too few arguments supplied... ' . oops.
>
> One can say nary("foo"); and then "foo"([x]) := /* some operation on
> an indeterminate number of arguments e.g. */ apply ("+", x); and then
> you get the expected behavior:
>
> nary("foo");
> "foo" ([x]) := apply ("+", x);
> "foo" (); => 0
> "foo" (123); => 123
> 3 foo 3; => 6
> 5 foo 2 foo 98; => 105
> 4 foo 8 foo 3 foo 7; => 22
> a foo b foo a foo b; => 2*b + 2*a
>
>
> > Also, the simplifier knows about commutativity, associativity, etc for
> operators +, *.
> > But it doesn't know about foo. Is
> > b foo a to be simplified to a foo b?
> > Is p foo p foo q the same as p foo q?
>
> One can say declare("foo", symmetric); or equivalently declare("foo",
> commutative); and then
>
> '(a foo b foo a foo b); => a foo a foo b foo b
>
> See also declare("foo", antisymmetric); and maybe others.
>
>
> The biggest gap in Maxima's otherwise-admirable extensibility, in this
> context, is that rules (tellsimp / tellsimpafter / defrule / defmatch)
> don't recognize any n-ary operators aside from "+" and "*". For
> example, a longstanding thorn is that "." isn't handled as an n-ary
> operator -- one can define rules on "." only for a specific number of
> arguments. I have made some experiments from time to time to see if I
> could make that happen, but didn't come to any conclusions.
>
> HTH
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

I've taken the liberty of extending the display flags for matrix,
determinant, and box expressions. See commits 99a826..66001d on master.
For matrix(...), display_matrix_brackets (default true) governs whether
brackets are placed on either side of a matrix. Otherwise the matrix
elements are displayed without brackets. This flag has the expected effect
when display2d_unicode = true and display2d_unicode = false.
For determinant(...), display_determinant_bars (default true) governs
whether vertical bars are placed on either side of the matrix in an
expression 'determinant(matrix(...)) . Otherwise the expression is
displayed as an ordinary function call, as it is now. This flag has the
expected effect when display2d_unicode = true and display2d_unicode = false.
For box(...), display_box_double_lines (default true) governs whether
box(...) expressions are drawn with double-line Unicode characters, as they
are now, or single-line Unicode characters.This flag has an effect only
when display2d_unicode = true. I guess I could have imagined something
sensible to do when display2d_unicode = false for the sake of consistency
... I might still do that.
I only worked on the 2-d pretty printer -- I didn't try to update any other
displays such as tex(...) output.
Here is a tiny demo. See rtest_unicode_display.mac and
test_matrix_display.mac in the tests folder for additional examples.
(%i2) foo: matrix ([a, b, c], [d, e, f], [g, h, i]);
 ┌ ┐
 │ a b c │
 │ │
(%o2) │ d e f │
 │ │
 │ g h i │
 └ ┘
(%i3) 'determinant (foo);
 │ a b c │
 │ │
(%o3) │ d e f │
 │ │
 │ g h i │
(%i4) box (%o2);
 ╔═══════════╗
 ║┌ ┐║
 ║│ a b c │║
 ║│ │║
(%o4) ║│ d e f │║
 ║│ │║
 ║│ g h i │║
 ║└ ┘║
 ╚═══════════╝
(%i5) display_matrix_brackets: false $
(%i6) foo;
 a b c
(%o6) d e f
 g h i
(%i7) display_box_double_lines: false $
(%i8) %o4;
 ┌─────────┐
 │ a b c │
 │ │
(%o8) │ d e f │
 │ │
 │ g h i │
 └─────────┘
This 2-d Unicode stuff looks pretty bad in the Gmail composer, as
the vertical characters don't join up. It looks much better in a terminal,
where the vertical characters abut one another. I hope that what you see is
more like the latter than the former.
Hope this helps in some way.
Robert

Hi all,
yesterday I sent this message -
 https://sourceforge.net/p/maxima/mailman/message/59245215/
about tricks to understand the display functions...
I just wrote something slightly better.
If I run this in Maxima
 load("/tmp/dim-save.lisp");
 a^b;
 a^bc;
 ab^cd;
 ab^(cd^ef);
 ab^(cd^(ef[gh]));
 :lisp (dim-show)
I get this output:
 (%i1) load("/tmp/dim-save.lisp")$
 (%i2) a^b;
 b
 (%o2) a
 (%i3) a^bc;
 bc
 (%o3) a
 (%i4) ab^cd;
 cd
 (%o4) ab
 (%i5) ab^(cd^ef);
 ef
 cd
 (%o5) ab
 (%i6) ab^(cd^(ef[gh]));
 ef
 gh
 cd
 (%o6) ab
 (%i7) :lisp (dim-show)
 (REV-OUT (( % o 2 ) (0 0) a (0 1 b)))
 (REV-OUT (( % o 3 ) (0 0) a (0 1 b c)))
 (REV-OUT (( % o 4 ) (0 0) a b (0 1 c d)))
 (REV-OUT (c d (0 1 e f)))
 (REV-OUT (( % o 5 ) (0 0) a b (0 1 c d (0 1 e f))))
 (REV-OUT (c d (0 2 (0 0 e f) (0 -1 g h))))
 (REV-OUT (( % o 6 ) (0 0) a b (0 1 c d (0 2 (0 0 e f) (0 -1 g h)))))
 NIL
 (%i7)
Here is dim-save.lisp:
cat > /tmp/dim-save.lisp <<'%%%'
(defvar dim-saved)
(setq dim-saved nil)
(defun dim-save (&rest plist)
 (setq dim-saved `(,@dim-saved ,(copy-tree plist)))
 plist)
(defun dim-show ()
 (let ((*print-pretty* nil))
 (loop for plist in dim-saved
 do (format t "~a~%" plist))))
(defun my-reverse-nnlist (abcd)
 (let* ((a (car abcd))
(b (cadr abcd))
(cd (cddr abcd)))
 `(,a ,b ,@(my-reverse cd))))
(defun my-reverse-otherlist (list)
 (reverse (mapcar #'my-reverse list)))
(defun my-reverse (o)
 (if (listp o)
 (if (numberp (car o))
 (my-reverse-nnlist o)
 (my-reverse-otherlist o))
 o))
;; `dimension-superscript-saving-1' saves a lot of information.
;; `dimension-superscript-saving-2' saves just the essential.
(defun dimension-superscript-saving-1 (form result)
 (dim-save :pos 1 :form form :result result)
 (let ((out (dimension-superscript form result)))
 (dim-save :pos 2 :form form :result result :out out)
 out))
(defun dimension-superscript-saving-2 (form result)
 (let ((out (dimension-superscript form result)))
 (dim-save :rev-out (my-reverse out))
 out))
(displa-def mexpt dimension-superscript-saving-2)
(displa-def %mexpt dimension-superscript-saving-2)
%%%
 Cheers,
 Eduardo

Hello,
As Jaime suspected at the beginning, the error was due to a simple mistake on my part, something I totally overlooked while I was focused on the syntax. I want to thank you all, especially to Jaime for all the help,
Regards,
Ilgar
________________________________
From: Jaime Villate <vi...@fe...>
Sent: Sunday, October 12, 2025 16:10
To: Kemal Ilgar Eroglu <kie...@ho...>; Daniel Volinski via Maxima-discuss <max...@li...>
Subject: Re: [Maxima-discuss] About the rk solver
Hello,
Ilgars code works fine with Maxima's rk function, giving similar results as the Rust program that he used to implement 4th-order Runge-Kutta. There were just a few errors in the definition of the derivatives. I still have to investigate why rf45 fails.
Regards,
Jaime
On 09/10/25 09:17, Kemal Ilgar Eroglu wrote:
Hello Jaime and Daniel,
Thanks for the quick response.
@Daniel: In that example I get "true" as well. I got the expected results in all simple trials.
@Jaime: I didn't know about how to use the single quote sign to see the input. I was assuming that maxima "unfolded" the function calls etc. into the identical expression, but you showed me how to see it explicitly, thanks.
I also expect the reason to be some triviality, but I have checked the code so many times that I decided to ask about it here out of desperation. Also, I would expect rkf45 to yield a similar result, but it doesn't look like that. That contributed to my suspicion that something about the machinery behind could be the culprit.
I will do some more checks today (with a fresh mind!), including a comparison with rkf45. In any case I will report my results here. If I can't find what the problem is I will just share the code here.
Thanks again,
Ilgar
________________________________
From: Daniel Volinski via Maxima-discuss <max...@li...><mailto:max...@li...>
Sent: Thursday, October 9, 2025 05:08
To: max...@li...<mailto:max...@li...> <max...@li...><mailto:max...@li...>
Subject: Re: [Maxima-discuss] About the rk solver
Hi Ilgar,
I'm using Maxima "5.38.1". I don't see any failure:
In my case I get:
P1:rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
[[0.0,1.0,1.0],[0.2,1.224661396266667,
1.46582874],[0.4,1.52398346186353,2.091705547236073],[
0.6000000000000001,1.958124694600492,2.935362811658838],
[0.8,2.639625806630312,4.085536123295163],[1.0,
3.7933966821123,5.685866197365394]]
The same with:
P2:rk([x+x*(t2), x+y], [x,y], [1,1], [t,0,1,0.2]);
Ergo: is(P1=P2); => true
Could you please be more specific about "for some reason it doesn't work"?
Do you get any error messages?
Daniel Volinski
En miércoles, 8 de octubre de 2025, 23:14:09 GMT+3, Jaime Villate via Maxima-discuss <max...@li...><mailto:max...@li...> escribió:
Hello,
If instead of P1:... and P2:... you quote the rk commands you will see what you are giving to rk, namely:
'rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
---> rk([t^2*x+x,y+x],[x,y],[1,1],[t,0,1,0.2])
'rk([x+x*(t^2), x+y], [x,y], [1,1], [t,0,1,0.2]);
---> 'rk([t^2*x+x,y+x],[x,y],[1,1],[t,0,1,0.2])
Namely, both in the case of P1 and P2 you're passing to rk the same list for the right-hand sides of the differential equations, which are two expressions that depend on t, x and y (the independent variable t and the two state variables x and y, as the manual says it should be).
The fact that in the case of P1 you went around the bushes by defining "functions" is of no relevance.
I still don't understand why your code failed but I suspect that is due to some triviality and not what you think.
Regards,
Jaime (author or rk)
On 08/10/25 19:20, Kemal Ilgar Eroglu wrote:
Hello everyone,
I am trying to numerically solve an ODE system using the RK4 algorithm. I first attempted to do it using Sagemath which uses maxima's rk function to do the job. This is a system with 14 unknown functions and the right-hand sides of the equations include the variables themselves as well as calls to some functions of these variables. These functions are defined in the script. From my experiments with simple examples I know that Sage and/or maxima can handle this kind of input, see below.
The results did not come as I expected, so, (suspecting some kind of translation error from Sage to maxima) I tried to do the computations directly on maxima itself. It was failure again. I ended up implementing the RK4 algorithm for this system using the Rust language and finally got the correct results. By the way, I also tried the rkf45 function but its output seemed to be even more divergent.
So, my question is: What exactly are the limitations of the rk function? The documentation for rk says "The only variables that may appear in those expressions are the independent variable and any of the dependent variables.", but apparently maxima can handle more than that. For example, the following code will output "true":
load(dynamics);
f1(t) := t^2;
f2(u) := x*f1(u);
x_times_t_squared : f2(t);
x_deriv : x + x_times_t_squared;
y_deriv : x+y;
P1:rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
P2:rk([x+x*(t^2), x+y], [x,y], [1,1], [t,0,1,0.2]);
is(P1=P2);
This is the kind of thing I was doing in my code, but for some reason it doesn't work (I can post my code if necessary, but the example above gives the idea I think). I checked it countless times for typos, compared it against the working Rust code, and the maxima code looks correct. Maybe I am bumping into some kind of limitation which I don't know. Any ideas?
Ilgar
_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Hello,
Ilgars code works fine with Maxima's rk function, giving similar results 
as the Rust program that he used to implement 4th-order Runge-Kutta. 
There were just a few errors in the definition of the derivatives. I 
still have to investigate why rf45 fails.
Regards,
Jaime
On 09/10/25 09:17, Kemal Ilgar Eroglu wrote:
> Hello Jaime and Daniel,
>
> Thanks for the quick response.
>
> @Daniel: In that example I get "true" as well. I got the expected 
> results in all simple trials.
>
> @Jaime: I didn't know about how to use the single quote sign to see 
> the input. I was assuming that maxima "unfolded" the function calls 
> etc. into the identical expression, but you showed me how to see it 
> explicitly, thanks.
>
> I also expect the reason to be some triviality, but I have checked the 
> code so many times that I decided to ask about it here out of 
> desperation. Also, I would expect rkf45 to yield a similar result, but 
> it doesn't look like that. That contributed to my suspicion that 
> something about the machinery behind could be the culprit.
>
> I will do some more checks today (with a fresh mind!), including a 
> comparison with rkf45. In any case I will report my results here. If I 
> can't find what the problem is I will just share the code here.
>
> Thanks again,
> Ilgar
>
>
> ------------------------------------------------------------------------
> *From:* Daniel Volinski via Maxima-discuss 
> <max...@li...>
> *Sent:* Thursday, October 9, 2025 05:08
> *To:* max...@li... 
> <max...@li...>
> *Subject:* Re: [Maxima-discuss] About the rk solver
> Hi Ilgar,
>
> I'm using Maxima "5.38.1". I don't see any failure:
>
> In my case I get:
>
> P1:rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
> [[0.0,1.0,1.0],[0.2,1.224661396266667,
> 1.46582874],[0.4,1.52398346186353,2.091705547236073],[
> 0.6000000000000001,1.958124694600492,2.935362811658838],
> [0.8,2.639625806630312,4.085536123295163],[1.0,
> 3.7933966821123,5.685866197365394]]
>
> The same with:
> P2:rk([x+x*(t2), x+y], [x,y], [1,1], [t,0,1,0.2]);
>
> Ergo: is(P1=P2); => true
>
> Could you please be more specific about "for some reason it doesn't work"?
> Do you get any error messages?
>
> Daniel Volinski
>
> En miércoles, 8 de octubre de 2025, 23:14:09 GMT+3, Jaime Villate via 
> Maxima-discuss <max...@li...> escribió:
>
>
> Hello,
>
> If instead of P1:... and P2:... you quote the rk commands you will see 
> what you are giving to rk, namely:
>
>
> 'rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
>
> --->  rk([t^2*x+x,y+x],[x,y],[1,1],[t,0,1,0.2])
>
>
> 'rk([x+x*(t^2), x+y], [x,y], [1,1], [t,0,1,0.2]);
>
>
> ---> 'rk([t^2*x+x,y+x],[x,y],[1,1],[t,0,1,0.2])
>
>
> Namely, both in the case of P1 and P2 you're passing to rk the same 
> list for the right-hand sides of the differential equations, which are 
> two expressions that depend on t, x and y (the independent variable t 
> and the two state variables x and y, as the manual says it should be).
>
>
> The fact that in the case of P1 you went around the bushes by defining 
> "functions" is of no relevance.
>
>
> I still don't understand why your code failed but I suspect that is 
> due to some triviality and not what you think.
>
>
> Regards,
>
> Jaime (author or rk)
>
>
> On 08/10/25 19:20, Kemal Ilgar Eroglu wrote:
> Hello everyone,
>
> I am trying to numerically solve an ODE system using the RK4 
> algorithm. I first attempted to do it using Sagemath which uses 
> maxima's rk function to do the job. This is a system with 14 unknown 
> functions and the right-hand sides of the equations include the 
> variables themselves as well as calls to some functions of these 
> variables. These functions are defined in the script. From my 
> experiments with simple examples I know that Sage and/or maxima can 
> handle this kind of input, see below.
>
> The results did not come as I expected, so, (suspecting some kind of 
> translation error from Sage to maxima) I tried to do the computations 
> directly on maxima itself. It was failure again. I ended up 
> implementing the RK4 algorithm for this system using the Rust language 
> and finally got the correct results. By the way, I also tried the 
> rkf45 function but its output seemed to be even more divergent.
>
> So, my question is: What exactly are the limitations of the rk 
> function? The documentation for rk says "The only variables that may 
> appear in those expressions are the independent variable and any of 
> the dependent variables.", but apparently maxima can handle more than 
> that. For example, the following code will output "true":
>
> load(dynamics);
>
> f1(t) := t^2;
>
> f2(u) := x*f1(u);
>
> x_times_t_squared : f2(t);
>
> x_deriv : x + x_times_t_squared;
> y_deriv : x+y;
>
> P1:rk([x_deriv, y_deriv], [x,y], [1,1], [t,0,1,0.2]);
>
> P2:rk([x+x*(t^2), x+y], [x,y], [1,1], [t,0,1,0.2]);
>
> is(P1=P2);
>
>
> This is the kind of thing I was doing in my code, but for some reason 
> it doesn't work (I can post my code if necessary, but the example 
> above gives the idea I think). I checked it countless times for typos, 
> compared it against the working Rust code, and the maxima code looks 
> correct. Maybe I am bumping into some kind of limitation which I don't 
> know. Any ideas?
>
> Ilgar
>
>
> _______________________________________________ Maxima-discuss mailing 
> list Max...@li... 
> <mailto:Max...@li...> 
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss 
> <https://lists.sourceforge.net/lists/listinfo/maxima-discuss>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li... 
> <mailto:Max...@li...>
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss 
> <https://lists.sourceforge.net/lists/listinfo/maxima-discuss>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss 

On Sat, 2025年10月11日 at 17:01 -0400, Stavros Macrakis wrote:
> 
> 
> This is the "noun/verb" scheme which you can look up in the
> manual....
> 
>     -s
> 
Thank you, that clarifies some things.
I'm almost there. See below, it looks like it works but I cheated. In
my call to tellsimpafter I need to put "inpart(sm,2)" as the second
argument to the sum. But if I do that, then when I call myfunc(S) I get
the error "sum: index must be a symbol; found inpart(sm,2)". So how can
I get inpart(sm,2) to evaluate inside the tellsimp?
(%i1) S: sum(c[i]*g(i),i,1,N);
 N
 ____
 ╲
(%o1) ⟩ c g(i)
 ╱ i
 ̅ ̅ ̅ ̅
 i = 1
(%i2) matchdeclare(sm, lambda([x],is( inpart(x,0)=nounify(sum) )) )$
(%i3) tellsimpafter(myfunc(sm),
 sum( myfunc(inpart(sm,1)),i,inpart(sm,3),inpart(sm,4) ) )$
(%i4) myfunc(S);
 N
 ____
 ╲
(%o4) ⟩ myfunc(c g(i))
 ╱ i
 ̅ ̅ ̅ ̅
 i = 1

On Sat, 2025年10月11日 at 19:37 +0000, Daniel Volinski via Maxima-discuss
wrote:
> is(op(S)=nounify(sum)); => true
Thanks Dan, this works.
On Sat, 2025年10月11日 at 19:47 +0000, Barton Willis via Maxima-discuss
wrote:
> I'm certain that we all discussed this sometime in the past two
> decades. What does the user documentation say?
Indeed it's in the docs: "When a_i and/or p_i are lists, each of the
atoms gets all of the properties."
It didn't occur to me that this would work for an undeclared or
unassigned list.
-E

S: sum(c[i]*x^i,i,1,N)$
op(S)-nounify('sum) => 0
op(S)-verbify('sum) => sum - sum
T: '( sum by(1,i,1,3)) $
op(T)-nounify('sum) => sum - sum
op(T)-verbify('sum) => 0
This is the "noun/verb" scheme which you can look up in the manual....
 -s
On Sat, Oct 11, 2025, 14:37 ehm <eri...@gm...> wrote:
> Hi Barton,
>
> I didn't know that declaring c complex was enough, but that works for
> me!
>
> For the second part, I want to 'matchdeclare' on a sum. Even to use
> your suggested solution I would like to determine if an expression was
> a sum. None of the following work, and I'd like to understand why:
>
> (%i4) S: sum(c[i]*x^i,i,1,N)$
>
> (%i5) part(S,0);
> (%o5) sum
> (%i6) is( part(S,0) = 'sum );
> (%o6) false
> (%i7) is( part(S,0) = sum );
> (%o7) false
> (%i8) is( inpart(S,0) = sum );
> (%o8) false
> (%i9) is( inpart(S,0) = 'sum );
> (%o9) false
> (%i10) is( inpart(S,0) = "sum" );
> (%o10) false
>
> I can't seem to get these to work with equal() either. I'm not sure
> what I'm missing...
>
> -Eric M
>
>
> On Sat, 2025年10月11日 at 17:46 +0000, Barton Willis wrote:
> > (%i1) display2d : false$
> >
> >
> > When c is declared complex, so is c[k]
> >
> >
> >
> > For your other question, maybe you could use substinpart:
> >
> > (%i22) S : sum(c[i]*x^i,i,1,N)$
> > (%i23) substinpart (f(inpart(S,1)), S, 1);
> > (%o23) sum(f(c[i]*x^i),i,1,N)
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Caution: conjugate and featurep have different opinions:
(%i1) declare(c,complex)$
OK
(%i2) featurep(c, complex);
(%o2) true
But featurep doesn't consider c[3] to be complex:
(%i3) featurep(c[3],complex);
(%o3) false
But conjugate flags c[3] to be complex
(%i4) conjugate(c[3]);
(%o4) conjugate(c[3])
And realpart and imagpart seem to obey this as well
(%i9) imagpart(c[42]);
(%o9) imagpart(c[42])
(%i10) realpart(c[42]);
(%o10) realpart(c[42])
I'm certain that we all discussed this sometime in the past two decades. What does the user documentation say?
________________________________
From: Daniel Volinski via Maxima-discuss <max...@li...>
Sent: Saturday, October 11, 2025 2:37 PM
To: max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] working with sums
Caution: Non-NU Email
Eric,
You can use:
op(S); => sum
is(op(S)=nounify(sum)); => true
another useful command:
args(S); => [c[i]*x^i,i,1,N]
Daniel Volinski
En sábado, 11 de octubre de 2025, 21:41:30 GMT+3, ehm <eri...@gm...> escribió:
Hi Barton,
I didn't know that declaring c complex was enough, but that works for
me!
For the second part, I want to 'matchdeclare' on a sum. Even to use
your suggested solution I would like to determine if an expression was
a sum. None of the following work, and I'd like to understand why:
(%i4) S: sum(c[i]*x^i,i,1,N)$
(%i5) part(S,0);
(%o5) sum
(%i6) is( part(S,0) = 'sum );
(%o6) false
(%i7) is( part(S,0) = sum );
(%o7) false
(%i8) is( inpart(S,0) = sum );
(%o8) false
(%i9) is( inpart(S,0) = 'sum );
(%o9) false
(%i10) is( inpart(S,0) = "sum" );
(%o10) false
I can't seem to get these to work with equal() either. I'm not sure
what I'm missing...
-Eric M
On Sat, 2025年10月11日 at 17:46 +0000, Barton Willis wrote:
> (%i1) display2d : false$
>
>
> When c is declared complex, so is c[k]
>
>
>
> For your other question, maybe you could use substinpart:
>
> (%i22)   S : sum(c[i]*x^i,i,1,N)$
> (%i23)   substinpart (f(inpart(S,1)), S, 1);
> (%o23)   sum(f(c[i]*x^i),i,1,N)
_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!Aq-a0_IaPp3_VdM5ZgZAjcroG-koUen-WulCNKFT30yoizsINKFGqoJ27AtucwpCibEKLAmUBJUsI6IEUUNTP-Dy9y5bOzBXjA$>

Eric,
You can use:
op(S); => sum
is(op(S)=nounify(sum)); => true
another useful command:
args(S); => [c[i]*x^i,i,1,N]
Daniel Volinski
 En sábado, 11 de octubre de 2025, 21:41:30 GMT+3, ehm <eri...@gm...> escribió: 
 
 Hi Barton,
I didn't know that declaring c complex was enough, but that works for
me!
For the second part, I want to 'matchdeclare' on a sum. Even to use
your suggested solution I would like to determine if an expression was
a sum. None of the following work, and I'd like to understand why:
(%i4) S: sum(c[i]*x^i,i,1,N)$
(%i5) part(S,0);
(%o5)                sum
(%i6) is( part(S,0) = 'sum );
(%o6)                false
(%i7) is( part(S,0) = sum );
(%o7)                false
(%i8) is( inpart(S,0) = sum );
(%o8)                false
(%i9) is( inpart(S,0) = 'sum ); 
(%o9)                false
(%i10) is( inpart(S,0) = "sum" );
(%o10)               false
I can't seem to get these to work with equal() either. I'm not sure
what I'm missing...
-Eric M
On Sat, 2025年10月11日 at 17:46 +0000, Barton Willis wrote:
> (%i1) display2d : false$
> 
> 
> When c is declared complex, so is c[k]
> 
> 
> 
> For your other question, maybe you could use substinpart:
> 
> (%i22)   S : sum(c[i]*x^i,i,1,N)$
> (%i23)   substinpart (f(inpart(S,1)), S, 1);
> (%o23)   sum(f(c[i]*x^i),i,1,N)
_______________________________________________
Maxima-discuss mailing list
Max...@li...
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
 

Hi Barton,
I didn't know that declaring c complex was enough, but that works for
me!
For the second part, I want to 'matchdeclare' on a sum. Even to use
your suggested solution I would like to determine if an expression was
a sum. None of the following work, and I'd like to understand why:
(%i4) S: sum(c[i]*x^i,i,1,N)$
(%i5) part(S,0);
(%o5) sum
(%i6) is( part(S,0) = 'sum );
(%o6) false
(%i7) is( part(S,0) = sum );
(%o7) false
(%i8) is( inpart(S,0) = sum );
(%o8) false
(%i9) is( inpart(S,0) = 'sum ); 
(%o9) false
(%i10) is( inpart(S,0) = "sum" );
(%o10) false
I can't seem to get these to work with equal() either. I'm not sure
what I'm missing...
-Eric M
On Sat, 2025年10月11日 at 17:46 +0000, Barton Willis wrote:
> (%i1) display2d : false$
> 
> 
> When c is declared complex, so is c[k]
> 
> 
> 
> For your other question, maybe you could use substinpart:
> 
> (%i22)   S : sum(c[i]*x^i,i,1,N)$
> (%i23)   substinpart (f(inpart(S,1)), S, 1);
> (%o23)   sum(f(c[i]*x^i),i,1,N)

(%i1) display2d : false$
When c is declared complex, so is c[k]
(%i2) declare(c,complex)$
Doesn't seem like this should be needed:
(%i3) declare(N,real)$
And similarly, not sure this should be needed either:
(%i4) declare(i,integer)$
(%i5) S: sum(c[i]*x^i,i,1,N)$
(%i6) conjugate(S);
(%o6) 'sum(conjugate(c[i])*x^i,i,1,N)
For your other question, maybe you could use substinpart:
(%i22)   S : sum(c[i]*x^i,i,1,N)$
(%i23)   substinpart (f(inpart(S,1)), S, 1);
(%o23)   sum(f(c[i]*x^i),i,1,N)
________________________________
From: ehm <eri...@gm...>
Sent: Friday, October 10, 2025 4:31 PM
To: max...@li... <max...@li...>
Subject: [Maxima-discuss] working with sums
Caution: Non-NU Email
Hi All,
I have two simple things I would like to do with sums.
Consider...
(%i2) S: sum(c[i]*x^i,i,1,N);
 N
 ____
 \ i
(%o2) > c x
 / i
 ----
 i = 1
(%i3) conjugate(S);
 N
 ____
 \ i
(%o3) conjugate( > c x )
 / i
 ----
 i = 1
(%i4)
1. How can I declare the c[i] complex for any i?
2. How do I map any function I call on the sum into the sum?
i.e, I want
myfunc( sum(A,B,C,D) ) ---> sum( myfunc(A), B,C,D )
I've tried to do this with tellsimp and tellsimpafter, but it does
nothing as if it's not matching the pattern. I used
matchdeclare([A,B,C,D],true);
tellsimpafter( myfunc( sum(A,B,C,D) ), sum( myfunc(A),B,C,D ) );
Thanks for any help.
-Eric M
_______________________________________________
Maxima-discuss mailing list
Max...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!E8UfoLbGH50v5LqaZ4jq-yu2_SHBv52o0b45puDqZWgi1TKqgcOEEgbC9D-PYn7Y1S4OOkqGFTPdb_7GRcM$

Hi all,
I found a nice way to _try_ to understand the "result" arguments of
"dim-*" functions. These lines in displa.lisp define how objects like
"a^b" will be displayed:
 (displa-def mexpt dimension-superscript)
 (displa-def %mexpt dimension-superscript)
They set the "dimension" property of both "mexpt" and "%mexpt" to the
function "dimension-superscript". The code below replaces that by
"dimension-superscript-saving", that is a wrapper around
"dimension-superscript" that appends the "result" of
"dimension-superscript" to the list stored in the variable
"dim-saved", and after that it makes Maxima display some objects of
the form "a^b", and it prints the contents of "dim-saved"...
Here is the code - obviously a very fragile hack:
 to_lisp();
 (defvar dim-saved)
 (setq dim-saved nil)
 (defun dim-save (result)
 (setq dim-saved `(,@dim-saved ,result))
 result)
 (defun dimension-superscript-saving (form result)
 (dimension-superscript form (dim-save result)))
 (displa-def mexpt dimension-superscript-saving)
 (displa-def %mexpt dimension-superscript-saving)
 (to-maxima)
 b^cd;
 ab^cd;
 ab^cde;
 ab^cde[fg];
 ab^cde[fgh];
 to_lisp();
 (loop for o in dim-saved
 do (format t "~a~%" o))
 (to-maxima)
and here is the relevant part of its output, slightly reindented:
 (%i2) b^cd;
 cd
 (%o2) b
 (%i3) ab^cd;
 cd
 (%o3) ab
 (%i4) ab^cde;
 cde
 (%o4) ab
 (%i5) ab^cde[fg];
 cde
 fg
 (%o5) ab
 (%i6) ab^cde[fgh];
 cde
 fgh
 (%o6) ab
 (%i7) to_lisp();
 Type (to-maxima) to restart, ($quit) to quit Maxima.
 MAXIMA> (loop for o in dim-saved
 do (format t "~a~%" o))
 ((32 0) b (0 1 d c))
 ((31 0) a b (0 1 d c))
 ((31 0) a b (0 1 e d c))
 ((30 0) a b (0 2 (0 -1 g f) (0 0 e d c)))
 ((29 0) a b (0 2 (0 -1 h g f) (0 0 e d c)))
Now the question. Each of these "result"s looks like the "dimension
strings" that are described in this comment in displa.lisp,
;; <dimension string> ::= () | (<string element> . <dimension string>)
;; <string element> ::= character |
;; (<column-relative> <row-relative> . <dimension string>) |
;; (<drawing function> . args)
;; <column-relative> ::= <fixnum>
;; <row-relative> ::= <fixnum>
;; <drawing function> ::= D-HBAR | D-VBAR | D-INTEGRALSIGN | ...
;; When a character appears in a dimension string, it is printed and
;; the cursor moves forward a single position. (The variable OLDCOL is
;; incremented) When a form with a fixnum car is encountered, the
;; first two elements of the form are taken to be relative displacements
;; for OLDCOL and OLDROW. *** NOTE *** After drawing the cddr of the form,
;; OLDROW is reset to its original value, but OLDCOL is left in the new
;; position. Why this is done is beyond me. It only appears to complicate
;; things.
but some parts of them are reversed in a funny way... for example, I
_guess_ that
 ((29 0) a b (0 2 (0 -1 h g f) (0 0 e d c)))
is converted to this
 ((29 0) a b (0 2 (0 -1 f g h) (0 0 c d e)))
in some part of displa.lisp - but I couldn't find the code that does
that, and I am not sure of the right way to reverse the parts.
Any hints?
 Thanks in advance!
 Eduardo =)

Hi All,
I have two simple things I would like to do with sums.
Consider...
(%i2) S: sum(c[i]*x^i,i,1,N);
 N
 ____
 \ i
(%o2) > c x
 / i
 ----
 i = 1
(%i3) conjugate(S);
 N
 ____
 \ i
(%o3) conjugate( > c x )
 / i
 ----
 i = 1
(%i4) 
1. How can I declare the c[i] complex for any i?
2. How do I map any function I call on the sum into the sum?
i.e, I want
myfunc( sum(A,B,C,D) ) ---> sum( myfunc(A), B,C,D )
I've tried to do this with tellsimp and tellsimpafter, but it does
nothing as if it's not matching the pattern. I used
matchdeclare([A,B,C,D],true);
tellsimpafter( myfunc( sum(A,B,C,D) ), sum( myfunc(A),B,C,D ) );
Thanks for any help.
-Eric M

Hello again,
I was not able to find the error. So I will send it to you Jaime, thanks for your time,
Best,
Ilgar
________________________________
From: Jaime Villate <vi...@fe...>
Sent: Thursday, October 9, 2025 12:42
To: Kemal Ilgar Eroglu <kie...@ho...>; maxima-discuss <max...@li...>
Subject: Re: [Maxima-discuss] About the rk solver
On 09/10/25 09:17, Kemal Ilgar Eroglu wrote:
> I will do some more checks today (with a fresh mind!), including a
> comparison with rkf45. In any case I will report my results here. If I
> can't find what the problem is I will just share the code here.
Or if you don't want to clean the code to make it easier to understand,
you can also send me a copy in private and I will help you figure out
what the problems is.
Regards,
Jaime