Activity for Robert Dodier
-
Robert Dodier posted a comment on ticket #4294
It appears Gnuplot doesn't provide any complete reset function. The accepted answer for this question: https://stackoverflow.com/questions/64498369/total-reset-of-a-gnuplot-session has some details about working around the issue.
-
Another possibility is Gnuplot's save command, which writes current settings into a file, which can be loaded via Gnuplot's load command. I see save treats the set term value specially; one has to save save term to get the set term string! Yikes. I wonder if save has been made more comprehensible in more recent versions (I'm working with Gnuplot 5.0).
-
I encountered another example of this bug; the gnuplot_svg_background leaks from one plot to the next when plot_format is gnuplot_pipes, but not when it is gnuplot. See the examples for that in tests/rtest_plot.mac. Looking at the Gnuplot documentation (Gnuplot 5.0 for the record -- I know that's old), I see it says: (quote) The following are not affected by reset. set term set output set loadpath set fontpath set linetype set encoding set decimalsign set locale set psdir set fit Note that reset...
-
update to 'apply' documentation ...
-
I don't see why Maxima should prohibit differentiating with respect to a constant. Surely it's equivalent to just renaming the variable, carrying out the operation, and naming it back again.
-
restructure 'format' package table info
-
Create texinfo documentation for package 'format'
-
Merged into master as commit 805c385 which comprises both commits shown here. I have some follow-up questions about it which I'll raise on maxima-discuss.
-
Add in support for the gnuplot "pointinterval" option to plot2d.
-
MS Windows: quit after plot2d with plot_format = gnuplot causes error when trying to delete temporary file
-
@vttoth I'm inclined to look at whether a concise description of the behavior is possible; if so, then fix up the documentation, otherwise formulate a concise description and make the code match it. I would be interested to consider requiring that the second argument be a mapatom, and to assign it but not evaluate it. I'm not yet ready to claim that must be the case, only that I'm willing to consider it. If we change the behavior, we should ideally make some previous behavior an error, as opposed...
-
Here's another bit reported by @willisbl a few days ago. "To find the number of terms, makelist calls float on the difference of the fourth and third arguments. The function float looks up numerval data. So (%i1) numerval(a,7)$ (%i2) makelist(a,k,a,8); (%o2) [a,a] This is OK, I guess, but is it predictable from the user documentation? No, I don't think so."
-
makelist evals 2nd arg and doesn't report some errors
-
I'm generally in favor of fixing up stuff like that, in the interest of making it easier to predict what's going to happen. makelist being pretty commonly used, it seems like it merits special attention -- if you have any bug fixes, I would be interested to try it.
-
Thanks for the bug report. Does it work correctly for any number smaller than 13?
-
imaxima is unable to display zn_mult_table(13)
-
The function part2cont of the sym module is unable to handle cases with multiple variables
-
The function part2cont of the sym module is unable to handle cases with multiple variables
-
STYLE-WARNING in share/contrib/diffequations/odelin.lisp
-
I think it's SBCL which generates warnings like that; I've tagged it accordingly. If that's not right, we'll just change the tag.
-
difapply mostly untested in testsuite
-
Maxima can't differentiate beta function
-
'diff(CONST,VAR) should simplify to zero
-
I think there are two separate problems here. (1) About the symbol property INTERNAL, comments in the code say that it is supposed to prevent the symbol from appearing in asksign questions. Only one built-in symbol has it (namely ind) , and it is assigned to gensyms or other made-up symbols in the limit and integration code. I don't think we should worry about users assigning it to a symbol; it is not a Maxima symbol and it can't be assigned by a Maxima function. (2) About the gensym appearing in...
-
wrong answer to a complex expression of real integral
-
I've pushed commit cbf63ef to put the example shown in the original problem statement into rtest4.mac.
-
floor, ceiling, unit_step need simplifications applied to noun forms
-
Ray, sounds great. Why don't you go ahead and merge the bug fix branch, I don't feel the need to review it. The changes you've mentioned make sense to me.
-
I tried this patch and after a clean build with SBCL it seems to prevent the bug from surfacing. diff --git a/src/globals.lisp b/src/globals.lisp index 6b620e0e4..c07e59414 100644 --- a/src/globals.lisp +++ b/src/globals.lisp @@ -1133,7 +1133,7 @@ (defmvar $factorflag nil "If `t' constant factor of polynomial is also factored" :properties ((evflag t))) -(defmvar $dontfactor '((mlist)) +(defmvar $dontfactor (copy-tree '((mlist))) "A list of variables with respect to which factoring is not to occur.")...
-
I seem to recall bumping into some kind of surprise when constant data are modified by a destructive operation. I think maybe it was the compiler merging identical constant expressions and then it got destructively modified somewhere. See: https://stackoverflow.com/questions/74947450/common-lisp-is-the-interpreter-or-compiler-allowed-to-coalesce-identical-consta In this case I speculate that the constant expression is ((MLIST)) and somewhere it has been modified to contain the build info list.
-
Thanks, Ray. I agree that resolving all the warnings is a worthy goal, and although doing all of them is going to be a lot of work, we can work on it a little bit at a time.
-
psubst simplifies with simp:false
-
I've bumped into this before. psubst should honor the prevailing value of the simp flag -- I guess that is what the patched version is doing above.
-
calculates geometric sum incorrectly inside integrate function
-
I've marked this as "not a bug". Osman, thanks for your interest in Maxima and taking the time to submit a ticket.
-
programmode is mostly broken
-
Probably programmode should just be expunged. There are too many ways to solve equations, and I don't think it's worth the effort to try to extend each of them to handle programmode.
-
I agree the patch is terrible in the sense that it is changing things that shouldn't make a difference; it's probably masking a deficiency in the build system, as you were saying. I wonder if it's possible to pare it down to a smaller set of variables (ideally just one), which could help us determine which files are out of order in the build system. Although it is puzzling to me that putting the variables in global.lisp doesn't produce the correct behavior, since globals.lisp is always compiled before...
-
I've attached a possible bug fix. This is just undoing some of the moving around declarations in commit fa86361. I don't see why this would fix it; it seems possible to me that there is some other problem, still invisible, which this patch is masking. However, at least this seems to make this bug go away.
-
configure script doesn't honor some --without-foo flags
-
Invisible characters should work better
-
Unicode punctuation characters should be handled as ASCII synonyms
-
Parser complains but doesn't err out on bad syntax
-
Changing the status from "maybe-fixed" to "closed" since "maybe-fixed" suggests it needs testing to verify the bug has gone away, and that testing has already been carried out.
-
Ticket moved from /p/maxima/bugs/4309/
-
Ticket moved from /p/maxima/bugs/4310/
-
Looks like FFACTOR assigns DISREP properties.
-
I bumped into this issue just a moment ago. I find that read_matrix("filename.csv") fails to recognize the BOM at the start of filename.csv, but S: openr("filename.csv"); read_matrix(S, 'comma) does appear to recognize, and omit, the BOM. The first thing that comes to mind is that openr is opening the file with a different character encoding than read_matrix -- my first guess is that whatever openr is doing should be copied by read_matrix. Or perhaps read_matrix should call openr to open the file...
-
read_nested_list and read_matrix give unexpected results on csv files that start with a BOM
-
I bumped into this issue just a moment ago. I find that read_matrix("filename.csv") fails to recognize the BOM at the start of filename.csv, but S: openr("filename.csv"); read_matrix(S, 'comma) does appear to recognize, and omit, the BOM. The first thing that comes to mind is that openr is opening the file with a different character encoding than read_matrix -- my first guess is that whatever openr is doing should be copied by read_matrix.
-
Tracing PDISREP and PDISREP2 seems to show the results diverge there. Looks like PDISREP2 gets a different argument in SBCL compared to Clisp. Is it possible that the wrong value has been assigned to a DISREP property? If so that suggests a problem in NEWSYM.
-
Some investigation shows that the error is coming out of RETFACTOR1, for which SBCL returns -6 where a nonatomic expression is calculated by Clisp. Here's a slightly modified case. I see that factor is called by gfactor on a modified argument. I've skipped ahead to the factor call here. $ sh maxima-local -g Loading /home/dodier/.maxima/maxima-init.mac Maxima branch_5_47_base_1182_gdc9d6aa https://maxima.sourceforge.io using Lisp SBCL 2.3.7 Distributed under the GNU Public License. See the file COPYING....
-
Hmm. I am also working on Linux x86_64, with SBCL 2.3.7 and ECL 23.9.9. With branch_5_47_base_1182_gdc9d6aa (a few commits later than the ones shown above), I see the error with both SBCL and ECL (and not with Clisp 2.49). Ray, can you try a clean build and see if that changes anything?
-
gfactor throws Lisp error
-
git bisect seems to indicate that commit [ fa86361 ] is the origin of the bug. That commit changed special variable declarations -- I speculate that special variables might be handled differently by different Lisp implementations. It would be interesting to trace different Lisps and see if the code path is the same or different, and if different, then where and why they diverge. Bear in mind that fa86361 won't build without modification -- there is a stray n at the very top of src/lmdcls.lisp which...
-
Copying message from RJF via email. """ I think this is wrong. Evaluated numerically and expanded Maxima gives -(4.934802200544679*%i)-1.5707963267948966 But the integral evaluated directly numerically (using romberg() ..) gets 0.696094.... Mathematica gets 1/8 \[Pi] (-1 + Log[16]) which is 0.696094... Exploring whether li[2] is computed wrong.. Mathematica says PolyLog[2,-1/2]//N is -0.448.. Maxima says li[2](-1/2) is -0.448.. So that's not it. Note that this expression ex can be anti-differentiated...
-
Trying the example with commit ff883f32a (post 5.47) with SBCL 2.1.11 on Linux returns a result in terms of polylogarithm functions. I don't know if it's correct. -(((%i*(12*li[2](2)-6*log(2)^2)+%pi*(24-12*log(2))+19*%i*%pi^2)/12-%i*li[2](-(1/2))-%i*li[2](-2))/4)
-
asksign: internal error, zeroa+zerob: integration prompts error
-
parsing problem: thru 3 for i in [a,b]
-
round/floor/ceiling slow for hi-precision bfloats
-
-1/taylor(x,x,0,1) => 0
-
spherical_harmonic(n,m,x,y) incorrect
-
0 * 0.0 --> 0, but 0.0 * 0 --> 0.0
-
rectform(abs(XX)) should not assume that XX is real
-
Simplify sqrt(2*x^2) with domain:complex
-
Problems related to "assume"
-
read_matrix issues
-
Incorrect integral evaluation
-
forget doesn't check argument structure
-
remove removes facts created by declare. On looking at the reference manual, I see the items for remove and forget don't specifically say that, so that could be clarified. An alternative is to extend forget to handle facts from declare but I think we don't want to go down that road.
-
forget doesn't handle facts created with declare
-
OK by me to change op to bind partswitch to false.
-
Footnote. This specific problem was fixed by commit 411e3500. I see that the test for floating point infinity is unconditional; I am thinking that it should be possible to disable it, given that one can create floating point infinity through operations other than exponentiation, so it's not generally prohibited in Maxima, if allowed by the Lisp implementation.
-
find_root() gives completely wrong result
-
carg(-1),numer => %pi
-
Lisp error from trigreduce
-
Still present post-5.47. A stack trace shows that the error stems from the function *RED calling CL:GCD with a null argument. I didn't investigate further.
-
ev doesn't work as expected with subscripted variables
-
"if" doesn't give errors for non-booleans
-
lambda[...] doesn't give error
-
I agree that lambda[[x], ...] shouldn't be treated as a function, but I'm not sure it should be an error. Something like lambda[3] could be treated as an ordinary subscripted variable (as it is now).
-
plot2d incorrectly plots |xy|+1=|x|+|y|
-
Commit [ 5cf6012 ] changes the default value of sample such that the examples of plot2d cited in this report all produce a reasonable output (the lines are a little crooked but there are two vertical and two horizontal lines in each case). There is more work that could be done on implicit plots but let's close this report and look for further problems.
-
2D Plot issue
-
I see that commit [ 5cf6012 ] changed the default value of sample, which is enough to correct the problem reported by OP. I know that there is more to do about the implicit plot sampling topic, but let's close this report and wait for additional reports about any problems detected post-5cf6012.
-
Some time ago I wrote a function inferred_encoding which is in the stringproc package. inferred_encoding is autoloading. Can someone try inferred_encoding on some examples of files which contain byte-order marks and see if it returns the correct value? Or attach some examples of such files to this bug report so that I can try them?
-
Reading tab-delimited datafiles
-
Hi Rene, thanks for the update. From what you said, the problem is the presence of ascii(9) versus ascii(11), so it seems like the problem is not in Maxima itself. I'm marking this report as "not a bug" accordingly. No problem, please open a bug report or post a message to maxima-discuss whenever you run into something. Hope this helps, and all the best.
-
Rene, looks like there are a few different things going on. First, the ASCII tab character is control-I, and since I is the 9th character, tab is ascii(9), not ascii(11) (unless you have modified the global variable ibase to allow octal number input via ibase: 8.; note that the trailing dot with no further digits indicates a decimal integer, whatever the value of ibase). If you try split(dataLine, ascii(9), true), does it work as expected? Second, can you specifically try the same operation in command...
-
Rene, thanks for the bug report. What is the error message which you are encountering? You mentioned wxMaxima; does the operation work as expected if you run it in command line Maxima instead?
-
Looks like the error is coming from POWERX in src/matrix.lisp. POWERX has already called $INVERT which returns scalar 1, and then POWERX calls CHECK which emits the error message. CHECK is essentially ensuring that its argument is a matrix, coercing a list to a matrix; maybe it should coerce a scalar to a matrix as well? Dunno. Or, maybe POWERX should be reorganized slightly to ensure that CHECK isn't called after $INVERT.
-
Well, it's unnecessary for string output to get routed through this stuff constructing an uninterned symbol -- I guess that's probably a vestige left over from when Maxima strings were implemented as Lisp symbols. I don't know how to adjust the trip through DIMENSION-ATOM but anyway it seems like if the argument is a string, it should just be output as such. I don't know without looking which function has coerced the string to a list of characters, but anyway that seems unnecessary. The bit in MAKESTRING...
-
hardcoded ASDF cache path
-
Hi Fabio, thanks for your interest in Maxima and Maxima-Jupyter. I see that you've opened a ticket on the issue tracker for maxima-jupyter over on GitHub (https://github.com/robert-dodier/maxima-jupyter/issues/127), that's great. Since this problem is specific to maxima-jupyter, we should conduct any discussion over on GitHub instead of here. I'll close this ticket and try to follow up on the other ticket.
-
printf fails to output initial percent sign when tilde-m present
-
plot3d() error with Gnuplot 6
-
Unused variables in src/plot.lisp
-
if statement in function ignored while plotting
1 >