Bug: get_halflife_points for start!=0

[Gero1999]

The function has two main weaknesses that might be relevant to address:

1. It does not consider start, using lambda.z.time.first, lambda.z.time.last directly. That only makes the calculations valid if start = 0

2. It is not interval specific. Unfortunately if we have more than one interval with a half-life calculation for the same concentration group, there is a possbility that the user unconsciously excluded part of the excretion phase for one of them, providing half-lifes calculated with different points. This needs to raise an error or warning somehow.

Additionally, because this function may have many potential uses in the future would be nice to optimize its speed as much as we can

#TODO

• get_halflife_points works for intervals with start != 0 (test: interval with start != 0)
• get_halflife_points provides a warning/error when two half-lifes from the same group use different points (test: collapsing intervals for the same conc group)

Optional

• improve fun speed
• allow as input the PKNCAdata obj as well

[billdenney]

Thanks for finding this. I have fixed start != 0 in #471.

I think that the interval-specificity is covered with this test. Are you looking for something else?

pknca/tests/testthat/test-half.life.R

Lines 389 to 404 in 409e391

	# Multiple, overlapping half-life calculations gives an error
	o_conc <- PKNCAconc(d_conc, conc~Time|Subject)
	o_data <-
	PKNCAdata(
	o_conc,
	intervals =
	data.frame(
	start = 0, end = c(24, Inf),
	half.life = TRUE
	)
	)
	o_nca <- suppressMessages(suppressWarnings(pk.nca(o_data)))
	expect_error(
	suppressMessages(get_halflife_points(o_nca)),
	regexp = "More than one half-life calculation was attempted on the following rows: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11"
	)

How would you use a PKNCAdata object? You need to know the half-life calculation results which requires NCA calculation.

I'm always happy to have speed-ups (as long as the code remains readable and is solely R, (e.g. not C, C++, Rust, etc.)).

[Gero1999]

Hey, thanks for the fix! Yes, you are right, the interval specificity is already covered.

Regarding using a PKNCAdata obj, I was thinking in just adding a method for it to 1) filter only intervals with half.life dependent parameters, 2) run pk.nca, 3) apply the current method for PKNCAresults.

Regarding the speed-up, in my head would be preventing the use of the looping and instead move to dplyr column merging and modifications. But I understand that for readability this way looks quite clean

[billdenney]

For the PKNCAdata idea, sure, please make a PR. When filtering for intervals with half-life dependent parameters, please make it so that only half-life is calculated (in other words, don't do the extra work for e.g. aucinf, CL, ...).

For speed, I'd hesitate to change in the way you're suggesting. If there's a way to make it faster in a clearly readable way, I'm open to that.