Activity for Robert Dodier
-
Robert Dodier modified ticket #4622
Windows display issue
-
Thank you for your interest in Maxima, and thank you for the bug report. I have closed this ticket as "won't fix" since the problem is not in Maxima itself. Please feel free to raise any new issues on the bug tracker or mailing list (https://sourceforge.net/projects/maxima/lists/maxima-discuss).
-
Hmm, I'm sorry to hear defsystem isn't working for ECL + Windows. Defsystem is an older system for building Lisp programs and indeed it hasn't been updated in decades to the best of my knowledge. I guess my advice is to try to solve the problems in ASDF, although I know that's easier said than done. I have a Windows system I can try it on, I will try to remember to try building with ECL in the near future.
-
incorrect integration
-
Closing this ticket as fixed. Git bisect shows it was fixed by commit 4d8e30 which was intended to fix #4257, nice to see this one got fixed too. I added the original problem as a test case in commit 50a7d7c.
-
Dominik, thanks for the additional example. I've copied it to a separate ticket: https://sourceforge.net/p/maxima/bugs/4620/
-
trigreduce incorrect result with domain = complex
-
limit( (sin(x)+1)/sin(x), x, inf); -> 1 and not und
-
Yes, the examples here should definitely be included as test cases. I've marked this ticket with the milestone has_test_cases. I know that's little-used, but anyway maybe it will help us keep track of this.
-
Appears that this bug was fixed somewhere between Maxima 5.47 and 5.48. I will try to pin down the specific commit.
-
Well, the result %o4 seems OK -- it is not incorrect, right? It's just that limit and/or integrate was not able to figure out the integral. For the record, I see that integrate can't figure out the integral (i.e., returns a noun expression) for both integrate((1-1/t)^t*%e^(%e*t), t, %e, x) and integrate((1-1/t)^t*%e^(%e*t), t, %e, inf).
-
Further, I found that the calculation of the following expression also seems to be problematic: (%i4) n(x) := integrate((1-1/t)^t*%e^(%e*t), t, %e, x); limit(n(x), x, inf); (%o3) n(x):=integrate((1-1/t)^t*%e^(%e*t),t,%e,x) (%o4) integrate((1-1/t)^t*%e^(%e*t),t,%e,inf)
-
Not entirely sure what's going on, but anyway I see (%i26) n(x)/d(x); x ⌠ - %e x ⎮ %e t 1 t (%o26) %e ⎮ %e (1 - ─) dt ⎮ t ⌡ %e and limit appears to be looking at each of the terms; it gets 0 for the limit of the first term (correctly), and for the second it gets inf ⌠ ⎮ %e t 1 t (%o27) ⎮ %e (1 - ─) dt ⎮ t ⌡ %e I speculate the limit is thinking that it can just multiply the two limits together, and then it gets 0. limit might be only looking to see if the result of the second is not a limit noun expression,...
-
OK by me to make the changes suggested. I don't work on the limit code too much but the proposed changes make sense to me.
-
askinteger extremely weak
-
residue should check if taylor series is a power series
-
Maxima-5.48.1 Breaks Draw3d With Surface_Hide=True
-
Thanks for the bug report. I am marking it as "won't fix", since it appears that the problem is in Gnuplot. If some further information is found which suggests the problem is in Maxima after all, no problem, we can just reopen this ticket.
-
Control stack regression with abs_integrate / 5.48.0
-
Looks like this is triggered by a bug in limit. See bug report #4619.
-
limit(inf = inf) causes stack overflow
-
Control stack regression with abs_integrate / 5.48.0
-
floor fails with factored argument
-
ceiling also stumbles on this example, returning an incorrect result. (%i1) ceiling(factor(1013*1019*1021*1031*1033*1039*1049*1051*1061)/3); (%o1) 454732756132228744033075200 while the correct result, I think, is (%i2) ceiling((1013*1019*1021*1031*1033*1039*1049*1051*1061)/3); (%o2) 454732756132228747506337474 Tracing PRETTY-GOOD-FLOOR-OR-CEILING shows that it's called when factor is present, not otherwise. Increasing fpprec to 100 (I didn't try anything else) enables ceiling to return a noun expression...
-
indefinite integral result contains unneeded constant of integration
-
Moving this ticket to the feature requests tracker. The new feature would be detecting a constant of integration which can be omitted from the result.
-
Ticket moved from /p/maxima/bugs/4610/
-
different result in an integral
-
Andres, thanks for taking the time to make a report. I'm marking this ticket as "not a bug", since it appears that the result is correct; it differs from the expected result by just a constant. I agree the presence of the extra constant is suboptimal. I think it's reasonable to think about ways to detect constant terms that could be omitted. That would be a new feature for the indefinite integration code. As such I will move this ticket to the feature requests tracker.
-
I'm not sure about a global variable for this purpose, mostly because it would be hard to explain exactly what the effect of it is -- I'm pretty sure it's possible to display some large expressions, with many more lines than the length of linearraybecause the pretty printer can sometimes break up stuff; we would have to explain why that works some times and not others. How about if we just increase the size of linearray to 1000 or something?
-
Couple of things here. (1) plot2d/plot3d should try harder to get a string -- probably just call $string (via mfuncall since it's a Maxima defmspec) from the value of gnuplot_command. (2) plot2d/plot3d should, of course, catch any Lisp errors and create a Maxima error instead.
-
Tobias, I think you might have to ask for help on the ECL discussion list or create a bug report ticket or something. I searched for some clues about the error message and couldn't find anything. I don't have a Windows development environment so I can't try it for myself. I looked at the ECL source code and the error message seems to be coming out of a C function named si_run_program_inner which appears to implement the Lisp function SYS::RUN-PROGRAM-INNER. I thought maybe I could get some insight...
-
guess_exact_value failure on trivial case
-
I'm closing this as not-a-bug since we weren't able to reproduce it. We can reopen it if someone figures out how to reproduce it.
-
Compilation on Windows using ECL
-
Some digging around in the ECL source code and searching the web seems to show that cl.exe is the MS Visual C/C++ compiler and linker. You mention that you have installed msvc; is it possible that you need to add the folder containing cl.exe to the path? Maybe cl.exe didn't get installed for some reason?
-
Compilation on Windows using Lisp
-
Stavros, I don't see that output; the loop doesn't print anything in either case, and trying similar expressions seems to show guess_exact_value returns reasonable results (not exactly the same as the input, maybe factored differently or, in some cases, with nested sqrts). I tried it with 5.47.0 and with a recent build, on Linux in both cases. What does build_info() say on your system? What do you get if you say batch("rtest_pslq", test) ? That has a number of simple examples for guess_exact_value....
-
guess_exact_value failure on trivial case
-
printf loops indefinitely processing tilde-@ and tilde-curly-brace
-
printf causes Lisp error with tilde-@ and no line termination
-
Here's a proof-of-concept implementation for a Maxima value hash table using cl-custom-hash-table. (load "package.lisp") (load "custom-hash-table.lisp") (in-package :maxima) (defun hasher1 (e) (hasher (list e))) (cl-custom-hash-table:define-custom-hash-table-constructor make-custom-hash-table-one-key :test alike1 :hash-function hasher1) (cl-custom-hash-table:define-custom-hash-table-constructor make-custom-hash-table-multiple-keys :test alike1 :hash-function hasher) (defun $make_custom_hash_table...
-
Yes, I think that's a good solution. I see that project (cl-custom-hash-table) punts the ball to an implementation-specific hash table if one is available, and otherwise constructs a layer over Common Lisp hash tables. That makes a lot of sense to me.
-
Yeah, that looks useless to me too. I suppose part of the issue is that rectform(foo) turns into realpart(foo) + %i*imagpart(foo) which is correct, strictly speaking, but not altogether useful; I wonder if rectform should have flag to say whether to produce results like that. Just thinking out loud. Back to trigrat, I suppose the general approach (at least in this case) is to exponentialize trig functions, apply rectform, and see what falls out. Maybe trigrat (and other functions of a similar nature)...
-
It's not a bug of imaxima. It's behaviour of the counter variable MaxMatrixCols defined in amsmath package. Its default value is 10. If you need, say, 15 cols, issue the instruction \setcounter{MaxMatrixCols}{15} I think this is answered in previous message. Best, Jinsong
-
Steven, thank you for your work on this problem. I fixed the error a different way, which allows trigreduce to allow simplifications involving trig inverses, but to be more careful about it. See commit [ 723d702 ] for the details. Thanks again for your help, I appreciate it.
-
trigreduce: Don't simplify calling a function on its inverse
-
Overly eager simplification in trigreduce
-
Fixed by commit [ 723d702 ]. Closing this report. Thanks to everyone for your comments. It has been a long road, sorry for the delay.
-
Trigreduce doesn't return principal value of atan(tan(...))
-
Fixed by commit [ 723d702 ]. Closing this report.
-
Error with complex numbers - example with trigreduce
-
Fixed by commit [ 723d702 ]. Closing this report.
-
arctan and trigreduce error
-
Fixed by commit [ 723d702 ]. Closing this report.
-
One of the staff tutors at the Open University contacted me with a simpler example. I'll just copy/paste what he wrote: "If you would like to see an easier example of the carg bug then it happens for any angle larger than pi/2. For example trigreduce(carg(cos(3*%pi/5)+%i * sin(3*%pi/5))) will give the incorrect answer."
-
trigreduce(sin(x)^2/cos(x)^2)
-
Still present (same result) in 53c7739 (post-5.47).
-
SOLVE gives a wrong answer
-
Still present (same result) in 7ed806f (post-5.47). I see to_poly_solve returns %union([t = %i*%pi*%z38153]) which seems optimal.
-
Thanks for your interest in Maxima. The problems you describe are consequences of the way that the snap is packaged; I have some more comments about that below. My advice is to stop trying to use the snap and instead install Maxima and/or wxMaxima via apt-get: $ sudo apt-get install maxima maxima-doc maxima-share gnuplot-x11 $ sudo apt-get install wxmaxima The versions of Maxima and wxMaxima which are available for Ubuntu 24.04 are not the most recent versions, but I believe they are close enough...
-
maxima snap install for 5.47.0 partly broken
-
Can't create variable-sized matrix with complex elements
-
Paul, thanks for your interest in Maxima. David S. gave a solution so I'm closing this ticket. maxima-discuss is a mailing list which you use via email, as opposed to a forum used via the browser; you can subscribe to maxima-discuss at: https://sourceforge.net/projects/maxima/lists/maxima-discuss All topics related to Maxima are discussed on that mailing list, comprising how-to questions, software development topics, bug reports, reports about other projects using Maxima, commentary, etc. Feel free...
-
Min/max of demonstrably complex expressions should trigger an error or return und (I'm leaning towards und although not dead-set on it); I don't think it makes sense to return them unsimplified, because that suggests that there is some interpretation, beyond the extent of what's built into Maxima, to make it make sense. Min/max of complex numbers must be undefined since otherwise it implies that complex numbers are ordered -- if we allow that, we are not just extending identities into hitherto-undefined...
-
Bug in postinst script for maxima-common .deb file
-
Phlummox, thank you for your interest in Maxima, and thank you for investigating this problem. I wonder what we should do at this point. Debian installation files are also maintained on the Debian package website (https://packages.debian.org/search?keywords=maxima), and it looks like that list is up to date, so, although we could try to fix this problem, we could also redirect interested users to the Debian package list. I'm kind of leaning towards pointing to the Debian package list, since otherwise...
-
error message when adding non-conformable matrices
-
I've pushed commit [ fa4dcfa1d ] to give a more meaningful error message. Examples: (%i2) matrix ([a, b], [c, d]) + [x, y, z]; addition: non-conformable list or matrix arguments. -- an error. To debug this try: debugmode(true); (%i3) matrix ([a, b], [c, d]) + matrix ([x, y, z], [z, y, x]); addition: non-conformable list or matrix arguments. -- an error. To debug this try: debugmode(true); (%i4) [a, b, c, d] + [x, y, z]; addition: non-conformable list or matrix arguments. -- an error. To debug this...
-
I observed it with a current build (ae4069). A stack trace shows: 0: (ABS (#:%I193 1 1)) 1: (ROOT-BOUND (3 1 0 (#:%I193 1 1))) 2: (STURM1 (#:X192 3 1 0 (#:%I193 1 1)) (1 . 100000000)) 3: (CALLAPPRS (#:X192 3 1 0 (#:%I193 1 1))) 4: (CALLSOLVE1 ((#1=#:X192 3 1 0 (#:%I193 1 1)) . #1#)) 5: (CALLSOLVE ((#1=#:X192 3 1 0 (#:%I193 1 1)) . #1#)) 6: (BAKALEVEL1 NIL ((#:X192 3 1 0 (#:%I193 1 1))) #:X192) 7: (BAKALEVEL (NIL) ((#:X192 3 1 0 (#:%I193 1 1))) #:X192) 8: (ALGSYS ((#:X192 3 1 0 (#:%I193 1 1)))) 9:...
-
batch("foo.mac", test) triggers Lisp error in UNIX-LIKE-BASENAME
-
expand(1/(1+%i)^4) => (-4)^(-1) (unsimplified)
-
Looks like test cases were merged in commit eb4bf.
-
inconsistent limit results with trig
-
Looks like it was fixed by commit 24a57b6 and I see the test cases are present in rtest_limit_extra.mac.
-
tlimit(exp(x)/x^5,x,inf) = 0
-
Bug appears to be fixed now; I didn't investigate when it got fixed. Test cases merged in commit ae40695.
-
Various limits give UND where they should give IND
-
Looks like the test cases were merged in commit df1748.
-
integration error 0 to negative exponent
-
Test cases merged into master as commit 7e6a5ab. Bug is still present.
-
About debugging, see also SB-VM::SHOW-ALL-TLS-INDEXED-SYMBOLS as defined in: https://sourceforge.net/p/sbcl/sbcl/ci/84bd6884dda719158a46e014e4e48d2ac18fd5f3/ That function also requires SBCL to be built --with-sb-devel.
-
Maxima crashes on repeated run of rtest_rules (SBCL 2.5.2)
-
There are other bug reports about similar errors being triggered in various places, not just rtest_rules. See e.g. https://sourceforge.net/p/maxima/bugs/4236/ .
-
OK, after looking at it a little bit, I don't think it's kill(all). Repeatedly trying run_testsuite(tests = rtest_rules) with other Lisp implementations (Clisp, Clozure CL, ECL, ABCL) on WIndows and on Linux works as expected, there's no crash or error even after trying it 20 times. But with SBCL on both WIndows and Linux, it fails after a few tries (3 or 4). I am thinking now that SBCL is allocating something in thread-local storage which happens to be exercised by rtest_rules. If we can figure...
-
My guess is that kill(all) is not correctly restoring the status quo ante with respect to simplification functions. Probably there is some leftover stuff which is getting declared again and it's calling itself. The place to look is the OPERATORS property on MPLUS, MTIMES, etc. I wonder if it's possible to get a stack trace from LDB.
-
Yeah, the mnewton implementation is naive in the sense that it is pretty directly derived from a textbook description of Newton's algorithm, and it's well-known that the results depend on the initial point. I'm a little torn about what to do about this. On the one hand, strengthening mnewton with guards against failed iterations (divide by zero or diverging to infinity or cycles) makes a lot of practical sense. On the other hand, it would be really awesome to be able to formulate a Newton algorithm...
-
Hmm, I think I covered the bit about trace in commit 8a91dae. Do we have an example of a DEFMFUN function which trace handles incorrectly? About COERCE-FLOAT-FUN, the stuff about plotting the real part is a workaround to avoid problems with complex numbers with small imaginary parts. As it has been pointed out, COERCE-FLOAT-FUN got borrowed into the numerical analysis code, where that's maybe not a great idea. The first thing that comes to mind is to say (defvar *plot-realpart* nil) and then have...
-
activecontexts and build_info weirdness
-
Looks like this bug report is a duplicate of #4308 and has been fixed by commit e7fbfb6. (I see that this report is for version 5.47.0, and e7fbfb6 came after 5.47.0.) I'll close this report accordingly.
-
My first guess is that some code is doing destructive modification of static data and the compiler has merged some empty lists (as allowed by CLHS I'm pretty sure). We've bumped into a similar bug before and the work around was just to declare the empty lists as (list '(mlist)) instead of '((mlist)) or something like that.
-
with_stdout doesn't capture output of command executed via system
-
OK, I've pushed patches for various Lisps and tested it on Linux and Windows, and for the combinations I've tried, capturing standard output seems to work as expected. Also made incidental compatibility fixes. Tried it with Clisp, SBCL, Clozure CL, ABCL, LispWorks, and Allegro on Windows, in addition to stuff on Linux as mentioned above. git log --author=dodier 01b2ff~1..ade2052 will show what I was working on. Closing this ticket as fixed.
-
I've pushed commit 01b2ff8 which, I believe, implements standard output capture for several Lisps on Linux (GCL, ECL, Clisp, CMUCL, Allegro, SBCL, Clozure CL, LispWorks, and ABCL). Haven't tried anything on Windows yet.
-
It's not so much that I "don't like" it, as that it is unconventional -- it looks clumsy compared to stuff one sees in textbooks. About NFORMAT, I guess that's a possibility, although it does create a disconnect between the order of terms in displayed expressions and their internal representations. I know that there is already the stuff about MPLUS expressions being displayed in reverse order; I don't know at this point whether we would want to create another such disconnect.
-
Many parts of Maxima assume that constants sort before variables. Why would you want to change that? If you don't like the presentation format, nformat is probably the right thing to change.
-
I guess the test-running code should make use of the macro for ensuring the ordinary display environment for displaying its own messages (but not for displaying the computation results, I guess). I forget what it's called -- WITH-STANDARD-DISPLAY-SETTINGS or something like that.
-
I think it's acceptable that rectform handles the grouping (and that grouping doesn't happen by default). About ordering %i in multiplicative expressions, I would be interested to experiment with changing GREAT so that constants sort after variables, instead of before, as it is now. (Yes, OF COURSE, IT GOES WITHOUT SAYING that any changes to GREAT must be carefully and extensively tested before being pushed into production. Sorry for shouting.)
-
should complex forms look like Real + %i* Imag?
-
I think I see how to get program output to be directed to *STANDARD-OUTPUT* for the various Lisp implementations presently covered by system, except for Allegro and Lispworks; for those I don't have a working installation, but I will consult the documentation and try to guess it. Working on a patch for system, stay tuned.
1 >