You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In dev/plotEqn-test.R, I've tried to supply my own labels for lines, b/c I want to use x and y for the variables and simplify the equations to the form y = a + b * x. I have a test version in dev/plotEqn.R, where I'd like to also add options to control the solution points, allowing the argument solution = list(pch =, cex=, col=)
(This is for an example where I'd like to show the duality of points and lines in data / beta space.)
A <- matrix(c( 1, 2, 0,
-1, 2, 1), 3, 2) |> print()
b <- c(2, 1, 1)
# works OK
plotEqn(A, b, vars = c("x", "y"))
# try to change the labels: doesn't work
plotEqn(A, b, vars = c("x", "y"),
labels = c("y = x - 2",
"y = 1/2 - x",
"y = 1"))
The lines appear, but not the labels
I can't see what is wrong with the relevant code in the function (around line 132)
I took a look at this a couple of days ago and have thought about it a bit since. I think that the simplify option could use a complete rewrite, perhaps separating the signs, coefficients, and variables. I don't know when I'd have a chance to attempt that.
Just to be clear: the figure I'm trying to create is the left panel of that below, illustrating the duality between lines in data space
and points in $\beta$ space.
I did this from scratch, starting from
# Equations as intercepts & slopes in data space
x <- c(-2, .5, 1)
y <- c( 1, -1, 0)
# plot lines in data space
plot(0,0, type ="n",
xlab = "x",
ylab = "y",
xlim = c(-1, 4), ylim = c(-3, 2),
cex.lab = 2, asp = 1,
main = "Data space")
abline(h = 0, v = 0, col = "gray")
for (i in seq_along(x)) {
abline(x[i], y[i], col = col[i], lwd = 2)
}
...
then adding annotations of the simplified y = ... form of the equations, calculating the intersections of lines, etc., all because I couldn't do this with plotEqn().
Not a big hurry to fix the simplify problem, now that I've done this graph, but it would be nice to fix at least the bug with labels.
Yes, the two problems were clear to me: (1) You can't get user-supplied labels with plotEqn(); (2) the automatic labels are poorly simplified. I was addressing (2), which I think I could improve (but don't know when). I didn't see the source of (1).
I don't see how you can make something like this work with expression(), which can't simply take a character string as an argument (and produce a proper graphed equation) and must follow proper R syntax (which, I suspect, is why the current version doesn't work right).
This assumes that the variables have been mapped from x1 to expressions, x[1], which is desirable in the case that
(a) no vars= has been given, so the variables become expressions, if (missing(vars)) vars <- c(expression(x[1]), expression(x[2]))
(b) no labels= has been given, so the equation labels become the result of showEqn(A, b, vars, simplify=TRUE)
Unless @philchalmers objects, I suggest to add your simplifyEqn(), then consider how to fix plotEqn() in the case that triggered this issue, namely when equation labels are specified.
In this case, the function could just treat them as given; it would be up to the user to decide whether to use expressions in them.
I don't have an objection to improving the simply logic as I agree there's room for improvement, though I'm wondering about changing the output focus of showEqn() now that TeX rendering is available and has become a major focus. For instance, a more natural rendering approach at this point is to use
A <- matrix(c( 1, 2, 0,
-1, 2, 1), 3, 2)
b <- c(2, 1, 1)
showEqn(A,b,latex=TRUE) |> Eqn()
which looks fine (though I'd prefer if Eqn() were called within showEqn() when latex=TRUE to avoid the pipe), but then the simplify argument makes the output awful.
showEqn(A,b,latex=TRUE,simplify=TRUE) |> Eqn()
Obviously this needs to be fixed too, though given the new focus on TeX instead of ASCII outputs should showEqn() be modified to be TeX driven instead? The ASCII and TeX approaches are not particularly complimentary.... just trying to get ahead of future issues.
Maybe I'm missing something, but isn't the fundamental problem that although character strings can occur within an expression, character strings aren't expressions? Try, e.g.,
Activity
john-d-fox commentedon Oct 23, 2024
I took a look at this a couple of days ago and have thought about it a bit since. I think that the
simplifyoption could use a complete rewrite, perhaps separating the signs, coefficients, and variables. I don't know when I'd have a chance to attempt that.friendly commentedon Oct 23, 2024
Just to be clear: the figure I'm trying to create is the left panel of that below, illustrating the duality between lines in data space$\beta$ space.
and points in
I did this from scratch, starting from
then adding annotations of the simplified
y = ...form of the equations, calculating the intersections of lines, etc., all because I couldn't do this withplotEqn().Not a big hurry to fix the
simplifyproblem, now that I've done this graph, but it would be nice to fix at least the bug withlabels.john-d-fox commentedon Oct 23, 2024
Yes, the two problems were clear to me: (1) You can't get user-supplied labels with
plotEqn(); (2) the automatic labels are poorly simplified. I was addressing (2), which I think I could improve (but don't know when). I didn't see the source of (1).john-d-fox commentedon Oct 23, 2024
Here's a first attempt at simplifying 2-variable equations, which could be used in
showEqn()andplotEqn():For example,
I don't see how you can make something like this work with
expression(), which can't simply take a character string as an argument (and produce a proper graphed equation) and must follow proper R syntax (which, I suspect, is why the current version doesn't work right).friendly commentedon Oct 23, 2024
This looks nice, and would help certainly in
showEqn().It would also help for my use case, but I think I see where the
expression()problem comes from:This assumes that the variables have been mapped from
x1to expressions,x[1], which is desirable in the case that(a) no
vars=has been given, so the variables become expressions,if (missing(vars)) vars <- c(expression(x[1]), expression(x[2]))(b) no
labels=has been given, so the equation labels become the result ofshowEqn(A, b, vars, simplify=TRUE)Unless @philchalmers objects, I suggest to add your
simplifyEqn(), then consider how to fixplotEqn()in the case that triggered this issue, namely when equationlabelsare specified.In this case, the function could just treat them as given; it would be up to the user to decide whether to use expressions in them.
Does that sound workable?
philchalmers commentedon Oct 23, 2024
I don't have an objection to improving the
simplylogic as I agree there's room for improvement, though I'm wondering about changing the output focus of showEqn() now that TeX rendering is available and has become a major focus. For instance, a more natural rendering approach at this point is to usewhich looks fine (though I'd prefer if Eqn() were called within showEqn() when latex=TRUE to avoid the pipe), but then the
simplifyargument makes the output awful.Obviously this needs to be fixed too, though given the new focus on TeX instead of ASCII outputs should showEqn() be modified to be TeX driven instead? The ASCII and TeX approaches are not particularly complimentary.... just trying to get ahead of future issues.
john-d-fox commentedon Oct 24, 2024
Maybe I'm missing something, but isn't the fundamental problem that although character strings can occur within an expression, character strings aren't expressions? Try, e.g.,
It is possible to render LaTeX in plots.
friendly commentedon Oct 24, 2024
I agree with @philchalmers that
Eqn()makes the rendering ofshowEqn()nicer, but that's not the point here.The issue is being able to use equations as line labels in
plotEqn(), particularly when they are supplied as input to thelabelsargjohn-d-fox commentedon Oct 24, 2024
To elaborate my previous examples slightly, compare