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

Roadmap for future development of DomainSets #150

Open
daanhb opened this issue Feb 20, 2024 · 3 comments
Open

Roadmap for future development of DomainSets #150

daanhb opened this issue Feb 20, 2024 · 3 comments

Comments

@daanhb
Copy link
Member

daanhb commented Feb 20, 2024

Here are a few areas I'm thinking of to improve DomainSets. I'm linking to existing issues.

  1. Factor out the map code. It has no place in this package, and there is a lot of overlap with other packages. The main motivation originally for writing new code was to allow rectangular maps, which you need to map e.g. from 1D to 3D. At the time most existing packages assume that maps are invertible, square or both. (Factor out Map's #92, Don't export jacobian #87)
  2. Integrate better with existing packages that define domains, in orde to reuse them. A proof of concept using package extensions is in https://github.com/daanhb/DomainSetsExtensions.jl (package extensions and interoperability with different domain types #149)
  3. Write documentation. Even the basic syntax for primitives is not documented. The mechanism of associating domains with canonical domains is very versatile and potentially useful if it were known how to use it (Write documentation #101)
  4. Avoid type piracy. A lot has improved already, but there are some remnants of operators from Base and LinearAlgebra being overloaded simply because they look nice. This will likely take another breaking release, but it should be done. (arithmetic operations with broadcasting #148, Don't use ×? #67)
  5. Come up with a good implementation of approximate in (or approx_in), using atol and rtol arguments. It's important to get this right, since we've been so careful about distinguishing between open and closed domains as well. (use atol and rtol in approx_in #124)
  6. Implement fewer concrete domains. We've been using IntervalSets for intervals. I'm reluctant to expand the implementation of simplices and hyperfaces because other packages already do this, both better and with more focus. (Support hyperfaces #100, Should boundary(::Rectangle) use simpler types? #142)

I've been playing with a DomainSetsCore package, but I don't think it is essential to move forward so it's not on the list.

Ideally, these improvements make DomainSets smaller and yet more functional.

@daanhb
Copy link
Member Author

daanhb commented Feb 20, 2024

Pinging a few people, consider this for-your-information: @dlfivefifty @oschulz @aplavin @hyrodium @zsunberg @cscherrer

@daanhb
Copy link
Member Author

daanhb commented Apr 2, 2024

Update: the first item (factoring out maps) is largely done. All map code now lives in a submodule FunctionMaps.jl, which has its own test suite and could turn into a separate package. For now, everything is backwards compatible (or so it should be) and the internal change happened in v0.7.10.

@oschulz
Copy link

oschulz commented Apr 3, 2024

Thanks for keeping us up to date, @daanhb !

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