[seek-kr] Re: [seek-dev] data typing in ptolemy

[Rich Williams]

Hi Chad et al -

I'm in a meeting Mon and Tues, and so wouldn't be available until Weds for a
call.  However I suspect you can work this out without me.

I replied to Chad, rather than reply to all (oops), so what I sent yesterday
is below.  I've gotta run now and get on a plane, but I'll try and read
other comments along the way and add my two cents worth.

Rich

----------------------------------------------------------------------------
-----------

Hey Chad

Here are some comments on the thorny problem you posed.

On the issue of missing values:  Sending nothing does not seem like an
option - as Chad's examples make clear, I think you have to send a signal
that indicates that a value is missing.  That means the question becomes how
to send that signal.  I think that encoding 'missing' as a specific allowed
value is a dangerous idea.  I suspect that dealing with floating point
numbers can be worked out fairly easily, as there are probably bits
available to create an encoding in a NaN value to indicate that it is a
missing value.  Simply using NaN when data is missing seem preferable to
encoding 'missing' as a specific allowed value.  Hopefully existing code
would deal correctly with receiving NaN values.  In your example, a plotter
receiving a (validNumber, NaN) should have sane behavior, like doing nothing
with that pair.

Similarly, any data type where the range of allowed values is smaller than
the range of possible values that can be represented in the memory allocated
for the variable can be dealt with by sending an 'out of range' value and
making sure the actor that receives the data is checking that the incoming
data is valid and looking for encoded 'missing' values.

This leaves data for which there are no unused encodings available, which
includes most of the existing ptolemy types.  Then I don't see how to deal
with missing values, as any combination of bits could be a valid value, and
I can't see how to signal that a value is missing.

Given this, isn't it simply a requirement of the existing type system and
actors that the data have no missing values?  If you use encoded missing
values, I don't see how you can guarantee the functioning of existing actors
and types, except perhaps in the case of using a NaN encoding in floating
point numbers to indicate 'missing'.

Taking all this into account and looking at the problem from a class
hierarchy standpoint, it's not clear to me that subclassing the existing
ptolemy types is the correct approach.  An actor that functions correctly
with an 'extended' tokens (for example one that can use tokens that have a
missing value encoding) will also be able to function with tokens that have
no missing value encoding and never have missing values.  Conversely, an
actor that requires all values to be present should only function with the
current tokens, not the extended tokens.  This suggests that ExtendedToken
is a base class for StandardToken rather than vice versa.  In the case of
numeric types, a 16 bit signed integer that ranges from -32768 to 32767 (or
whatever...) is a special case of a 16 bit signed integer with a specified
range of values.  (It just so happens that its range of values fills the
whole domain of possible values.)  It looks like you need to insert a class
ExtendedIntToken between ScalarToken and IntToken, but that's not a very
helpful suggestion...

On the other hand, semantic typing seems orthogonal to these issues, and I
see no reason why an actor with no ability to process semantic types
shouldn't use data that includes a semantic type, as long as they are
syntactically type compatible.

Finally, a question about the Ptolemy type structure.  Why is it that the
token classes are arranged hierarchically but the type classes are flat?  I
would thing that the ScalarType would have two subclasses of
IntegerType(abstract) and DoubleType, and IntegerType would be subclassed
with (IntType, LongType), or something like that.

Rich