DomainSets.jl icon indicating copy to clipboard operation
DomainSets.jl copied to clipboard

Depend on EltypeExtensions.jl?

Open putianyi889 opened this issue 11 months ago • 6 comments

I notice that a large part of FunctionMaps/src/util/common.jl coincides with EltypeExtensions.jl I made recently. Would it be a good idea to add that as a dependency?

putianyi889 avatar Mar 16 '24 11:03 putianyi889

Hi, indeed there is quite some overlap. Is EltypeExtensions being used elsewhere?

That code in common.jl goes back a long way. Since DomainSets is used by ApproxFun and by BasisFunctions, I had originally in mind moving this functionality to a package that could be used by both (say JuliaApproximationCore.jl).

daanhb avatar Apr 02 '24 12:04 daanhb

Is EltypeExtensions being used elsewhere?

It's very new, so no. But I'm trying to get it used by LazyArrays, etc.

putianyi889 avatar Apr 02 '24 12:04 putianyi889

Names aside, is there a difference in functionality? The logic in common.jl is that an object has an eltype, a numtype and a prectype. Here, eltype is the standard element type, numtype is the type of number being used (typically Float64 or ComplexF64, i.e. the "field" if you will, a scalar even when working with vectors), and prectype is the floating point type associated with it (Float64).

There are routines to convert them, called convert_eltype, convert_numtype and convert_prectype.

daanhb avatar Apr 02 '24 12:04 daanhb

EltypeExtensions.elconvert -> convert_eltype EltypeExtensions.baseconvert -> convert_numtype EltypeExtensions.precisionconvert -> convert_prectype

There could be slight difference in edge cases, but the ideas are the same.

putianyi889 avatar Apr 02 '24 12:04 putianyi889

Are you familiar with ApproxFun and what's being used there for this functionality? I'd consider moving if it results in more sharing within JuliaApproximation. (Not a fan of the naming for now but that's a separate concern :-) )

daanhb avatar Apr 02 '24 12:04 daanhb

Not a fan of the naming

The naming scheme comes from FillArrays.jl. I think both schemes are clear enough. Since the package doesn't have many downstreams it's easy to make breaking changes.

Are you familiar with ApproxFun

not quite. I've switched to ClassicalOrthogonalPolynomials for some years. A brief code search shows there isn't anything like it.

putianyi889 avatar Apr 02 '24 13:04 putianyi889