
        Bugfile for the Atlas of Reductive Lie groups project

06-30-04 : something must be wrong with the involution matrix. In type A1.T1,
	giving (1,1) as a lattice generator gets us something not stable under
	involution!

07-01-04 : found two mistakes: one in setInvolution (incrementation of r was
	done by the first component of slt, the group letter, instead of the
	second!), and one in addSimpleInvolution, where nothing was done for
	non-complex torus factors. It seems to work ok now.

09-20-04 : I have the uneasy feeling that there is a bug larking in the
	symmetrization procedure (when getting the lattice from the user.)
	The bug appeared in Berder for type A3.E6.T1.T1 (I think), with
	real form II,split,complex. But it doesn't seem reproducible (perhaps
	depends on the memory state, if too many vectors are taken into account
	?) Also got non-symmetric complaints for A3.E6.T2, which is absurd.
	Annoying!

09-24-04 : a bug in the interface : it won't accept type C.
09-24-04 : solved : the error message was inconsistent about the ranks.

09-25-04 : cmatrix was wrong --- did use R.rank instead of R.semisimpleRank.

09-25-04 : strange behaviour when we try to get the lattice in split type B4;
	the funny thing is that B3 and B5 behave normally. Actually, the
	bug is in the construction of the root list.
09-26-04 : first hint : cartan matrix is wrong for B4! --- in fact, it seems
	to be wrong for all even rank B's.
09-26-04 : I believe that the smith normal basis w.r.t. the cartan matrix
	is wrong in this case.
09-27-04 : ok, found it. Pretty heavy bug in blockReduce : it didn't update
	the basis when doing a row-operation! Anyway, the whole setup of
	smith-normal was shaky; it should run through the hole routine again
	when blockReduce kicks in. This is corrected now; blockReduce does
	much less than it used to do, we re-enter the main routine.

10-01-04 : realized that I was permuting types B and C! This is because
	I got the definition of the Cartan matrix wrong: I was using
	coroot(i).root(j), instead of the converse.

10-05-04 : a bad moment today. It turned out that when correcting the
	previous bug I had made a mistake : changing copyColumn to
	copyRow is _not_ the same thing as doing copyRow from the
	tranpose matrix ... This caused havoc in the involution matrices.
	In type A3 II, it didn't even permute the roots anymore!

10-05-04 : a very weird bug, one of the strangest I've met so far. It is
	in the copy constructor of CartanSubGroup, invoked when pushing
	the first csg on d_cartan, in the RealRedGroup constructor.
	Everything goes fine until we start copying the various RootSets,
	and even here the trouble arises only on the third one! Even more
	bizarre, it arises only for fairly large groups : E6 and over,
	B6 and over, but not B5, D7 and over but not D6.
10-08-04 : ok, found it, I think. Not so weird after all; the RootSets had
	not been initialized to the correct size.

10-11-04 : just implemented the classification of gradings up to W-conjugacy!
	In fact, the gradings up to C-conjugacy should be the same thing
	as the classification of the real forms of the group; more precisely,
	of the equal rank forms. The problem is that I sometimes get a
	segmentation fault in type B6 --- somehow I don't seem to be able
	to get it on the debugger now. Most likely something wrong with the
	PartitionIterator stuff. The function prints stop1, ... , correctly,
	which means that the PartitionIterator in makeGradings gets 
	constructed, but doesn't output any gradings, so if this is reliable,
	that means that the crash occurs in the PartitionIterator loop of
	makeGradings.

10-11-04 : just found a bug in the incrementation operator of BitMap.
	The test for when we have reached the end before reaching the
	last chunk was wrong : it should have been (d_capacity - d_bitAddress) 
	<= longBits. Corrected now. As usual, it is amazing how much works
	with such a bad bug. It may have been a cause for the previous one
	also.

11-12-04 : have been trying to do a little cleanup lately. Trying to get rid
	of placement new (which I tend to abuse and use instead of assignment,
	with the corresponding risk of memory leaks), I notice that I failed
	to see that some assignment operators are more subtle than I thought.
	I thought that the only issue was memory leak and shared memory in
	pointer members; but there is also the issue of invalidated pointers
	and iterators, when a class carries iterators that point into its
	own data structures. That makes copying them really hard, pretty
	much next to impossible in general! (it would involve finding the
	relative position of the iterator in the structure, and resetting the
	new one to that same relative position.)

01-17-05: oops, apparently a bug-report disappeared during some cvs clumsiness.
	The issue was very bizarre behaviour with some fields of the d_fiber
	field in a CartanClass, when I had decided to move the cocycle and
	the weylAction to the fiber. Something like that a const reference
	would change in the course of a function call. I think it was a
	combination of forgetting to update the copy constructor so that
	those fields didn't get updated correctly, and gdb getting confused
	with that kind of modification, as sometimes happened. Anyway, after
	correcting the copy constructor a _fresh_ gdb had no more problems.

01-17-05: an implicit assumption in the RootDatum structure: I was assuming
	that the root list (but _not_ the coroot list, it cannot be true
	for both), was ordered, so that I could search it with lower_bound.
	The problem is that this is not a selfdual condition, and so the
	duality constructor made a rootdatum for which rootNbr didn't work.
	If we sort the roots after duality, the problem becomes the
	compatibility between the root system and its dual; so I reverted
	to find, which I don't think makes much of a difference anyway, as
	the sets are small and the function is not heavily used.

10-04-05: for type F4, showdualforms doesn't print out the real forms in the
	correct ordering.
10-04-05: the reason is quite interesting: for the dual forms, we are looking
	at the _dual_ F4, where the short roots come first. So the split
	special grading is now supported by root 3, which makes it appear
	as the intermediate grading.
	The strange thing now is that things should seem to work for most
	other types, where the same kind of bad renumbering would seem to
	occur.
10-06-05: resolved, by allowing the dual of F4 as type f4, and for completeness
	the dual of G2 as g2; the dual of B2 was already available as C2,
	happily. Not very pretty but good enough for now. Perhaps this should
	be allowed only internally.

10-04-05: blocksizes are very wrong (e.g., the compact form appears to have
	more than one representation!) Probably something wrong with the
	numbering of dual real forms.
10-04-05: ok, found it. The bug occurred only for _optimized_ compilations,
	because I had an assert with a very important side-effect
	(assert(firstSolution(...))) in cartanclass.cpp. Amazing that there
	wouldn't be a much worse crash!

10-05-05: segmentation fault in strongreal for type A3 intermediate, cartan
	class 0.
10-05-05: resolved. I had forgotten to include the toWeakReal call in the
	case of a unique class of real forms.

10-22-05: swatted a bad bug in WeylGroup::twist: it was using prod instead of
	prodIn. Amazing how it could have survived for so long! (it manifested
	itself only in type D.)

10-24-05: the cayley tables for blocks seem wrong. Type B3 sc, (split,split),
	yields an undefined result for the third cayley transform of 15;
	strangely enough this is not cught by the assertion.