Activity for Kris Katterjohn
-
Kris Katterjohn modified ticket #4356
support tracing simplifying functions
-
Merged. Closing this ticket.
-
ChangeLog entry for bug #4356
-
Merge branch 'kjak-bug4356-simp-trace'
-
Thanks, and I agree. Which is why I'm just curious if there is even a consensus on what the result should be even when simply multiplying two literal zeros like 0*0.0. (And I'm not suggesting that we start officially using terms like "exact zero" in Maxima. As I said in the other bug report, I was just temporarily borrowing that from Scheme.)
-
See the already existing bug [#3184]. This sort of thing has been discussed elsewhere too. In that [#3184] I question whether or not we actually want to apply float contagion in some cases involving multiplication of floats with an exact zero 0. I suppose applying float contagion in these cases is the "obvious" thing to do, but it's not actually obvious to me that Maxima should do it in these cases.
-
I was able to sit down earlier today and push my changes to a new branch, kjak-bug4356-simp-trace. You can check it out with git or browse it here: https://sourceforge.net/p/maxima/code/ci/kjak-bug4356-simp-trace/tree/ This includes tracing simplifying functions, the Call/Simp output changes, and the changes to how args are printed out and read in at trace breakpoints. Stavros (or anyone): if you want to play around with this but don't want to checkout this branch with git, I was able to load the...
-
Distinguish between simp and non-simp functions in trace output
-
Fix bug #4356: support tracing simplifying functions
-
trace: only print and read args in a way that users know/care about
-
Add some new tests to rtest_trace
-
Besides changing to Call/Simp (or whatever we want), the last thing I want to do is make traced special forms and simplifying functions play more nicely with things like the break and errorcatch trace options. As it's been implemented, if a user wants to use these options and change the list of args at a trace breakpoint then they are expected to use our internal argument calling conventions. This is just a quick example, but when tracing block and wanting to change the list of args in a call, users...
-
Hi Stavros. I'd prefer using Call/Simp over brackets/parentheses. But either way this just shadows the OPERATORS property, and it works for built-in operators like "+" and functions defined with the simplifying package. (%i4) trace("+"); (%o4) [+] (%i5) 1+2+3; 1 Enter "+" [1, 2, 3] 1 Exit "+" 6 (%o5) 6 (%i6) (1+2)+3; 1 Enter "+" [1, 2] 1 Exit "+" 3 1 Enter "+" [3, 3] 1 Exit "+" 6 (%o6) 6 With display2d:false we have some goofy printing though: (%i11) display2d:false$ (%i12) (1+2)+3; 1 Enter \"\+\"...
-
maybe: add WNA check
-
is: use ONEARGCHECK for a more consistent WNA error message
-
Remove an unnecessary PROGN
-
Set ONCE-TRANSLATED during translation of a named function's body
-
Add symbol checks to translators for MCALL, MARRAYREF, and MARRAYSET
-
Remove the obsolete HOOK-TYPE property from some symbols
-
Consolidate some CASE clauses in TRACE-APPLY
-
support tracing simplifying functions
-
I need to play around with this some more before committing, but I have this working right now: (%i2) trace(sin,cos,gamma)$ (%i3) gamma(x); 1 Enter gamma [x] 1 Exit gamma gamma(x) (%o3) gamma(x) (%i4) gamma(6); 1 Enter gamma [6] 1 Exit gamma 120 (%o4) 120 (%i5) gamma(x+5); 1 Enter gamma [x+5] 1 Exit gamma gamma(x+5) (%o5) gamma(x+5) (%i6) gamma_expand:true$ (%i7) gamma(x+5); /* recursive example */ 1 Enter gamma [x+5] 2 Enter gamma [x] 2 Exit gamma gamma(x) 1 Exit gamma x*(x+1)*(x+2)*(x+3)*(x+4)*gamma(x)...
-
Fix possible lisp error when translating entier
-
Limit gives IND instead of correct finite result
-
I'm updating the name of this ticket since my aforementioned fix for [#3926] changed the result from und to ind: (%i1) R:(rr*cos(rr))/sqrt(1-cos(rr)^2)$ (%i2) limit(R,rr,0); (%o2) ind
-
See also the discussion in [#4376].
-
I agree that a user might expect parallel bindings here, but the documentation for ev describes what's going on: V: expression (or alternately V=expression) causes V to be bound to the value of expression during the evaluation of expr. [...] If V is a non-atomic expression then a substitution rather than a binding is performed. I don't have access to a newer Maxima version at the moment, but here are some quick examples using an older version that I currently have access to: (%i1) ev(a + b, [a, b]...
-
Merge branch 'master' of ssh://git.code.sf.net/p/maxima/code
-
Add translation for plog (using TRANSLATE-WITH-FLONUM-OP)
-
Translate atan2 using TRANSLATE-WITH-FLONUM-OP
-
TRANSLATE-WITH-FLONUM-OP: handle functions that take multiple args
-
Consolidate some code for translating args and unioning modes
-
Lisp error for elliptic_f
-
Hi Barton. I'm not seeing the lisp error using a recent git build: (%i1) K : elliptic_f(%pi,%i); (%o1) elliptic_f(%pi,%i) (%i2) float(%); (%o2) 0.5907605684295543*%i+2.842544562090073 This report is a few years old and there isn't much to go on since there is no error message given. I'm going to close this ticket. If the problem still exists, then please comment or re-open the ticket.
-
(Here I'm ignoring any issues regarding the actual implementation of any of this.) I wonder if there is a consensus on what the result should be, even for these specific cases of multiplying two literal zeros like 0*0.0 or 0.0*0. Of course we could have the result of multiplying a 0.0 with a 0 be a 0.0 just because float contagion. Certainly many languages, including Common Lisp, handle it this way. Alternatively, if I borrow some Scheme terminology for a moment, we could have the result of multiplying...
-
Fix lisp error from quad_qawf when given an invalid trig arg
-
Use %%PRETTY-FNAME in more quadpack error messages
-
I can't test in a recent Maxima build at the moment, but see bug [#4121] where it was argued that neither atan2(0,pz) nor atan2(0,nz) should return a nounform. Looks like in a newer Maxima we should have atan2(0,pz) yielding 0 and atan2(0,nz) yielding %pi.
-
subst allows more than 3 arguments
-
I'm closing this ticket since we have much better wna checks now. (%i1) subst(a,b,x+b,p,q,w); subst: expected at most 3 arguments but got 6: [a,b,x+b,p,q,w] -- an error. To debug this try: debugmode(true);
-
Part of the definition of eval_when is in transl, where it can do useful stuff. But see also [1560c9].
-
Fix the misplaced TRANSLATE property for atan2
-
Fix outdated comment that refers to the old package name BIGFLOAT-USER
-
MFUNCTION-CALL-AUX: replace an EVAL with SYMBOL-VALUE
-
transl: do not assume a catch's mode based on the last body form
-
transl: avoid generating (RETURN (GO ...)) at the end of a PROG
-
Remove the obsolete DEFMTRFUN-EXTERNAL macro
-
transl: simplify MRETURN mode calculation
-
transl: remove outdated and incorrect comment from TR-MPROG-BODY
-
transl: fix toplevel eval_when for eval and load times
-
parsing problem: thru 3 for i in [a,b]
-
Fixed by commit [f2a4dd].
-
Fix bug #3191: parsing problem: thru 3 for i in [a,b]
-
Using git HEAD it seems that I'm seeing what Ray was seeing: (%i1) display2d; (%o1) false (%i2) taylor(-1,x,0,0); (%o2) +(-1) (%i3) taylor(x-1,x,0,1); (%o3) -1+x (%i4) display2d : true$ (%i5) taylor(-1,x,0,0); (%o5)/T/ - 1 + . . . (%i6) taylor(x-1,x,0,1); (%o6)/T/ - 1 + x + . . . So out of these it looks like only %o2 has the display issue now. SBCL and CLISP on Linux.
-
parsing problem: thru 3 for i in [a,b]
-
diff --git a/src/nparse.lisp b/src/nparse.lisp index b32a03fd4..c2de06e0a 100644 --- a/src/nparse.lisp +++ b/src/nparse.lisp @@ -1558,7 +1558,7 @@ ($do . ()) ($for . ($for)) ($from . ($in $from)) - ($in . ($in $from $step $next)) + ($in . ($in $from $step $next $thru)) ($step . ($in $step $next)) ($next . ($in $step $next)) ($thru . ($in $thru)) ;$IN didn't used to get checked for No problems with the test suite, share test suite or rtest_translator. Before: (%i1) '(thru 3 for i in [1, 2, 3, 4] do...
-
translate fails with go tag in final position
-
Thanks for the report. Fixed by commit [0313d7]. (%i1) p(x) := for n thru 4 do block(if n = 2 then go(HOP), print(n), HOP)$ (%i2) p (1); 1 3 4 (%o2) done (%i3) translate (p); (%o3) [p] (%i4) p (1); 1 3 4 (%o4) done
-
Fix bug #4260: translate fails with go tag in final position
-
Add some more tests for go/return to rtest_translator
-
transl: change some go/return warnings to errors
-
Fix the error message for (interpreted) return
-
partswitch affects op and operatorp
-
Hi Robert, thanks for commenting. Fixed by commit [ba1819].
-
Mention inflag in the docs for operatorp
-
Fix bug #4307: partswitch affects op and operatorp
-
parser gives an error for :lisp following a comment
-
Closing this as a "duplicate" of the newer [#4086] since there has been some activity in that one.
-
translate fails with go tag in final position
-
The :lisp construct has several other known limitations as well: https://sourceforge.net/p/maxima/mailman/message/37128965/ If you're interested, the lisp_eval described in that post is now in Maxima under the name eval_string_lisp.
-
partswitch affects op and operatorp
-
I also don't see any inconsistency in operatorp(x,op) returning false and op(x) signaling an error. I also think that operatorp would be more useful if it returned false for an expression without an operator. (And FWIW in commercial Macsyma 421.45 operatorp(x,op) returns false.) However, I do see some problems in the proposed definition above that adds a LISTP check. operatorp, like op, is affected by part flags like inflag. (This is documented for op but not for operatorp.) (%i1) inflag : false$...
-
BIND-TRANSL-STATE: bind *LOCAL* instead of the obsolete LOCAL
-
parse_string fails to parse string which contains semicolon
-
Fixed by commit [e1f4de].
-
Fix bug #3996: parse_string fails to parse string which contains semicolon
-
Compiling: "If" is handled differently on translating and interpreting
-
Closing this ticket. We now get the desired behavior. See bug [#4008] for more. (%i1) foo (x) := if x > 0 then 1 else 0$ (%i2) foo (u); (%o2) if u > 0 then 1 else 0 (%i3) translate (foo)$ (%i4) foo (u); (%o4) if u > 0 then 1 else 0
-
parse_string fails to parse string which contains semicolon
-
Below is a patch with tests. I see no problems with the test suite or share test suite. diff --git a/share/stringproc/eval_string.lisp b/share/stringproc/eval_string.lisp index 72e5bf4ca..884d44769 100644 --- a/share/stringproc/eval_string.lisp +++ b/share/stringproc/eval_string.lisp @@ -54,12 +54,9 @@ (let ((*mread-prompt* "")) (third (mread *parse-string-input-stream*)) )) -;; (ENSURE-TERMINATOR S) -- if the string S does not contain dollar sign `$' or semicolon `;' -;; then append a dollar sign...
-
draw: avoid lisp error when region's expr doesn't evaluate to boolean
-
Replace IS-BOOLE-CHECK with the new $IS-BOOLE-EVAL
-
translator and prederror
-
I've committed fixes and improvements related to various predicates, operators, if, do, is, and maybe. Some of these are related to prederror and some are other things I noticed while working on the prederror stuff. Now translated code now behaves the same as interpreted code wrt prederror. I have many tests that compare the results of translated code with the results of interpreted code. Here's the new behavior for the original example in this bug report: (%i1) F(x) := if equal(x,107) then 6 else...
-
Merge branch 'master' of ssh://git.code.sf.net/p/maxima/code
-
Change the translation of # to avoid the problematic TRP-NOT
-
Merge branch (bug #4008)
-
Translated if now honors prederror
-
Update the ChangeLog for bug #4008
-
Translated do now binds prederror to true when evaluating test
-
Improve the translation of notequal
-
Fix the bogus translations of <= and >=
-
Fix the bogus translations of and/or/not when prederror is false
-
Consolidate code for translating some relational operators
-
Fix the inefficient evaluation of translated predicates
-
Improve the transl modes for is/maybe in the boolean case
-
trpred functions now return mode info
-
Consolidate code for evaluating and/or/not expressions
-
MEVALP_TR: return result of MEVALP1_TR instead of unknown
-
MEVALP1_TR: only return what MEVALP2 does if it's boolean
1 >