These seem to work, as of Maple 2017.0 ,

is(`Or`(k::posint, k::negint, k = 0)) assuming k::integer;

                              true

is(`Or`(k::negint, k::nonnegint)) assuming k::integer;

                              true

is(`Or`(k::posint, k::nonposint)) assuming k::integer;

                              true

@Carl Love Quite a bit of the time seems to be spent in convert(...,listlist) and in the Matrix constructor.

Does this produce the same result, just with listlist until the the subtraction?

It gets me about a factor of six better timing.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
Ones:= Matrix((n$2), 1):
MA:= {seq(Ones - rtable(M,subtype=Matrix), M= MA)}:
time() - st;

Assuming that I haven't inadvertantly broken it, on my machine this seems to indicate that about half the time here is spent in producing Matrices from the listlists.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
MA:= eval(MA,[1=0,0=1]):
time() - st;
MA:= {seq(rtable(1..n,1..n,M,subtype=Matrix), M= MA)}:
time() - st;

@Carl Love At a brief glance (because the OP hasn't yet supplied actual re-usable code) I wonder whether there might be a problem in the float-range, eg. double-precision under evalhf during computation, or perhaps even single-precision during rendering. If the former is the case then it might be that UseHardwareFloats:=false of raising Digits>16 (to prevent evalhf) might help. It looks like increased working precision might be useful for the example just on numerical grounds. But that's just a wild guess based on eye-balling it briefly.

@_Maxim_ Yes, all valid types are properties.

I agree about the documentation of properties. (btw, who would know to use AndProp versus And or `and`, just by reading the help pages?!)

This problematic behavior of `and` -- the unwanted evalb of `=` and `<>` -- is a kernel thing. Perhaps it's fixable. I know it can catch out even expert users. I'll submit another bug report on it.

For use with `is` or `assuming` , you could try using `And` instead.

@John Fredsted I would say that using the `<>` angle-bracket constructor and/or Matrix/Vector indexing is shorter and (as a unified approach) more easy to use overall than some bunch of commands like Augment, Stack, AddRow, DeleteRow, AddColumn, DeleteColumn, etc. But I'd also say that clear, simple examples of the related functionality are not found in help pages that are well referenced.

What I'd like to see are more representative examples on the help page to which Kitonum referred.

Also, it's always been the case the there are not enough cross-references (and help aliases) for the rtable_indexing help page. Perhaps that page is over-complicated. Perhaps that Matrix and Vector Construction Shortcuts page should also include simple example of indexing, so that removal of certain rows and columns is shown next to to examples of adding them. After all, Matrix indexing provides a short cut for DeleteRow and DeleteColumn.

It's unfortunate that the two pages mentioned above don't have cross-references to each other.

While I'm griping, I find it not useful that the See Also references from help pages are ordered alphabetically rather than by relevance/importance.

@vv I've formed a habit. I haven't thought of a case whether it matters for the parameter name (as opposed to the rhs of a keyword option, say).

If your final goal is just to be able to evaluate the symbolic inverse equations (for Vector x) at arbitrary numeric values of parameter kappa then I suggest that your approach is likely misguided.

For considerations of performance speed as well as numeric stability I would consider instead creating a procedure/function which took float values for kappa as argument and returned the purely float results for x from purely floating-point linear solving.

If your final goal is just to obtain float x (for arbitrary float kappa) then what is the system in which you want to do that? Is it Maple, or some language like C/python/etc? Is there no good float linear solver in your final program?

@David1 

If I substitute the values of special into eq4 then I get this:

eq4;

                r11 r12 + r21 r22 + r31 r32 = 0

special;

    [r13 = 0, r23 = 0, r31 = 0, r32 = 0, r33 = 1, s1 = 0,
     s2 = 0, s3 = 0, t1 = 0, t2 = 0, t3 = 0]

eval(eq4, special);

                     r11 r12 + r21 r22 = 0

I don't see how you could possibly obtain 2*r22*sqrt(1-r22^2)=0 from that substitution (as you now claim to obtain), since there is no sqrt in the original eq4. Your original question had eq4 as, literally:

eq4:=r11*r12+r21*r22+r31*r32 = 0;

Here is an attachment with some random values of r22 in -1..1, where the substitutions from utilizing each of manysols then leads to various roots. polysys2a.mw

You don't need to edit the equations in your original Question. Just add a Reply (comment) to the original Question. You don't need to include all the equations as text. Simply put them in a Maple worksheet and attach it to your Reply using the big green arrow in the Mapleprimes editor.

@Carl Love The RootFinding:-Isolate command seemed to indicate that the polymomial system had infinitely many solutions. But I suspect that confidence in that is undermined by the possibility of numerical inaccuracy in the supplied float coefficients.

@David1 If there are infinitely many solutions with particular fixed values set for only some strict subset of the variables (ie. a partially restricted problem) then there are infinitely many solutions for the system. So, yes, the system of equations you supplied has infinitely many solutions, it seems.

For the actual question you asked it doesn't matter whether some strict subset of the variables have fixed values -- what matters is whether any of the remaining variables can take on infinitely many values. I showed a restricted problem in which r22 can take any value between -1 and 1.

The last line of zeros in my attachment are the residuals when the solutions I showed are substituted into the equations.

If you have some additional constraints on the variables (eg. fobidding the partially restricted equations I formed) then you really should show them.

If by "next line" you mean entering multi-line statements in 2D Input by using Shift-Enter to drop to the line below then I don't think that there's a way to avoid getting the extra, inserted space.

@claus christensen Sorry, I don't really understand how your last comment relates to my suggestion because I don't have any idea how your intended application is going to function.

There is an undocumented Hide export of the Layout subpackage, which you can use to clobber off the display of Execution Group Boundaries. Note that it will affect all Execution Groups in your sheet. Also, since its not a package export it has to be called with its full command name. And as far as I know there's no programmatic way to turn it back on in the same sheet. I don't really recommend this and, again, I'm not sure how it solves your "problem" properly because I don't understand the problem.   display-problems_Hide.mw

Another way to insert content without a border is to use a Table (whose borders you can suppress from display). I prefer this to the above. display-problems_Table.mw

This might be an appropriate time to mention that in general I've found that it often works out better for interactive applications to use elements from the Components subpackage, rather than only Layout elements. For one thing, that allows you to insert say a PlotComponent just once and then have some Button/Textarea/MathContainer/etc be used to update it with a new plot as the math example is switched/changed in-place. display-problems_PlotComponent.mw

You don't have to build your application with these programmatic commands (and I apologize if you know this already). You can use the palette and menubar to insert embedded-components and GUI Tables, and adjust the code that runs below them using the mouse. This is often convenient to prototype interactive applications, and indeed many people only do this. I personally find that even when I prototype in this way I often still want to write fully programmatic code that generates the same whole application -- because I prefer to have my applications as plaintext source code against which I can do version control.

[edit] The Input/Output Layout elements (within Group/Document elements) can be useful for constructing purely expository material, while the Component elements provide an interactive facility. It may be that you want to reconstruct such expository material when the particular math example is changed, and then re-insert the whole application in-place within the same Task Region. That's a bit advanced, but could be quite slick. A way to do that would be to write re-usable procedures for full reconstruction, based on the new example as argument. A master procedure which utilizes the reusable content functionality of the InsertContent command (its replaceid option) could then re-insert the wholly new example including new expository material as well as the same Button/etc that triggers the rewrite.

@wndrslope This thread is 8 years old, and the issues/causes in that Maple release may be different from those of your problem.

So post your example as a distinct new Question.

And upload your document, using the big green arrow. Don't try and mimic your 2D Input as pasted plaintext or an Image.

@tomleslie This behavior is new to Maple 2017, I believe. (Bug reports submitted.)

Download 2017_roundoff_2D.mw

If you wish to test a name like _Z1 for assumptions (or otherwise manipulate or utilize same in some computation) then you can use the command getassumptions. For Carl's example,

getassumptions(_Z1);

               {_Z1~::integer}