maxima-discuss — Maxima discussion list

Re: [Maxima-discuss] numerical issues with bfloat

[Igor P. <ipe...@gm...>]

Thanks a lot for the useful suggestion.

I hadn't increased ffprec enough.

Bests

Igor P

On 10/1/25 17:25, Raymond Toy wrote:
>
> On 10/1/25 4:09 AM, Stavros Macrakis wrote:
>
>> Maxima bfloats are not mpfr floats.
>>
>> Reorganizing a floating point calculation often changes the results.
>>
>> The default precision of bfloat is 16 decimal digits, internally 56 
>> bits. See ? fpprec
>>
>> So it's not surprising that the results are different.
>
> Indeed. Let's look at |qr|:
>
> |(%i6) qr:radcan(qq); 31/2 (%o6) - ((1391611950183735955030016 3 51/2 
> - 24455840869029408432698763712577 sqrt(2)) %pi)/(492075 2 ) |
>
> Let's look at the numerator:
>
> |(%i11) num(%o6); 31/2 (%o11) - (1391611950183735955030016 3 - 
> 24455840869029408432698763712577 sqrt(2)) %pi |
>
> Get rid of the |%pi| and the negative sign:
>
> |(%i12) -%/%pi; 31/2 (%o12) 1391611950183735955030016 3 - 
> 24455840869029408432698763712577 sqrt(2) |
>
> Finally, look at the different addends and compute their values using 
> bfloats with the default fpprec:
>
> |(%i13) args(%); 31/2 (%o13) [1391611950183735955030016 3 , - 
> 24455840869029408432698763712577 sqrt(2)] (%i14) bfloat(%); (%o14) 
> [3.458578183621962b31, - 3.458578183621961b31] |
>
> Notice that these two numbers differ in the last printed digit. Hence, 
> you have catastrophic cancellation. Using |fpprec:64| helps a lot to 
> reduce this catastrophic cancellation:
>
> |(%i15) fpprec:64; (%o15) 64 (%i16) bfloat(%o13); (%o16) 
> [3.458578183621960832487653530045997492242744898248851938977856214b31, 
> - 3.458578183621960832487661662133679379108480718140347561074398981b31] |
>
> What's the conclusion? Not sure, but it certainly helps to do some 
> analysis (if possible) before trusting a numerical result. Or just be 
> lazy and try with increasing |fpprec| until the results stabilize. (I 
> usually do this because I'm lazy.)
>
> ​
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Eduardo O. <edu...@gm...>]

Hi Leo,

Overthinking what?
I can only give a useful answer if I change your question...
If your "real" question was "what do you need that for?",
then here is a short answer - also incomplete, but whatever.

Let me refer to these three articles as "Hewitt1", "Hewitt2", and
"Hewitt3":

https://flm-journal.org/Articles/2D02A71022192F96A5A92F55B04AB0.pdf
https://flm-journal.org/Articles/62ECB1AC893A68B151356F711BC362.pdf
https://flm-journal.org/Articles/1982BC67D75CA318A4C64B67C7CD14.pdf

Their titles are:

"Arbitrary and Necessary Part 1: a Way of Viewing the Mathematics
Curriculum"
"Arbitrary and Necessary Part 2: Assisting Memory"
"Arbitrary and Necessary Part 3: Educating Awareness"

and I will refer to these (non-free) books as "Sfard" and
"RestIsAlgebra":

@Book{Sfard,
  author = {A. Sfard},
  title = {Thinking as Communicating -- Human Development, the
                  Growth of Discourses, and Mathematizing},
  publisher = {Cambridge},
  year = {2008},
  shorthand =    {Sfard},
}

@Book{RestIsAlgebra,
  editor = {S. Stewart},
  title = {And the Rest is Just Algebra},
  publisher = {Springer},
  year = {2017},
  shorthand =    {RestIsAlgebra},
}

They all discuss students who see maths as "rules without reasons",
and what is the process to make them "understand" mathematics. There
is a very nice example in p.6 of Hewitt1 - a story about a student who
starts with x-y=2 and then does everything wrong. I won't point to
other specific points in these books and articles now... I'm
mentioning them here just because they are "very recommended", and we
usually don't stumble on these topics.

I'm getting lots of students like that in my Calc 2 classes, and I am
working on materials to help them visualize ideas that are very basic
for us but very hard for them, like "take the particular case in which
x=3"... and I am working on an article about that.

  Cheers,
    Eduardo


On Thu, 2 Oct 2025 at 12:52, Leo Butler <Leo...@um...> wrote:

> Hello,
>
> Aren't you over-thinking this?
>
> All you are doing is playing with a list and extracting sub-lists. I
> don't see why you need to involve the simplifier or pattern matching.
> Or even define =. as an nary operator. Why not just use `eq' as the op?
>
> Best regards,
> Leo
>

Re: [Maxima-discuss] nary() syntax ... was Re: A question about expression_with_a_certain_op[n]

[Robert D. <rob...@gm...>]

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

Re: [Maxima-discuss] nary() syntax ... was Re: A question about expression_with_a_certain_op[n]

[Eduardo O. <edu...@gm...>]

Hi Richard,

if foo is n-ary then I think that the correct way to define it as a
function is with:

  nary("foo");
  "foo"([as]) := [42,as];
  2 foo 3;                /* [42, [2, 3]] */
  2 foo 3 foo 4;          /* [42, [2, 3, 4]] */

but I've never defined any n-ary operator "as a function" - all of the
few n-ary operators that I've defined and used followed this idea from
the manual,

  Even some built-in operators have no simplifications. For example,
  '=' does not "simplify" - it is a place-holder with no
  simplification semantics other than to simplify its two arguments,
  in this case referred to as the left and right sides

but with "display" and "tex" properties...

  Cheers,
    Eduardo


On Thu, 2 Oct 2025 at 13:54, Richard Fateman <fa...@gm...> wrote:

> Just another thought about this.
> 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.
> 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.
>
> 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?
>
> etc etc.
>    Good luck
> Rjf
>

[Maxima-discuss] nary() syntax ... was Re: A question about expression_with_a_certain_op[n]

[Richard F. <fa...@gm...>]

Just another thought about this.
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.
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.

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?

etc etc.
   Good luck
Rjf



On Thu, Oct 2, 2025 at 8:53 AM Leo Butler <Leo...@um...> wrote:

> Hello,
>
> Aren't you over-thinking this?
>
> All you are doing is playing with a list and extracting sub-lists. I
> don't see why you need to involve the simplifier or pattern matching.
> Or even define =. as an nary operator. Why not just use `eq' as the op?
>
> Best regards,
> Leo
>
> On Thu, Oct 02 2025, Eduardo Ochs <edu...@gm...> wrote:
>
> > Hi list,
> >
> > is is possible to use tellsimpafter to define the action of [n] on
> > objects of the form expression_with_a_certain_op[n]? In case of "no",
> > what is the workaround? Here's what I was trying... I defined an n-ary
> > equality operator, "=.", and I was playing with ways of extracting the
> > subexpressions and sub-equalities of objects like "a=.b=.c=.d=.e":
> >
> >   has_op_1(e)   := if not atom(e) then not subvarp(e);
> >   has_op_2(e,o) := if has_op_1(e) then is(op(e)=o);
> >   eqdotp  (e)   := has_op_2(e,"=.");
> >   matchdeclare  (_eqdot,eqdotp);
> >   matchdeclare  ([_a,_b,_n],all);
> >   matchdeclare  (_n,all);
> >   tellsimpafter (subexpr(_eqdot,_n), args(_eqdot)[_n]);
> >   nary("=.");
> >   eqdot_subexpr(e,n) := args(e)[n];
> >   eqdot_subeq  (e,n) := args(e)[n] = args(e)[n+1];
> >
> >   oo : a=.b=.c=.d=.e;
> >   [op(oo), args(oo)];    /* [=., [a, b, c, d, e]] */
> >   eqdot_subexpr(oo,2);   /* b */
> >   eqdot_subexpr(oo,3);   /* c */
> >   eqdot_subeq  (oo,2);   /* b = c */
> >   subexpr      (oo,2);   /* b */
> >
> >   tellsimpafter (_eqdot[_n], args(_eqdot)[_n]);  /* error */
> >
> > The error is:
> >
> >   tellsimpafter: main operator of pattern must not be match variable;
> >   found: _eqdot
> >
> > Thanks in advance!
> >   Eduardo Ochs
> >   https://anggtwu.net/eev-maxima.html
> >
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> >
>
> --
> ---
> Best regards,
> Dr Butler
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Richard F. <fa...@gm...>]

The way tellsimp  and tellsimpafter work is they put additional
simplifications on particular symbols.
(In lisp-speak, they put the additional rules as part of a program on the
property list of atoms.)
You could do something like tellsimp( a =. b , ....)  in which case the
rule would be put on the atom $=.  in the system.
But as the system points out, it won't work if you are being too coy about
what you are simplifying.
as tellsimp(vague_operator_Ill_tell_you_later(a,b,c) ....);

defrule might help, or you could just cut to the chase and write
allequal(a,b,c,d)   or perhaps list_of_equals( [a,b,c,d]).

Rjf



On Thu, Oct 2, 2025 at 8:53 AM Leo Butler <Leo...@um...> wrote:

> Hello,
>
> Aren't you over-thinking this?
>
> All you are doing is playing with a list and extracting sub-lists. I
> don't see why you need to involve the simplifier or pattern matching.
> Or even define =. as an nary operator. Why not just use `eq' as the op?
>
> Best regards,
> Leo
>
> On Thu, Oct 02 2025, Eduardo Ochs <edu...@gm...> wrote:
>
> > Hi list,
> >
> > is is possible to use tellsimpafter to define the action of [n] on
> > objects of the form expression_with_a_certain_op[n]? In case of "no",
> > what is the workaround? Here's what I was trying... I defined an n-ary
> > equality operator, "=.", and I was playing with ways of extracting the
> > subexpressions and sub-equalities of objects like "a=.b=.c=.d=.e":
> >
> >   has_op_1(e)   := if not atom(e) then not subvarp(e);
> >   has_op_2(e,o) := if has_op_1(e) then is(op(e)=o);
> >   eqdotp  (e)   := has_op_2(e,"=.");
> >   matchdeclare  (_eqdot,eqdotp);
> >   matchdeclare  ([_a,_b,_n],all);
> >   matchdeclare  (_n,all);
> >   tellsimpafter (subexpr(_eqdot,_n), args(_eqdot)[_n]);
> >   nary("=.");
> >   eqdot_subexpr(e,n) := args(e)[n];
> >   eqdot_subeq  (e,n) := args(e)[n] = args(e)[n+1];
> >
> >   oo : a=.b=.c=.d=.e;
> >   [op(oo), args(oo)];    /* [=., [a, b, c, d, e]] */
> >   eqdot_subexpr(oo,2);   /* b */
> >   eqdot_subexpr(oo,3);   /* c */
> >   eqdot_subeq  (oo,2);   /* b = c */
> >   subexpr      (oo,2);   /* b */
> >
> >   tellsimpafter (_eqdot[_n], args(_eqdot)[_n]);  /* error */
> >
> > The error is:
> >
> >   tellsimpafter: main operator of pattern must not be match variable;
> >   found: _eqdot
> >
> > Thanks in advance!
> >   Eduardo Ochs
> >   https://anggtwu.net/eev-maxima.html
> >
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> >
>
> --
> ---
> Best regards,
> Dr Butler
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Leo B. <Leo...@um...>]

Hello,

Aren't you over-thinking this?

All you are doing is playing with a list and extracting sub-lists. I
don't see why you need to involve the simplifier or pattern matching.
Or even define =. as an nary operator. Why not just use `eq' as the op?

Best regards,
Leo

On Thu, Oct 02 2025, Eduardo Ochs <edu...@gm...> wrote:

> Hi list,
>
> is is possible to use tellsimpafter to define the action of [n] on
> objects of the form expression_with_a_certain_op[n]? In case of "no",
> what is the workaround? Here's what I was trying... I defined an n-ary
> equality operator, "=.", and I was playing with ways of extracting the
> subexpressions and sub-equalities of objects like "a=.b=.c=.d=.e":
>
>   has_op_1(e)   := if not atom(e) then not subvarp(e);
>   has_op_2(e,o) := if has_op_1(e) then is(op(e)=o);
>   eqdotp  (e)   := has_op_2(e,"=.");
>   matchdeclare  (_eqdot,eqdotp);
>   matchdeclare  ([_a,_b,_n],all);
>   matchdeclare  (_n,all);
>   tellsimpafter (subexpr(_eqdot,_n), args(_eqdot)[_n]);
>   nary("=.");
>   eqdot_subexpr(e,n) := args(e)[n];
>   eqdot_subeq  (e,n) := args(e)[n] = args(e)[n+1];
>
>   oo : a=.b=.c=.d=.e;
>   [op(oo), args(oo)];    /* [=., [a, b, c, d, e]] */
>   eqdot_subexpr(oo,2);   /* b */
>   eqdot_subexpr(oo,3);   /* c */
>   eqdot_subeq  (oo,2);   /* b = c */
>   subexpr      (oo,2);   /* b */
>
>   tellsimpafter (_eqdot[_n], args(_eqdot)[_n]);  /* error */
>
> The error is:
>
>   tellsimpafter: main operator of pattern must not be match variable;
>   found: _eqdot
>
> Thanks in advance!
>   Eduardo Ochs
>   https://anggtwu.net/eev-maxima.html
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

-- 
---
Best regards,
Dr Butler

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Eduardo O. <edu...@gm...>]

Thanks!!!
I will try defrule when I wake up, and here is a screenshot of
my verbatimboxes using matrices with the standard padding
and border characters... I will try to finish the documentation
tomorrow, and include examples that show how these
verbatimboxes are LaTeXed.
  Cheers and good night =).
    Eduardo

On Thu, 2 Oct 2025 at 02:27, Robert Dodier <rob...@gm...> wrote:

> Eduardo, I haven't looked at it carefully, but consider working with
> defrule instead of tellsimp/tellsimpafter, since defrule allows the
> main operator to be a match variable.
>
> HTH & all the best,
>
> Robert
>
> PS. I am working on some code to implement display of matrices without
> padding as you mentioned a few days ago.
>

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Robert D. <rob...@gm...>]

Eduardo, I haven't looked at it carefully, but consider working with
defrule instead of tellsimp/tellsimpafter, since defrule allows the
main operator to be a match variable.

HTH & all the best,

Robert

PS. I am working on some code to implement display of matrices without
padding as you mentioned a few days ago.

Re: [Maxima-discuss] A question about expression_with_a_certain_op[n]

[Eduardo O. <edu...@gm...>]

Ooops, sorry, my question had an error...
This works,

  matchdeclare  ([_a,_b,_c,_n],all);
  tellsimpafter (f(_a,_b,_c)[_n], [_a,_b,_c][_n]);
  f(a,b,c)[2];   /* b */

but I was trying to adapt that to a case in which the f can receive
any number of arguments...

  Cheers! =)
    Eduardo


On Thu, 2 Oct 2025 at 01:40, Eduardo Ochs <edu...@gm...> wrote:

> Hi list,
>
> is is possible to use tellsimpafter to define the action of [n] on
> objects of the form expression_with_a_certain_op[n]? In case of "no",
> what is the workaround? Here's what I was trying... I defined an n-ary
> equality operator, "=.", and I was playing with ways of extracting the
> subexpressions and sub-equalities of objects like "a=.b=.c=.d=.e":
>
>   has_op_1(e)   := if not atom(e) then not subvarp(e);
>   has_op_2(e,o) := if has_op_1(e) then is(op(e)=o);
>   eqdotp  (e)   := has_op_2(e,"=.");
>   matchdeclare  (_eqdot,eqdotp);
>   matchdeclare  ([_a,_b,_n],all);
>   matchdeclare  (_n,all);
>   tellsimpafter (subexpr(_eqdot,_n), args(_eqdot)[_n]);
>   nary("=.");
>   eqdot_subexpr(e,n) := args(e)[n];
>   eqdot_subeq  (e,n) := args(e)[n] = args(e)[n+1];
>
>   oo : a=.b=.c=.d=.e;
>   [op(oo), args(oo)];    /* [=., [a, b, c, d, e]] */
>   eqdot_subexpr(oo,2);   /* b */
>   eqdot_subexpr(oo,3);   /* c */
>   eqdot_subeq  (oo,2);   /* b = c */
>   subexpr      (oo,2);   /* b */
>
>   tellsimpafter (_eqdot[_n], args(_eqdot)[_n]);  /* error */
>
> The error is:
>
>   tellsimpafter: main operator of pattern must not be match variable;
>   found: _eqdot
>
> Thanks in advance!
>   Eduardo Ochs
>   https://anggtwu.net/eev-maxima.html
>
>

[Maxima-discuss] A question about expression_with_a_certain_op[n]

[Eduardo O. <edu...@gm...>]

Hi list,

is is possible to use tellsimpafter to define the action of [n] on
objects of the form expression_with_a_certain_op[n]? In case of "no",
what is the workaround? Here's what I was trying... I defined an n-ary
equality operator, "=.", and I was playing with ways of extracting the
subexpressions and sub-equalities of objects like "a=.b=.c=.d=.e":

  has_op_1(e)   := if not atom(e) then not subvarp(e);
  has_op_2(e,o) := if has_op_1(e) then is(op(e)=o);
  eqdotp  (e)   := has_op_2(e,"=.");
  matchdeclare  (_eqdot,eqdotp);
  matchdeclare  ([_a,_b,_n],all);
  matchdeclare  (_n,all);
  tellsimpafter (subexpr(_eqdot,_n), args(_eqdot)[_n]);
  nary("=.");
  eqdot_subexpr(e,n) := args(e)[n];
  eqdot_subeq  (e,n) := args(e)[n] = args(e)[n+1];

  oo : a=.b=.c=.d=.e;
  [op(oo), args(oo)];    /* [=., [a, b, c, d, e]] */
  eqdot_subexpr(oo,2);   /* b */
  eqdot_subexpr(oo,3);   /* c */
  eqdot_subeq  (oo,2);   /* b = c */
  subexpr      (oo,2);   /* b */

  tellsimpafter (_eqdot[_n], args(_eqdot)[_n]);  /* error */

The error is:

  tellsimpafter: main operator of pattern must not be match variable;
  found: _eqdot

Thanks in advance!
  Eduardo Ochs
  https://anggtwu.net/eev-maxima.html

Re: [Maxima-discuss] numerical issues with bfloat

[Raymond T. <toy...@gm...>]

On 10/1/25 4:09 AM, Stavros Macrakis wrote:

> Maxima bfloats are not mpfr floats.
>
> Reorganizing a floating point calculation often changes the results.
>
> The default precision of bfloat is 16 decimal digits, internally 56 
> bits. See ? fpprec
>
> So it's not surprising that the results are different.

Indeed. Let's look at |qr|:

|(%i6) qr:radcan(qq); 31/2 (%o6) - ((1391611950183735955030016 3 51/2 - 
24455840869029408432698763712577 sqrt(2)) %pi)/(492075 2 ) |

Let's look at the numerator:

|(%i11) num(%o6); 31/2 (%o11) - (1391611950183735955030016 3 - 
24455840869029408432698763712577 sqrt(2)) %pi |

Get rid of the |%pi| and the negative sign:

|(%i12) -%/%pi; 31/2 (%o12) 1391611950183735955030016 3 - 
24455840869029408432698763712577 sqrt(2) |

Finally, look at the different addends and compute their values using 
bfloats with the default fpprec:

|(%i13) args(%); 31/2 (%o13) [1391611950183735955030016 3 , - 
24455840869029408432698763712577 sqrt(2)] (%i14) bfloat(%); (%o14) 
[3.458578183621962b31, - 3.458578183621961b31] |

Notice that these two numbers differ in the last printed digit. Hence, 
you have catastrophic cancellation. Using |fpprec:64| helps a lot to 
reduce this catastrophic cancellation:

|(%i15) fpprec:64; (%o15) 64 (%i16) bfloat(%o13); (%o16) 
[3.458578183621960832487653530045997492242744898248851938977856214b31, - 
3.458578183621960832487661662133679379108480718140347561074398981b31] |

What's the conclusion? Not sure, but it certainly helps to do some 
analysis (if possible) before trusting a numerical result. Or just be 
lazy and try with increasing |fpprec| until the results stabilize. (I 
usually do this because I'm lazy.)

​

Re: [Maxima-discuss] numerical issues with bfloat

[Michel T. <ta...@lp...>]

Le 01/10/2025 à 10:12, Igor Pesando a écrit :
>
> Now if you try to do the same computation with R using the same mpfr
> library (I don't know whether the same version) you get ....

Consider, following Stavros idea, the following:

Maxima 5.48.1 https://maxima.sourceforge.io
using Lisp SBCL 2.5.8

(%i1) 
qq:((42328762422919168*3^(19/2)-1020404800499791299075*sqrt(2))*%pi)/(5*2^(19/2))
  +((114866054188452371105939465*sqrt(3)-249900741459*2^(99/2))*%pi)/(5242880*3^(9/2))
  +((44912031264987141343855529*sqrt(3)-781679147445*2^(93/2))*%pi)/(13107200*3^(3/2))
  +((1439185410761439252972725*sqrt(3)-1603107148923*2^(81/2))*%pi)/(1638400*sqrt(3))
  -((101083151603075712162029*sqrt(3)-900771348897*2^(75/2))*%pi)/(81920*3^(3/2))-
  (397992477574879*%pi)/16511297126400$

(%i2) qr:radcan(qq);
                                      31/2
(%o2) - ((1391611950183735955030016 3
51/2
                 - 24455840869029408432698763712577 sqrt(2)) 
%pi)/(492075 2    )
(%i3) qf:factor(qq);
(%o3) ((24455840869029408432698763712577 sqrt(2) sqrt(3)
51/2  19/2
                       - 59904331359825180393845645377536) %pi)/(25 
2     3    )
(%i4) q0: -inpart(qf,4,2) /inpart(qf,4,1)$

(%i5) fpprec:16;
(%o5)                                 16
(%i6) bfloat(qq);
(%o6)                         4.188123926016877b3
(%i7) bfloat(qr);
(%o7)                        - 2.044971377673459b3
(%i8) bfloat(q0);
(%o8)                                1.0b0
(%i9) fpprec:32;
(%o9)                                 32
(%i10) bfloat(qq);
(%o10)               1.0940966878634238343622068201596b-5
(%i11) bfloat(qr);
(%o11)               1.0940967459989769199596357848314b-5
(%i12) bfloat(q0);
(%o12)                1.0000000000000000000000023512804b0
(%i13) fpprec:64;
(%o13)                                64
(%i14) bfloat(qq);
(%o14) 1.094096767106645616816035040876573195641179441484968568346303529b-5
(%i15) bfloat(qr);
(%o15) 1.094096767106645616816035040876573195640339186572047842998702713b-5
(%i16) bfloat(q0);
(%o16) 1.000000000000000000000002351280569685031554276286551780025082575b0
(%i17)

You see that qr and qf are much simpler than qq, computing with 16 
digits of precision gives totally wrong results for qq, and qr. With 32 
digits the result is basically correct , you see that qq and qr are 
close, computing with 64 bits confirms that. Note that the 32 digits 
computation provides only 7 correct digits, by comparison with 64.

On the other hand, the results computed by R are obviously wrong. 
Conclusion, qq is hard to compute and in such case one needs to increase 
fpprec, until the results stabilize. Probably the knob you have used 
with R is incorrect.



-- 
Michel Talon

Re: [Maxima-discuss] numerical issues with bfloat

[Stavros M. <mac...@gm...>]

Maxima bfloats are not mpfr floats.

Reorganizing a floating point calculation often changes the results.

The default precision of bfloat is 16 decimal digits, internally 56 bits.
See ? fpprec

So it's not surprising that the results are different.

       -s




On Wed, Oct 1, 2025, 01:13 Igor Pesando <ipe...@gm...> wrote:

> Hi,
>
> I stumbled upon this somewhat strange result with bfloat.
>
> I don't understand whether it is an issue with maxima or with mpfr.
>
> Bests
>
> Igor
>
> *************************************************************
>
> Given qq (see below)
>
>   qr:radcan(qq)$
>   qf:factor(qq)$
>   q0: -inpart(qf,4,2) /inpart(qf,4,1);
>
>
> (%i42) bfloat(qq)
> (%o42) 4.188123926016877b3
> (%i43) bfloat(qf)
> (%o43)                                                   0.0b0
> (%i44) bfloat(qr)
> (%o44)                                           - 2.044971377673459b3
> (%i45) bfloat(q0)
> (%o45)                                                   1.0b0
>
> grind(qq);
>
> ((42328762422919168*3^(19/2)-1020404800499791299075*sqrt(2))*%pi)/(5*2^(19/2))
>
>   +((114866054188452371105939465*sqrt(3)-249900741459*2^(99/2))*%pi)/(5242880*3^(9/2))
>
>   +((44912031264987141343855529*sqrt(3)-781679147445*2^(93/2))*%pi)/(13107200*3^(3/2))
>
>   +((1439185410761439252972725*sqrt(3)-1603107148923*2^(81/2))*%pi)/(1638400*sqrt(3))
>
>   -((101083151603075712162029*sqrt(3)-900771348897*2^(75/2))*%pi)/(81920*3^(3/2))-(397992477574879*%pi)/16511297126400$
>
>
> Now if you try to do the same computation with R using the same mpfr
> library (I don't know whether the same version) you get (nothing changes
> if you increase the precision bits)
>
>   source("chk_bfloat.R")
> [1] "qq="
> 1 'mpfr' number of precision  256   bits
> [1]
>
> -446.1916076831764495413451122093049754402188000233785286504445524804926159424586
> [1] "qf="
> 1 'mpfr' number of precision  256   bits
> [1]
>
> -391.396653469201855731088331331138112896353745267664096145498964277332727353535
> [1] "qr="
> 1 'mpfr' number of precision  256   bits
> [1]
>
> -282.0758409335675110946339908157827967124983329755483705975213000759088416150404
> [1] "q0="
> 1 'mpfr' number of precision  256   bits
> [1]
>
> 0.9999999999999999158864760403613870668999538104235270048381069013342538356410945
> [1] "q00="
> 1 'mpfr' number of precision  256   bits
> [1]
>
> 0.9999999999999999393801842849230711695227228190160556567214759512716719866319566
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] numerical issues with bfloat

[Igor P. <ipe...@gm...>]

Hi,

I stumbled upon this somewhat strange result with bfloat.

I don't understand whether it is an issue with maxima or with mpfr.

Bests

Igor

*************************************************************

Given qq (see below)

  qr:radcan(qq)$
  qf:factor(qq)$
  q0: -inpart(qf,4,2) /inpart(qf,4,1);


(%i42) bfloat(qq)
(%o42) 4.188123926016877b3
(%i43) bfloat(qf)
(%o43)                                                   0.0b0
(%i44) bfloat(qr)
(%o44)                                           - 2.044971377673459b3
(%i45) bfloat(q0)
(%o45)                                                   1.0b0

grind(qq);
((42328762422919168*3^(19/2)-1020404800499791299075*sqrt(2))*%pi)/(5*2^(19/2))
  +((114866054188452371105939465*sqrt(3)-249900741459*2^(99/2))*%pi)/(5242880*3^(9/2))
  +((44912031264987141343855529*sqrt(3)-781679147445*2^(93/2))*%pi)/(13107200*3^(3/2))
  +((1439185410761439252972725*sqrt(3)-1603107148923*2^(81/2))*%pi)/(1638400*sqrt(3))
  -((101083151603075712162029*sqrt(3)-900771348897*2^(75/2))*%pi)/(81920*3^(3/2))-(397992477574879*%pi)/16511297126400$


Now if you try to do the same computation with R using the same mpfr
library (I don't know whether the same version) you get (nothing changes 
if you increase the precision bits)

  source("chk_bfloat.R")
[1] "qq="
1 'mpfr' number of precision  256   bits
[1] 
-446.1916076831764495413451122093049754402188000233785286504445524804926159424586
[1] "qf="
1 'mpfr' number of precision  256   bits
[1] 
-391.396653469201855731088331331138112896353745267664096145498964277332727353535
[1] "qr="
1 'mpfr' number of precision  256   bits
[1] 
-282.0758409335675110946339908157827967124983329755483705975213000759088416150404
[1] "q0="
1 'mpfr' number of precision  256   bits
[1] 
0.9999999999999999158864760403613870668999538104235270048381069013342538356410945
[1] "q00="
1 'mpfr' number of precision  256   bits
[1] 
0.9999999999999999393801842849230711695227228190160556567214759512716719866319566

Re: [Maxima-discuss] No differential operator?

[Richard F. <fa...@gm...>]

This syntax hacking is generally not going to work well because there are
too many other nuances to
existing semantics for multiplication and powers for ordinary algebraic
objects that interfere with
the apparently identical but NOT identical operators  (as in "differential
operators").
But some of it can be hacked, as

/*convert D^5@@q  to  d(q,5) for more processing */

matchdeclare([n,r,s],true);
tellsimp(D^n,subst(n,kk,lambda([zz],d(zz,kk) )));
infix("@@",100,100);
tellsimp(r @@ s,apply(r,[s]));
/*try this out */
D^2 @@ q;     ---->  converts to   d(q,2)
 ...........  That is  something like D^2 q    is changed to d(q,2),  which
is ordinary functional notation.........

However, getting exactly your notation, including  D q  to convert to
d(q,1) when there is no "^1" seems
to require some contortion.

I can in fact get (D^2+D^3)@@q     to  look like     d(q,2)+d(q,3),  but it
is not pretty or sufficiently general.

As I suggested earlier, one can create a whole system of computer
manipulation that can handle
D+D^2+D^5    etc,  (using rules, or writing in Lisp, or for that matter,
Python or Julia or ....) and then
at appropriate junctures, calling Maxima to apply the usual rules of
arithmetic on algebraic expressions
that ultimately result from applying operators.

Or you can write your stuff in terms of    d(x,n)   in the first place,
using tools like substitution, lambda
calculus application, etc.   Lambda expressions (used above) are sort of
like operators.  e.g. classical
examples would be an operator like ADDONE  :   lambda([x],x+1)
on the left is the operator, on the right is the "functional"
lambda-expression that is similar.

Learning about lambda expressions can be educational.

RJF

On Tue, Sep 30, 2025 at 9:10 AM Eduardo Ochs <edu...@gm...> wrote:

> Hi Blaine,
>
> Do you know how to define new postfix operators?
> Can you try this and tell us more about what your postfix
> differentiation would look like?
>
>   "_x"(o) := diff(o,x);
>   postfix("_x");
>   (x^2)_x;
>
> Cheers,
>   Eduardo Ochs
>   http://anggtwu.net/eev-maxima.html
>
>
> On Mon, 29 Sept 2025 at 22:53, Blaine Edward Hewitt via Maxima-discuss <
> max...@li...> wrote:
>
>> So I am new to maxima (and cas software in general), and I am trying to
>> figure out how to use a general differential operator (d/(dx)) not just
>> the diff() function. diff() is missing the simplicity of operating to
>> the right and being able to change the number of derivatives with en
>> exponent (d/(dx))^2. These problems make it tedious to make operators
>> and find their expectation values in quantum mechanics for example <px>
>> and <xp> to <p> and <p^2>. While this is not so bad finding expectation
>> values for the Hamiltonian as well as using other operators such as a
>> and a_+ is making me loose my mind. Such functionality is preventing me
>> from making my own operators that use derivatives/partial derivatives.
>> Am I going insane or does this functionality not exist in maxima?
>>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] No differential operator?

[Eduardo O. <edu...@gm...>]

Hi Blaine,

Do you know how to define new postfix operators?
Can you try this and tell us more about what your postfix
differentiation would look like?

  "_x"(o) := diff(o,x);
  postfix("_x");
  (x^2)_x;

Cheers,
  Eduardo Ochs
  http://anggtwu.net/eev-maxima.html


On Mon, 29 Sept 2025 at 22:53, Blaine Edward Hewitt via Maxima-discuss <
max...@li...> wrote:

> So I am new to maxima (and cas software in general), and I am trying to
> figure out how to use a general differential operator (d/(dx)) not just
> the diff() function. diff() is missing the simplicity of operating to
> the right and being able to change the number of derivatives with en
> exponent (d/(dx))^2. These problems make it tedious to make operators
> and find their expectation values in quantum mechanics for example <px>
> and <xp> to <p> and <p^2>. While this is not so bad finding expectation
> values for the Hamiltonian as well as using other operators such as a
> and a_+ is making me loose my mind. Such functionality is preventing me
> from making my own operators that use derivatives/partial derivatives.
> Am I going insane or does this functionality not exist in maxima?
>

Re: [Maxima-discuss] No differential operator?

[Barton W. <wi...@un...>]

Here are links to two additional resources:


  1.
 https://github.com/QMeqGR/qm-maxima

  2.
https://github.com/barton-willis/operator_algebra


If you all have questions about using operator_algebra , please ask—I'm interested in fixing bugs, supporting users, and extending the code.

--Barton
________________________________
From: David Billinghurst <dbm...@gm...>
Sent: Tuesday, September 30, 2025 2:50 AM
To: Blaine Edward Hewitt <bl...@ph...>
Cc: max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] No differential operator?

Caution: Non-NU Email

On 30/09/2025 15:16, Richard Fateman wrote:
There is this paper
https://ntrs.nasa.gov/citations/19770021848<https://urldefense.com/v3/__https://ntrs.nasa.gov/citations/19770021848__;!!PvXuogZ4sRB2p-tU!BvfzdVKAjgbwpAjWRxXQwEbvX_DQ8WOPr2mf4f8nLGuiHZIoQFO-80DoV1KICe5IRVEVEFazt3fJqRk$>
but I can't find a copy online right now...

It is pp473-490 of Proceedings of the 1977 MACSYMA Users' Conference available from https://maxima.sourceforge.io/documentation.html<https://urldefense.com/v3/__https://maxima.sourceforge.io/documentation.html__;!!PvXuogZ4sRB2p-tU!BvfzdVKAjgbwpAjWRxXQwEbvX_DQ8WOPr2mf4f8nLGuiHZIoQFO-80DoV1KICe5IRVEVEFazWml7Iz8$>

Re: [Maxima-discuss] No differential operator?

[Michel T. <ta...@lp...>]

Maybe this is a case where using the Maple CAS would be useful, see:

https://www.maplesoft.com/support/help/maple/view.aspx?path=D


Le 30/09/2025 à 00:09, Blaine Edward Hewitt via Maxima-discuss a écrit :
> So I am new to maxima (and cas software in general), and I am trying to
> figure out how to use a general differential operator (d/(dx)) not just
> the diff() function. diff() is missing the simplicity of operating to
> the right and being able to change the number of derivatives with en
> exponent (d/(dx))^2. These problems make it tedious to make operators
> and find their expectation values in quantum mechanics for example <px>
> and <xp> to <p> and <p^2>. While this is not so bad finding expectation
> values for the Hamiltonian as well as using other operators such as a
> and a_+ is making me loose my mind. Such functionality is preventing me
> from making my own operators that use derivatives/partial derivatives.
> Am I going insane or does this functionality not exist in maxima?
>
-- 
Michel Talon

Re: [Maxima-discuss] No differential operator?

[David B. <dbm...@gm...>]

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 30/09/2025 15:16, Richard Fateman
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CADB8Zm7SVNbHgwknm9Ffsa28xeO=FvJ...@ma...">
      <div class="gmail_default"
        style="font-family:arial,sans-serif;font-size:small">There is
        this paper</div>
      <div class="gmail_default"
        style="font-family:arial,sans-serif;font-size:small"><a
          href="https://ntrs.nasa.gov/citations/19770021848"
          moz-do-not-send="true" class="moz-txt-link-freetext">https://ntrs.nasa.gov/citations/19770021848</a></div>
      <div class="gmail_default"
        style="font-family:arial,sans-serif;font-size:small">but I can't
        find a copy online right now...</div>
    </blockquote>
    <p>It is pp473-490 of Proceedings of the 1977 MACSYMA Users'
      Conference available from
      <a class="moz-txt-link-freetext" href="https://maxima.sourceforge.io/documentation.html">https://maxima.sourceforge.io/documentation.html</a><br>
    </p>
  </body>
</html>

Re: [Maxima-discuss] No differential operator?

[Richard F. <fa...@gm...>]

There is this paper
https://ntrs.nasa.gov/citations/19770021848
but I can't find a copy online right now...
and also this, more immediately available paper
https://dl.acm.org/doi/pdf/10.1145/32439.32488

which was done by Jeffrey Golden in Macsyma circa 1986, not Maxima.

There may be attempts to do operator calculus here in Maxima, but I don't
see them in
the "share" directory.

My advice is to basically
change your expectations of what Maxima and other CAS can do, and adapt
*your thinking* about manipulations to match what can be easily done with
what is
available. I expect that your human flexibility to use what amounts to
functional
notation will still get you considerable leverage in computation

  In particular having   f^3 * x   mean   f(f(f(x)))  requires changing the
meaning of ^ and *,
which requires *syntactic *and *semantic* changes to the usual meanings of
these operations
in a CAS.  It is possible to do some of this, but probably not easily.

You might also want to change the display of  f(f( ...))  as well.

 One possibility might be to separately do your
operator manipulation  like f*f --> f^2    or perhaps  f.f --> f^^2  for a
while and then do some
"resimplification" that changes     f^^2* E   to   f(f(E))   (etc)  [think
here of "f" as some differential
operator].

Realize that writing a differential equation as  (D^2+x*D)(y) = g(x,y)  is
essentially punning and
overloading the most common notations of powers, multiplication, and
adjacency
 for purposes that require substantial context to disambiguate.  This
context is implicit in
papers that (say) factor operator expressions as though they were
polynomials.

Why not just "add" operators to Maxima?

There are already compromises to "common" mathematics in Maxima, in that
sin x  is written as sin(x),   3xy  is written as 3*x*y.  Other CAS also
have compromises....
If you were using Mathematica, you would have to write Sin[x]   and 3*x*y
 or 3 x y .
Could programs be written to allow sinx and 3xy?  Sure. But might sinxy
mean sin(x*y) or
sin*x*y  or even sin(x)*y or ...
So my advice is to re-think your computation with operations
that fit in the functional syntax and semantics.
You can easily define some operation D  such that D( f+g) is changed to
d(f,x)+d(g,x).
However,  D^2(f+g) is not legal syntax.
D^^n.x  is legal, although D^^2.x is not legal .. because the 2. is treated
as floating point!

If you feel there is insufficient leverage in your thinking in terms of
existing syntax to enable you
 to solve hard problems, you can either continue to work "by hand", or you
can
join the people building systems-- learn to program new syntax and
semantics, and
offer your additional facilities to future users.   [[I am not discounting
the possibility
that such code such as the work by Jeff Golden might help you, if it has
been rewritten
for Maxima.  If so, I hope some other reader of your note to the
Maxima-discuss newsgroup
will answer!]
Good luck
Richard Fateman






On Mon, Sep 29, 2025 at 6:50 PM Blaine Edward Hewitt via Maxima-discuss <
max...@li...> wrote:

> So I am new to maxima (and cas software in general), and I am trying to
> figure out how to use a general differential operator (d/(dx)) not just
> the diff() function. diff() is missing the simplicity of operating to
> the right and being able to change the number of derivatives with en
> exponent (d/(dx))^2. These problems make it tedious to make operators
> and find their expectation values in quantum mechanics for example <px>
> and <xp> to <p> and <p^2>. While this is not so bad finding expectation
> values for the Hamiltonian as well as using other operators such as a
> and a_+ is making me loose my mind. Such functionality is preventing me
> from making my own operators that use derivatives/partial derivatives.
> Am I going insane or does this functionality not exist in maxima?
>
> --
> From, Blaine Hewitt
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] No differential operator?

[Blaine E. H. <bl...@ph...>]

So I am new to maxima (and cas software in general), and I am trying to
figure out how to use a general differential operator (d/(dx)) not just
the diff() function. diff() is missing the simplicity of operating to
the right and being able to change the number of derivatives with en
exponent (d/(dx))^2. These problems make it tedious to make operators
and find their expectation values in quantum mechanics for example <px>
and <xp> to <p> and <p^2>. While this is not so bad finding expectation
values for the Hamiltonian as well as using other operators such as a
and a_+ is making me loose my mind. Such functionality is preventing me
from making my own operators that use derivatives/partial derivatives.
Am I going insane or does this functionality not exist in maxima?

-- 
From, Blaine Hewitt

Re: [Maxima-discuss] Online interface issue

[Leo B. <Leo...@um...>]

On Sun, Sep 28 2025, Robert Dodier <rob...@gm...> wrote:

> Hmm, some investigation seems to show that the online Maxima
> calculator page which was previously at www.dma.ufv.br has moved to
>
> http://intermat.dma.ufv.br/maxima/index.php
>
> Note that it is an http URL and not https.
>
> Archive.org seems to show that the Maxima online calculator hosted by
> dma.ufv.br was an instance of Yamwi, "yet another Maxima web
> interface", by Mario Rodriguez Riotorto.
>
> https://yamwi.sourceforge.net/index.html

That project seems to have been abandoned by Mario.
I forked it a while ago, and have made some improvements.

https://github.com/leo-butler/yamwi/tree/master

The documentation (in README.org and htdocs/) needs to be updated
further. The screenshot in the README is from yamwi running on my laptop
with an Apache webserver.

>
> Ufv.br is Universidade Federal de Viçosa, Brasil -- I wasn't able to
> figure out who made Yamwi available there. Of course, we owe a debt of
> gratitude to them. A web interface for any system, Maxima or
> otherwise, is making use of computing resources, and obtaining those
> resources is probably the key problem to be solved.

I hope to get a second site up in the next few weeks.

Best regards,
Leo

Re: [Maxima-discuss] Online interface issue

[Robert D. <rob...@gm...>]

Hmm, some investigation seems to show that the online Maxima
calculator page which was previously at www.dma.ufv.br has moved to

http://intermat.dma.ufv.br/maxima/index.php

Note that it is an http URL and not https.

Archive.org seems to show that the Maxima online calculator hosted by
dma.ufv.br was an instance of Yamwi, "yet another Maxima web
interface", by Mario Rodriguez Riotorto.

https://yamwi.sourceforge.net/index.html

Ufv.br is Universidade Federal de Viçosa, Brasil -- I wasn't able to
figure out who made Yamwi available there. Of course, we owe a debt of
gratitude to them. A web interface for any system, Maxima or
otherwise, is making use of computing resources, and obtaining those
resources is probably the key problem to be solved.

Hope this helps in some way,

Robert

Re: [Maxima-discuss] Online interface issue

[Vince Blay-M. <v.b...@gm...>]

Thanks Raymond,
This link works pretty well on pc both Zorin (linux) and windows . my test
on mobil app was a bit sluggish..... possibly due the short-handed key
strokes of the mobil devices (i.e. cellphone lacking execution characters).
Vinny

On Fri, Sep 26, 2025 at 12:45 AM Raymond Toy <toy...@gm...> wrote:

> I don't know what that website did, but maybe this would work for you:
> https://maxima-on-wasm.pages.dev/
>
> Ray
>
> On Thu, Sep 25, 2025, 7:33 AM S Peak via Maxima-discuss <
> max...@li...> wrote:
>
>> Public
>>
>> The maxima online interface is showing as
>>
>> "Hmmm… can't reach this page
>> Check if there is a typo in www.dma.ufv.br.
>>
>>    - Search the web for dma ufv br
>>    <https://www.bing.com/search?form=ANLKDR&q=dma%20ufv%20br>
>>
>> DNS_PROBE_FINISHED_NXDOMAIN"
>>
>> How do I access the online interface as I am not able to download Maxima.
>> Kind regards,
>> Star Peak
>>
>>
>> Public
>> This email may contain confidential information and should not be shared
>> with any third party without the prior written agreement of the sender. If
>> you are not the intended recipient, take no action and contact the sender
>> immediately.
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>


-- 
This e-mail (including any attachment) is for the sole use of the intended
recipient(s) and may contain confidential and/or privileged information. If
you are not an intended recipient, please notify the sender immediately and
delete or destroy the original and any copy.