search

JuliaApproximation / DomainSets.jl

A Julia package for describing domains as continuous sets of elements
MIT License
72 stars 12 forks source link

Depend on EltypeExtensions.jl? #159

Open putianyi889 opened 4 months ago

putianyi889 commented 4 months ago

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?

daanhb commented 3 months ago

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).

putianyi889 commented 3 months ago

Is EltypeExtensions being used elsewhere?

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

daanhb commented 3 months ago

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.

putianyi889 commented 3 months ago

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.

daanhb commented 3 months ago

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 :-) )

putianyi889 commented 3 months ago

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.