baharev / safe-eliminations

Identifying numerically safe eliminations automatically
BSD 3-Clause "New" or "Revised" License
5 stars 2 forks source link

Trying to understand the use cases #1

Closed baharev closed 6 years ago

baharev commented 7 years ago

@EDWhyte There is an important piece that the original sympy_tree.py in sdopt-tearing does but solvable.py doesn't: In sympy_tree.py all the possible safe eliminations are stored in a dictionary (unfortunately as string). I am almost sure that you will need the eliminations too.

Please clarify your use case, and suggest a solution. The simplest is to do it as in sympy_tree.py but store the SymPy expression trees for all possible eliminations that were flagged as safe.

EDWhyte commented 7 years ago

@baharev

My plan is to list the indices of the unsafe eliminations using solvable.py based on the incidence matrix that was constructed.

I have code that constructs the incidence matrix and the plan is to use the stored unsafe eliminations and turn the indexed value negative in order for bordered.py to create the forbidden variable.

baharev commented 7 years ago

@EDWhyte I am afraid there is still some serious misunderstanding.

Let us assume that you have decided to eliminate y from the equation below:

x - log(y) + 3 = 0

How will you actually do it in your code? In other words, how will you form the Python code, corresponding to this elimination?

y = e^(x+3)

My point is that the Python code for this elimination is readily available in solvable.py:

https://github.com/baharev/safe-eliminations/blob/d89c41959bc35401c928de5ac0d74ed0b3d02e06/solvable.py#L91

Note that these symbolic manipulations with SymPy are painfully slow for large systems, so I would try very hard not to recompute them unnecessarily.

EDWhyte commented 7 years ago

@baharev

I now understand your concern and I agree

symbolic manipulations with SymPy are painfully slow for large systems, so I would try very hard not to recompute them unnecessarily

I think an approach like in sympy_tree.py is probably best.

My code works with the incidence matrix so if the original (unordered) row number can be associated with the sympy variable in a dictionary could work eg for the test case in the code:

{0: {x: 2 - y - z, y: 2 - x - z, z: 2 - x - y}, 1: {z: -y**2 + 3}, 2: {x: 2.718exp(-z), z: -log(x) + 1}}

baharev commented 7 years ago

OK. The outermost datastructure can be a list (faster):

[{x: 2 - y - z, y: 2 - x - z, z: 2 - x - y}, {z: -y**2 + 3}, {x: 2.718exp(-z), z: -log(x) + 1}]

How do you want to store the keys (variables) and values (eliminations) in the dictionaries?

I think the most flexible (most generic) would be the straightforward way: Storing the keys as SymPy sp.Symbols and the values as SymPy expression trees.

baharev commented 7 years ago

Hmmm. I am still sitting on the fence with the keys in the dictionaries. I would expect the variables to be stored as strings (as their names), or by index. Having Sympy Symbols as keys is not very useful then, as you do not have an easy way to look things up in the dictionaries.

One solution would be to add a keyword argument. It would take a function that takes the Sympy Symbols as argument and returns the keys for the dictionaries. By default, it would turn the variables into strings, and if that default is not OK with the user, then the user can pass in some other function.

In any case, it requires some thinking.

EDWhyte commented 7 years ago

The sympy keys can also be set to original column index?

baharev commented 7 years ago

Yes, if we take a function as keyword argument, then it is the caller's responsibility to map the names to the column index. He or she can pass in this function.

All in all, I think the keyword argument would be the most appropriate, since we do not know what the users might want to do, or how they want to store their data.

baharev commented 7 years ago

OK, please put in a pull request with your final version of solvable.py.

I will merge it, clean it up a bit, and will also add this keyword argument thingy.

baharev commented 7 years ago

I moved the example into a separate module: solvable.py should be (will be one day) a module in a library. It also makes the code much more clearer and cleaner.

Please check and provide feedback.

However, let's not waste each others time with PEP 8, or turning comments into reST docstrings, or with the Zen of Python, or whether it is spelled optimization or optimisation etc.

But please fix wrong or very confusing sentences, tell me if you find the API very clumsy, or the example is unclear, etc.