rowchooser docs

[jss, 2008-05-27 19:01:55]

http://codereview.appspot.com/1186/diff/1/2
File RowChooser.xml (right):

http://codereview.appspot.com/1186/diff/1/2#newcode3
Line 3: <summary> Gives back row from matrix at certain index </summary>
/Returns/ is the word. The index maybe /certain/, but it needs to be
/specified/.

http://codereview.appspot.com/1186/diff/1/2#newcode4
Line 4: <description> </description>
you really want to move the description of what the component actually does
(return a row vector from a 2d matrix) in here, and only specify possible matrix
layouts in the method descriptions.

http://codereview.appspot.com/1186/diff/1/2#newcode7
Line 7: 1xM matrix consisting of the values from the NxM input matrix at the row
of the specified index.
its worth noting that the type is equal to the type of the input matrix.

http://codereview.appspot.com/1186/diff/1/2#newcode10
Line 10: Matrix of any sort.
not that arbitrary.
we need to impose strict limits on its dimensionality and number of channels.

http://codereview.appspot.com/1186/diff/1/2#newcode13
Line 13: 1x1 matrix specifing the index (int).
int? nope. anything.

http://codereview.appspot.com/1186/diff/1/2#newcode16
Line 16: </component>
no, we dont reach that doc quality everywhere. but its a start :)

[jss, 2008-05-27 19:08:12]

http://codereview.appspot.com/1186/diff/1/2
File RowChooser.xml (right):

http://codereview.appspot.com/1186/diff/1/2#newcode2
Line 2: <component name="Resize" authors="cls" version="1.0">
the name :)

[cls, 2008-05-27 20:58:48]

http://codereview.appspot.com/1186/diff/1/2
File RowChooser.xml (right):

http://codereview.appspot.com/1186/diff/1/2#newcode2
Line 2: <component name="Resize" authors="cls" version="1.0">
On 2008/05/27 19:08:12, jss wrote:
> the name :)

ack

http://codereview.appspot.com/1186/diff/1/2#newcode3
Line 3: <summary> Gives back row from matrix at certain index </summary>
On 2008/05/27 19:01:56, jss wrote:
> /Returns/ is the word. The index maybe /certain/, but it needs to be
> /specified/.

ack

http://codereview.appspot.com/1186/diff/1/2#newcode4
Line 4: <description> </description>
On 2008/05/27 19:01:56, jss wrote:
> you really want to move the description of what the component actually does
> (return a row vector from a 2d matrix) in here, and only specify possible
matrix
> layouts in the method descriptions.
> 

ack - check my latest checkin... I'm not sure if it is allright by now.

http://codereview.appspot.com/1186/diff/1/2#newcode7
Line 7: 1xM matrix consisting of the values from the NxM input matrix at the row
of the specified index.
On 2008/05/27 19:01:56, jss wrote:
> its worth noting that the type is equal to the type of the input matrix.

What would that note look like, "Notice, the 1xM matrix is of the same data type
as the input matrix."?

http://codereview.appspot.com/1186/diff/1/2#newcode10
Line 10: Matrix of any sort.
On 2008/05/27 19:01:56, jss wrote:
> not that arbitrary.
> we need to impose strict limits on its dimensionality and number of channels.

What kind of limits would that be? As many columns as we have percentiles? Guess
not, as we would have to check the graph for that parameter. Instead, I guess,
we will come back to practical limits? 
When it comes to channels: We have to have only one channel, I guess. True?

http://codereview.appspot.com/1186/diff/1/2#newcode13
Line 13: 1x1 matrix specifing the index (int).
On 2008/05/27 19:01:56, jss wrote:
> int? nope. anything.

So I just write "1x1 matrix specifing the index." or am I supposed to further
explain "Matrix can convey any data type."?
Anyway, taking any data type is possible, cuz we're gonna check type inside the
component and throw some exceptions when an invalid type was passed.

http://codereview.appspot.com/1186/diff/1/2#newcode16
Line 16: </component>
On 2008/05/27 19:01:56, jss wrote:
> no, we dont reach that doc quality everywhere. but its a start :)

I was skipping through quite some components and have rarely seen such an
explicit documentation - I thought. On the one hand, it was for that reason why
had trouble finding a good heuristic for documenting, and on the other hand, got
the impression that documenting in jamf is not supposed to be that explicit.