Bug #4318

RExpression NA converts to string "nil", not value nil

Added by Oliver Soong almost 10 years ago. Updated almost 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When RExpression exports an NA value, it gets converted to the string "nil", not the actual nil value. See attached workflow.

NA-nil problem.xml (34.9 KB) NA-nil problem.xml Oliver Soong, 08/14/2009 02:57 PM
NA-nil problem 2.xml (67.6 KB) NA-nil problem 2.xml Oliver Soong, 08/14/2009 04:42 PM


#2 Updated by ben leinfelder almost 10 years ago

I've changed to use StringToken.NIL when we encounter NA objects in R.
This is still different than Token.NIL. StringToken.NIL works with the attached workflow (as I assume you want it to) whereas Token.NIL actually shows as "niltype" and so neither condition is met.
I'm leaving it as StringToken.NIL for now (it's almost a negligible change this way - but still important)

#3 Updated by Oliver Soong almost 10 years ago

Ok, now I'm just getting confused again. How many different nils are there? Is there a simple way to robustly test for them (akin to R's is.null function)? Am I just not thinking of the reason why we want different types of NA values for different types of nil values?

By way of example, an R NA -> StringToken.NIL -> R "NA". On the other hand, a Ptolemy nil -> Token.NIL (?) -> R NA. But at the same time, Ptolemy nil -> Token.NIL (?) -> Ptolemy not-nil (so nil != nil).

I'm attaching a workflow to show of some of the perverseness. Part of it is my own fault (, but I plead ignorance.

#4 Updated by Christopher Brooks almost 10 years ago

BTW - the test case should probably be checked in and run
as part of the nightly build so that this bug stays fixed.

Is there documentation about how to add test cases to the test system?

#5 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 4318

Also available in: Atom PDF