RFC: Domain symbolics

[Roger-luo]

A short recap of slack discussion: currently, we have Expression <: Number, however, if a generic function is defined on Real, this won't "just work".

The simplest fix as proposed by @ChrisRackauckas is to move Expression <: Real. However, this will fail if there are symbolic complex numbers (which is also crucial in Yao's case). In fact, I believe we will need some kind of domain inference/ types to represent domains instead of letting the IR expression to handle it.

My proposal is to separate the IR with domain types, which mean Expression will not be subtype of Real nor Number, we will have a wrap type to help the dispatch, which can just be

struct SymReal <: Real
    data
end

where data can be Expression or Variable or other things that is defined as real number or inferred as real number and same for complex number and other kind of numbers or even matrices, linear maps etc. I'm trying out this idea in my toy symbolic engine, I'll make that public soon.

This is actually a similar idea with Tracker, the implementation of TrackedReal looks like following:

struct TrackedReal{T} <: Real
   tape::Tracked
   data::T
end

Update: I implemented some of my ideas here Sym.jl

[GiggleLiu]

Like mathematica, we have x \in R. But it is used in simplification only. I am wondering how practical that would be to mix julia Real type with real types in expression. If x Is real, it Is still hard to answer whether log(x) is real? or sqrt(x) is Real? Here we need to assume x>0 too, then it is beyond julia type system. As the expression becomes longer, the deduction becomes more complex.

In Yao, the reason why it error is also because we put Float64(input_number) in the constructor, the real types would help but can't just work. We can just lose the restriction of using Real only in Yao but sometimes throw a warning like losing unitary if the expression Is not real (not the type). Treating an expression as a Real type can make more expressions like Float64(x) and isapprox(..., tol=x) error at a wrong place, becaude it is beyond our knowledge of Real.

An overall comment: I believe errors and warnings on input stage are good. it is better than just works, the program has less probability of running into unwanted bugs.

[Roger-luo]

I am wondering how practical that would be to mix julia Real type with real types in expression.

The inference happens at each operator, e.g sin(::Real) => Real this is just type inference. The symbolic engine itself do not need to contain any information about the domain, it is like an AST and a typed AST. some simplification can just happen on AST without type, but some can happen on the type, which will tell you the domain.

We can just lose the restriction of using Real only in Yao but sometimes throw a warning like losing unitary if the expression Is not real (not the type).

Loose the type upper bound means it will be legal to define mathematically wrong staff, which is also not elegant (even we try our best to prevent this by warnings and constructor restrictions).

And one more thing, if we decide to loose the constrain it also means from now on, we need to keep in mind try not to define anything that would break the symbolic computation on new things, which make it less extensible and fragile.

Treating an expression as a Real type can make more expressions like Float64(x) and isapprox(..., tol=x) error at a wrong place, becaude it is beyond our knowledge of Real.

Again, I believe it is similar to type inference, they happen at different level, about your example, it is wrong, Float64(x) will give you the same error when you try to convert something not convertable, which is a pretty clear InexactError. The error line number is correct, error message is correct, I don't see what's wrong.

I believe errors and warnings on input stage are good. it is better than just works

It is only good if it is an desired error. It doesn't make any sense and very frustrating if a mathematically real number cannot used as Real number (even talking about Julia ecosystem itself).

[ChrisRackauckas]

What's a case where this actually shows up? Using Number gets the symbolics through the generic codes I've tried, such as linear algebra. For special functions, we have those in the computation graph anyways, so that's fine. I haven't found a concrete case where it errors on Number but not on Real.

[Roger-luo]

as long as there is something stricter (asking for Integer or Real), so either we redefine all the instructions and block definitions or we need a symbol that is Real e.g

https://github.com/QuantumBFS/YaoArrayRegister.jl/blob/master/src/instruct.jl#L216

https://github.com/QuantumBFS/YaoArrayRegister.jl/blob/master/src/instruct.jl#L239

and more... we can't just say yeah one can use complex number or something not real for phases in the definition.

PS. I just played it a bit, it seems my idea works pretty well currently, one can feed it into Yao without doing anything else.

[ChrisRackauckas]

FWIW this is the kind of style I used in the PDE formulation here: SciML/DifferentialEquations.jl#469 .

[ChrisRackauckas]

This is now all about the Symbolics.jl metadata system, so I'll close it here.