It’s not apparent how this helps for an expression that isn’t equal to an exact number

julia> foo
acos(0) + π*2var"##225"
julia> Symbolics.symbolic_to_float(foo)
ERROR: UndefVarError: `_x` not defined

Not that there is a maximum for a linear function. The more pressing issue is that the solution seems wrong, unless I’ve sorely misunderstood what symbolics_solve is solving:

I think the answer given is correct, however, just in a very awkward form. I have no idea how you would use it, say to give an explicit solution to the problem, or as I intended, to find the maximum value of a third derivative of a function.

The zeroes of cosine are π apart, the output’s elements are 2π apart, which I evaluated earlier to check. Maybe the author @Yassin_ElBedwihy can help explain, I’m not an experienced user of Symbolics and can’t find an explanation in the documentation.

If you were trying to find a maximum value of a function by checking where its derivative is zero, there isn’t always one unique place for its maximum. Sine peaks at 1 periodically, and it coincides with only “half” its derivative cosine’s zeroes.

To me, the first ones seem obviously better for showing the periodicity cos(x)=0 (wolframalpha.com). Turns out Wolfram Alpha could do something like the second shifted ones for more complex equations, I tried the example in the symbolic_solve announcement sin(x^2 +1)^2 + sin(x^2 + 1) + 3=0 (wolframalpha.com) and clicking “more roots” and “exact forms” gives 8 roots but half of them are shifted (incidentally they also simplify away the leading 1//2 and 4 coefficients by multiplying). I’m not positive but it looks like those could also be collapsed into 4, which would also deviate from the symbolic_solve output.

I think that was just an easier shorthand for the generated var"##__", there’s no good way to generate simpler symbols that could easily collide with the user’s current or likely upcoming symbols.

There’s no “first” results for a periodic function, so we have to specify the inputs ourselves. I haven’t figured out how to reference a generated variable for substitute, but that can evaluate expressions with user-defined variables to a numerical Num, which I showed earlier. Symbolics.value(::Num) unwraps to the underlying Number subtype, could be Int, Float64, Rational{Int},etc.

That’s an idea, but we can’t possibly do it in advance when we don’t know how many generated variables would be needed. Maybe a way to do it afterward, like counting the number of generated variables and a method to replace them with a vector of enough of our own variables. Maybe there’s already a way to do that for any variables now already, I just never learned.

Afterwards, you can use Symbolics.get_variables in order to get the only variable in some printed out root and subtitute it for whatever value you want, here is 0 for example:

I’m really not qualified to correct any math, I’m just an occasional user (so those tips are very appreciated). I can at least note that the asin terms all have a coefficient of -1, which would simplify to +1 if we cancel out the 1/2 and -4 terms. However, Wolfram Alpha’s asin terms’ coefficients vary between +1 and -1, adding the extra π when it’s -1. I don’t know if there’s an asin identity that reconciles that and collapses the 8 roots into 4 closer spaced roots, so my earlier guess seems unfounded from my perspective, just happened to superficially resemble a simpler case we could verify.

Rather than manually tweaking expressions to compare to Wolfram Alpha results, which aren’t verified to be right either, could periodic or otherwise infinite sequence of roots be verified numerically, even within a finite range? Is there a CAS principle where solving simpler problems correctly (y^2+y+3=0, y=sin(z), z=x^2+1 would be simpler parts) would solve more complex problems correctly?