Minutes 040607: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
| (5 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
* Agree to | * Agree to | ||
** Sample derive from DataObject | ** Sample derive from DataObject | ||
** SampleAlgorithmBase derive from | ** SampleAlgorithmBase derive from ProcessObject | ||
* Generators | * Generators | ||
** Only the ones that do not need inputs | ** Only the ones that do not need inputs | ||
| Line 17: | Line 17: | ||
* Deprecation Strategy | * Deprecation Strategy | ||
** Keep the old classes, delegating to the new classes? | ** Keep the old classes, delegating to the new classes? | ||
*** Better for maintenance. | |||
** Keep the old classes around, with a CMake configuration option? | ** Keep the old classes around, with a CMake configuration option? | ||
*** Brings the complication of requiring duplicate dashboard to ensure that both versions of the code still work. | |||
** ListSampleBase | |||
*** Candidate for deprecation | |||
*** Search algorithm | |||
** Distances | |||
*** Have them as plug in objects or as Functor | |||
** KdTree | |||
*** Maybe not to derive from DataObject ? | |||
*** Maybe should derive from Sample ? | |||
*** Identify Use cases before deciding. | |||
*** Allow other distance (non-Euclidean) to be used. | |||
** Classifiers | |||
*** Do not quite fit in a pipeline style... | |||
*** We need to study Use Cases. | |||
*** Some in Statistics / Some in Algorithms (for Images). | |||
== Action Items == | == Action Items == | ||
Latest revision as of 19:02, 9 April 2007
Attendees
- Jim Miller
- Nick Tuicston
- Luis Ibanez
Discussion
- Statistics
- Jim suggests to add a cross-sample
- Agree to
- Sample derive from DataObject
- SampleAlgorithmBase derive from ProcessObject
- Generators
- Only the ones that do not need inputs
- That comes down to the random number generators
- Deprecation Strategy
- Keep the old classes, delegating to the new classes?
- Better for maintenance.
- Keep the old classes around, with a CMake configuration option?
- Brings the complication of requiring duplicate dashboard to ensure that both versions of the code still work.
- ListSampleBase
- Candidate for deprecation
- Search algorithm
- Distances
- Have them as plug in objects or as Functor
- KdTree
- Maybe not to derive from DataObject ?
- Maybe should derive from Sample ?
- Identify Use cases before deciding.
- Allow other distance (non-Euclidean) to be used.
- Classifiers
- Do not quite fit in a pipeline style...
- We need to study Use Cases.
- Some in Statistics / Some in Algorithms (for Images).
- Keep the old classes, delegating to the new classes?
