maxima-bugs — Reports from the SF bug-tracking system

[Maxima-bugs] [maxima:bugs] Re: #4291 log(%i) isn't %i*%pi/2

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

It is intentional behavior that ``log`` does not try to return the principal value.
Not even ``log(-1)`` simplifies (unless ``lognegint`` is set).

One can imagine many ways of handling the multivaluedness of ``log`` etc. (and I'm sure RJF has written something on this), but the current Maxima behavior is that ``log`` does not try to return a principal value. Probably because doing so leads to problems. Unfortunately, we don't have a *rationale* document explaining all the design decisions like this.



---

**[bugs:#4291] log(%i) isn't %i*%pi/2**

**Status:** open
**Group:** None
**Labels:** log 
**Created:** Tue Apr 16, 2024 10:47 PM UTC by Raymond Toy
**Last Updated:** Wed Apr 17, 2024 02:41 PM UTC
**Owner:** nobody


`log(%i)` returns a noun form.  Should it return `%i*%pi/2`?

However, it's not clear if Maxima's `log` function is the principal log or not.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

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

``kill`` currently doesn't kill system-defined functions, and I don't think it should. It does kill any *values* of those symbols. If the values are system-defined, it shouldn't kill those either. For example, ``float`` is both a system function and a system variable (with slightly different behavior!), so ``kill(float)`` should give an error.

Current behavior (Maxima 5.46.0 SBCL 2.3.0):
~~~~
float(2/3)  =>  0.6666666666666666
block([float:true],2/3)  =>  0.6666666666666666
float(2)  =>  2.0
block([float:true],2)  =>  2
~~~~


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Wed Apr 17, 2024 03:08 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

AFAIK, you can't get back the original version.  And I don't see why a share package wouldn't just use a different name if they want to use a custom version of `taylor`.  A lot less confusing for everyone not to use the well known `taylor` function.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Wed Apr 17, 2024 03:06 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Yes, I agree that `kill(taylor)` removing the assigned value is acceptable.  But if you redefine the function you can't get back the original via `kill`.  That's going to wreak havoc if you forgot or use other packages that depend on `taylor` working as originally defined.

Perhaps the easiest way forward is to have `defmvar` add a property denoting that this is a system variable that should not be killed.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Tue Apr 16, 2024 11:15 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #4280 integrate(sin(n*x)*cos(2*n*x), x) is wrong

[Raymond T. <rt...@us...>]

If the expression involves only one unknown, as in `2*n=n`, I think that's viable.  But what about `sin(k*n*x)*cos(3*k*n*x)`?  We ask if `k*n = 3*k*n`.  If we answer yes, we get a wrong answer again because if it's true, then `k*n = 0`,   and the integral should be 0.  Perhaps if the expression on the left and right sides contain exactly the same variables, we can do something?sbu

But what about `sin(k*n*x)*cos(2*n*m*x)`?  We're asked if `2*m*n=k*n`.  If yes, the integral is `-cos(2*m*n*x)/(4*m*n)`.  This isn't quite right either because `m` or `n` could be zero.


---

**[bugs:#4280] integrate(sin(n*x)*cos(2*n*x),x) is wrong**

**Status:** open
**Group:** None
**Labels:** integrate 
**Created:** Wed Mar 27, 2024 05:09 PM UTC by Raymond Toy
**Last Updated:** Wed Apr 17, 2024 05:06 AM UTC
**Owner:** nobody


In [#4265] we fixed an issue with `integrate(sin(n*x)*cos(m*x),x)`.  However, we now have
```
(%i1) integrate(sin(n*x)*cos(2*n*x),x);
Is 2 n equal to n?

yes;
Evaluation took 0.0000 seconds (2.9100 elapsed) using 81.609 KB.
                                      2
                                   cos (2 n x)
(%o1)                            - ───────────
                                       4 n
```

This is wrong.  Since we said `2n=n`, we must have `n=0`.  The returned integral should be 0 because the integrand is `sin(0*x)*cos(0*x)` which is 0.  Trying to take the limit of `%o1` as `n` approaches 0 returns infinity.  This differs, for example, with
```
(%i2) integrate(sin(n*x)*sin(2*n*x),x);
Is 2 n equal to n?

yes;
Evaluation took 0.0000 seconds (2.2300 elapsed) using 91.742 KB.
                                x   sin(4 n x)
(%o2)                           ─ - ──────────
                                2      8 n
(%i3) limit(%,n,0);
Evaluation took 0.0100 seconds (0.0100 elapsed) using 537.406 KB.
(%o3)                                  0
```

Not sure what to do about this case.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #4291 log(%i) isn't %i*%pi/2

[Raymond T. <rt...@us...>]

Oh, I forgot about `plog`.  And I know `rectform` will produce the desired result.  The question was if `log(%i)` should return `%i*%pi/2` without extra work.


---

**[bugs:#4291] log(%i) isn't %i*%pi/2**

**Status:** open
**Group:** None
**Labels:** log 
**Created:** Tue Apr 16, 2024 10:47 PM UTC by Raymond Toy
**Last Updated:** Tue Apr 16, 2024 11:12 PM UTC
**Owner:** nobody


`log(%i)` returns a noun form.  Should it return `%i*%pi/2`?

However, it's not clear if Maxima's `log` function is the principal log or not.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4280 integrate(sin(n*x)*cos(2*n*x), x) is wrong

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

Hmm, that's a good one. The question is coming from one of the calls to `askequal` in MONSTERTRIG (src/sin.lisp). I wonder if MONSTERTRIG should try to solve `2*n = n` if `askequal` returns `yes`.


---

**[bugs:#4280] integrate(sin(n*x)*cos(2*n*x),x) is wrong**

**Status:** open
**Group:** None
**Labels:** integrate 
**Created:** Wed Mar 27, 2024 05:09 PM UTC by Raymond Toy
**Last Updated:** Wed Mar 27, 2024 05:09 PM UTC
**Owner:** nobody


In [#4265] we fixed an issue with `integrate(sin(n*x)*cos(m*x),x)`.  However, we now have
```
(%i1) integrate(sin(n*x)*cos(2*n*x),x);
Is 2 n equal to n?

yes;
Evaluation took 0.0000 seconds (2.9100 elapsed) using 81.609 KB.
                                      2
                                   cos (2 n x)
(%o1)                            - ───────────
                                       4 n
```

This is wrong.  Since we said `2n=n`, we must have `n=0`.  The returned integral should be 0 because the integrand is `sin(0*x)*cos(0*x)` which is 0.  Trying to take the limit of `%o1` as `n` approaches 0 returns infinity.  This differs, for example, with
```
(%i2) integrate(sin(n*x)*sin(2*n*x),x);
Is 2 n equal to n?

yes;
Evaluation took 0.0000 seconds (2.2300 elapsed) using 91.742 KB.
                                x   sin(4 n x)
(%o2)                           ─ - ──────────
                                2      8 n
(%i3) limit(%,n,0);
Evaluation took 0.0100 seconds (0.0100 elapsed) using 537.406 KB.
(%o3)                                  0
```

Not sure what to do about this case.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4282 integrate((1-cos(x))^(3/2), x, 0, 2*%pi) wrong by factor of 2, correct in earlier version

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

I looked at this some more and I think that there are some different things going on. (1) `integrate((1-cos(x))^(3/2), x, 0, 2*%pi)` calls SININT to compute an antiderivative, which you can see via `display2d: false` and `trace(?sinint)`. But that antiderivative isn't valid over the whole range `(0, 2*%pi)`.  (2) Under some conditions that invalid antiderivative gets simplified to another invalid derivative, this time containing `atan(tan(x))` instead of `atan2(sin(x), cos(x))`. That other pseudo-antiderivative has somewhat different properties. In particular I think `limit` finds a different limit at `2*%pi`. (3) The conditions for simplifying the antiderivative aren't clear. The stuff about cleaning up CLEARSIGN and VARLIST might come into play.

I think it's just luck that Maxima ever got the correct result -- there is too much that's wrong with this picture. I think the place to start is to try to get SININT to return a valid antiderivative, or, failing that, to detect that it can't, and indicate a failure (I don't remember if that means to return NIL or to throw something or what). Independently, we can investigate why the trig expressions get simplified in different ways -- returning different results for the same problem is a bug. We might consider opening separate bug reports for these two aspects.


---

**[bugs:#4282] integrate((1-cos(x))^(3/2), x, 0, 2*%pi) wrong by factor of 2, correct in earlier version**

**Status:** open
**Group:** None
**Labels:** integrate 
**Created:** Mon Apr 08, 2024 07:26 AM UTC by David Scherfgen
**Last Updated:** Tue Apr 09, 2024 04:55 PM UTC
**Owner:** nobody


Current Maxima gives an answer that's half the correct answer.
An earlier version of Maxima (5 41.0) gives the correct answer, which is 2^(9/2)/3.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

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

I think it's fine that ``kill(taylor)`` kills the assigned value. Maxima is a Lisp-2: having both a function value and a value is OK. (Whether that was a good idea we can leave to another day.)


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Tue Apr 16, 2024 10:31 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4291 log(%i) isn't %i*%pi/2

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

We have ``plog`` for principal value: ``plog(%i) => %i*%pi/2``.
For ``log``,  you can use ``rectform``.
Note for example that ``plog(a*b)`` never gets simplified to ``plog(a)+plog(b)``, not even with ``logexpand:super``.


---

**[bugs:#4291] log(%i) isn't %i*%pi/2**

**Status:** open
**Group:** None
**Labels:** log 
**Created:** Tue Apr 16, 2024 10:47 PM UTC by Raymond Toy
**Last Updated:** Tue Apr 16, 2024 10:47 PM UTC
**Owner:** nobody


`log(%i)` returns a noun form.  Should it return `%i*%pi/2`?

However, it's not clear if Maxima's `log` function is the principal log or not.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4291 log(%i) isn't %i*%pi/2

[Raymond T. <rt...@us...>]

---

**[bugs:#4291] log(%i) isn't %i*%pi/2**

**Status:** open
**Group:** None
**Labels:** log 
**Created:** Tue Apr 16, 2024 10:47 PM UTC by Raymond Toy
**Last Updated:** Tue Apr 16, 2024 10:47 PM UTC
**Owner:** nobody


`log(%i)` returns a noun form.  Should it return `%i*%pi/2`?

However, it's not clear if Maxima's `log` function is the principal log or not.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4290 integrate(log(cos(x)), x, 0, %pi2) has non-zero imaginary component

[Raymond T. <rt...@us...>]

---

**[bugs:#4290] integrate(log(cos(x)),x,0,%pi2) has non-zero imaginary component**

**Status:** open
**Group:** None
**Labels:** integrate 
**Created:** Tue Apr 16, 2024 10:44 PM UTC by Raymond Toy
**Last Updated:** Tue Apr 16, 2024 10:44 PM UTC
**Owner:** nobody


```
(%i1) integrate(log(cos(x)),x,0,%pi/2);
Evaluation took 0.5100 seconds (0.5100 elapsed) using 75.429 MB.
                                                        2
                                               35 %i %pi
                            2   2 %pi log(4) - ──────────
                      %i %pi                       3
(%o1)                 ─────── - ─────────────────────────
                        24                  8
(%i2) expand(%);
Evaluation took 0.0000 seconds (0.0000 elapsed) using 25.031 KB.
                                    2
                            3 %i %pi    %pi log(4)
(%o2)                       ───────── - ──────────
                                2           4
```
This is incorrect since `cos(x) >= 0` over the integration range, so the integrand is always real.  The actual value of the integral is `-%pi*log(2)/2`, which we have.  The imaginary part should not be there.

Tracing `antideriv` indicates that Maxima is computing the antiderivative and computing the limits and getting the limits incorrect.  Presumably, the wrong branch is taken.

We have something similar for `integrate(log(sin(x)),x,0,%pi/2)`.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Yes.  We can certainly limit it to symbols that are not `fboundp`.  Not sure if that takes care of everything we want.

But I also believe you shouldn't be able to redefine builtin functions like `taylor`. :-)


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Tue Apr 16, 2024 10:05 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

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

Well, ``*builtin-symbols*`` includes many things that are not variables. For example, ``taylor`` is a function name, and it is perfectly legal (though maybe inadvisable) to set it to a value. Killing it doesn't kill its functional value:
~~~~
taylor(x,x,a,1)  =>   a+(x-a)
taylor:23  =>   23
kill(taylor)  =>   done
taylor(x,x,a,1)  =>   a+(x-a)
taylor  =>   taylor
~~~~
For that matter, you can redefine the function:
~~~~
taylor(q):=q^2$
taylor(23) => 529
~~~~




---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Tue Apr 16, 2024 08:57 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Gunter K. <pet...@us...>]

perhaps kill () should return system variables into their original state instead of undefining them and therefore kill all the changes the user made...


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Tue Apr 16, 2024 04:43 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

I think this is more complicated than just having an `assign` property.  Consider the variable `polyfactor` that is used by `allroots`.  When true, `allroots` produced a polynomial of all the factors instead of just a list of the roots.

Here is a messy example:
```
(%i16) eqn: (1 + 2*x)^3 = 13.5*(1 + x^5);
Evaluation took 0.0000 seconds (0.0000 elapsed) using 1.328 KB.
                                   3          5
(%o16)                    (2 x + 1)  = 13.5 (x  + 1)
(%i17) allroots(eqn);
Evaluation took 0.0000 seconds (0.0000 elapsed) using 55.602 KB.
(%o17) [x = 0.8296749902129361, x = - 1.0157555438281212, 
x = 0.9659625152196369 %i - 0.4069597231924075, 
x = - 0.9659625152196369 %i - 0.4069597231924075, x = 1.0]
(%i18) polyfactor:true;
Evaluation took 0.0000 seconds (0.0000 elapsed) using 80 bytes.
(%o18)                               true
(%i19) allroots(eqn);
Evaluation took 0.0000 seconds (0.0000 elapsed) using 57.398 KB.
(%o19) - 13.5 (x - 1.0) (x - 0.8296749902129361) (x + 1.0157555438281212)
                                  2
                                (x  + 0.813919446384815 x + 1.0986997971102883)
(%i20) kill(polyfactor);
remvalue: polyfactor
                  doesn't appear to be a known variable; just unbind it anyway.
Evaluation took 0.0000 seconds (0.0000 elapsed) using 10.125 KB.
(%o20)                               done
(%i21) allroots(eqn);
allroots: unexpected error; treat results with caution.
allroots: only 2 out of 5 roots found.

Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable $POLYFACTOR is unbound.
   [Condition of type UNBOUND-VARIABLE]

```
So, we killed `polyfactor`.  The error message about `remvalue` is kind of confusing.  What makes it not a known variable?

Then when we call `allroots` again, we get an error that `polyfactor` is unbound.

Is there really any reason we should allow the user to kill system variables?


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 08:22 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

What should happen if we try to kill a variable that has an assign property?  Silently do nothing?  Print a warning?  Signal an error?

I think I have this implemented correctly, but I'd like to know what people think should happen when you do this.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 08:20 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Weird, but ok. Not going to do anything about those.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 08:01 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] Re: #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Commit [d67e64] adds the variables related to the translator.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 04:52 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4286 fourie package fail for square wave coefficients

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

- **labels**: share packages, fourie --> share packages, fourie, limit, ldefint



---

**[bugs:#4286] fourie package fail for square wave coefficients**

**Status:** open
**Group:** None
**Labels:** share packages fourie limit ldefint 
**Created:** Wed Apr 10, 2024 12:13 PM UTC by Eric Majzoub
**Last Updated:** Sun Apr 14, 2024 07:20 PM UTC
**Owner:** nobody


I'm resubmitting this bug because I noticed that an earlier version of Maxima (5.45.1) works, but the current git version has the bug. Also, my first attempt to submit the bug report did not show up. I think it should have been 4272, but that number is missing in the bug list.

(Note: setup_autoload("abs_integrate.mac",unit_step)  is in my maxima-init)

This works fine:
~~~
Maxima 5.45.1 https://maxima.sourceforge.io
using Lisp SBCL 2.3.6-2.fc39
(%i1) f(x):=2*unit_step(x)-1;
(%o1)                     f(x) := 2 unit_step(x) - 1
(%i2) load(fourie);
(%o2)         /usr/share/maxima/5.45.1/share/calculus/fourie.mac
(%i7) fourier(f(x),x,1);
(%t7) a[0] = 0
(%t8) a[n] = 0
(%t9) b[n] = 2/(%pi*n)-(2*cos(%pi*n))/(%pi*n)
~~~

Current git does not:
~~~
Maxima branch_5_47_base_1083_ga2775dcfb https://maxima.sourceforge.io
using Lisp SBCL 2.4.3
This shows the bug:
(%i15) fourier(f(x),x,1);
(%t15) a[0] = 0
(%t16) a[n] = -(('limit(signum(x)*sin(%pi*n*x),x,-1,plus))/(%pi*n))
            +('limit(signum(x)*sin(%pi*n*x),x,1,minus))/(%pi*n)
(%t17) b[n] = -('limit(1/(%pi*n)+signum(x)/(%pi*n)
                                -(signum(x)*cos(%pi*n*x))/(%pi*n),x,-1,plus))
            +'limit(1/(%pi*n)+signum(x)/(%pi*n)
                             -(signum(x)*cos(%pi*n*x))/(%pi*n),x,1,minus)
~~~




---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #4286 fourie package fail for square wave coefficients

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

Eric, I think the various behaviors observed are due to changes in `limit` and maybe `ldefint` in different versions of Maxima. The simplest related example which I can find is the following. I am working with the current version (5a08d75).

By the way, Maxima has a built-in `signum` function so I'll work with that instead of `2*unit_step(x) - 1`.
```
(%i4) ldefint(signum(x)*sin(x),x,0,%pi);
                  ⌠                               ⌠
                  ⎮                               ⎮
(%o4)   limit     ⎮ signum(x) sin(x) dx - limit   ⎮ signum(x) sin(x) dx
        x -> %pi- ⎮                       x -> 0+ ⎮
                  ⌡                               ⌡
```
Verbifying the `limit` and `integrate` noun expressions doesn't change the result:
```
(%i5) ev (%, nouns);
                  ⌠                               ⌠
                  ⎮                               ⎮
(%o5)   limit     ⎮ signum(x) sin(x) dx - limit   ⎮ signum(x) sin(x) dx
        x -> %pi- ⎮                       x -> 0+ ⎮
                  ⌡                               ⌡
```
However, after loading the share package `abs_integrate`, I see that Maxima can figure out a result for those.
```
(%i6) load (abs_integrate) $

(%i7) ev (%o4, nouns);
(%o7)                                  2
```
Going back to the Fourier decomposition. Bear in mind that `abs_integrate` is loaded already.
```
(%i11) load (fourie) $

(%i12) fourier (signum(x), x, 1);
(%t12)                               a  = 0
                                      0

(%t13)                               a  = 0
                                      n

                        2 signum(x)   2 signum(x) cos(%pi n x)
               limit   (─────────── - ────────────────────────)
               x -> 1-     %pi n               %pi n
(%t14) b  = 2 (────────────────────────────────────────────────
        n                             2
                                        2 signum(x)   2 signum(x) cos(%pi n x)
                               limit   (─────────── - ────────────────────────)
                               x -> 0+     %pi n               %pi n
                             - ────────────────────────────────────────────────)
                                                      2

(%o14)                         [%t12, %t13, %t14]
```
As in the preceding example with just `signum`, Maxima needs an extra nudge to complete the calculation.
```
(%i15) ev (%t14, nouns);
                                  2     2 cos(%pi n)
(%o15)                     b  = ───── - ────────────
                            n   %pi n      %pi n

```
I think the current behavior of Maxima is not incorrect, although it's less useful when it returns stuff that needs further evaluation. I guess it could be a bug that Maxima lost the ability to calculate some limits along the way from 5.45 onward to the present. I will look at changes in the behavior of `limit` and see what the changes are, and whether they amount to bugs. I will leave this open while I look at that and then close this one, and maybe open another ticket for anything I find.


---

**[bugs:#4286] fourie package fail for square wave coefficients**

**Status:** open
**Group:** None
**Labels:** share packages fourie 
**Created:** Wed Apr 10, 2024 12:13 PM UTC by Eric Majzoub
**Last Updated:** Thu Apr 11, 2024 02:44 PM UTC
**Owner:** nobody


I'm resubmitting this bug because I noticed that an earlier version of Maxima (5.45.1) works, but the current git version has the bug. Also, my first attempt to submit the bug report did not show up. I think it should have been 4272, but that number is missing in the bug list.

(Note: setup_autoload("abs_integrate.mac",unit_step)  is in my maxima-init)

This works fine:
~~~
Maxima 5.45.1 https://maxima.sourceforge.io
using Lisp SBCL 2.3.6-2.fc39
(%i1) f(x):=2*unit_step(x)-1;
(%o1)                     f(x) := 2 unit_step(x) - 1
(%i2) load(fourie);
(%o2)         /usr/share/maxima/5.45.1/share/calculus/fourie.mac
(%i7) fourier(f(x),x,1);
(%t7) a[0] = 0
(%t8) a[n] = 0
(%t9) b[n] = 2/(%pi*n)-(2*cos(%pi*n))/(%pi*n)
~~~

Current git does not:
~~~
Maxima branch_5_47_base_1083_ga2775dcfb https://maxima.sourceforge.io
using Lisp SBCL 2.4.3
This shows the bug:
(%i15) fourier(f(x),x,1);
(%t15) a[0] = 0
(%t16) a[n] = -(('limit(signum(x)*sin(%pi*n*x),x,-1,plus))/(%pi*n))
            +('limit(signum(x)*sin(%pi*n*x),x,1,minus))/(%pi*n)
(%t17) b[n] = -('limit(1/(%pi*n)+signum(x)/(%pi*n)
                                -(signum(x)*cos(%pi*n*x))/(%pi*n),x,-1,plus))
            +'limit(1/(%pi*n)+signum(x)/(%pi*n)
                             -(signum(x)*cos(%pi*n*x))/(%pi*n),x,1,minus)
~~~




---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

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

- **Comment**:

Setting or binding ``%``, ``_``, and ``__`` can occasionally be useful, although arguably in poor taste.



---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 03:03 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Commit [ced117] checks the values for all the variables listed in this bug except for the ones related to translation.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 03:02 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Filed [#4209] to document `all` for `savedef` and `showtime`.


---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sun Apr 14, 2024 03:01 PM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Maxima-bugs] [maxima:bugs] #3703 Many variables shouldn't be killable; also allowable values for some variables

[Raymond T. <rt...@us...>]

Minor correction:  `$loadprint` can also be `autoload` or `true`.

We also probably don't want to allow users to set `_` and `__`.  And
maybe `%`.  However, it seems a bit harmless because after the another
input, `_` and `%` appear to have the correct values.

Not really sure what to do wit h`savedef` and `showtime`, since the value `all` isn't documented.




---

**[bugs:#3703] Many variables shouldn't be killable; also allowable values for some variables**

**Status:** open
**Group:** None
**Labels:** kill assignment 
**Created:** Tue Jan 12, 2021 08:26 PM UTC by Stavros Macrakis
**Last Updated:** Sat Jan 23, 2021 04:10 AM UTC
**Owner:** nobody


There are many global variables which shouldn't be killable.
First off, any variable with an 'assign property.

But also all the other variables which are read by Maxima, whether they're boolean  (simp, dotassoc, ...) or numeric (maxposex, ...). Probably every $xxx variable that is defmvar or declared special.

Then the following ones need to have assign properties added (with legal values):

$logexpand
(nil t $all $super)

$loadprint
(nil $loadfile)

$radexpand $rootsconmode $triginverses $scalarmatrixp $assumescalar
(nil t $all)

$savedef $showtime
(nil t $all) -- not documented

$tr_warn_fexpr $tr_warn_meval $tr_warn_mode $tr_warn_undeclared $tr_warn_undefined_variable
($all $compile $compfile $translate)


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.