On 9/10/2009 5:28:07 PM, rijackson wrote:
>On 9/10/2009 5:01:04 PM, philipoakley
>wrote:
>
>>What is wrong is the need to manually
>>manage the
>>linkage between the location in the data
>>array and
>>an ancillary vector holding the unit
>>based sample
>>locations.
>
>As opposed to what? Manually managing
>the linkage between the location in the
>data array and an ancillary range
>variable holding the unit based sample
>locations?
Yes. I.e. as opposed to such manual error prone and labour intensive methods of maintaining an ancillary vector of index values.
>
>>I think you misread/misunderstood what I
>>had tried
>>to say.
>
>Maybe.
>
>> It is using the regular A[i
>>where i is a
>>range variable for iteration across a
>>data set I
>>meant. Thus both A[0.3s and A[i with
>>i:0s,0.1s;1.9s would be acceptable, as
>>ways of
>>accessing the data.
>
>You can't access a vector using 0.1s.
>It's not an index.
Oh yes you can. You are (in this case) thinking as a mathematician based on current mathcad implementation. I can easily look up the temperature at (hh:mm:ss) 3:45:21.3 from a data logger - that indexes directly into the data table as required, and can/should return the vaklue with units attached, just as the user has no need to know if the logger was set to 10Hz, 20Hz, or 1000Hz. the indexed location has the same 'unit'ed time code.
A range variable is the implicit method such data is created with when analytic values are prepared. e.g. creating a sine wave of temperature variation over time.
>Or are you proposing
>that if I use 0.1s Mathcad works out
>it's the second value in the sequence,
>and then sets the index to 1? How does
>it know which range variable to use
>unless you tell it? If you have to tell
>it the name of the range variable and
>the value, how is that fundamentally any
>better than using match with your times
>held in a vector?
>
>The part that is fundamentally better
>I think this comes back to the same
>argument we have had before. In fact it
>illustrates my (and others) point.
>People get into trouble when they use
>range variables for anything other than
>indexing and maybe setting the ranges
>for graphing.
The reason they get into trouble is that the intuitive expectations are not implemented.
And there are two faults with the implementation. You are concentrating on the other one.
a) Indexing is only allowed via integer values, fractions and reals are not allowed...
b) Indexing is not allowed via units (e.g. value at 3.ft) Such indexing currently has no concept of the users data sampling points in the unit space.
[c] also, confounding array indexing issues, range definition issues, and their unteraction/usage ! 😉
These become confounded when users attempt to access at say location 0.25 (no units, because they haven't used units before... [excel, c, matlab, basic...]).
The key to distinguishing case (a) from (b) is the presence of a unit[dimension] flag, whether an SI dimension or a mathcad extension [currency, angle, userUnit1, userUnit2...]
>More often than not that's
>because they think they should behave
>like vectors, but they are not vectors.
>Even if you changed this particular
>behavior so that it worked like it was a
>vector, they will still behave
>differently in other ways.
>
>If you use range variables only for
>indexing, and vectors for everything
>else, what you want to do works just
>fine right now (using match).
>
>Richard
Stuart has a point about properly introducing the 'sequence' concept, which includes the representation for ranges [often it is the representation that is at issue, not the implementation - see Tom's comments].
There should be no problems for a user to have her/his data ('y-axis) automatically associated with the corresponding sampling meta-data ('x-axis') and be processed directly using that meta-dat based indexing, rather than implementation and storage based indexing.
Philip Oakley
