Commit v4.alpha1

dev/TODO

@@ -0,0 +1,93 @@
+=============================================================================
+From: Frank.Celler@Math.RWTH-Aachen.de
+Date: Fri, 13 Dec 96 10:43 MET
+Subject: SUMMARY: immediate methods
+
+At the moment the general feeling is that (immediate) methods are
+under control.  There is still some room for improvement:
+
+- 'SetFilterObj' and 'RunImmediateMethods' can be moved to kernel
+  to reduce the garbage still created
+
+- the 'SUBTR_SET' in 'RunImmediateMethods' can be optimised to use
+  some static area (note that 'RunImmediateMethods' is *not*
+  reentrant)
+
+- it is possible to add a second level cache to the method selection
+  to reduce calls to 'IsSubsetFlags'
+
+The suggestion is to leave 'RunImmediateMethods' and 'SetFilterObj'
+alone at the moment.  I will put the email into 'TODO' list in
+"gap/4.0/dev".
+
+mfg Frank
+
+=============================================================================
+Date: Thu, 14 Nov 96 14:07 MET
+From: Frank.Celler@Math.RWTH-Aachen.de
+Subject: minutes of the meeting
+
+Thomas, Martin and I have talked about lists, vectors, ranges and the
+problem with length, we came to following conclusion (?):
+
+There are the ``relatively'' easy changes to 'LEN_LIST' to allow it
+return GAP objects instead of small C integers, but then the kernel
+has to be very careful not to assume that the length is small and most
+of the code has to duplicated, namely one large and one small version.
+We all had the feeling that this will not change the real problems or
+even worse create new ones.  So, we want to clean up the list code:
+(the following points are not necessarily in the order one has to
+attack them):
+
+- internal lists have always a small length,  that means that it
+  is not possible to have plain list of length larger than 2^28
+  (or maybe 2^32) on 32-bit machines, 'LEN_LIST' can only be
+  applied to internal objects, 'LENGTH' is the GAP interface for
+  all kind of objects
+
+- on the other hand we want ranges to have large start and end points,
+  therefore ranges are no longer *internal* objects,  they will become
+  external objects
+
+- the for/list assignment has to be carefull to catch the special
+  case of a range constructor with small integer bounds
+
+- the list access/assigment has to be more flexible and becomes a
+  binary operation
+
+- the conversion/test functions are split into three different
+  functions
+
+- 'ResetFilterObj' and 'SetFilterObj' are implemented using a table
+  for internal types
+
+- there will be a general function to replace one object by another,
+  this can be used to change representations (even from internal
+  to external and v.v.)
+
+- 'vecffe.c' has to converted
+
+two minor points:
+
+- the default for 'Position' has three arguments, 'Position' might become
+  a simple operation not a table/operation hybrid
+
+- the set should not try to convert external objects into set unless
+  it is absolutely necessary
+
+(I have the feeling that I missed one point)
+
+I'm willing to do these changes (except maybe for 'vecffe.c') and try
+to produce a documentation about the internal list managment along the
+way.  However, this will take some time!
+
+I would be better if - say Werner - could have a look at the free
+groups and polycyclic groups elements and see where the problems with
+64 bits machine arise (the test file does produce errors but I hope
+they are easy to fix).  Steve, you looked at "blist.c" for 64 bits, so
+this is already dealt with (?).
+
+mfg Frank
+
+
+