[GiNaC-list] [patch] Allow exprseq in the arguments to lsolve()

[Richard B. Kreckel]

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.