Floating point assumptions

[ChrisRackauckas]

In order to have some number systems work with Plots, it needs to get rid of floating point assumptions. For example:

using RecipesBase, Unitful

@recipe function f(val1::AbstractVector{S}, val2::AbstractVector{T}, val3::AbstractMatrix{U}) where {S<:Quantity , T<:Number, U<:Number}
  xlabel --> quantity_to_plot_string(S)
  ustrip.(val1),val2,val3
end
@recipe function f(val1::AbstractVector{S}, val2::AbstractVector{T}, val3::AbstractMatrix{U}) where {S<:Number, T<:Quantity , U<:Number}
  ylabel --> quantity_to_plot_string(T)
  val1,ustrip.(val2),val3
end
@recipe function f(val1::AbstractVector{S}, val2::AbstractVector{T}, val3::AbstractMatrix{U}) where {S<:Number, T<:Quantity , U<:Number}
  zlabel --> quantity_to_plot_string(U)
  val1,val2,ustrip.(val3)
end
x,y,z = (2u"kg").*ones(10),(1u"s").*collect(1:10),(3u"N").*collect(1:10)

using Plots
plotly()
plot(x,y,xaxis =(0u"kg",1u"kg"),yaxis = (0u"s",10u"s"))

fails because

https://github.com/JuliaPlots/Plots.jl/blob/master/src/types.jl#L53-L57

assumes all input numbers can be converted to Float64. A type for the extrema, matching the series, should get passed to the creation here, and typemax + typemin should be the defaults instead.

[mkborregaard]

I think it's more complicated than that, as Plots relies on being able to apply type recipes to input until it can be automatically converted to AbstractVector{<:Float}.