[kepler-dev] Token.toString method(s)

Christopher Brooks cxh at eecs.berkeley.edu
Sun Feb 26 18:11:11 PST 2006


I just checked in changes to DoubleMatrixToken and MatrixToken
that should do the trick.  I ended up using a Set, and I don't allocate
it unless there is a nil token.  We are definitely introducing overhead
in a few places, but I tried to be smart about it.

We should probably review this code asap, perhaps Tuesday.
Maybe some of the Keplerites would like to call in? We would
review 1-2pm on Tuesday.  I'd probably review
Token, DoubleToken, ArrayToken, MatrixToken and DoubleMatrixToken
We'd review just the methods that involve nil.
If there is sufficient interest, I could set up a conference call.

_Christopher
----- Original Message ----- 
From: "Edward A. Lee" <eal at EECS.Berkeley.EDU>
To: "Christopher Brooks" <cxh at eecs.berkeley.edu>
Cc: "Mladen Vouk" <vouk at ncsu.edu>; <Kepler-dev at ecoinformatics.org>
Sent: Sunday, February 26, 2006 10:54 AM
Subject: Re: [kepler-dev] Token.toString method(s)


> At 01:07 AM 2/26/2006, Christopher Brooks wrote:
>>One issue here is that it would be nice if when we
>>have a DoubleMatrix that has a nil value, then if
>>we print it out and then read it back in with an
>>ExpressionReader, then we get the same matrix with
>>a nil value.  This points to printing nil as nil
>>not NaN.  So, we will need to keep a list of which
>>elements are nil. We probably want something fast,
>>like an ArrayList here, which as roughly O(n) time for
>>adds,  The ArrayList docs say:
> 
> 
> I hope this can be done in a way that doesn't
> introduce overhead when nil is not in use (the
> common case).  The intent of matrix tokens (vs.
> array tokens) is to maximize efficiency of numerical
> operations...
> 
> 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  
> 
>


More information about the Kepler-dev mailing list