Drawing Surface Function [TODO]

(1) How to draw now:
To plot a 1-D surface function
f(x) = sin(x)
You can use:

external matlab
reads surface_line;
system
f(x) = sin(x);
surface_line = f(t);

To plot a 2-D surface function
x+y=0, you should treat x as t and
define y in terms of x, so you get y = f(x),
Then use above method to draw it.

Or you can parameterize both x, and y with another z
func_x (x) = sin(x);
func_y (y) = cos(y);

then define
x_curve = func_x(t);
y_curve = func_y(t);

in matlab reads x_curve, and y_curve.

(2) Problem:
"This will work around the derivative issue and the code appears to work fine, but now I am unable to plot the surface that the vehicle traverses, because it is a function. Is there some way to do this? It would be helpful if once I have more complex surfaces I can see the surface and the system's response to the surface together on the plot. Thanks."

"I agree that this will work, but it regresses back to what I had for the implementation before this. Before I could create a function, I had to individually create each track along the surface in terms of t. If you look at 2DofSpringDamper-4Wheel-Surface.phydl on my Wiki page, that is what I did there - after individually calculating each line along the surface in terms of t, I could plot them. However, this is not the ideal way to do things. Assuming a more complex system, or one where there are more than four objects tracking along a surface, it can become quite tedious to calculate each individually, and ideally the software should be able to do it for you. This was the whole point of adding functions in the first place - so that you dont have to calculate each function. Which worked (see 2DofSpringDamper-4Wheel-Surface2.phydl, allowing for modifications for derivative of function), but then its not helpful if you have to calculate each function anyway again to plot.

Basically, while I agree that this will work around the problem, it is a step backwards, and I think that there is some better way to fix the problem. Everyone please let me know what they think."

-Kevin

(3) Comments:
"the problem is that Kevin would like to render a multi-parameter function (the surface), and we are only letting it pass to the outside world as a single parameter function. This seems like a particularly enlightening situation, because it points out a limitation of the current way in which we are doing "external": We are assuming that all external interactions with the outside world are simple values that are functions of times. This is certainly a very useful thing to have, but it is not the only kind of thing that we'd like to have in external with the outside world. When we are working on real problems in Acumen and we are modeling a complex physical
environment, this model will have complex constants that are basically functions, and we will want to have a good way to pass such functions back and forth with the outside
tools."

"[TO Angela]: In some sense, we can already achieve this with the current external mechanism. Basically, if we want to export a function f:A -> B we can export it
as (lambda (t) f) : T -> A -> B, which is a function that just ignores time. The only problem, of course, is that the user on the other side is likely to recompute this function many times on the other side. of course, we also have to have function spaces in our co-domain. An alternative way that might be worth trying is to allow a new syntactic form "reads constant ..." and "writes constant ..." which basically does the trick that we are talking about above implicitly, and could possibly make it easier for outside programs to recognize this situation."

-Walid