GraphCa has rather ad hoc rules for defining whether an expression is renderable. This will need to updated in various ways to support more potential graph plots (e.g. for complex numbers and equations defined on the complex plain or in complex space). One of those updates is with regard to a way of conceptualizing what is being rendered.
Currently, the app assumes a function of a single variable being plotted is being ontologically mapped to 2d cartesian space: the variable of the function is bound to the x-axis of the graph, serving as the domain of the expression; meanwhile, the output of the function is bound to the y-axis of the graph, serving as the range or co-domain of the expression.
However, this is implicitly defined: GraphCa is happy to plug an expression like x+1 into its rendering algorithm with an implicit binding of the resultant values to the y-axis. However, this does not correspond to the nominal behavior defined in many (most?) branches of math: typically, an explicit binding of the result of an expression to a name is established. For the current example, this would look something like: y = x+1.
GraphCa takes much of its conception of math notation from the world of programming languages, which, despite deep histories of being demonstrably applied math, take liberties with their conscription of mathematical constructs. The most obvious example would be the nominal idea of assignment in programming: one binds a value of an expression to a name. In GraphCa, this would be: y := x+1.
However, this isn't really what graph plotting is doing. Rather than setting a variable to a value, it is more accurate to say---for a continuous curve---that points along that curve belong to the expression being evaluated iff the equivalence relation between the y-coordinate and the expression being evaluated yield true. In GraphCa, this suggests something like y == x+1, a boolean valued function.
Indeed, this change in perspective has relevant merit: consider the typical graphs associated with inequalities, such as y < x. Such plots will typically depict whole regions of the graph being shaded to reflect large quantities of y for which the equivalence relation holds true for a given x. This suggest a multi-valued function, perhaps.
Programming has the conception of equivalence and inequalities; in GraphCa, these take the form of the inequality expression operators. Again, for reference, this would be something like: y < x. Notice this does not define a value for the variable y; rather, it asserts a relationship between y and x based around notions of truth. Valid y will be those values which comport with x that result in a true response.
Should GraphCa want to be able to render inequalities (and, perhaps, handle a better semantic definition of a plot for equality), it should be looking at plotted values as satisfying (possibly implicit) equivalence relations.
This introduces some curious behavior that needs to be standardized: given the following expression, which variable is bound to the x-axis and which bound to the y-axis?
r+5 > sin(t)
Obviously, for a 2d graph, an inequality of more than two variables would be unplottable; however, as in the previous example, the two variables describe a curve and the area on one side of it for which the expression is valid in 2d space. This expression is valid in GraphCa: there is no demonstrable reason why either side of an inequality couldn't have arbitrarily complex sub-expressions; yet, the variables in discussion need to be mapped to a 2d plain.
The simplest option would be occurrence order. In the above, r is mapped to the x-axis, t to the y-axis. This could potential lead to oddities, especially when multiple curves with different variables are plotted on the same graph. (As a separate issue, graphs currently do not label their axes, which is problematic.) Occurrence order would happily comport with the behavior of invoke.
However, consider the following expression: y < x^2; occurrence order would suggest that the variable y is bound to the x-axis, while the variable x is bound to the y-axis. Without special casing this particular arrangement of variables, this would suggest alphabetic order. That, or an assumption regarding sub-tree structure: an inequality with a direct left-hand variable child could reasonably assume that is intended to be the y-axis variable.
GraphCa has rather ad hoc rules for defining whether an expression is renderable. This will need to updated in various ways to support more potential graph plots (e.g. for complex numbers and equations defined on the complex plain or in complex space). One of those updates is with regard to a way of conceptualizing what is being rendered.
Currently, the app assumes a function of a single variable being plotted is being ontologically mapped to 2d cartesian space: the variable of the function is bound to the x-axis of the graph, serving as the domain of the expression; meanwhile, the output of the function is bound to the y-axis of the graph, serving as the range or co-domain of the expression.
However, this is implicitly defined: GraphCa is happy to plug an expression like
x+1into its rendering algorithm with an implicit binding of the resultant values to the y-axis. However, this does not correspond to the nominal behavior defined in many (most?) branches of math: typically, an explicit binding of the result of an expression to a name is established. For the current example, this would look something like:y = x+1.GraphCa takes much of its conception of math notation from the world of programming languages, which, despite deep histories of being demonstrably applied math, take liberties with their conscription of mathematical constructs. The most obvious example would be the nominal idea of assignment in programming: one binds a value of an expression to a name. In GraphCa, this would be:
y := x+1.However, this isn't really what graph plotting is doing. Rather than setting a variable to a value, it is more accurate to say---for a continuous curve---that points along that curve belong to the expression being evaluated iff the equivalence relation between the y-coordinate and the expression being evaluated yield true. In GraphCa, this suggests something like
y == x+1, a boolean valued function.Indeed, this change in perspective has relevant merit: consider the typical graphs associated with inequalities, such as
y < x. Such plots will typically depict whole regions of the graph being shaded to reflect large quantities ofyfor which the equivalence relation holds true for a givenx. This suggest a multi-valued function, perhaps.Programming has the conception of equivalence and inequalities; in GraphCa, these take the form of the inequality expression operators. Again, for reference, this would be something like:
y < x. Notice this does not define a value for the variabley; rather, it asserts a relationship betweenyandxbased around notions of truth. Validywill be those values which comport withxthat result in atrueresponse.Should GraphCa want to be able to render inequalities (and, perhaps, handle a better semantic definition of a plot for equality), it should be looking at plotted values as satisfying (possibly implicit) equivalence relations.
This introduces some curious behavior that needs to be standardized: given the following expression, which variable is bound to the x-axis and which bound to the y-axis?
Obviously, for a 2d graph, an inequality of more than two variables would be unplottable; however, as in the previous example, the two variables describe a curve and the area on one side of it for which the expression is valid in 2d space. This expression is valid in GraphCa: there is no demonstrable reason why either side of an inequality couldn't have arbitrarily complex sub-expressions; yet, the variables in discussion need to be mapped to a 2d plain.
The simplest option would be occurrence order. In the above,
ris mapped to the x-axis,tto the y-axis. This could potential lead to oddities, especially when multiple curves with different variables are plotted on the same graph. (As a separate issue, graphs currently do not label their axes, which is problematic.) Occurrence order would happily comport with the behavior ofinvoke.However, consider the following expression:
y < x^2; occurrence order would suggest that the variableyis bound to the x-axis, while the variablexis bound to the y-axis. Without special casing this particular arrangement of variables, this would suggest alphabetic order. That, or an assumption regarding sub-tree structure: an inequality with a direct left-hand variable child could reasonably assume that is intended to be the y-axis variable.