Added the ability to pass known SymPy symbols to symbolics_to_sympy function

[owiecc]

SymPy has the ability to add constraints to variables:

sx = symbols("x", positive = True)

These variables however are different than those created by symbolics_to_sympy:

@variables x
symbolics_to_sympy(x) == sx # false 

I added the ability to pass a dictionary, a vector or a tuple of known SymPy symbols to symbolics_to_sympy function.

@variables x
symbolics_to_sympy(x, Dict("x"=>sx)) == sx # true
symbolics_to_sympy(x, [sx]) == sx # true
symbolics_to_sympy(x, (sx,)) == sx # true

This solves #347.

┆Issue is synchronized with this Trello card by Unito

[ChrisRackauckas]

I think it would be cleaner to just scan the metadata for some symbols and then copy them over? But that might start to set in stone the assumptions interface. @YingboMa @shashi what do you think?

[owiecc]

If you can add the metadata to @variables already then yes, it would be cleaner. This solution will work until you find a good interface for assumptions and will continue to work once that is implemented. I set the defaults to fall back on empty dictionary of symbols.

[ChrisRackauckas]

the metadata system already exists. @variables x [positive=true] exists. @shashi I think there isn't any documentation on how to register a new property though?

LoadError: Base.Meta.ParseError("unknown property type positive")
in expression starting at C:\Users\accou\OneDrive\Computer\Desktop\test.jl:2
option_to_metadata_type(#unused#::Val{:positive}) at variable.jl:173
setprops_expr(expr::Expr, props::Vector{Any}, macroname::Symbol, varname::Expr) at variable.jl:189
construct_var(macroname::Symbol, var_name::Expr, type::Type, call_args::Nothing, val::Nothing, prop::Vector{Any}) at variable.jl:231
construct_vars(macroname::Symbol, v::Symbol, type::Type, call_args::Nothing, val::Nothing, prop::Vector{Any}, transform::Function, isruntime::Bool) at variable.jl:165
_parse_vars(macroname::Symbol, type::Type, x::Tuple{Symbol, Expr}, transform::Function) at variable.jl:136
_parse_vars(macroname::Symbol, type::Type, x::Tuple{Symbol, Expr}) at variable.jl:81
var"@variables"(__source__::LineNumberNode, __module__::Module, xs::Vararg{Any}) at variable.jl:339
eval at boot.jl:373 [inlined]

[owiecc]

If you want to play nice with SymPy you'd need to register or map all possible SymPy assumptions. Can the properties be arbitrary or is it a fixed set?

[ChrisRackauckas]

It can be arbitrarily extended. Now, some of those stem from the type information, so @variables x::Complex for example is the way to do complex, or @variables x::Integer (and the default is just @variables x::Real). Commutative and such would be determined by the algebra on the type, not metadata. zero is a bit odd? We'd just use a literal. @variables x::Rational. Etc.

So I think the metadata ones would be:

• odd/even
• prime
• composite
• algebraic
• transcendental
• irrational (is this one just ::Real? Or do we need to explicitly have Real\Rational?)
• Do we need all of positive, nonpositive, negative, and nonnegative, or just positive and nonnegative?
• hermitian and antihermitian

Of course, we aren't doing all of the cryptography stuff yet, so I think the main ones are how to handle positive/nonpositive/..., whether irrational is needed, and whether hermitian is handled by the type (I assume for quantum?)

[shashi]

function Symbolics.option_to_metadata_type(::Val{:foo})
  FooType
end

@variables x [foo=1]

getmetadata(x, FooType) #=> 1

[0x0f0f0f]

It can be arbitrarily extended. Now, some of those stem from the type information, so @variables x::Complex for example is the way to do complex, or @variables x::Integer (and the default is just @variables x::Real). Commutative and such would be determined by the algebra on the type, not metadata. zero is a bit odd? We'd just use a literal. @variables x::Rational. Etc.

So I think the metadata ones would be:

* `odd`/`even`

* `prime`

* `composite`

* `algebraic`

* `transcendental`

* `irrational` (is this one just ::Real? Or do we need to explicitly have Real\Rational?)

* Do we need all of `positive`, `nonpositive`, `negative`, and `nonnegative`, or just `positive` and `nonnegative`?

* `hermitian` and `antihermitian`

Of course, we aren't doing all of the cryptography stuff yet, so I think the main ones are how to handle positive/nonpositive/..., whether irrational is needed, and whether hermitian is handled by the type (I assume for quantum?)

For metadata like odd/even see https://juliasymbolics.github.io/Metatheory.jl/dev/egraphs/#EGraph-Analyses

[0x0f0f0f]

* Do we need all of `positive`, `nonpositive`, `negative`, and `nonnegative`, or just `positive` and `nonnegative`?

The sign of expressions forms a semilattice. This also fits well for an e-graph analysis. Using e-graph analyses doesn't require e-graph rewriting tho.