Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Depend on EltypeExtensions.jl? #159

Open
putianyi889 opened this issue Mar 16, 2024 · 6 comments
Open

Depend on EltypeExtensions.jl? #159

putianyi889 opened this issue Mar 16, 2024 · 6 comments

Comments

@putianyi889
Copy link

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
Copy link
Member

daanhb commented Apr 2, 2024

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
Copy link
Author

Is EltypeExtensions being used elsewhere?

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

@daanhb
Copy link
Member

daanhb commented Apr 2, 2024

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
Copy link
Author

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
Copy link
Member

daanhb commented Apr 2, 2024

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants