No.  By that reasoning

assume(x>0);
about(x);
Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),infinity)

type(x>0, property);
                                          false

The phrase `x > 0' is not the property.  The property is being greater than 0; x is assumed to have that property.

No.  By that reasoning

assume(x>0);
about(x);
Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),infinity)

type(x>0, property);
                                          false

The phrase `x > 0' is not the property.  The property is being greater than 0; x is assumed to have that property.

I reported it as a bug. I hope you meant "scooping up" and not "souping up".

Certainly it is an annoyance, if not worse.  I can understand how this might have slipped through the cracks; attributes are under-utilized, and where used are frequently names or strings.  So this aspect was presumably not tested. 

I'm guessing you're using this parity attribute to return the factor of a symmetric/antisymmetric permutation (seems like a nice way to handle this). To work around this issue you might, instead, just use the value itself, rather than an equation, as the attribute.

Looks like a gui bug.  Presumably the presence of an equation attribute (other types also cause the display problem) in a list type prevents the list from displaying.  This works as expected in cmaple. A simpler demo is

setattribute([],1=1)

Hmm. The title say January but the text says February.  Do I get two prizes 8-). Considering that I didn't post all of January, that would be something.

Clever.  I didn't notice that the solution matched the condition for continuity at x=c.  That does make it more interesting than otherwise.  Of course, the general solution, with f intersecting g, remains unsolved.  Maybe it, too, leads to the same result, which would be nice, indeed.

Clever.  I didn't notice that the solution matched the condition for continuity at x=c.  That does make it more interesting than otherwise.  Of course, the general solution, with f intersecting g, remains unsolved.  Maybe it, too, leads to the same result, which would be nice, indeed.

This doesn't help.  Is the integral from a to c?  Are signed areas allowed?  If signed areas are not allowed, that is, all area is positive, then the best solution is the trivial solution, c = a, which yields an integral of 0.  You cannot do better than that if the area is always positive.

If signed areas are allowed, that is, the problem is actually to minimize the integral

A := int(f(x)-g(x), x=a..c);

then the solution is as I previously mentioned.  That is, it is either c=a, c=b, or

solve(diff(A,c)=0, c);

                                RootOf(f(_Z) - g(_Z))

that is, a solution of f(c)=g(c), such that c is in the interval [a,b].
 

This doesn't help.  Is the integral from a to c?  Are signed areas allowed?  If signed areas are not allowed, that is, all area is positive, then the best solution is the trivial solution, c = a, which yields an integral of 0.  You cannot do better than that if the area is always positive.

If signed areas are allowed, that is, the problem is actually to minimize the integral

A := int(f(x)-g(x), x=a..c);

then the solution is as I previously mentioned.  That is, it is either c=a, c=b, or

solve(diff(A,c)=0, c);

                                RootOf(f(_Z) - g(_Z))

that is, a solution of f(c)=g(c), such that c is in the interval [a,b].
 

What you are observing is one branch of a bifurcation.  Try the following,

f := proc(x,n) local y,z; z := 1./x; y := z; to n do y := z^y end do end proc:
plt1 := plot(rcurry(f,100),10..16):
plt2 := plot(rcurry(f,101),10..16):
plots[display](plt1,plt2);

I understand your desire for symmetric code---particularly in code that computes symmetries---however, there is a price to be paid.  The purely structured type '[anything,anything,anything]' is about 10x faster than the type that calls satisfies.  A close reading of www.mapleprimes.com/blog/joeriel/recursivetypes indicates that that is to be expected.

Rather than special types for sets and lists with a specified number of elements, I'd rather see a slightly more general approach that could work with other structures, maybe a type `numbops' (a better name is welcome), so that

type([a,b,c], 'And(list(posint), numbops(3))')

does what you want.  Naturally this would have to be a built-in type to gain the speed advantage; we can easily construct one without the speed advantage

TypeTools:-AddType(numbops, proc(x,n) evalb(nops(x)=n) end proc):

For a list you can do

type(expr, ['anything'$3])

For a set you could use satisfies,

type(expr, And(set, satisfies(s -> nops(s)=3)))

The question is poorly stated, but it is possible that is still well-formed, if we allow signed-area so that the goal is to minimize int(f(x)-g(x),x=a..c), in which case the answer is either a root of f(c) - g(c) or the boundaries (a,b).

The question is poorly stated, but it is possible that is still well-formed, if we allow signed-area so that the goal is to minimize int(f(x)-g(x),x=a..c), in which case the answer is either a root of f(c) - g(c) or the boundaries (a,b).