From: SourceForge.net <no...@so...> - 2004-10-23 15:27:59
|
Patches item #1052584, was opened at 2004-10-22 22:22 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1052584&group_id=10894 Category: 14. List Object Group: TIP Implementation Status: Open Resolution: None Priority: 5 Submitted By: Salvatore Sanfilippo (antirez) Assigned to: miguel sofer (msofer) Summary: O(1) space [range] command. Initial Comment: That's a first version of the [range] command working in O(1) space. There is some minor bug I'll fix tomorrow, but the basic stuff appears to be ok. commands aware of the new arithSeries object in the TEBC and normal fashion: llength lindex foreach New commands: Only [range]. The change is minimal from the user point of view. From the core side is a bit more tricky because of the O(1) space aims. Other stuff optimized for this object: SetListObjFromAny will directly convert ranges into lists without to pass for the string repr. Open issues: The code needs a check in order to don't allow the generation of ranges that are longer than the max listObj length supported by the current Tcl code. For the rest, I used Wide Ints in order to ensure that ranges shorter than the max list length, but having as elements Wide ints will work. Performance changes: The effects on the performances of the list-oriented should be very small, there is some test more than before. The case of: foreach x [range 0 $n] is faster than the equivalent [for] form by 10% to 30% from a first test. The appended patch should apply against HEAD. ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2004-10-23 12:27 Message: Logged In: YES user_id=148712 The patch uses wideInts for {start,end, step}, but is restricted to a length of INTMAX elements - not this patch's fault, Tcl lists have this restriction. One possible performance impact is that the element variable in [foreach] loops is always a wideInt. Whenever the element is representable by an int, this may impose conversion costs in further computations with it. It may be interesting to study how to return an int object whenever possible. Mybe adding a arithSeriesRepPtr->intObjPtr, and insuring that one of those pointers is always valid, and the other is NULL? There may be better solutions ... ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-10-23 07:12 Message: Logged In: YES user_id=148712 Assigning to myself ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1052584&group_id=10894 |