Please upload the document, so that we could examine it. Use the green up-arrow in the Mapleprimes editor.

@tomleslie I interpreted Christopher's comment as being general, and so was my answer. As such, both are accurate.

You'd already made your points about the fitting periodic data/functions in your answer. It might not be the case here, but in general your claim is wrong that local vs global solutions don't come into it. A nonlinear fitting problem could have both a globally optimal fit (according to some metric) as well as a one or more inferior locally optimal fit (by same metric), both of which could be accompanied by their respective equivalently good fits at periodic intervals.

@Christopher2222 The issue is that the Statistics:-Fit command utilizes local optimization solvers, and for a nonlinear problem the local minima may exist which are not (even very close to) the global mimimum. What is so wonderful about the DirectSearch package is that not only does it contain global optimization solvers but it also contains curve-fitting/regression front-ends which utilize those solvers. And those curve-fitting commands also have a healthy choice of metric (ie. defn of residuals by several formula, allowing for various concepts of "best fit").

@itsme 

I notice that site has already been updated (both comments and functionality chart) since you first posted this, and following the discusions above. (I too wonder why comments were deleted.)

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.