search

rtoy / maxima

A Clone of Maxima's repo
Other
0 stars 0 forks source link

to_poly_solve error when declare(a,constant) before loading #2029

Open rtoy opened 1 month ago

rtoy commented 1 month ago

Imported from SourceForge on 2024-07-05 17:34:18 Created by bigfooted on 2016-03-20 13:47:46 Original: https://sourceforge.net/p/maxima/bugs/3111

I get an error when I declare the constant "a" before loading to_poly_solve. This is happening when declaring "a" or "b" but not "c" or "_a".

(%i1) declare(a,constant); (%o1) done (%i2) load(to_poly_solve); WARNING: DEFUN/DEFMACRO: redefining macro OPAPPLY in /home/nijsob/mathematics/maxima-5.37.3/share/fourier_elim/fourier_elim.lisp, was defined

in /home/nijsob/mathematics/maxima-5.37.3/share/to_poly_solve/to_poly.lisp WARNING: DEFUN/DEFMACRO: redefining macro OPCONS in /home/nijsob/mathematics/maxima-5.37.3/share/fourier_elim/fourier_elim.lisp, was defined

in /home/nijsob/mathematics/maxima-5.37.3/src/binary-clisp/nummod.fas define: in definition of one_to_one_reduce, found bad argument a -- an error. To debug this try: debugmode(true);

rtoy commented 1 month ago

Imported from SourceForge on 2024-07-05 17:34:18 Created by rswarbrick on 2016-03-20 22:09:57 Original: https://sourceforge.net/p/maxima/bugs/3111/#c31b

I think Maxima is doing the right thing here: you're just asking it to do something a bit odd. If you write declare(a, constant), this means "treat a as a symbolic constant, whose value is some fixed number". This allows you to define new constants that work a bit like %pi or %e.

Inside the code for to_poly_solve, there is a function (one_to_one_reduce) that has a as a parameter. You can see the same error if you write something like this:

declare(a, constant);
foo (a) := 1 + a;

Maxima quite reasonably refuses to evaluate the second definition: it's akin to having written foo(%pi) := 1+%pi. Maybe you've just told me how to evaluate foo at 3.141, but I don't know how to evaluate it anywhere else...

Please reply again to this report in the next couple of days if what I've just written doesn't explain what's going on, else I'll close the report when I next come past.

rtoy commented 1 month ago

Imported from SourceForge on 2024-07-05 17:34:22 Created by rswarbrick on 2016-03-22 08:28:20 Original: https://sourceforge.net/p/maxima/bugs/3111/#074d

Sorry, I don't think this demonstrates that you understood what I tried to explain. The point is that the declare(xxx, constant) feature is a rather low-level mechanism that allows the user to define a new constant. The resulting thing doesn't make sense as a variable any more (just like %pi and %e don't).

You can reasonably argue that existing code should somehow be able to ignore newly declared constants. I think that probably the only way to do that sensibly is to introduce some form of namespaces (something that Robert Dodier has mused about in the past?). However, I don't think a bug report is the right place to track such a large new language feature. Maybe discuss it on the mailing list?

rtoy commented 1 month ago

Imported from SourceForge on 2024-07-05 17:34:25 Created by bigfooted on 2016-03-22 09:34:51 Original: https://sourceforge.net/p/maxima/bugs/3111/#61cf

I'm sorry, I see that in my reply I said variables a,b,c, which is not what I meant. I want "a" to be a constant like %pi and %e. And at the same time I want to_poly_solve to still work and not force me to use constant "c". Anyway, I asked about this on the mailing list and Barton Willis asked me to file a bug report. Robert Dodier said it is scope confusion. I agree that if you want to solve this for the entire maxima cas, it is indeed a big issue. I do think it is an issue that needs to be solved, but maybe not through this bug report. Thanks for your input.