Scott, even though not necessary, thanks for putting in that acknowledgment. Brian, maybe my blog post The art of linking could be of interest to you.

Scott, even though not necessary, thanks for putting in that acknowledgment. Brian, maybe my blog post The art of linking could be of interest to you.

... as always providing delightfully compact code.

... as always providing delightfully compact code.

Is the following of any help?

with(SolveTools:-Inequality):
for s1 in {-1,1} do
for s2 in {-1,1} do
for s3 in {-1,1} do
for s4 in {-1,1} do
for s5 in {-1,1} do
for s6 in {-1,1} do
for s7 in {-1,1} do
for s8 in {-1,1} do
	sol := LinearUnivariateSystem({seq(s||i*eqs[i] > 0,i = 1..8)},x);
	if sol <> {} then print (s1,s2,s3,s4,s5,s6,s7,s8,sol) end if
end do:
end do:
end do:
end do:
end do:
end do:
end do:
end do:

Is the following of any help?

with(SolveTools:-Inequality):
for s1 in {-1,1} do
for s2 in {-1,1} do
for s3 in {-1,1} do
for s4 in {-1,1} do
for s5 in {-1,1} do
for s6 in {-1,1} do
for s7 in {-1,1} do
for s8 in {-1,1} do
	sol := LinearUnivariateSystem({seq(s||i*eqs[i] > 0,i = 1..8)},x);
	if sol <> {} then print (s1,s2,s3,s4,s5,s6,s7,s8,sol) end if
end do:
end do:
end do:
end do:
end do:
end do:
end do:
end do:

Ah, now I see your strategy: there are 2^8 = 256 combinations of being on one or the other sides of the eight lines. Clever! The task at hand now, is then to make Maple do the hard work, that is, programming it efficiently.

Ah, now I see your strategy: there are 2^8 = 256 combinations of being on one or the other sides of the eight lines. Clever! The task at hand now, is then to make Maple do the hard work, that is, programming it efficiently.

I would also much appreciate such an explanation because, using your expr2, something like

> eval(1 + x + 3*y,1 = a);
                          2            
                         a  + x a + 3 y

even though consistent with the dismantle-form 1*1 + 1*x + 3*y, as given by you, seems quite counter-intuitive, especially because

> ToInert(1 + x + 3*y);
       _Inert_SUM(_Inert_INTPOS(1), _Inert_NAME("x"),
       _Inert_PROD(_Inert_NAME("y"), _Inert_INTPOS(3)))

correctly contains only a single _Inert_INTPOS(1).

I am certainly not an expect on these matters, but I think that I would prefer to use the second expressions (the first ones being yours) in the following code:

expr  := 1 + a^2:
expr2 := 1 + x + 3*y:
eval(expr,2 = -1),eval(expr,a^2 = 1/a);
eval(expr2,1 = 2),subsop(1 = 2,expr2);

By the way, very nice pictures.

I also got that error, and looking at the code initially I thought it was a typo, as the syntactically correct version is style=patchnogrid. But it is quite deliberate, see Alec's comment after the first picture of his post. However, I can find no reason why style does not work inside the pre-tags, that is, it works fine whenever I use it.

What I was asking for was something like:

getArgs := (inert,argType) -> map(
	x -> `if`(op(0,x) = _Inert_||argType,x,NULL),[op(inert)]
):

which has the ability to filter out the appropiate type of arguments at the upper level only. An example:

inert := ToInert(Matrix(3,3,(i,j) -> i..j)):
getArgs(inert,RANGE);
getArgs(inert,SET);

This example shows that my function getArgs, in contrast to select, can distinguish between the dimensional ranges of the matrix, and the (deeperly nested) ranges of the entries of the matrix. Can getArgs be improved upon?

No, I think of pulling out arguments at the current level of nesting, compare the following two expressions (subInert1 being related to your suggestion, and subInert2 being related to my original suggestion):

inert := ToInert(Matrix(2,2,(i,j) -> f({i,j}))):
subInert1 := indets(inert, specfunc(anything,_Inert_SET)):
subInert2 := {op(select(has,inert,_Inert_SET))}:
nops(subInert1),nops(subInert2);

I guess that my intention with this thread was just to hear how the different Maple masters handle these issues. My uneasiness with these issues of ToInert stems from the fact that there seems to be no readily available source documenting the exact arguments and their orderings.

You can combine your conditions into one solve statement as follows:

s  := k[1,1]*x[1]+k[2,2]*x[1];
s1 := k[1,1]*x[1]+k[1,2]*x[2];
l := solve({
	coeff(s,x[1])=coeff(s1,x[1]),		# Your former l
	coeff(s,x[2])=coeff(s1,x[2]),k[1,2]=0	# Your former p
	},{k[1,1],k[2,2],k[1,2],k[2,1]}
);
assign(l);