[NMusers] Covariate modeling course in Philadelphia Oct 22-23, 2012

[Mats Karlsson]

Dear all,

 

The Uppsala Pharmacometrics Group have over the years given a number of 
intermediate and advanced courses on various topics related to population PKPD 
modeling using NONMEM. 

Now we offer a new course: covariate model building. 

The course will provide participants with knowledge to efficiently tailor 
methods to build and evaluate covariate models to different situations. The 
participants will learn about pros and cons about commonly used methods, but 
also learn about new methods* that can substantially improve the efficiency of 
covariate modeling and increase the ability to diagnose the quality of the 
resulting model. The course will be taught using NONMEM and our freeware PsN 
(psn.sf.net) and Xpose (xpose.sf.net) that allow the use of many different 
automated model building and evaluation methods. 

 

For more information please visit  
 
http://www.med.upenn.edu/kmas/Mats/Matsindex.htm.  

 

 

*Some recent advances in covariate modeling methodology by the Uppsala 
Pharmacometric Research Group

 


Authors

Title

Reference


Åsa Johansson and Mats O Karlsson

Multiple imputation of missing covariates in NONMEM and evaluation of its 
sensitivity to η-shrinkage

WCoP 2012


Vijay Ivaturi, Ron Keizer and Mats O. Karlsson

A full random effects model for characterising covariate relations

WCoP 2012


Andrew C. Hooker and Mats O. Karlsson

The Kaplan-Meier Mean Covariate plot (KMMC): a new diagnostic for covariates in 
time-to-event models.

PAGE 2012


Takayuki Katsube, Akash Khandelwal, Andrew C Hooker, E. Niclas Jonsson, Mats O 
Karlsson

Characterization of Stepwise Covariate Model Building Combined with 
Cross-Validation

PAGE 2012


Mats O Karlsson

A full model approach based on the covariance matrix of parameters and 
covariates

PAGE 2012


Khandelwal A, Harling K, Jonsson EN, Hooker AC, Karlsson MO.

A fast method for testing covariates in population PK/PD Models.

AAPS J. 2011 ;13:464-72. 


Bergstrand M, Hooker AC, Wallin JE, Karlsson MO.

Prediction-corrected visual predictive checks for diagnosing nonlinear 
mixed-effects models.

AAPS J. 2011 ;13:143-51. 


Paul G. Baverel, Radojka M. Savic, Scott F. Marshall, Mats O. Karlsson

A novel covariate search method intended for PKPD models with nonparametric 
parameter distributions

PAGE 2011


Takayuki Katsube, Akash Khandelwal, Kajsa Harling, Andrew C Hooker, Mats O 
Karlsson 

Evaluation of Stepwise Covariate Model Building Combined with Cross-Validation

PAGE 2011


Ron J Keizer, Akash Khandelwal, Andrew C Hooker, Mats O Karlsson

The bootstrap of Stepwise Covariate Modeling using linear approximations

PAGE 2011


Akash Khandelwal, Andrew C Hooker, and Mats O Karlsson

Influence of Correlated Covariates on Predictive Performance for Different 
Models

PAGE 2011


Vijay D Ivaturi, Andrew C Hooker, Mats O Karlsson

Selection Bias in Pre-Specified Covariate Models

PAGE 2011


Åsa M. Johansson, Mats O. Karlsson

Comparison of methods for handling missing covariate data

PAGE 2011


Akash Khandelwal, Kajsa Harling, E Niclas Jonsson, Andrew C Hooker, Mats O 
Karlsson

Covariate Model Building Using Linear Approximations

PAGE 2010


Savic RM, Karlsson MO.

Importance of shrinkage in empirical bayes estimates for diagnostics: problems 
and solutions.

AAPS J. 2009 ;11:558-69. 


 

 

 

 

Best regards,

Mats

 

Mats Karlsson, PhD

Professor of Pharmacometrics

 

Dept of Pharmaceutical Biosciences

Faculty of Pharmacy

Uppsala University

Box 591

75124 Uppsala

 

http://www.farmbio.uu.se/research/researchgroups/pharmacometrics/

 

Phone: +46 18 4714105

Fax + 46 18 4714003

 

RE: [NMusers] Intel vs AMD

[Bob Leary]

Even when using a non-Intel compiler  (e.g. gnu compilers) with exactly the 
same compiler options and optimization levels on AMD and Intel that generates 
exactly the same
code for both , there can be numerical differences between AMD and Intel 
processors.

We did a study [1] on Phoenix NLME results using the gnu g77 compiler  with 
different Intel processors and Windows  operating systems going back to 2002 
and up to current generation processors (i3/i5/i7) and Windows 7. We generally 
got bit for bit identical results  across every system tested when the compiler 
settings were the same.But AMD processors gave slightly different results.  
I found an AMD technical manual that indicated the probable reason - it advised 
that  the AMD 80-bit x87 math floating point unit can give slightly different 
results than the corresponding Intel FPU.
Indeed, we have found this to be the case in practice.


{1} R. Leary et al, "Exact Reproducibility of Population  PK/PD MLME Numerical 
Results across Different Computational Environments", PAGE 2011 (abstract 2042].

-Original Message-
From: owner-nmus...@globomaxnm.com [mailto:owner-nmus...@globomaxnm.com] On 
Behalf Of Nick Holford
Sent: Sunday, August 12, 2012 4:56 PM
To: nmusers
Subject: Re: [NMusers] Intel vs AMD

Mark,

I think you may not be fully appreciating the terms of the agreement when you 
say "it is generally accepted that Intel continues to impair the optimization 
on AMD CPU".Under the terms of the agreement (which you provide below) it is 
perfectly OK for Intel to optimize their compilers for Intel CPUs without 
including any optimization for AMD CPUs. 
Furthermore they are not required to provide any optimization for AMD CPus. 
Therefore, unless Intel don't know how to optimize compilers you must expect 
the Intel compiler to perform better on an Intel CPU.

This issue might (or might not) be relevant to Martin's query about 
'differences'. He does not specify the kind of difference e.g. faster? 
more accurate?. It may be possible to choose compiler options that produce 
identical numerical results on both CPUs but at the price of speed.

Rik Schoemaker suggested using these Intel compiler options /nologo /nbs /w /Gs 
/fp:strict to obtain consistent numerical results
(http://www.cognigencorp.com/nonmem/current/2011-May/3266.html) with different 
NONMEM 7 versions across different operating systems. Perhaps these options 
would ensure numerical consistency across different CPU types.

Best wishes,

Nick

On 13/08/2012 8:27 a.m., Mark Sale - Next Level Solutions wrote:
> Martin
>  Yes, the results can be different. Intel has been accused of 
> "crippling" the executable when the Intel compiler is used on AMD CPUs
> http://www.agner.org/optimize/blog/read.php?i=49
>
> by turning off all optimization - they actually pretty much admitted 
> this in the lawsuit - but explained that it was for the benefit of the 
> customer - sort of like in the 1980's when Microsoft pretty much 
> disabled WordPerfect with every new OS release.
>
> and yes, different optimization setting will give different results,
> 32 bit will also give different results from 64 bit.  Sometimes the 
> phase of the moon, or the users astrological sign makes a different as 
> well ;-) Below is from the settlement:
> Intel shall not include any Artificial Performance Impairment in any 
> Intel product or require any Third Party to include an Artificial 
> Performance Impairment in the Third Party’s product. As used in this 
> Section 2.3, “_Artificial Performance Impairment_” means an 
> affirmative engineering or design action by Intel (but not a failure 
> to act) that (i) degrades the performance or operation of a Specified 
> AMD product, (ii) is not a consequence of an Intel Product Benefit and
> (iii) is made intentionally to degrade the performance or operation of 
> a Specified AMD Product. For purposes of this Section 2.3, “_Product 
> Benefit_” shall mean any benefit, advantage, or improvement in terms 
> of performance, operation, price, cost, manufacturability, 
> reliability, compatibility, or ability to operate or enhance the 
> operation of another product.
>
> In no circumstances shall this Section 2.3 impose or be construed to 
> impose any obligation on Intel to (i) take any act that would provide 
> a Product Benefit to any AMD or other non-Intel product, either when 
> such AMD or non-Intel product is used alone or in combination with any 
> other product, (ii) optimize any products for Specified AMD Products, 
> or (iii) provide any technical information, documents, or know how to AMD.
>
>
> But, it is generally accepted that Intel continues to impair the 
> optimization on AMD CPU.
> So, to answer your question, I don't think there is any way to insure 
> consistent results between Intel and AMD CPUs.
>
> Mark
>
>
> Mark Sale MD
> President, Next Level Solutions, LLC
> www.NextLevelSolns.com 
> 919-846-9185
> A carbon-neu

RE: [NMusers] Intel vs AMD

[Mark Sale - Next Level Solutions]

Bob,  That certainly makes sense, the CPU architechs are constantly tweaking the instruction sets, even for routine things like dividing.  So, it is very unlikely that AMD and Intel both came up with exactly the same binary code for even simple math (and binary floating point instructions are always just an approximation to decimal operations).  Who can forget the Pentium 5 CPU that had a bug in the instruction set that gave a grossly wrong answer with dividing carefully selection numbers.  So, I suspect that CPU type must be added to the things that can cause NONMEM or Phoenix and Monolix to give different results, along withcompileroptimization settings32 vs 64 bit Interestingly, there can (very rarely) even be randomness in the answer.   Cosmic rays actually can hit individual bits in memory and flip them. Parity checking/error correcting code (ECC) will detect these single bit changes.  The rate is about 10−10−10−17 error/bit·h.  Most DRAM in PC is not ECC, most in servers and workstation is ECC.MarkMark Sale MDPresident, Next Level Solutions, LLCwww.NextLevelSolns.com 919-846-9185A carbon-neutral companySee our real time solar energy production at:http://enlighten.enphaseenergy.com/public/systems/aSDz2458


 Original Message 
Subject: RE: [NMusers] Intel vs AMD
From: Bob Leary 
Date: Mon, August 13, 2012 9:13 am
To: Nick Holford , nmusers


Even when using a non-Intel compiler  (e.g. gnu compilers) with exactly the same compiler options and optimization levels on AMD and Intel that generates exactly the same
code for both , there can be numerical differences between AMD and Intel processors.

We did a study [1] on Phoenix NLME results using the gnu g77 compiler  with different Intel processors and Windows  operating systems going back to 2002 and up to current generation processors (i3/i5/i7) and Windows 7. We generally got bit for bit identical results  across every system tested when the compiler settings were the same.But AMD processors gave slightly different results.  I found an AMD technical manual that indicated the probable reason - it advised that  the AMD 80-bit x87 math floating point unit can give slightly different results than the corresponding Intel FPU.
Indeed, we have found this to be the case in practice.


{1} R. Leary et al, "Exact Reproducibility of Population  PK/PD MLME Numerical Results across Different Computational Environments", PAGE 2011 (abstract 2042].

-Original Message-
From: owner-nmus...@globomaxnm.com [mailto:owner-nmus...@globomaxnm.com] On Behalf Of Nick Holford
Sent: Sunday, August 12, 2012 4:56 PM
To: nmusers
Subject: Re: [NMusers] Intel vs AMD

Mark,

I think you may not be fully appreciating the terms of the agreement when you say "it is generally accepted that Intel continues to impair the optimization on AMD CPU".Under the terms of the agreement (which you provide below) it is perfectly OK for Intel to optimize their compilers for Intel CPUs without including any optimization for AMD CPUs. 
Furthermore they are not required to provide any optimization for AMD CPus. Therefore, unless Intel don't know how to optimize compilers you must expect the Intel compiler to perform better on an Intel CPU.

This issue might (or might not) be relevant to Martin's query about 'differences'. He does not specify the kind of difference e.g. faster? 
more accurate?. It may be possible to choose compiler options that produce identical numerical results on both CPUs but at the price of speed.

Rik Schoemaker suggested using these Intel compiler options /nologo /nbs /w /Gs /fp:strict to obtain consistent numerical results
(http://www.cognigencorp.com/nonmem/current/2011-May/3266.html) with different NONMEM 7 versions across different operating systems. Perhaps these options would ensure numerical consistency across different CPU types.

Best wishes,

Nick

On 13/08/2012 8:27 a.m., Mark Sale - Next Level Solutions wrote:
> Martin
>  Yes, the results can be different. Intel has been accused of 
> "crippling" the executable when the Intel compiler is used on AMD CPUs
> http://www.agner.org/optimize/blog/read.php?i=49
>
> by turning off all optimization - they actually pretty much admitted 
> this in the lawsuit - but explained that it was for the benefit of the 
> customer - sort of like in the 1980's when Microsoft pretty much 
> disabled WordPerfect with every new OS release.
>
> and yes, different optimization setting will give different results,
> 32 bit will also give different results from 64 bit.  Sometimes the 
> phase of the moon, or the users astrological sign makes a different as 
> well ;-) Below is from the settlement:
> Intel shall not include any Artificial Performance Impairment in any 
> Intel product or require any Third Party to include an Artificial 
> Performance Impairment in the Third Party’s product. As used in this 
> Section 2.3, “_Artificial Performance Imp

Re: [NMusers] Intel vs AMD

[Martin Johnson]

Thanks for all your comments and now I understand that there could be 
always slight differences between different CPU/architecture.


However, Would it possible that there could be differences in successful 
minimizations in nonmem runs. For example, for a same model, in one 
CPU/architecture the model run is minimized successfully  with 
covariance step and in the other the run is terminated with rounding error.


I would like to say that I have not faced this problem yet. Just a 
question, to learn from your experience.


regards,
Martin

On 08/13/2012 03:13 PM, Bob Leary wrote:

Even when using a non-Intel compiler  (e.g. gnu compilers) with exactly the 
same compiler options and optimization levels on AMD and Intel that generates 
exactly the same
code for both , there can be numerical differences between AMD and Intel 
processors.

We did a study [1] on Phoenix NLME results using the gnu g77 compiler  with 
different Intel processors and Windows  operating systems going back to 2002 
and up to current generation processors (i3/i5/i7) and Windows 7. We generally 
got bit for bit identical results  across every system tested when the compiler 
settings were the same.But AMD processors gave slightly different results.  
I found an AMD technical manual that indicated the probable reason - it advised 
that  the AMD 80-bit x87 math floating point unit can give slightly different 
results than the corresponding Intel FPU.
Indeed, we have found this to be the case in practice.


{1} R. Leary et al, "Exact Reproducibility of Population  PK/PD MLME Numerical 
Results across Different Computational Environments", PAGE 2011 (abstract 2042].

-Original Message-
From: owner-nmus...@globomaxnm.com [mailto:owner-nmus...@globomaxnm.com] On 
Behalf Of Nick Holford
Sent: Sunday, August 12, 2012 4:56 PM
To: nmusers
Subject: Re: [NMusers] Intel vs AMD

Mark,

I think you may not be fully appreciating the terms of the agreement when you say 
"it is generally accepted that Intel continues to impair the optimization on AMD 
CPU".Under the terms of the agreement (which you provide below) it is perfectly OK 
for Intel to optimize their compilers for Intel CPUs without including any optimization 
for AMD CPUs.
Furthermore they are not required to provide any optimization for AMD CPus. 
Therefore, unless Intel don't know how to optimize compilers you must expect 
the Intel compiler to perform better on an Intel CPU.

This issue might (or might not) be relevant to Martin's query about 
'differences'. He does not specify the kind of difference e.g. faster?
more accurate?. It may be possible to choose compiler options that produce 
identical numerical results on both CPUs but at the price of speed.

Rik Schoemaker suggested using these Intel compiler options /nologo /nbs /w /Gs 
/fp:strict to obtain consistent numerical results
(http://www.cognigencorp.com/nonmem/current/2011-May/3266.html) with different 
NONMEM 7 versions across different operating systems. Perhaps these options 
would ensure numerical consistency across different CPU types.

Best wishes,

Nick

On 13/08/2012 8:27 a.m., Mark Sale - Next Level Solutions wrote:

Martin
  Yes, the results can be different. Intel has been accused of
"crippling" the executable when the Intel compiler is used on AMD CPUs
http://www.agner.org/optimize/blog/read.php?i=49

by turning off all optimization - they actually pretty much admitted
this in the lawsuit - but explained that it was for the benefit of the
customer - sort of like in the 1980's when Microsoft pretty much
disabled WordPerfect with every new OS release.

and yes, different optimization setting will give different results,
32 bit will also give different results from 64 bit.  Sometimes the
phase of the moon, or the users astrological sign makes a different as
well ;-) Below is from the settlement:
Intel shall not include any Artificial Performance Impairment in any
Intel product or require any Third Party to include an Artificial
Performance Impairment in the Third Party’s product. As used in this
Section 2.3, “_Artificial Performance Impairment_” means an
affirmative engineering or design action by Intel (but not a failure
to act) that (i) degrades the performance or operation of a Specified
AMD product, (ii) is not a consequence of an Intel Product Benefit and
(iii) is made intentionally to degrade the performance or operation of
a Specified AMD Product. For purposes of this Section 2.3, “_Product
Benefit_” shall mean any benefit, advantage, or improvement in terms
of performance, operation, price, cost, manufacturability,
reliability, compatibility, or ability to operate or enhance the
operation of another product.

In no circumstances shall this Section 2.3 impose or be construed to
impose any obligation on Intel to (i) take any act that would provide
a Product Benefit to any AMD or other non-Intel product, either when
such AMD or non-Intel product is used alone or in combination with any
other product, (

Re: [NMusers] Intel vs AMD

[Nick Holford]

Martin,

In my experience NONMEM internally uses a pseudo-random process to 
decide if convergence has been achieved even when the objective function 
and parameter estimates are essentially the same. As far as I know this 
has nothing to do with the compiler or CPU. So I do not pay much 
attention to NONMEM's declaration of success.


Nick

On 14/08/2012 9:00 a.m., Martin Johnson wrote:
Thanks for all your comments and now I understand that there could be 
always slight differences between different CPU/architecture.


However, Would it possible that there could be differences in 
successful minimizations in nonmem runs. For example, for a same 
model, in one CPU/architecture the model run is minimized 
successfully  with covariance step and in the other the run is 
terminated with rounding error.


I would like to say that I have not faced this problem yet. Just a 
question, to learn from your experience.


regards,
Martin

On 08/13/2012 03:13 PM, Bob Leary wrote:
Even when using a non-Intel compiler (e.g. gnu compilers) with 
exactly the same compiler options and optimization levels on AMD and 
Intel that generates exactly the same
code for both , there can be numerical differences between AMD and 
Intel processors.


We did a study [1] on Phoenix NLME results using the gnu g77 
compiler  with different Intel processors and Windows  operating 
systems going back to 2002 and up to current generation processors 
(i3/i5/i7) and Windows 7. We generally got bit for bit identical 
results  across every system tested when the compiler settings were 
the same.But AMD processors gave slightly different results.  I 
found an AMD technical manual that indicated the probable reason - it 
advised that  the AMD 80-bit x87 math floating point unit can give 
slightly different results than the corresponding Intel FPU.

Indeed, we have found this to be the case in practice.


{1} R. Leary et al, "Exact Reproducibility of Population  PK/PD MLME 
Numerical Results across Different Computational Environments", PAGE 
2011 (abstract 2042].


-Original Message-
From: owner-nmus...@globomaxnm.com 
[mailto:owner-nmus...@globomaxnm.com] On Behalf Of Nick Holford

Sent: Sunday, August 12, 2012 4:56 PM
To: nmusers
Subject: Re: [NMusers] Intel vs AMD

Mark,

I think you may not be fully appreciating the terms of the agreement 
when you say "it is generally accepted that Intel continues to impair 
the optimization on AMD CPU".Under the terms of the agreement (which 
you provide below) it is perfectly OK for Intel to optimize their 
compilers for Intel CPUs without including any optimization for AMD 
CPUs.
Furthermore they are not required to provide any optimization for AMD 
CPus. Therefore, unless Intel don't know how to optimize compilers 
you must expect the Intel compiler to perform better on an Intel CPU.


This issue might (or might not) be relevant to Martin's query about 
'differences'. He does not specify the kind of difference e.g. faster?
more accurate?. It may be possible to choose compiler options that 
produce identical numerical results on both CPUs but at the price of 
speed.


Rik Schoemaker suggested using these Intel compiler options /nologo 
/nbs /w /Gs /fp:strict to obtain consistent numerical results
(http://www.cognigencorp.com/nonmem/current/2011-May/3266.html) with 
different NONMEM 7 versions across different operating systems. 
Perhaps these options would ensure numerical consistency across 
different CPU types.


Best wishes,

Nick

On 13/08/2012 8:27 a.m., Mark Sale - Next Level Solutions wrote:

Martin
  Yes, the results can be different. Intel has been accused of
"crippling" the executable when the Intel compiler is used on AMD CPUs
http://www.agner.org/optimize/blog/read.php?i=49

by turning off all optimization - they actually pretty much admitted
this in the lawsuit - but explained that it was for the benefit of the
customer - sort of like in the 1980's when Microsoft pretty much
disabled WordPerfect with every new OS release.

and yes, different optimization setting will give different results,
32 bit will also give different results from 64 bit. Sometimes the
phase of the moon, or the users astrological sign makes a different as
well ;-) Below is from the settlement:
Intel shall not include any Artificial Performance Impairment in any
Intel product or require any Third Party to include an Artificial
Performance Impairment in the Third Party’s product. As used in this
Section 2.3, “_Artificial Performance Impairment_” means an
affirmative engineering or design action by Intel (but not a failure
to act) that (i) degrades the performance or operation of a Specified
AMD product, (ii) is not a consequence of an Intel Product Benefit and
(iii) is made intentionally to degrade the performance or operation of
a Specified AMD Product. For purposes of this Section 2.3, “_Product
Benefit_” shall mean any benefit, advantage, or improvement in terms
of performance, operation, price, cost, manufact

Re: [NMusers] Covariate modeling course in Philadelphia Oct 22-23, 2012

[Stefanie Hennig]

Hi Mats,

 To which days do we need to change PAGANZ to have this course here in
Brisbane?? :-)

/Stefanie

On Mon, Aug 13, 2012 at 10:04 PM, Mats Karlsson  wrote:

> Dear all,
>
> ** **
>
> The Uppsala Pharmacometrics Group have over the years given a number of
> intermediate and advanced courses on various topics related to population
> PKPD modeling using NONMEM. 
>
> Now we offer a new course: covariate model building. 
>
> The course will provide participants with knowledge to efficiently tailor
> methods to build and evaluate covariate models to different situations. The
> participants will learn about pros and cons about commonly used methods,
> but also learn about new methods* that can substantially improve the
> efficiency of covariate modeling and increase the ability to diagnose the
> quality of the resulting model. The course will be taught using NONMEM and
> our freeware PsN (psn.sf.net) and Xpose (xpose.sf.net) that allow the use
> of many different automated model building and evaluation methods. 
>
> ** **
>
> For more information please visit
> http://www.med.upenn.edu/kmas/Mats/Matsindex.htm.  
>
> ** **
>
> ** **
>
> *Some recent advances in covariate modeling methodology by the Uppsala
> Pharmacometric Research Group
>
> ** **
>
> *Authors*
>
> *Title*
>
> *Reference*
>
> Åsa Johansson and Mats O Karlsson
>
> Multiple imputation of missing covariates in NONMEM and evaluation of its
> sensitivity to η-shrinkage
>
> WCoP 2012
>
> Vijay Ivaturi, Ron Keizer and Mats O. Karlsson
>
> A full random effects model for characterising covariate relations
>
> WCoP 2012
>
> Andrew C. Hooker and Mats O. Karlsson
>
> The Kaplan-Meier Mean Covariate plot (KMMC): a new diagnostic for
> covariates in time-to-event models.
>
> PAGE 2012
>
> Takayuki Katsube, Akash Khandelwal, Andrew C Hooker, E. Niclas Jonsson,
> Mats O Karlsson
>
> Characterization of Stepwise Covariate Model Building Combined with
> Cross-Validation
>
> PAGE 2012
>
> Mats O Karlsson
>
> A full model approach based on the covariance matrix of parameters and
> covariates
>
> PAGE 2012
>
> Khandelwal A, Harling K, Jonsson EN, Hooker AC, Karlsson MO.
>
> A fast method for testing covariates in population PK/PD Models.
>
> AAPS J. 2011 ;13:464-72. 
>
> Bergstrand M, Hooker AC, Wallin JE, Karlsson MO.
>
> Prediction-corrected visual predictive checks for diagnosing nonlinear
> mixed-effects models.
>
> AAPS J. 2011 ;13:143-51. 
>
> Paul G. Baverel, Radojka M. Savic, Scott F. Marshall, Mats O. Karlsson
>
> A novel covariate search method intended for PKPD models with
> nonparametric parameter distributions
>
> PAGE 2011
>
> Takayuki Katsube, Akash Khandelwal, Kajsa Harling, Andrew C Hooker, Mats O
> Karlsson 
>
> Evaluation of Stepwise Covariate Model Building Combined with
> Cross-Validation
>
> PAGE 2011
>
> Ron J Keizer, Akash Khandelwal, Andrew C Hooker, Mats O Karlsson
>
> The bootstrap of Stepwise Covariate Modeling using linear approximations**
> **
>
> PAGE 2011
>
> Akash Khandelwal, Andrew C Hooker, and Mats O Karlsson
>
> Influence of Correlated Covariates on Predictive Performance for Different
> Models
>
> PAGE 2011
>
> Vijay D Ivaturi, Andrew C Hooker, Mats O Karlsson
>
> Selection Bias in Pre-Specified Covariate Models
>
> PAGE 2011
>
> Åsa M. Johansson, Mats O. Karlsson
>
> Comparison of methods for handling missing covariate data
>
> PAGE 2011
>
> Akash Khandelwal, Kajsa Harling, E Niclas Jonsson, Andrew C Hooker, Mats O
> Karlsson
>
> Covariate Model Building Using Linear Approximations
>
> PAGE 2010
>
> Savic RM, Karlsson MO.
>
> Importance of shrinkage in empirical bayes estimates for diagnostics:
> problems and solutions.
>
> AAPS J. 2009 ;11:558-69. 
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> Best regards,
>
> Mats
>
> ** **
>
> Mats Karlsson, PhD
>
> Professor of Pharmacometrics
>
> ** **
>
> Dept of Pharmaceutical Biosciences
>
> Faculty of Pharmacy
>
> Uppsala University
>
> Box 591
>
> 75124 Uppsala
>
> ** **
>
> http://www.farmbio.uu.se/research/researchgroups/pharmacometrics/
>
> ** **
>
> Phone: +46 18 4714105
>
> Fax + 46 18 4714003
>
> ** **
>



-- 
Stefanie Hennig

Division of Pharmacokinetics and Drug Therapy
Department of Pharmaceutical Biosciences
Uppsala University
Biomedicum, Box 591
Uppsala, 75124
Sweden

41 Norman St
Coorparoo, QLD 4151

Tel (home): +61-7-3397 7895
email: stefanie.hen...@farmbio.uu.se