plot(0:0.1:2pi,[sin(x)^1+cos(x)^1 for x=0:0.1:2pi])
gives you
But
julia> plot(0:0.1:2pi,[sin(x)^2+cos(x)^2 for x=0:0.1:2pi])
┌ Warning: No strict ticks found
└ @ PlotUtils ~/.julia/packages/PlotUtils/bZEEj/src/ticks.jl:191
┌ Warning: No strict ticks found
└ @ PlotUtils ~/.julia/packages/PlotUtils/bZEEj/src/ticks.jl:191
gives
Looks almost OK for me. It is almost constant, and you can observe the effect of finite precision of Float64 computations. The question is how to define a general default Y scale in this case.
Nevertheless, the number of significant digits for the Y ticks label could be automatically adapted in
order to produce distinguishable strings…
FWIW different default behavior is chosen by Makie:
using CairoMakie
lines(0:0.1:2pi,[sin(x)^2+cos(x)^2 for x=0:0.1:2pi])
produces
I am refering to the warning messages
┌ Warning: No strict ticks found
└ @ PlotUtils ~/.julia/packages/PlotUtils/bZEEj/src/ticks.jl:191
┌ Warning: No strict ticks found
└ @ PlotUtils ~/.julia/packages/PlotUtils/bZEEj/src/ticks.jl:191
Those messages should not be there because the plot command is perfectly legitimate.
The command is legitimate, but the y-range is too small,
julia> yr = extrema([sin(x)^2+cos(x)^2 for x=0:0.1:2pi])
(0.9999999999999999, 1.0000000000000002)
julia> yr[2] == nextfloat(1.0)
true
i.e., there is no space to put any ticks in between.
If you supply a suitable range on your own, the warning disappears:
plot(0:0.1:2pi,[sin(x)^2+cos(x)^2 for x=0:0.1:2pi]; ylims = (0.9, 1.1))
perfect then.
I agree with Steven, the way Plots reports the issue is not becoming of production software. The warning (“No strict ticks found”) seems like some internal debugging output meant for developers of Plots. It’s not at all suitable for non-interactive use of Plots (how is one meant to programmatically address a printed warning?), and, on the other hand, it’s not user-friendly enough for interactive use.
On the other hand, I’m not sure that the Plots package is still being actively developed; I’ve never used either Plots or Makie much, but it was my understanding that Makie is meant to replace Plots. Meaning that interface design suggestions would be misplaced with Plots, if it’s not being developed any more, and it would be better to just move to Makie?
I agree. I do not use Plots.jl and always prefer Makie anyway.
Nevertheless, the problem is not specifically related to trigonometry and the fact that the warning mentioning a problem with the ticks is not user-friendly enough should not, IMHO, be flagged as a bug or as a failure of the Plots.jl package.
Finally, although it seems that I did not properly understood the initial question/gripe, I think that it is obvious that I did take some time to answer it in a sunny Sunday morning. Having a bold answer when you are just trying to help is not very enjoyable.
The latest version, 1.39.0, was released on August 30th, so about 5 weeks ago. In the last 6 months, Plots had 70+ commits from 12 different people. In addition the backends are being developed as well of course, the latest release of the default GR backend was 2 weeks ago.
It’s also ironic that Plots is being dinged in a thread about sub-Float64 accuracy tick issues, given that Makie converts data to Float32 for plotting so it’s normally Makie where people complain about plots going wrong because of issues with floating point accuracy.
OK, thank you for the clarification.
Hehe I didn’t want to say it 