{"id":20500594,"url":"https://github.com/juliaapproximation/domainsetscore.jl","last_synced_at":"2026-03-19T16:07:53.684Z","repository":{"id":186708133,"uuid":"675607431","full_name":"JuliaApproximation/DomainSetsCore.jl","owner":"JuliaApproximation","description":"An interface package for working with domains as continuous sets of elements","archived":false,"fork":false,"pushed_at":"2023-11-26T14:36:13.000Z","size":31,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":6,"default_branch":"main","last_synced_at":"2026-01-22T07:44:41.691Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Julia","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/JuliaApproximation.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-08-07T10:04:08.000Z","updated_at":"2023-08-07T10:05:30.000Z","dependencies_parsed_at":"2023-11-26T15:38:24.512Z","dependency_job_id":null,"html_url":"https://github.com/JuliaApproximation/DomainSetsCore.jl","commit_stats":null,"previous_names":["juliaapproximation/domainsetscore.jl"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/JuliaApproximation/DomainSetsCore.jl","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JuliaApproximation%2FDomainSetsCore.jl","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JuliaApproximation%2FDomainSetsCore.jl/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JuliaApproximation%2FDomainSetsCore.jl/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JuliaApproximation%2FDomainSetsCore.jl/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/JuliaApproximation","download_url":"https://codeload.github.com/JuliaApproximation/DomainSetsCore.jl/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JuliaApproximation%2FDomainSetsCore.jl/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30167962,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-06T07:56:45.623Z","status":"ssl_error","status_checked_at":"2026-03-06T07:55:55.621Z","response_time":250,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-15T18:21:50.743Z","updated_at":"2026-03-06T08:32:34.683Z","avatar_url":"https://github.com/JuliaApproximation.png","language":"Julia","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Build Status](https://github.com/JuliaApproximation/DomainSetsCore.jl/workflows/CI/badge.svg)](https://github.com/JuliaApproximation/DomainSetsCore.jl/actions)\n[![Coverage](https://codecov.io/gh/JuliaApproximation/DomainSetsCore.jl/branch/main/graph/badge.svg)](https://codecov.io/gh/JuliaApproximation/DomainSetsCore.jl)\n\n# DomainSetsCore.jl\nAn interface package for working with domains as continuous sets of elements.\n\nExamples of domains may be geometric sets such as intervals and triangles,\nor the complex plane without the negative real line. However, domains are not\nlimited to geometry. A domain could also be a collection of vectors or arrays,\nsuch as the set of all orthogonal `3x3` matrices.\n\nExisting types may add the interpretation of being a domain by implementing the\ndomain interface. They gain the ability to interact with other domains.\n\n## The domain interface\n\n### The `in` function\n\nA domain is a set of elements that is possibly continuous. Continuous sets are\ndefined mathematically, not by an exhaustive list of their elements. In practice membership of the set is defined by the implementation of `in`. The function\ncall `in(x, domain)` evaluates to true if the domain contains an element `y`\nsuch that `y == x`.\n\n#### Incompatible element types\n\nIn principle, the function `in(x, domain)` should not throw an exception even\nif the types seem mathematically nonsensical. In that case, the correct return\nvalue is `false`. This mimicks the behaviour of `in` for finite sets in Julia:\n```julia\njulia\u003e in(rand(3,3), 1:3)\nfalse\n```\nIndeed, a `3x3` matrix is not equal to any of the numbers `1`, `2` or `3`.\n\n\n### The `domaineltype` function\n\nThe defining mathematical condition of a continuous set might be satisfied by\nvariables of different types. Still, the interface defines the `domaineltype`\nof a domain. It is a valid type for elements of the set.\n\nFunctions that generate elements of the domain should generate elements\nof that type. As a consequence, for finite sets such as an `AbstractArray` or `AbstractSet`, the `domaineltype` agrees with the `eltype` of that set. For\nintervals on the real line, the `domaineltype` might be `Float64`. When there is\nno clear candidate the `domaineltype` might simply be `Any`.\n\n\n### Minimal formal interface\n\nThe domain interface is formally summarised in the following table:\n\n| Required methods | Brief description |\n| ---------------- | ----------------- |\n| `in(x, d)` | Returns `true` when `x` is an element of the domain, `false` otherwise |\n| `DomainStyle(d)` | Returns `IsDomain()` if `d` implements this interface |\n\nOptional methods include:\n\n| Important optional methods | Default definition | Brief description\n| --- | --- | --- |\n| `domaineltype(d)` | `eltype(d)` | Returns a valid type for elements of the domain |\n\nSeveral extensions of this minimal interface are defined in the [DomainSets.jl](https://github.com/JuliaApproximation/DomainSets.jl) package.\n\n\n## Domains as mathematical sets\n\nA domain behaves as much as possible like the mathematical set it represents, irrespective of its type. Thus, for example, two domains should be considered\nequal if their membership functions agree.\n\nIt is not always possible to realize this intended behaviour in practice. Indeed\nit may be difficult to discover automatically whether two domains are equal,\nespecially when their types are different. Still, the principle serves as a\ndesign goal.\n\n\n## The Domain supertype and DomainStyle trait\n\nThis package defines the abstract type `Domain{T}` of continuous sets with\n`domaineltype` equal to `T`. No concrete domain types are defined in this\npackage.\n\nThe package also defines the trait `DomainStyle`. Any type can declare to\nimplement the domain interface by defining\n```julia\nDomainSetsCore.DomainStyle(d::MyDomain) = IsDomain()\n```\nObjects of type `Number`, `AbstractArray` and `AbstractSet` are declared to be\ndomains in this package.\n\n## Using the domain interface in practice with `DomainRef`\n\nWith the exception of subtypes of `Domain`, the set of types implementing the\ndomain interface is not based on a common abstract supertype. Functions that are\nintended to manipulate domains may simply omit the type of the domain in the\nfunction signature. However, functions defined in other packages can not be\nextended to work for domains, as there is no common type to dispatch on.\nFor that reason this package defines the `DomainRef` reference.\n\nIn the absence of function ownership, the practice of domain references requires\nactive intent both by users and by developers. For a user, passing `DomainRef(d)`\nto a function indicates that `d` is to be treated as a domain. For a developer,\nthe implementation `foo(d::DomainRef)` may be used to extend the functionality\nof `foo` to domains.\n\nThe reference `DomainRef(d)` is not in itself a domain, it is merely a reference.\nThe developer of `foo(d::DomainRef)` may use `domain(d)` to access the domain\nobject. More generally, one can implement `foo(d::AnyDomain)` and use\n`domain(d)` in the function definition. In that case the user may invoke `foo`\nboth indirectly with a domain reference and directly with a concrete subtype of\n`Domain`.\n\n\n### Example usage\n\nAn example of this practice is the functionality of `union` in the\n[DomainSets.jl](https://github.com/JuliaApproximation/DomainSets.jl) package.\nFirst, the package defines a generic function `uniondomain(d1,d2)` with no\nrestrictions on the types of `d1` and `d2`. The function returns an object that\nbehaves as the mathematical union of the two arguments. It always interprets the arguments as domains, regardless of their types.\n\nA user wanting to use the standard `∪` syntax for this purpose has to make this intention explicit by writing `DomainRef(d1) ∪ DomainRef(d2)`. The outcome is\nequivalent to `uniondomain(d1, d2)`, and could be different from what `d1 ∪ d2`\nmeans in other contexts for the combination of types of `d1` and `d2`. That\noriginal behaviour of `∪`, quite possibly an error in fact, is not changed.\n\nA developer may make the `∪` syntax more accessible to users as follows. As soon\nas one of `d1` or `d2` is a `Domain`, or a reference to a domain, the call to\n`union` can safely be interpreted as the union of domains. Thus, a developer may\nwrite:\n```julia\nunion(d1::Anydomain, d2) = uniondomain(domain(d1), d2)\nunion(d1, d2::AnyDomain) = uniondomain(d1, domain(d2))\nunion(d1::AnyDomain, d2::AnyDomain) = uniondomain(domain(d1),domain(d2))\n```\nThese definitions are safe in the sense that there is no ambiguity and no\npossible clash with any existing definition of `union(d1,d2)` in other packages.\n\n\n## Package interoperability\n\nThe goal of the domain interface is to make objects from different packages\ninteroperable with minimal interaction between packages and, thus, maximal\nindependence in their development.\n\nSay package A and package B both define a type that can be interpreted as a\ndomain, respectively `objectA` and `objectB`. Package C may define the domain\ninterface for `objectA` using the `DomainStyle` trait. Package D may similarly\ndefine the domain interface for `objectB`. Package E could load `DomainSets` and packages C and D. A user of package E can type `uniondomain(objectA,objectB)`.\n\nThis construction requires no active collaboration between the developers of\npackages A, B, C, D and E. They can all be developed independently. Package C\nrelies on package A and on `DomainSetsCore`. Package D relies on package B and\non `DomainSetsCore`. Package E relies on packages C, D and `DomainSets`.\nPackages C, D and E could be developed as package extensions.\n\n\n\n## More functionality with domains\n\nUnions and intersections of domains, as well as many other set operations, are implemented generically in the\n[DomainSets.jl](https://github.com/JuliaApproximation/DomainSets.jl) package.\n\nIntervals inheriting from the `Domain` supertype are implemented in\n[IntervalSets.jl](https://github.com/JuliaMath/IntervalSets.jl).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuliaapproximation%2Fdomainsetscore.jl","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjuliaapproximation%2Fdomainsetscore.jl","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuliaapproximation%2Fdomainsetscore.jl/lists"}