[GiNaC-devel] Please revert 29c464d3f387426bdb5ecf9c262fc2f9f2600a70

[Alexei Sheplyakov]

Hi,

On Wed, Nov 05, 2008 at 02:41:32PM +0100, Jens Vollinga wrote:

> > 	And the Makefile.in patch removes the release target in order to
> > generate proper .so with proper versioning.
> 
> I applied these both.

Please revert the second patch. First of all, there's nothing wrong with
current versioning scheme. Secondly, changing SONAME in that way breaks
every binary linked with libginac (i.e. binary linked with GiNaC 1.4.3
won't work any more after upgrade to 1.4.4). Since we maintain binary
compatibility in stable releases, changes like this are inacceptable (that
is, even if the patch in question were correct).

> I also don't know how to treat this one. Your patch applies to 
> "configure". But in the source "configure.ac" LIBS is not explicitly 
> extended by "-ldl", only DL_LIBS. So, this seems like we cannot repair 
> it. Maybe autoconf mixes it up?

The thing is: dlopen() is in libc on OpenBSD, so there's no need to link
with -ldl. I've changed  GINAC_EXCOMPILER m4 macro to check for dlopen()
in libdl and libc (see commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d
in my repository).

> > 	The chec_matrices.cpp patch is for a regression test that goes through
> > an infinite loop when attempting to do inverse_matrix() and the determinant
> > never becomes 0. So I had to comment that out until we can fix it. Maybe you
> > have a solution for this.
> 
> I don't know about this one. The check doesn't fail here (and never did 
> before AFAIR). Maybe this happens only on OpenBSD? Sounds strange.

It seems to be OpenBSD's rand() bug. The following program illustrates it:

$ cat badrand.c
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
	unsigned int i, modulus;
	modulus = 2;
	if (argc > 1)
		modulus = atoi(argv[1]);
	for (i = 0; i < 32; ++i)
		printf("%d: rand() %% %d = %d\n", i, modulus, rand() % modulus);
	return 0;
}

On GNU/Linux it gives something like

0: rand() % 2 = 1
1: rand() % 2 = 0
2: rand() % 2 = 1
3: rand() % 2 = 1
4: rand() % 2 = 1
5: rand() % 2 = 1
6: rand() % 2 = 0
7: rand() % 2 = 0
8: rand() % 2 = 1
9: rand() % 2 = 1
10: rand() % 2 = 0
11: rand() % 2 = 1
12: rand() % 2 = 0
13: rand() % 2 = 1
14: rand() % 2 = 1
15: rand() % 2 = 0
16: rand() % 2 = 0
17: rand() % 2 = 0
18: rand() % 2 = 0
19: rand() % 2 = 0
20: rand() % 2 = 1
21: rand() % 2 = 0
22: rand() % 2 = 1
23: rand() % 2 = 1
24: rand() % 2 = 0
25: rand() % 2 = 0
26: rand() % 2 = 0
27: rand() % 2 = 1
28: rand() % 2 = 1
29: rand() % 2 = 1
30: rand() % 2 = 1
31: rand() % 2 = 0

On OpenBSD the output looks like:

0: rand() % 2 = 0
1: rand() % 2 = 1
2: rand() % 2 = 0
3: rand() % 2 = 1
4: rand() % 2 = 0
5: rand() % 2 = 1
6: rand() % 2 = 0
7: rand() % 2 = 1
8: rand() % 2 = 0
9: rand() % 2 = 1
10: rand() % 2 = 0
11: rand() % 2 = 1
12: rand() % 2 = 0
13: rand() % 2 = 1
14: rand() % 2 = 0
15: rand() % 2 = 1
16: rand() % 2 = 0
17: rand() % 2 = 1
18: rand() % 2 = 0
19: rand() % 2 = 1
20: rand() % 2 = 0
21: rand() % 2 = 1
22: rand() % 2 = 0
23: rand() % 2 = 1
24: rand() % 2 = 0
25: rand() % 2 = 1
26: rand() % 2 = 0
27: rand() % 2 = 1
28: rand() % 2 = 0
29: rand() % 2 = 1
30: rand() % 2 = 0
31: rand() % 2 = 1

No randomness at all. That's why symbolic_matrix_inverse() always produces 4x4
matrix with several rows being zero. Such matrix is (obviously) degenerate,
so the loop

179     do {
180             for (unsigned co=0; co<size; ++co) {
181                     for (unsigned ro=0; ro<size; ++ro) {
182                             // populate some elements
183                             ex elem = 0;
184                             if (rand()%(size/2) == 0)
185                                     elem = sparse_tree(a, b, c, rand()%2, false, true, false);
186                             A.set(ro,co,elem);
187                     }
188             }
189     } while (A.determinant() == 0);

never terminates. Hopefully OpenBSD developers will fix their RNG.

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20081105/f896655f/attachment.sig