bugs: Propose performing flattening in client code at the outset, for easier
[libale.git] / bugs / issue-876c9d5bb7e4b7b461c023043a74bd62085be7c2.yaml
blobf223a30a82529408c207892be92cf51cdf3009c6
1 --- !ditz.rubyforge.org,2008-03-06/issue 
2 title: Determine memory architecture for median calculation.
3 desc: |-
4   Determine the number of buffers ('planes') to allocate for median calculation.
5   See {issue 2a9ae9d6db1fda0097a62dd69e52e33b33754e26} (Investigate median calculation ...) for more.
6 type: :task
7 component: libale
8 release: 
9 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
10 status: :unstarted
11 disposition: 
12 creation_time: 2009-02-07 11:33:45.567276 Z
13 references: []
15 id: 876c9d5bb7e4b7b461c023043a74bd62085be7c2
16 log_events: 
17 - - 2009-02-07 11:33:46.863110 Z
18   - David Hilvert <dhilvert@auricle.dyndns.org>
19   - created
20   - ""
21 - - 2009-02-07 13:11:08.840409 Z
22   - David Hilvert <dhilvert@auricle.dyndns.org>
23   - commented
24   - |-
25     It appears that this is not a new problem, as it's discussed in a comment in
26     ale:./d2/image_weighted_median.h, regarding cache performance in particular.  A
27     multiple-plane approach seems reasonable, as it is probably the most
28     straightforward approach; whether such planes should be allocated incrementally
29     or at the outset is less clear, however.
30     
31     Given that not all interfaces (or uses) of the code will necessarily know
32     capacity at the outset, however, perhaps incremental allocation would be the
33     best approach (where allocating a zero-valued, zero-weighted prefix plane
34     should always be safe).