[kepler-dev] NIL token

Tristan King tristan.king at jcu.edu.au
Mon Apr 3 23:04:11 PDT 2006 

Hi Christoper,

I understand the need for the nil token now, thanks for clearing that up.

I take it you're still in the middle of getting the ArrayToken nils to 
work? I just want to check to make sure I'm not doing something wrong or 
there's a bug.

I am still getting a conversion error when trying to send a 0 element array.

ptolemy.kernel.util.IllegalActionException: Run-time type checking 
failed. Token {} with type {nil} is incompatible with port type: 
{unsignedByte}
   in .<Unnamed Object>.Binary File Reader (dart).output
	at ptolemy.actor.TypedIOPort._checkType(TypedIOPort.java:741)
	at ptolemy.actor.TypedIOPort.send(TypedIOPort.java:463)
	at org.dart.BinaryFileReader.fire(BinaryFileReader.java:117)
	at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:309)
	at 
ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
	at ptolemy.actor.CompositeActor.fire(CompositeActor.java:331)
	at ptolemy.actor.Manager.iterate(Manager.java:613)
	at ptolemy.actor.Manager.execute(Manager.java:322)
	at ptolemy.actor.Manager.run(Manager.java:987)
	at ptolemy.actor.Manager$3.run(Manager.java:1028)

the port is assigned a type via the following code:
output.setTypeEquals(new ArrayType(BaseType.UNSIGNED_BYTE));

Thanks
--Tristan

Christopher Brooks wrote:
> Hi Tristan,
> I think I have most of the implementation of an empty array working.
> 
> I agree that having new StringToken(null) create an empty string is
> probably wrong.  We could change it, but I'm not sure if it would buy
> us much, and it might break things.
> 
> The way I'm thinking of the nil token is that it represents missing
> data that could have any value.  Certain operations work on nil
> values, for example any value added to a nil returns a nil.  However,
> operations like average should return regular numeric data, even if
> one or more elements of the average are nil.  However, we do get
> increased uncertainty in the average, and we don't have any way
> of showing that.
> 
> I took on the nil token task because it was at the top of the bug list
> for Kepler and it seemed like it needed to be implemented by someone
> who would make changes to the Ptolemy tree.  I somewhat understand why
> we need to represent missing data, but I make no claims as to
> whether this is the right implementation.  I'm sure that some people
> wish Java had better support for missing data.
> 
> The relationship between nil and null is subtle.
> 
> Anyway, thanks for your comments, I may have more to say later.
> 
> _Christopher
> 
> 
> 
> --------
> 
>     Ok this is a bit of a rant, and since i probably don't know even 5% of 
>     the internal workings of ptolemy/kepler i may be misguided in a lot of 
>     this rant so please correct me anywhere i need correction :).
>     
>     Maybe we need to take a step back and look at what a Token actually is, 
>     and what we're actually trying to achieve from a nil token. From the 
>     javadoc in the Token class a Token is simply a container for standard 
>     java objects and native types.
>     
>     So, What are we trying to achieve with a nil token? There must be a very 
>     good rationale to why we need such a mechanism, but i can't for the life 
>     of me figure out what it is. Are we trying to signify the lack of a 
>     variable, or a variable that has a null value?
>     
>     If we are talking about the lack of a variable, i.e an empty container 
>     then for one, I think nil is the wrong syntax for this.
>     
>     Now, should an empty container be allowed? Sure. But only for use as a 
>     trigger (i.e. the EventToken). I don't think it should be used to 
>     signify the lack of a value which may or may not exist.
>     
>     If we are trying to say the value in the container is null. It just 
>     doesn't make sense.
>     
>     If we look at the native types like ints doubles booleans etc, they 
>     cannot be null. They either exist, or they don't. So if the expression 
>     "int i = null;" is invalid in java, how can we say "IntToken i = 
>     Token.NIL;" (or IntToken.NIL)? I think forcing a specific condition to 
>     be handled as null can limit the programmer. Especially if they need to 
>     use the value Integer.MAX_VALUE and not have other actors view it as null.
>     
>     So what about Objects that can be assigned to null?
>     
>     What's wrong with something like:
>     Object o = null;
>     ObjectToken ot = new ObjectToken(o);
>     
>     or
>     Object[] o = null;
>     ArrayToken at = new ArrayToken(o);
>     
>     Sure, the null values stored in the Tokens may cause exceptions, but i 
>     think those exceptions should be handled by the programmer rather than 
>     avoided. I don't see why the container itself needs to know anything 
>     about the object it contains (except for the type).
>     
>     I feel the current direction is moving more away from the Tokens being 
>     transport containers to actually being the variables themselves.
>     
>     For example the StringToken container converts Strings which are null to 
>       Strings which have a value "". This doesn't fit with the definition of 
>     a container. It's not just transporting the objects, it's manipulating 
>     them as well. There is a very distinct difference between a String set 
>     to null and "", this conversion adds ambiguity to the String object.
>     
>     Another example is the ArrayToken container. When the Token is thought 
>     of as just being a container for arrays it makes no sense that empty 
>     arrays cannot be contained inside. Any array that is valid in java 
>     should be containable inside the token.
>     
>     As with my problem, I'm not trying to alert the other actors of the lack 
>     of a token, I want to send them an array that has no values. In java 
>     there is a distinct difference between: "Object[] o = null;" and 
>     "Object[] o = Object[0];". The ArrayToken container should just 
>     transport my array object and not be concerned about how long it is etc.
>     
>     What about the type of the array? maybe it should be specified by the 
>     programmer (the same way that ports have to be set), rather than being 
>     interpreted from the elements in the array, and have the base class as 
>     BaseType.OBJECT incase no type is specifically assigned. i've not put a 
>     lot of thought into this just yet, i'm sure i'll be doing a lot over the 
>     weekend :)
>     
>     In conclusion, 1. Scrap the nil token idea, and think more of how you 
>     would represent the missing values in a normal java program, and how you 
>     could contain that representation in a Token. And 2. the ArrayToken (and 
>     possibly some of the other tokens) need to be reworked so they act more 
>     like containers.
>     
>     Anyone else have any thoughts (anything to add, or critisisms) about the 
>     things i've brought up?
>     
>     --Tristan
>     
>     Edward A. Lee wrote:
>     > At 11:53 PM 3/29/2006, Christopher Brooks wrote:
>     >> I just checked in some changes so that some of the Tokens have their 
>     >> own NIL
>     >> token. Token.NIL, DoubleToken.NIL, IntToken.NIL, LongToken.NIL and all
>     >> of these NILs are of a new type, "NilType".  NilType is losslessly
>     >> convertible to (from?) DoubleType, IntType, LongType etc.
>     >>
>     >> I think we need these Token specific NILs so that the convert()
>     >> method will work.
>     > 
>     > This looks like the right solution to me...
>     > 
>     > An awkwardness is that every token class has to have a NIL
>     > and an appropriate convert method, but this awkwardness is
>     > only visible to token class developers.
>     > 
>     > I think that having an empty array be ArrayToken.NIL
>     > might be a very good solution too... We could then augment
>     > the expression language so that the string "{}" returns
>     > an instance of this.  It's element type is NilType.
>     > Since this is losslessly convertible to every type
>     > (including ArrayToken, by the way), then I think it should
>     > just work!
>     > 
>     > Amazing...  There may be a type system paper in this...
>     > 
>     > Edward
>     > 
>     > 
>     > 
>     > ------------
>     > Edward A. Lee
>     > Professor, Chair of the EE Division, Associate Chair of EECS
>     > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
>     > phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>     > eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal 
>     > 
>     
>     -- 
>     Tristan King                            | Ph: (07) 4781 6911
>     DART project team                       | Email: Tristan.King at jcu.edu.au
>     James Cook University                   | Web: http://dart.edu.au
>     Townsville QLD 4814                     | http://plone.jcu.edu.au/dart/
>     Australia                               |
> --------
> 

-- 
Tristan King                            | Ph: (07) 4781 6911
DART project team                       | Email: Tristan.King at jcu.edu.au
James Cook University                   | Web: http://dart.edu.au
Townsville QLD 4814                     | http://plone.jcu.edu.au/dart/
Australia                               |

More information about the Kepler-dev mailing list