shallit@ascutney.dartmouth.edu (05/24/89)
I would like to hear from users of mp whether the following represents
a bug or just a misunderstanding as to how mp works.
When I try to compute (-10) - (-20), I get -10 instead of 10.
Here's the code:
------------------------------------------------------------------------------
#include <mp.h>
/* compile with cc test.c -lmp */
main()
{
MINT *a, *b, *c, *d, *e, *f;
a = itom(-10);
b = itom(-20);
c = itom(0);
msub(a,b,c);
d = itom(10);
e = itom(20);
f = itom(0);
msub(d,e,f);
printf("c = ");
mout (c);
printf("\n f = ");
mout (f);
}
-------------------------------------------------------------------------
Jeff Shallit
Dartmouth College
shallit@dartmouth.edu
ath@helios.prosys.se (Anders Thulin) (06/01/89)
In article <13612@dartvax.Dartmouth.EDU> shallit@ascutney.dartmouth.edu () writes: >I would like to hear from users of mp whether the following represents >a bug or just a misunderstanding as to how mp works. > >When I try to compute (-10) - (-20), I get -10 instead of 10. > [...example deleted...] Perhaps this is more a question for comp.unix.questions ... I recently ran into this, too. Some further testing and examination of the code in msub() with dbx has (more-or-less) convinced me that although msub() takes good care to do the right thing for positive numbers (subtracting the number with smaller magnitude from the larger) it does not do so for negative numbers. Some related questions: There are several entries in libpm.a that appear to be useful, but that are not documented (at least not on SunOS 3.5). Does anybody know why? Those I have found are: fmin fmout invert mcan mcmp mout move omin omout mcmp() seems to compare two MINT's, returning a number greater than, equal to or less than zero depending on the comparison. omout() appears do the same as mout(), except in octal. Are these really for external use? Does anybody know exactly what they do? Also, I suspect there are some problems in mpow() or possibly mult(). Calling mpow() (or mult()) a large number of times causes more and more heap space to be allocated until finally mp terminates with the message `mp: no free space'. A guess: some routine allocates space for internal use but forgets to free it. Has anyone else ran into this?-- Anders Thulin INET : ath@prosys.se Programsystem AB UUCP : ...!{uunet,mcvax}!sunic!prosys!ath Teknikringen 2A PHONE: +46 (0)13 21 40 40 S-583 30 Linkoping, Sweden FAX : +46 (0)13 21 36 35