[comp.lang.c] bug in mp?

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