Hi, On 05/29/2018 08:35 PM, Vitaly Magerya wrote:

Hi, folks. Currently lsolve(eqns, vars) takes two lists as arguments, but then only accesses them via op(), so essentially any other container should work equally well. Here's a small patch to make it support exprseq in addition to lst. The motivation is that std::vector<ex>, upon which exprseq is based, can be more convenient to work with than std::list<ex>.

I think taht the original intent of exprseq was to share code between the derived types, rather than to instantiate objects of that type. Having said that, I'm aware that get_free_indices() returns an expreseq. I've applied your patch.

Note that there's one additional places where lst is required, but exprseq would work too: ex::subs(). It would make sense to support exprseq there too.

Also note that testing for lst is done via two different patterns in the source code: sometimes it is 'info(info_flags::list)', other times it is 'is_a<lst>'. It's not clear to me why this difference exists, or what should be the preferred way.

For lst, it's the same. But note that is_a<T>(e) leverages the type system and hence returns true for subtypes of T, too: is_a<expreseq>(sin(2*x)) is not the same as sin(2*x).info(info_flags::exprseq). Tactical use may not always be consistent, though. Cheers -richy.