Weakness of extracting free variables with CAS

[AndreG-P]

Neither Maple nor Mathematica are really capable of extracting free variables from an expression. Once there is a slightly more complex expression involved, especially with sums, they return non-sense. Even worse, in the case of integrals, both CAS can stop suddenly and die from trying to extract the variables.

I think it might be time to come up with our own implementation since it is no longer a real problem with LaCASt. Since LaCASt can handle sums, limits, integrals, etc., we would be able to extract variables easily.

[HowardCohl]

@AndreG-P This doesn't sound like that hard of a problem. I'm curious to hear your opinion on the level of difficulty of this task.

[AndreG-P]

@HowardCohl I don't think it's so hard. I trusted the power of Maple / Mathematica and never thought about it. But I simply have enough now. The CAS crashed so often or extracted wrong variables or non at all...

I will try to fix this already this night, so I can run the experiments again over the weekend.

[AndreG-P]

OK I implemented with 5304f98fa12cd4c9afc9348652dc7f4ed1e9b339

However, we face the good old question about indices. When I have an expression like a_n what are the tree variables here? In the context of our evaluator it make sense to interpret it as one free variable. But maybe with n as another free variable. So that's what I implemented now. It would extract a_n and n as free variables.

That's maybe not the right way but it seems to be a good solution for our evaluator and is already much better (and faster) than any cas implementation.

[HowardCohl]

OK I implemented with 5304f98

However, we face the good old question about indices. When I have an expression like a_n what are the tree variables here? In the context of our evaluator it make sense to interpret it as one free variable. But maybe with n as another free variable. So that's what I implemented now. It would extract a_n and n as free variables.

That's maybe not the right way but it seems to be a good solution for our evaluator and is already much better (and faster) than any cas implementation.

I would think that this would depend on whether there is some action on the variable n such as a sum or a product. Otherwise, in general a_n could potentially be a single variable.

[HowardCohl]

For instance there are cases such as

• F_s(x) is the Fermi-Dirac integral
• h_\xi http://dlmf.nist.gov/30.13.E3 should either be considered a single variable or a parameterization of a single variable...

But then again there are cases such as http://dlmf.nist.gov/30.3.E5 where there is no sum, integral or product. However this is a continued fraction and a ... situation, so not a lot you can do there maybe. Look at http://dlmf.nist.gov/30.3.E8 though where there is a _{2k}. Do you handle situations such as this?

[AndreG-P]

I think the semantic information is not sufficient for LaCASt to extract the right variables. In the cases you mentioned, there are almost always definitions somewhere else in the DLMF.

For example:

But then again there are cases such as http://dlmf.nist.gov/30.3.E5 where there is no sum, integral or product.

Here, LaCASt must take care of definitions of \alpha_k, \beta_k, and \gamma_k in order to extract the right variables.

Same in:

Look at http://dlmf.nist.gov/30.3.E8 though where there is a _{2k}. Do you handle situations such as this?

l_{2k} should be treated similarly as a function substitution.

So basically, LaCASt does a better job than CAS, but it still fails with this subscript cases, where the a_n are elements of a sequence.