Menu
▾
▴
#368 primep(1) => true
My understanding is that 1 is no longer considered
prime. But
(C1) primep(1);
(D1) TRUE
(C2) describe("primep");
0: PRIMEP :(maxima.info)Definitions for Number Theory.
Info from file C:/maxima/Maxima/info/maxima.info:
- Function: PRIMEP (n)
returns TRUE if n is a prime, FALSE if not.
(D2) FALSE
(C3)
Additionally
(C3) primep(-4);
(D3) FALSE
(C4) primep(-3);
(D4) TRUE
are suspect. And wouldn't it be better for primep(a)
to return itself instead of signaling an error?
(C5) primep(a);
Argument to PRIMEP must be an integer: a
-- an error. Quitting. To debug this try
Barton
Logged In: YES
user_id=588346
primep(0) also incorrectly gives true.
I am not sure whether -3 should give true or false. If
someday there is a gprimep (Gaussian integers), should only
top-right quadrant numbers be primes, or should any
unit*prime product be OK?
It doesn't seem useful to return a noun form for primep. To
be consistent with evenp and oddp, we should give FALSE if
the argument is not a literal integer.
It might be nice to have simplifying (rather than evaluating)
predicates of various kinds, but Maxima doesn't do that in
other areas, so perhaps we should first get simplifications like
(x^2>0) => (x#0) before worrying about simplifying primep....
Logged In: YES
user_id=1179910
cvs maxima returns false primep(0) and primep(1).
Andrej
Logged In: YES
user_id=501686
New implementation of $PRIMEP in src/ifactor.lisp returns
false for primep(0) and primep(1).
Whether primep(x) should return a noun form is a separate
issue, and I'm going to let it go for now because Maxima is
generally inconsistent in the use of noun forms, so I don't
see the point of filing a new report for primep alone.
Closing this report as fixed.