RE: Use of ACCEPT in $DATA
Hi Dennis,
Unfortunately, my reply will not provide a solution to your problem. It is more
about drawing attention to the fact that checking conditions numerically is not
exactly the same as checking conditions on a piece of a paper, because of
rounding. I’m sure that the users of the List are well aware of this fact, just
a reminder…
A simple example, I did this in Matlab, you can repeat it in R or other
programming language. I won’t waste your time by describing how I came to this
example. Compare the output of two expressions:
>> a1=0.06;
>> a2=0.05 + 0.01;
You would expect the equality between the two values, a1 and a2, right? True,
on paper. Here is the output of these two values with 20 decimals.
>> fprintf('%22.20f\n',a1)
0.05999999999999999800
>> fprintf('%22.20f\n',a2)
0.06000000000000000500
And, of course, the output of the logical expression (a1 ==a2) is FALSE.
Regards,
Sergei Leonov
ICON Innovation Center
Quoted reply history
From: [email protected] [mailto:[email protected]] On
Behalf Of Bill Denney
Sent: Thursday, August 24, 2017 6:45 PM
To: Dennis Fisher; [email protected]
Subject: RE: [NMusers] Use of ACCEPT in $DATA
Hi Dennis,
I don’t have an elegant solution for you (and I’ve been pining for the use of
combined Boolean operations like “TIME.GT.5.9.AND.TIME.LT.6.1” for a long time).
An inelegant solution could be to run the model once with a write statement to
see if you can identify the value like 6.0000001 and use it. That would
probably be fragile to different processor/compiler/math library combinations,
so I’d probably end up making the additional indicator column for certainty.
Thanks,
Bill
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On
Behalf Of Dennis Fisher
Sent: Thursday, August 24, 2017 6:16 PM
To: [email protected]<mailto:[email protected]>
Subject: [NMusers] Use of ACCEPT in $DATA
NONMEM 7.4.1
Colleagues
I am trying to use the ACCEPT option in $DATA in order to select a subset of
records (to evaluate the impact of the # of samples/subject on confidence
intervals).
I used the following code:
ACCEPT=(TIME=0, TIME=1, TIME=2, TIME=4, TIME=6, TIME=24)
NMTRAN then creates a dataset but — to my surprise — TIME=6 is not in the
dataset (all the others are).
I am copying the first few rows of the input dataset so that you can see what
is being provided to NMTRAN:
ID,AGE,MONTHS,SEX,WT,AMT,RATE,TIME,EVID,MDV,REPLICATE,IPRED,CWRES,DV,PRED,RES,WRES
1101,12,144,1,30.054,210.38,841.51,0,1,1,1,0,0,0,0,0,0
1101,12,144,1,30.054,0,0,1,0,0,1,187.42,0,179.28,199.26,-19.979,0
1101,12,144,1,30.054,0,0,2,0,0,1,180.92,0,187.92,194.09,-6.1659,0
1101,12,144,1,30.054,0,0,4,0,0,1,169.84,0,177.66,184.37,-6.712,0
1101,12,144,1,30.054,0,0,6,0,0,1,160.61,0,153.43,175.39,-21.96,0
The underlined / boldfaced value (6) in the final row is the problem.
I assume that NMTRAN is reading that value as something other than 6.0 (e.g.,
6.000001) and thereby omitting it.
I have reviewed NMHELP to see if there is some other way to accomplish this.
Ideally, there would be something like:
TIME.GT.5.9.AND.TIME.LT.6.1
but that does not appear to be supported.
The alternative is to modify the dataset to include many possible MDV/EVID
columns. However, it would be more elegant to do this in the control stream.
Or, if there is some way to find out the exact value that NMTRAN sees, I could
specify that value.
Any help would be appreciated.
Dennis
Dennis Fisher MD
P < (The "P Less Than" Company)
Phone / Fax: 1-866-PLessThan (1-866-753-7784)
http://www.plessthan.com/