SF[2477795] "assume":problems with fractions or multiples of %pi and %e

I have reported that I had a look to this bug report. These were my
first results I had already presented:

(%i1) assume(x<2*%pi);
(%o1) [2*%pi > x]

(%i2) is(x<2*%pi);
(%o2) true

(%i3) is(x<3*%pi);
(%o3) unknown

(%i4) is(x<10.0);
(%o4) unknown

We always have a problem with assume when the constant is involved in an
expression. The following expression is stored in the database for the
example above:

((MLIST) ((MGREATERP) ((MTIMES SIMP) 2 $%PI) $X))

The algorithm of the database do not convert the expression ((mtimes simp) 2 $%pi) in
something which can be compared with a number like in example (%i4) or
can be compared with other expressions involving %pi.

The code stops searching a correct result in the routines DCOMPARE and
DCOMP. Because ((mtimes) 3 $%pi) or a simple number like 10.0 does not
match the fact ((mtimes) 2 $%pi) in the database, the routines return
$PNZ which gives the result UNKOWN. 

Perhaps at this point the code can be extended to look again in the
database to find expression which might match when numerically
evaluated.

One problem for me is, that it seems to be necessary to write code with
low level database functions. I have tried several times to understand
the code of the database, but I have no idea how it really works.

The proposed workaround to store a numerically value in the database
works well:

(%i6) assume(x<2*%pi),numer;
(%o6) [x < 6.283185307179586]

(%i7) is(x<2*%pi);
(%o7) true

(%i8) is(x<3*%pi);
(%o8) true

(%i9) is(x<10.0);
(%o9) true

This is the expression which is stored in the database:

((MGREATERP) 6.283185307179586 $X))

Furthermore I tested to implemented the numerically evaluation directly
in the routine assume. That works for the given examples and even for
the testsuite (for one example the code stops and ask a sign), but might
generate other problems. E.g. x*%e^a is stored as x*2,71...^a. Thus
is(x*%e^a>0) will fail -- again it might be possible to force the
numerically evaluation now for the test expression. 

Unfortunately, the following example does not work anyway:

(%o1) [a > 0,a < 1.570796326794897]
(%i2) is(sin(a)>0);
(%o2) unknown 

Here we have the problem that functions are not well supported.

I think all these problems are not really bugs but a weakness of the
database and the implemented algorithm which do not support the needed
functionality.

Because I have problems to understand the code of the database, I have
no idea how to start to improve the database.

Dieter Kaiser