
	Workinglog for the Atlas of Reductive Lie Groups 

10-03-04 : made a start yesterday on version 0.2.3. The idea is that in this
	version, the central role will be played by the _complex_ group, aka
	the root datum. More precisely, we have a connected reductive complex
	group with a chosen torus. This forces me to re-think RootDatum,
	take out all the involution and topology stuff, which didn't have
	any business in there anyway, and RealReductiveGroup. There will
	now be a class RealForm holding the involution which characterizes
	the real form.

10-03-04 : need to look at the exception handling. Somehow this seems to
	have disappeared from the constructors of RealReductiveGroup. Perhaps
	correctly (no point in catching and rethrowing without doing anything?)
	but at least a comment would be in order.
10-13-04 : perhaps it is ok after all --- exceptions are just passed along.

10-13-04 : everything is in a sort of flux; I'm in the middle of a complete
	reordering of stuff in my mind, which hopefully will bring everything
	out at the same time. Trying to finish a correct construction of
	the Cartan classes along the current lines, even if much of it is
	likely to get ditched eventually, and replaced by better approaches.

10-13-04 : one thing that comes up over and again is expressing the roots
	in the root basis. In fact, I wonder if it wouldn't have been much
	better to have them _only_ in the root basis : going from the root
	basis to the lattice basis is simply applying the base-change
	matrix, contained in the SimpleRoot list; whereas in the other
	direction, it involves a matrix inversion each time. I will do
	this at some point; however, in a transitional period, I'll just
	have the two lists. There should then be two access functions :
	root (in lattice basis), and rootRB (in root basis).

	One should be very careful with this though, to avoid destroying
	the fundamental stability of the root set; that was one of the
	strengths of the previous setup. So perhaps, two lists ?

10-13-04 : look at the dependence of tori.h on realform : this is only because
	of Involution. Since we used Involution only to have some nice
	constructors, the general use of Involution should revert to
	LatticeMatrix I'm afraid; or else have something called 
	SpecialInvolution or something. Define Involution in latticetypes.
10-22-04 : done

10-13-04 : reorganized the bitvector stuff quite a bit. Finally got to
	the decision to make it into real linear algebra. So now we need to
	revisit all usages of BitVector and Component. Also we need to
	distinguish between ComponentList and BitMatrix. And finally, the
	data in BitMatrix should probably be a single bitset.
10-22-04 : done. Enormously simplified and clarified. Didn't put the data
	in a simgle bitset, though.

10-22-04 : I think I discovered a bug in gcc! When it complains about undefined
	variables, it sometimes mixes them up in the message. This happened
	to me in operator << for SimpleLieType, where it complained about
	undefined strm, but meant undefined slt.

10-29-04 : Need to have a look at adjustBasis in topology.cpp. It seems to me
	that perhaps it doesn't take into account the part of the new basis
	corresponding to torus components!

12-20-04 : my 50th birthday! I have been putting some notes in the CVS
	comments; perhaps not the best way. Right now, in the middle of
	implementing the CartanClasses structure; which will turn out
	to be some sort of cross-section of the parameter space.

12-20-04 : define a concept of decomposed number, for sizes of groups and
	orbits. Note that the factors will be very small, and certainly
	bounded by the rank+1; so for rank <= 16 the largest factor is
	17, and that occurs only in type A16. This will allow the explicit
	handling of group and quotient sizes (multiplication and division are 
	very easy!) without fear of overflow.

03-28-05 : having fun with custom allocators in the stl. I'm not very clear yet
	about the policy for allocator copying; it seems to do a lot of that.
	However there is a "bug" in vector::swap: it doesn't swap the 
	allocators. So this is a place where there is explicit use of the
	liberty to have all allocators for a given type be equal.

07-10-05 : I think I finally understood now the restriction-to-the-centre
	thing. At least, how these restrictions move. It should be so that
	(a) the trivial representation always corresponds to the principal
	co-grading (the one where all simple real coroots are non-compact)
	--- incidentally, the set of reps for that grading should be the set
	of one-dimensional characters of G, parametrized by \pi_0(G)^\vee;
	another way of computing the component group from the center of the
	dual group ? (b) the infinitesimal character determines the action
	of the center up to elements of order 2 in Z^\vee; the main idea is
	to look at the partition induced by the infinitesimal characters
	for the _adjoint_ group; from there, one can deduce the action of
	the center.

07-15-05 : look at makeFiberGroup in cartanclass.cpp. I'm not sure the lattice
	is the right one, although it's not essential. Shouldn't it rather
	be (1+tau)Q + corad^tau, something like that?

07-17-05 : need to revisit tori in the view of the new subquotient module.
	Probably most of the bitvector stuff can be hidden now. Also, need
	to see why there is so much emphasis on the dual side. Is it even used
	at all?
	Allmost done! it remains to redo componentMap and make a new FiberData
	class.

07-18-05 : two requests from Jeff: (a) compute R(G) = G/G_0.Z(G) (this one
	always injects into R(G_ad)) (b) compute Levi subgroups (i.e., give
	a subset of the simple roots, and compute the corresponding Levi)
	This should be easy enough, just applying a constructor essentially.

07-20-05 : the good news: I found the memory bug, it was bad initialization
	of some RootSet's (confusing size and capacity). Now things are
	working, and nicely fast, too. B2 is fine. Still, there is a mistake
	in the algorithm. I'm not keeping track of the variation of
	V^tau/V_-^tau appropriately. (for instance, when going from a complex
	torus to a more real torus, both should increase, by the same amount.)
	One way around this, which may be the thing to do anyway, would be
	to compute it directly from a lattice involution the first time a new
	Cartan class is reached, and then saturate that datum through
	conjugation right away. This isn't bad at all, as it would have to
	be done anyway. Essentially it means that the search for the
	FiberDatum would almost always succeed.

07-31-05: made some progress allready streamlining the kgb computation. Now 
	mostly what remains to be done is get rid of the RootStatus list.
	The status can in fact be computed directly. Indeed, the torus part
	of the Tits group element, if pushed over to the right, gives exactly
	the grading of the imaginary roots! And the classification into
	real, imaginary and complex may be carried out by the cross-action
	construction, as follows: if s_alpha.tau.s_alpha is not tau, then 
	alpha is complex. Otherwise, it is real if s_alpha_tau < tau, imaginary
	otherwise. Moreover, this part depends only on tau; so there could
	be a status list at the tau-level, and the final status list would
	be gotten at the start of the Cayley stuff (or at the end of the
	cross-action stuff) by crossing that with the grading from the torus
	part of the Tits element.

07-31-05: another issue is the computation of the minus space. I still feel
	that perhaps it could be computed at the level of T(2). In any case,
	it is guaranteed to grow by one and to contain m_alpha. So if m_alpha
	is not in there, add it and be done. Otherwise, do the current thing;
	this means that we are taking a complex torus to split.split; there
	could be something like a non-degenerate pairing of the cokernel of
	tau-1 with its image?

08-04-05: right in the middle of some heavy surgery on the CartanClass and
	CartanClasses classes. I'm going to ditch the classification of strong
	real forms there; put it up as a command in case some user wants it.
	I'm going to put the accent on _weak_ real forms, which we are much
	more interested in. Also, this is always a finite problem. So, we
	need to do the action on the adjoint fiber group. I'll take advantage
	to make the gradings more accessible, so that in particular an
	assertion can be put in to see if adjoint parameters really go
	one-to-one to gradings. Of course, one still wants to be able to
	compute orbits in the strong real forms, but that's fine with the
	cocycle formula. Same thing for the computation of the real Weyl group.
	One should like to output information about the center as well, and
	deduce from that the number of strong real forms lying over a given
	weak one (with derived central square, say.)

08-15-05: trudging forward on the CartanClasses rebuild. Finally I decided to
	introduce a Helper class that is derived; this has the nice effect
	that swapping with the helper class will put the right data into
	the original class. The extend function is written but needs to be
	tested; also, the hard part, which is the correlation, is still
	entirely to do. One might consider adding the "known" stuff from
	extend to the Helper class, as well as the Weyl group (which will
	not always be defined.) The dual root datum has already been 
	incorporated. I need to be careful with the real form labels.

08-15-05: I believe now that there could be something like a 
	ComplexReductiveInterface, that holds a constant pointer to the group.
	That way, the class will not be burdened by interface issues. Actually,
	it could even hold a _non_constant pointer to the group, like for
	instance the RealReductiveGroup thing, while still not owning it.
	Same thing of course for RealReductiveGroup, and all the big
	structures to come.

08-23-05: an excellent day today. After somewhat of a struggle, I believe that
	I have now extirpated the bugs from the new CartanClasses construction.
	Actually the adjoint fiber partition can be also constructed directly
	from the correlation; the main debugging tool was to check that these
	two partitions actually do coincide. It remains to make the new
	output function; currently it is printing the adjoint fiber picture,
	which is not what we want. We want to output the fiber picture,
	together with info about the center, and real form classes.

08-23-05: started ressuscitating realweyl. This will require writing an
	mAlpha member function for Fiber: the current one works only for
	imaginary simple roots, and is not what we want. Actually d_mAlpha
	should perhaps be part of the helper; mAlpha can be harmlessly
	computed. Be careful that we want the expression in subquotient
	coordinates, perhaps also in the one we are doing now, this needs
	to be looked at.

08-24-05: started preparing the extra data I would like to be able to output
	for real forms. The classification of real forms according to central
	square classes seems to work nicely. Dually, this is essentially
	what's required to identify a fixed central character.

09-04-05: excellent progress these last days. I think I'm rid now of all the
	"#if 0" stuff used during this long surgery process. Now it's a matter
	of finishing some undefined functions such as kgbsize, adding an
	inspection function realforms and dualrealforms, and making the
	output stuff for gradings and strong real forms. Also, one should
	add to the interface of ComplexReductiveGroup, so that all the useful
	accessors are available directly from there, without having to go
	into CartanClasses or Fiber.

09-04-05: but even more importantly, I need to set up something for automated
	testing. Something slightly less ambitious than this "testrun" stuff
	perhaps, or try to make that work, say already for simple groups. Some
	fairly nasty bugs were caught because of the assertions I put in here
	and there, but that's not enough.

10-20-05: the correct data type for a representation (or at least for the
	abstraction of it that is encoded in a sextuple) would be one
	Weyl group element (the corresponding twisted involution), and
	two elements of order 2, in the torus and the dual torus respectively.
	Then Cayley transforms and inverse Cayley transforms would do fairly 
	different things on the two elements of order two: on one side it
	would be the one-to-one orbit thing, on the other side the potentially
	one-to-two inverse thing. The twisted involution correlation would
	be built-in here. In this way, I believe a block could be directly
	constructed, from the basepoints of the real form and the dual real
	form contained in the cartanclass structure.

10-20-05: files added: sources/utilities/ctr_iterator.h
		       sources/io/block_io.h
		       sources/io/block_io.cpp

10-22-05: files changed: sources/structure/weyl.cpp: swatted a bad bug.
	                 www/realweyl.html: _&alpha; -> <sub>&alpha;</sub>

10-23-05: files added: sources/kl/descents.h
	               sources/kl/descents_fwd.h
		       sources/kl/descents.cpp

10-26-05: files added: sources/io/poset_io.h
		       sources/io/poset_io.cpp

10-30-05: files added: sources/kl/kl.h (!)
		       sources/kl/kl_fwd.h
		       sources/kl/kl.cpp
		       sources/utilities/polynomials.h
		       sources/utilities/polynomials_fwd.h
		       sources/utilities/polynomials_def.h
		       sources/kl/klsupport.h
		       sources/kl/klsupport_fwd.h
		       sources/kl/klsupport.cpp

11-02-05: files added: sources/io/kl_io.h
		       sources/io/kl_io.cpp

11-02-05: some more interesting numbers: 21,904,637 extremal pairs for the big
	block in type E7, of size 24,678 (3.6% of all possible pairs, about
	8% of all comparable pairs in the lazy ordering.) 175,756,777 extremal
	pairs for the next-to-biggest block in type E8, of size 73,410 (3.2%
	of all possible pairs), and 5,437,760,002 for the big block in type
	E8 (2.6% of all possible pairs, about 6% of all comparable pairs.)
	Actually the result of the last computation was 1,142,792,706, but I 
	think I can safely assume that it overflowed, exactly once (ok, that's 
	confirmed.)

11-06-05: removed file sources/io/io_error.h

11-07-05: have to stop for a while. recursiveMu() in kl.cpp is unfinished!

11-15-05: when the k-l setup has been modified, klPol can become an accessor.
	Functions like printAllKL in kl_io.h can take a const KLContext& as
	argument.

11-19-05: now that we have k-l, I'm a bit overwhelmed by the multiple things
	to do! (a) profile and speed up k-l and buffer construction (b) think
	through the klsupport stuff, and the tables that will be required;
	think about the corresponding i/o (c) set up ownership of k-l 
	computations, probably in mainmode? (d) write testing code; code to
	count primitive pairs; code to check the basepoint thing; dual block
	construction; duality check (e) write W-graph stuff.
11-24-05: (e) is done

11-19-05: files added: sources/gkmod/wgraph.h
		       sources/gkmod/wgraph.cpp
		       sources/io/wgraph_io.cpp
		       sources/io/wgraph_io.h
		       sources/utilities/graph.cpp

11-24-05: very interesting results from profiling the block construction for
	E7: allmost all the time goes to orbitPairs(), which I already knew,
	and within orbitPairs, almost all the time goes to tauPacket(), which
	came as a surprise. It should be possibl to speed up by a factor of
	five, I believe.

11-25-05: started work on reorganizing the k-l computation. Took d_extrPairs
	out of KLSupport, and replaced it by d_extr in KLContext. Although
	this is a little bit less pleasant, this setup allows us to keep only
	those entries that yield a non-zero polynomial. The thicket-fill now
	becomes even a little bit worse. The d_extr field in Thicket can be
	taken out, I believe, although it is probably cleaner this way;
	actually Thicket should perhaps have its own klPol function, so
	that the general one can be rewritten. The next step now is to go
	from extremal pairs to primitive pairs.

11-26-05: continuing from yesterday. Cleaned up yesterday's stuff a little bit
	more, and introduced primitive pairs. The write-out function was
	a little bit hairy to get right, but should be ok now. It is already
	used for the direct recursion cases; it should now also be introduced
	for the thicket and completePacket stuff. The cost of remembering
	all the primitive pairs appears to be around 20%, but it is certainly
	worth it speedwise.

12-03-05: files added: sources/gkmod/klcomputations.h
	    	       sources/gkmod/klcomputations.cpp
	    	       sources/gkmod/klcomputations_fwd.h
	    	       sources/gkmod/involutions.h
	    	       sources/gkmod/involutions_fwd.h

12-11-05: started the InvolutionSet stuff. It is going to be much nicer with
	a helper class---need to introduce that.

12-13-05: roughly speaking, InvolutionSet is finished. I still need to check
	if involutionNbr needs a revert in the weylword, and fix the twist
	in dualWeyl which I think is not right. Also check that toDualWeyl
	does the right thing when it matters (G2,F4).

8-18-06 [DV]: Worked with Fokko last five days on various memory
	issues mostly appearing in very large jobs.  Tried to run
	kllist for split C8 on a variety of machines; on all 32 bit
	machines, got a variety of out-of-memory errors when top
	reported that atlas had grown to....

	 machine     largest y	   memory used
	DV Mac	       253060		3.4G

	hypatia		245000		2.9G          (MIT comp. server)

	weierstrass	239495		2.55G	      (Lyon comp. server)     

	Eventually concluded that the machines were running out of
	32-bit pointer space (even if they had additional swap
	available) and so this didn't count as a crash.

	Finally ran C8 on (at least two) 64 bit machines: newton at
	MIT and eole at Lyon.  The former ran out of memory at a size
	of about 4G, near y=60K.  The latter grew to 8.3G at y=261525,
	which is the end of the computation, and printed the answer,
	then crashed while deallocating the memory from the
	computation.
	
	Fokko fixed a few bugs related to 64 bit machines: mostly
	use of undecorated 1 where an unsigned long was needed. On a
	32 bit machine that works, but on a 64 bit machine undecorated
	1 can be (must be?) a 32 bit integer.  In the end C8 runs fine
	on eole (still growing to 8.3G: the size approximately doubles
	because pointer sizes double).

	Fokko has a memory allocation scheme in sources/memory, which
	can replace std::set and std::vector and offers easier
	debugging of memory allocation problems.  Those files are not
	used in atlas 0.2.4.  When he put them into use (to build the
	polynomials and sets of pointers used for KL computations) a
	variety of obscure bugs appeared.  Most 32 bit Linux machines
	crashed on kllist for split E7 after computing the block,
	before computing any KL polynomials.  He finally found a
	missing pointer initialization in pool.cpp. Now this seems to
	work well.

8/28/06	[DV] Found a tiny bug in blocks.cpp, that could appear
	essentially only when the Weyl group is trivial (so for tori)
	and then only sometimes.  In building the collection of pairs
	(x,y) constituting the block, Fokko's original code incremented x
	until the involution (as recorded in d_involution[x] in the
	class d_kgb) changed. At the end of the list of x's, the code
	could look at an undefined value of d_kgb.involution(x). This
	seemed to have no serious consequences, but it's fixed now.

-------------------------------------------------------------------
From this point forward, the detailed working log will be found in the
CVS repository. For a summary of changes see the file CHANGES.
