To Do List - Revision history

SeanParent: /* Property Model Library */

2009-01-14T23:32:14Z

‎Property Model Library

SeanParent at 04:35, 13 January 2009

2009-01-13T04:35:52Z

SeanParent at 01:18, 30 September 2008

2008-09-30T01:18:23Z

SeanParent at 01:13, 30 September 2008

2008-09-30T01:13:04Z

SeanParent at 01:09, 30 September 2008

2008-09-30T01:09:32Z

SeanParent at 22:52, 16 April 2008

2008-04-16T22:52:57Z

SeanParent: /* Non-Mutating Algorithms */

2007-12-06T22:56:05Z

‎Non-Mutating Algorithms

SeanParent: /* Non-Mutating Algorithms */

2007-11-10T05:57:13Z

‎Non-Mutating Algorithms

SeanParent: /* Finding and Counting */

2007-11-10T05:56:34Z

‎Finding and Counting

SeanParent: /* Goals */

2007-10-24T19:37:41Z

‎Goals

@@ Line 22: / Line 22: @@
 # Uncouple the VM from the sheet - the sheet should operate only on function objects.
 ## Provide a variable lookup function for the VM (as well as programatic inspection).
 Beyond the 1.0.41 release here are some things I'd like to see happen next:

← Older revision		Revision as of 04:35, 13 January 2009
Line 8:		Line 8:

	We are working to restructure the documentation to include the "final" set of libraries and to flesh out the documentation, test cases, and in some cases, the code.		We are working to restructure the documentation to include the "final" set of libraries and to flesh out the documentation, test cases, and in some cases, the code.
		+
		+	==Property Model Library==
		+	[1/12/09] I'm now in the middle of a major overhaul of the property model library - This is slated for the 1.0.41 release. Here is the plan:
		+
		+	# <del>Write a "flow" algorithm on the interface cells / relationships to determine the calculation order without the need for backtracking.</del>
		+	# <del>Implement caching so calculations don't need to be repeated.</del>
		+	# <del>Implement contributing tracking by watching cell access and remove it from the VM.</del>
		+	# <del>Implement a "contributing" function that can be called from within the VM (similar to todays function but taking a named cell instead of an expression).</del>
		+	# Rework contributing tracking on initializers as above to work with caching.
		+	# Verify that "considered" is being set correctly with the new flow algorithm.
		+	# Review all logic to ensure that no new bugs were introduced.
		+	# Review all error handling to ensure a proper separation of runtime checks and asserts.
		+	# Uncouple the VM from the sheet - the sheet should operate only on function objects.
		+	## Provide a variable lookup function for the VM (as well as programatic inspection).
		+
		+	Beyond the 1.0.41 release here are some things I'd like to see happen next:
		+
		+	# Review of data-structures and algorithms and updating to use appropriate structures (boost graph?)
		+	# Factor out input cells/initializers and output cells from the core code (separate components?)

	==dictionary.hpp==		==dictionary.hpp==

@@ Line 12: / Line 12: @@
 * The get_value() functions are poorly named and could be generalized to work with any indexed container.
-: consider lookup() or value_at() as more appropriate names.
+(notes from conversation about removing get_value() from dictionary.hpp and providing a generalized form).
 ==string.hpp==
@@ Line 133: / Line 148: @@
 ---
 == Notes ==
 Check to see which intrinsics (like multiply returning long result) are in C99

@@ Line 13: / Line 13: @@
 * The get_value() functions are poorly named and could be generalized to work with any indexed container.
 : consider lookup() or value_at() as more appropriate names.
 ==Algorithms==

@@ Line 8: / Line 8: @@
 We are working to restructure the documentation to include the "final" set of libraries and to flesh out the documentation, test cases, and in some cases, the code.
 ==Algorithms==
@@ Line 15: / Line 20: @@
 ===Non-Mutating Algorithms===
-Order Selection Networks -
+* Order Selection Networks -
-	Rework pin, min, max, median_3, median_5, select_ith_n
+** [low priority] consider completing select.hpp to some k elements.
+* [low priority] consider adding sorting networks (sort_2, sort_3, etc.)
-	Review chapter from book (4)
-−
-	For each provide a comparison based, const, and non-const versions.
-−
-	Go to how many elements?
-−
-Definitions:
-	select_ith_n: return the ith element in non-descending order out of n elements.
-−
-	The network is minimal in the worst case if it does the minimum number of comparisons in the worst case and minimal in the average case if it does the minimum number of comparisons on average.
-−
-	The selection network is stable if the retuned element is selected out of n elements stably soreted in non-decending order (we do not do sorting).
-−
-	A selection network from partially ordered inputs is a selection network where a certain partial ordering of the elements is already determined.
-−
-	[We need to develop a naming convention for paritial ordering.]
-−
------
-−
-Question - do we provide sorting networks?
-−
------
-−
 * [done] Removed bound_if - replaced with key_function form of lower/upper_bound.
 Write a proper partition() (ordering and for forward iterator), partition_point_n(), and is_partitioned.
 non_strict_order_partition(range, element, strict_weak_ordering) arranges it so that elements are not greater followed by elements which are not less.
@@ Line 148: / Line 128: @@
 (notes from conversation about removing get_value() from dictionary.hpp and providing a generalized form).
 So - current summary and action items:
 ) get_value() in dictionary.hpp becomes deprecated next release (hmm - move to a deprecated namespace?) in favor of new algorithms.
 :38 PM
 ) We add:
 I find_at(I f, I l, const T&, P);
 [along with all range variants and specialize for associative containers - P defaults to identity if value_type(I) == P)
 otherwise P defaults to get_element<0> (or whatever the name is in adobe/functional.hpp)
 ) consider that get_element<0> should have a default implementation of identity to normalize the case.
 ) similarly provide find_value_at() and assign_at()
@@ Line 167: / Line 141: @@
 I assign_at(I, I, T, U&, P);
 ) review exisiting find() algorithms to see which it would also make sense to refine for containers (i.e. find() )
 ) Add an is_associative_container<> trait so we can automatically pick up new ASL containers and can be made to work with user containers.

@@ Line 51: / Line 51: @@
 ------
-Pull count_min/max_element. Replace with two passes - max_element(), count().
+* [done] Pull count_min/max_element. Replace with two passes - max_element(), count().
 -----

@@ Line 67: / Line 67: @@
 ===Finding and Counting===
-*(done) rename find_not_equal to find_not.
+*[done] rename find_not_equal to find_not.
 Extending find() - also provide find_not() and count_if_not() and count_not().

@@ Line 4: / Line 4: @@
 To that end, we are reviewing all of the libraries and for each one determining:
-# Is it used and/or useful and worth being completed. If not it will either be removed all together or partitioned into the platform libraries for later consideration.
+* Is it used and/or useful and worth being completed. If not it will either be removed all together or partitioned into the platform libraries for later consideration.
+* What is necessary to complete the space to create a completed body of work.
-# What is necessary to complete the space to create a completed body of work.
 We are working to restructure the documentation to include the "final" set of libraries and to flesh out the documentation, test cases, and in some cases, the code.