ecef_to_geocentric returns error when called with a Vector{Taylor1{Float64}}

[PerezHz]

Hi!

When trying to run

using SatelliteToolboxTransformations, TaylorSeries
v = Taylor1.(rand(3), 2)
ecef_to_geocentric(v)

the following error is returned:

ERROR: MethodError: no method matching AbstractFloat(::Taylor1{Float64})

Closest candidates are:
  (::Type{T})(::T) where T<:Number
   @ Core boot.jl:792
  AbstractFloat(::Int128)
   @ Base float.jl:269
  AbstractFloat(::Int16)
   @ Base float.jl:266
  ...

Stacktrace:
 [1] float(x::Taylor1{Float64})
   @ Base ./float.jl:294
 [2] float(::Type{Taylor1{Float64}})
   @ Base ./float.jl:311
 [3] ecef_to_geocentric(r_e::Vector{Taylor1{Float64}})
   @ SatelliteToolboxTransformations ~/.julia/packages/SatelliteToolboxTransformations/Gho81/src/reference_frames/geodetic_geocentric.jl:45
 [4] top-level scope
   @ REPL[6]:1

i.e., the error is coming from

SatelliteToolboxTransformations.jl/src/reference_frames/geodetic_geocentric.jl

Line 45 in b779038

T = float(eltype(r_e))

where the error occurs since Taylor1{Float64} cannot be converted to a float... maybe a possible fix can be to use promote_type somehow?

[PerezHz]

Btw, our current workaround is to overload this method for Vector{Taylor1{Float64}}, but then we incur in a slight type-piracy 🏴‍☠️, which we would like to avoid 😅. Re: PerezHz/NEOs.jl#62, and in particular this log line

[PerezHz]

That said, beyond the possible type piracy, we would like to be able to use this function without having to re-write it (it's essentially the same code, but without the conversion to float), so we thought it'd be best to ask for help here 😅

[ronisbr]

Hi @PerezHz !

I really need that conversion to float to make the output type consistent (we use these algorithms with Float32 often to mimic what we have in the onboard computer). Hence, we have:

promote_type(Int32, Int64, Float32) |> float
Float32

Otherwise, the algorithm will be promoted to Float64 due to Int64.

I am still not sure what is the best approach. However, since Taylor1 seems to behave like a floating-point number for most of operations, what is the problem to define AbstractFloat(S::Taylor1{T}) where T<:Number = S? It should fix all problems as well.

julia> v = Taylor1.(rand(Float32, 3), 2)
3-element Vector{Taylor1{Float32}}:
  0.22708648 + 𝒪(t³)
   0.6600746 + 𝒪(t³)
   0.6802838 + 𝒪(t³)

julia> Core.AbstractFloat(S::Taylor1{T}) where T<:Number = S

julia> ecef_to_geocentric(v)
( 0.7725128686145345 + 𝒪(t³),  1.2394485 + 𝒪(t³),  0.9747065024345271 + 𝒪(t³))

[PerezHz]

Many thanks for the swift reply @ronisbr! Indeed, this seems in principle like a plausible solution on TaylorSeries side; I'd like to keep this issue open just in case things don't work out as expected if that's okay 😄

[PerezHz]

Fixed by JuliaDiff/TaylorSeries.jl#353, thanks @ronisbr!