It may be that no solution is found because there is no solution, or it may just be that Maple is unable to find a closed-form solution: non-polynomial systems will only have closed-form solutions in rather special cases.  You might be able to use fsolve to find solutions numerically if you give appropriate numerical values to some of the parameters: fsolve will want as many variables as equations.

It may be that no solution is found because there is no solution, or it may just be that Maple is unable to find a closed-form solution: non-polynomial systems will only have closed-form solutions in rather special cases.  You might be able to use fsolve to find solutions numerically if you give appropriate numerical values to some of the parameters: fsolve will want as many variables as equations.

Yes, it should work I think.

Yes, it should work I think.

The linalg package is quite old.  Its data structures, vectors and matrices, are based on tables.  The LinearAlgebra package appeared in Maple 6, I think, and VectorCalculus in Maple 8.  Together they provide all the functionality that linalg has and more, and in many respects are better: in particular, LinearAlgebra is much better at floating-point numerical computation.  I doubt that linalg will be dropped any time soon, because there's still a lot of old code out there that uses it, and as far as I know all its procedures still work, but if you're writing new code you might as well use LinearAlgebra. 

The linalg package is quite old.  Its data structures, vectors and matrices, are based on tables.  The LinearAlgebra package appeared in Maple 6, I think, and VectorCalculus in Maple 8.  Together they provide all the functionality that linalg has and more, and in many respects are better: in particular, LinearAlgebra is much better at floating-point numerical computation.  I doubt that linalg will be dropped any time soon, because there's still a lot of old code out there that uses it, and as far as I know all its procedures still work, but if you're writing new code you might as well use LinearAlgebra. 

But in this case (if LinearSolve is right, and I would be very surprised if it was wrong for a system with rational entries), the solution space is empty: the system is inconsistent.  The coefficient matrix A has rank 15, and the vector b (if the system is written as A.x = b) is not in its column space.

But in this case (if LinearSolve is right, and I would be very surprised if it was wrong for a system with rational entries), the solution space is empty: the system is inconsistent.  The coefficient matrix A has rank 15, and the vector b (if the system is written as A.x = b) is not in its column space.

I don't think I'd call it a bug.  With your a as a vector whose entries are all unassigned, convert(a, set) produces the empty set {}.  The help page for ?convert,set says

In this case there are no stored entries, so this behaviour is entirely consistent with that description.

On the other hand, convert(a, list) does what you want.  The help page ?convert,list says

The convert/list function accepts a table or one-dimensional array, Array, Vector, or set, and makes a list of the elements.

Note there's no mention of "stored", so in this case you do get the entries a[i] for i from 1 to np.

I don't think I'd call it a bug.  With your a as a vector whose entries are all unassigned, convert(a, set) produces the empty set {}.  The help page for ?convert,set says

In this case there are no stored entries, so this behaviour is entirely consistent with that description.

On the other hand, convert(a, list) does what you want.  The help page ?convert,list says

The convert/list function accepts a table or one-dimensional array, Array, Vector, or set, and makes a list of the elements.

Note there's no mention of "stored", so in this case you do get the entries a[i] for i from 1 to np.

It might help if we could see the actual problem.  You can upload a file using the green up-arrow button.

Try this workaround:

> subs(RGB=HSV, plt);

It's not in a package.  You may be using an older version of Maple.  I think FormalPowerSeries was introduced in Maple 11.

It's not in a package.  You may be using an older version of Maple.  I think FormalPowerSeries was introduced in Maple 11.

OK, this one seems to be true (at least as series: outside the circle of convergence, branch cuts may be chosen differently)..

> eq:=hypergeom([a,b],[c],z) 
         = (1-z)^(-a)*hypergeom([a,c-b],[c],z/(z-1));

> map(convert,eq,FormalPowerSeries,z);

Sum(pochhammer(b,k)*pochhammer(a,k)/pochhammer(c,k)/k!*z^k,k = 0 .. infinity) = Sum(pochhammer(b,k)*pochhammer(a,k)/pochhammer(c,k)/k!*z^k,k = 0 .. infinity)

To convert the right side into the left:

> convert(convert(rhs(eq),FormalPowerSeries,z),hypergeom);

hypergeom([a, b],[c],z)

The other way doesn't seem so easy. 

First, change variables: if u = z/(z-1), then z = u/(u-1).

> A:= eval(lhs(eq), z = u/(u-1));

A := hypergeom([a, b],[c],u/(u-1))

Multiply by (1-u)^(-a), then convert to Formal Power Series and then to hypergeom:

> A2:= A * (1-u)^(-a);

> convert(convert(A2, FormalPowerSeries,u), hypergeom);

hypergeom([a, c-b],[c],u)

Now divide by (1-u)^(-a) and change variables back to z.

> simplify(eval(%/(1-u)^(-a), u = z/(z-1)));

hypergeom([a, c-b],[c],z/(z-1))*(-1/(z-1))^(a)

And for the final bit of simplification:

> simplify(expand(%)) assuming z<1, a::posint;

(1-z)^(-a)*hypergeom([a, c-b],[c],z/(z-1))