[kepler-dev] Token.toString method(s)
cxh at eecs.berkeley.edu
Sun Feb 26 01:07:29 PST 2006
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:
> The size, isEmpty, get, set, iterator, and listIterator
> operations run in constant time. The add operation runs in
> amortized constant time, that is, adding n elements requires O(n) time.
> All of the other operations run in linear time (roughly speaking).
> The constant factor is low compared to that for the LinkedList implementation.
Also, I hacked up LongToken and StringToken to handle
----- Original Message -----
From: Mladen Vouk
To: Edward A. Lee
Cc: Christopher Brooks ; Kepler-dev at ecoinformatics.org
Sent: Saturday, February 25, 2006 1:11 PM
Subject: Re: [kepler-dev] Token.toString method(s)
NaN should remain NaN to be compliant with
standards. I am not sure that it is ok to represent
nil as NaN either.
Good point - NaN is a legitimate result. With a simple Double token you
can tell whether toString should return nil from the isNil() method.
With a DoubleMatrix, we should probably print 'NaN' unless we can keep a
'shadow list' that could distinguish between 'nil' settings and NaN
Edward A. Lee wrote:
At 03:27 PM 2/24/2006, Christopher Brooks wrote:
I started looking at DoubleMatrixToken, but one issue is that
the underlying data type is a Java double, so I'd have to
keep a shadow list of nil tokens to make toString() print
nil instead of NaN. Right now, it is possible to create
a DoubleMatrix with [1.0, 2.0 ; 3.0,nil], but this is printed as
[1.0, 2.0; 3.0, NaN].
I don't think we should print NaN as nil...
The problem is that a DoubleMatrixToken might be a result
of some numerical calculation, and NaN is a legitimate result.
I think it's fine to represent nil as NaN, but I think it should
still print as NaN.
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
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kepler-dev