sign((-1)^number): Inconsistent handling of numbers

An oberservation concerning the $sign function of Maxima:

We call with an imaginary argument and get an expected error message:

(%i3) sign((-1)^(1/2));
`sign' called on an imaginary argument:
%i
 -- an error.  To debug this try debugmode(true);

Now we do the same with a float representation. We get a result:

(%i5) sign((-1)^(0.5));
(%o5) neg

When we use a bigfloat we get again the error:

(%i7) sign((-1)^(0.5b0));
`sign' called on an imaginary argument:
%i
 -- an error.  To debug this try debugmode(true);

We get the same results when we use any other half integral rational number.


Now we test rational numbers with an odd denominator. The following two results
are exptected:

(%i11) sign((-1)^(1/3));      /* simplifies to -1 */
(%o11) neg
(%i12) sign((-1)^(2/3));      /* simplifies to +1 */
(%o12) pos

When we do the same with float values we always get NEG as an answer:

(%i13) sign((-1)^float(1/3));
(%o13) neg                     /* OK */
(%i14) sign((-1)^float(2/3)); 
(%o14) neg                     /* Should be pos */

If we use bigfloat numbers we get errors.

(%i15) sign((-1)^bfloat(1/3));
`sign' called on an imaginary argument:
%i
 -- an error.  To debug this try debugmode(true);

(%i16) sign((-1)^bfloat(2/3));
`sign' called on an imaginary argument:
%i
 -- an error.  To debug this try debugmode(true);

The reason is that for bigfloat numbers the expression is evaluated to a complex
root (see SF[619927]).

(%i17) (-1)^bfloat(1/3);
(%o17) 8.660254037844386b-1*%i+5.0b-1

We get different results for rational, float and bigfloat numbers.

I think one problem is that the routine sign-mexpt in compar.lisp does not
handle the case of a negative base completely. For all cases not known by the
algorithm the default return value is the sign of the base and that is in the
cases above a negative sign.

Do you think the inconsistent handling of numbers is a bug?

Dieter Kaiser