off-topic - would you like help create a package for symbolic representation of sets?

[fkiraly]

Given your profile and obvious interest for the intersection of math, python, and symbolic computation: would you be interested in creating a package for symbolic representation of sets?

I've been looking for sth like this for:

• domain and domain validation of parameters in scikit-learn-like packages
• for symbolic representation of the domains of probability distributions, in skpro: https://github.com/sktime/skpro

[VascoSch92]

Hey 👋

it seems really interesting.

Do you have already some code on what you would like, or do you have a road-map/project plan on how the package should look like and what are the feature/IPA you are expecting?

PS (Off-topic): thanks for your other contributions (the PR and the suggestions). I will look deeply into them as soon as possible :-)

[fkiraly]

Do you have already some code on what you would like, or do you have a road-map/project plan on how the package should look like and what are the feature/IPA you are expecting?

Not in too much detail, but in essence I would like a symbolic representation language with eager computations for containedness, cardinality, and possibly other things like volumne/mass and expectation-like integrals.

I'd imagine the python counterpart of:

• set6, another package I've designed for this purpose in R: https://joss.theoj.org/papers/10.21105/joss.02598
• the Wolfram sets and symbolic logic module: https://www.wolframalpha.com/examples/mathematics/logic-and-set-theory
• sth I'm not sure about: the hypothesis package has a set language to define domains for tests, but it is not explicitly symbolic: https://hypothesis.readthedocs.io/en/latest/settings.html

Architecturally:

• sets would be parametric objects, inheriting from scikit-base BaseObject,
• skpro distributions get an attribute "domain", which is then sets-valued
• optionally, skpro distributions get a "mass" method which takes sets and outputs the mass w.r.t. the distr

From a roadmap perspective, therefore, it would be crucial to cover first:

• the reals, integers, and natural numbers
• finite part of Borel algebra over reals
• finite sets of integers and arbitrary objects
• composition: Cartesian product sets, power sets

[fkiraly]

Another related location is sklearn.utils._param_validation, which has a primitive language to define sets for parameter constraints. This is probably closest to hypothesis.

[VascoSch92]

It seems really interesting.

But why a package and not just a module in skpro? From what I see the main purpose of this project will be to serve the skpro distributions right?

If then we are happy, we could make it a proper package.

[fkiraly]

But why a package and not just a module in skpro? From what I see the main purpose of this project will be to serve the skpro distributions right?

Agreed, that might be a sensible starting point, and then one could spin it out, if other people are using it.

[VascoSch92]

Ok

Can we create a branch and we start working on it? Once we are happy with that we can merge, ok?

Do you have in mind a name for the module/package?

[VascoSch92]

I was reading the documentation about how SymPy implements sets (here). The API seems very interesting. Did you have taken in consideration their implementation for skpro or it doesn't have the functionalities you want to have?

[fkiraly]

very interesting point - I have not thought about this carefully, but perhaps the sympy sets module is sufficient for the use cases I have in mind.

There is even a statistics module with lots of distributions and support for composites: https://docs.sympy.org/latest/modules/stats.html
but that is not sufficient for the use case of tabular distribution representation and eager methods.

Perhaps some kind of a hybrid approach would work?

On the other hand, sympy is quite heavy as a dependency, for a use case where we do not need symbolic reasoning, simplification, evaluation, etc, but only representation mainly.

I think it's worth writing up the scope more precisely before we decide either way. I'll open an issue in skpro to discuss - given that you affirmed that you are interested, we can continue to scope options there?

[fkiraly]

opened here: sktime/skpro#244

[VascoSch92]

Closing as the discussion is moved to skpro repository