I think that separation of description and examples is generically better, provided that crossed hyperlinks were added between paragraphs in the description section and corresponding examples in the examples section.

I think that separation of description and examples is generically better, provided that crossed hyperlinks were added between paragraphs in the description section and corresponding examples in the examples section.

May be that something like Axiom streams is intended:

[i for i in 1..]

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, . . .]
		Type: Stream PositiveInteger

May be that something like Axiom streams is intended:

[i for i in 1..]

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, . . .]
		Type: Stream PositiveInteger

Fine. And, is there a command to go "upwards" in the tree? I mean, as for properties where there are commands to go both up and down in the lattice:

`property/ParentClosure`(real);
                       {TopProp, complex, real}

`property/ChildClosure`(real);
  {0, 1, Pi, Catalan, integer, prime, real, BottomProp, composite, 
fraction, irrational, rational, RealRange(0, infinity), 
RealRange(1, infinity), RealRange(2, infinity),
RealRange(-infinity, Open(0)), RealRange(Open(0), infinity)}

My reaction at observing this example is quite the opposite.

First, I would never been able to keep in mind all the type tree for an expression as it is produced here by PrintTree. So, such a tool is very useful and I suggest strongly that this WhatType package, or similar, become available from the standard library.

Second, what is missing is a graphical representation of the Maple type tree (at least for the top level library sector), like the Axiom Category and Domain graph. With this PrintTree kind of output, producing such graph would be more or less straightforward.

Third, packages may introduce their own types. And there are many packages. I do not beleive that it would be so repetitive!

Fourth, in Maple types are recognized as properties, as in:

type(ratpoly,type);
                                 true

type(ratpoly,property);
                                 true

assume(x,polynom);
about(x);
Originally x, renamed x~:
  is assumed to be: polynom

is(x,ratpoly);
                                 true

And there is on the one hand the property lattice and on the other hand this type tree. And also, the documentation is not clear on this relationship. So, this representation of the type side would help a lot.

Force is a vector magnitude. What is fy?, sounds like a component of the force. And what graphical representation for this fy are you looking for? E.g. a polar plot?

Force is a vector magnitude. What is fy?, sounds like a component of the force. And what graphical representation for this fy are you looking for? E.g. a polar plot?

Such small list would be better only if the subtype information, i.e. the conection between those  supertypes and what whatype informs could be easily recovered. For instance, if complex(extended_numeric) in ?type,atomic were a link to a list of its subtypes. As it stands, the list is small but not very informative.

Anyways, all the types in whattype are about 40. So, all the subtypes of complex(extended_numeric) there would be only a few.

OK. However, I would find better that "standard types" be used in that list, and I think that what best approaches this concept is the output whattype, i.e. fraction for 3/4.

Do I remember wrong, or you were working in a kind of  representation of the graph of types and their subtypes? If so, any news?

I find that the actual fun is reading the documentation trying to explain this behavior. On the one hand, ?map states:

For expressions of type atomic, map(fcn, expr) is identical to fcn(expr).

And indeed:

type(3/4,atomic);
                                 true

While, on the other hand, ?type,atomic states:

An object is of type atomic if it cannot be mapped over, that is, map(f, x)=f(x).

By the way, type fraction is not included in the subsequent list:

Objects in Maple which have this property are of type name, complex(extended_numeric), indexed, string, procedure, or `module`.

At this stage, I think that it would be more useful for you get used first with what Maple considers operands. And you do it with op:

op(3*x/4);
                                3/4, x

The name P is not necessary to observe this problem:

restart:
assume(g > 0);
about(-g);
-g:
  nothing known about this object

It occurs because the effect of assume(g > 0) is making an entry in the table property/object:

`property/object`[g];
                     RealRange(Open(0), infinity)

And then about reads the entries from this table, but there is none for index -g:

`property/object`[-g];
                         property/object[-g]

Hence, the return that nothing is known.

On the other hand, getassumptions goes to the indets of -g, i.e. g, and finds that there is an entry in the table for g:

getassumptions(-g);     
              {g::RealRange(Open(0), infinity)}

With Maple 13, there is a (bad) difference:

abs(argument(exp(y*I))) <= Pi; # assuming (y::real);
is(%) assuming (y::real);
                       argument(exp(y I))
                   -------------------------- <= Pi
                   signum(argument(exp(y I)))


                                false

With Maple 13, there is a (bad) difference:

abs(argument(exp(y*I))) <= Pi; # assuming (y::real);
is(%) assuming (y::real);
                       argument(exp(y I))
                   -------------------------- <= Pi
                   signum(argument(exp(y I)))


                                false