-
-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fast_callable should respect the variable order in callable symbolic expressions (treating them like lambda functions rather than like expressions) #7512
Comments
comment:2
Robert and I decided that the fourth plot should be the same as the second, but it is not. The error is in the fourth plot. The problem seems to be that in the fourth plot, the g(x,y) is really called as g(x=x_val, y=y_val), but should just be called as g(y_val, x_val) (i.e., not with named variables, but with just positional parameters). |
comment:3
Attachment: trac-7512-fast_callable-callable_expressions.patch.gz |
comment:4
We decided that this was just a symptom of a much deeper issue in fast_callable. The patch fixes the issue in fast_callable. |
Author: Robert Bradshaw, Tim Dumol, Jason Grout |
comment:7
Applied patch trac-7512-fast_callable-callable_expressions.patch to sage-4.3.2-alpha0 and tried the exact commands below (in that order). I looked for all 4 plots to be the same (as per the ticket description) but only Plot3d No.1 was the same as Plot3d No.3 - AND - Plot3d No.2 was the same as Plot3d No.4. I tried to see if swapping the ranges of x and y, would give me a clue as to what might be going on (refer plot3d No.5 below) but that caused an exception "ZeroDivisionError: float division" (at line 954: count = (end-start)/step IN sage/misc/misc.pyc)
|
comment:8
rossk: we decided that the four plots shouldn't be equal after all; the first should be the same as the third, and the second should be the same as the fourth. ping to robertwb: if you have time, it'd be great if you could review this too. |
Reviewer: Ross Kyprianou |
comment:9
Played with some examples and can see that the examples below act like lambda functions now (regardless of variable name or variable order or function format - all plots came out the same as expected). Hope that helps speed up the review (someone will still have to do the code review)
|
comment:10
I have two dumb questions. Not putting "needs work" in case someone else decides on the review.
|
comment:11
Replying to @kcrisman:
We do allow other variable names in callable expressions:
I'm also looking at your other points... |
comment:12
I meant that we aren't allowed to use another variable name to substitute for x and y, but rossk's examples indicate you can do this somehow (?) now since the variables are ignored. |
comment:13
Replying to @kcrisman:
I think in retrospect, I agree that this patch does not have the right design decision. Instead of throwing away the var values, we should make the default be the x.args() (so that someone doesn't need to specify the vars keyword if passing in a CallableSymbolicExpression). |
comment:14
Replying to @kcrisman:
The Expression in the code is different than Symbolic Expressions (instead, they are related to Expression trees, a fast callable construct. |
comment:16
I'm doing quite a bit of work on fast_callable over on #5572. I think I'll try to take care of this issue (with the different design decision I just mentioned) over there. |
comment:17
Changing to needs info, pending the decisions and work over on #5572 (i.e., the info needed is: is this ticket obsolete and invalid?) |
comment:24
Stalled in |
This is a somewhat subtle issue if the function is a pure python function (you'd need to analyze the argument names), but maybe a convention is that if variable names are specified, they must match up to argument names in the function, and then they are slotted into the function using a dictionary, so that no matter where in the variable range list the range for x appears, it always is sent to the function as f(x=value).
See http://sagenb.org/home/jason3/302/
I think that each of these should return the same plot:
CC: @sagetrac-wcauchois @robertwb @orlitzky
Component: graphics
Author: Robert Bradshaw, Tim Dumol, Jason Grout
Reviewer: Ross Kyprianou
Issue created by migration from https://trac.sagemath.org/ticket/7512
The text was updated successfully, but these errors were encountered: