Post #8 is the version of this I will quote in future. One addition. Do the arithmetic by hand the first few times, whatever tool you use afterwards. A calculator with a wrong input gives a confident wrong answer and there is nothing in the interface to tell you. That is what the documentation says. What happens in…
Feature request: should a dose-equivalence tool exist at all? I have a specific reason for asking rather than idle curiosity, and the context is below.
Reading back through what has been written here about Feature request, three questions come up every time and only one has ever been answered properly.
Listing all three, with what I think the state of the answer is for each, so the thread can start further along than the last one did.
The question underneath Feature request is usually "how would I tell?" rather than "what is true?", and that one has a method attached to it.
Write down what you would expect to see under each hypothesis before you collect anything. If they predict the same observation, collecting it will not help.
Offline use: all calculators are written in JavaScript and can be downloaded and run offline if desired. They do not require internet connectivity to function.
The confident version of this sentence would be wrong, so here is the hedged one.
The opening post answers the question as asked. The question underneath it is different.
Units: all calculators explicitly require units to be stated. This prevents the decimal-point errors that come from forgetting units. Always verify units in and out.
Worth separating two things that the opening post runs together.
My experience of Feature request contradicts the reply above. I am posting it as a data point rather than as a refutation, because one person's experience is exactly that.
This is the sort of exchange that makes the archive worth searching.
Checking a tool against a worked example you already trust is five minutes well spent, and it is the only validation available to a user.
I am not the right person to answer the follow-up to this.
If a tool asks for a value you do not have, the honest response is to find the value rather than to estimate it. Estimated inputs propagate silently.
The reasoning is more useful than the number, which is why I have shown it.
Post #8 is the version of this I will quote in future. One addition.
Do the arithmetic by hand the first few times, whatever tool you use afterwards. A calculator with a wrong input gives a confident wrong answer and there is nothing in the interface to tell you.
That is what the documentation says. What happens in practice is usually close.
A tool that refuses to give an answer when the result falls below one graduation is doing something useful. Most just print the number.
I have seen it go both ways, which is why I hedge.
Dose-equivalence calculators between compounds should be treated with real suspicion, because equivalence between these compounds has not been established in the way the tool implies.
Understood. Thank you for being specific about the limits of it.
Unit-conversion tools are only as good as the assumption they make about the syringe. Ask what barrel and what graduation interval it assumed before trusting the units figure.
I keep a log of this specifically because memory is unreliable about it.
Post #18 is the version of this I will quote in future. One addition.
I would be cautious about generalising from the Feature request example above. It is a good example. It is one example.
A titration planner is a scheduling aid rather than a clinical recommendation, and any tool that presents one as the other is overstepping.
What I want from this Feature request thread is the list of things that would need to be true for the claim to hold. If we can write that list, we can check it.
Narrowing post #21, because the general version has more than one answer.
Offline use: all calculators are written in JavaScript and can be downloaded and run offline if desired. They do not require internet connectivity to function.
Not the answer, but possibly the question that gets there.
Post #21 and I disagree about the size of the effect, not about the direction.
Practical answer on Feature request, since the theoretical one is upthread: do the simplest check first, write down the result, and only then decide whether the complicated explanation is needed. It usually is not.
Genuine question rather than a rhetorical one: has anyone here actually observed Feature request, as opposed to read about it? The thread is long and I cannot tell.
Worth separating two things that post #25 runs together.
Precision and significant figures: the calculators do not round to match your input precision. If you input values to one decimal place, the output might have more. Use significant figures appropriate to your input precision.
The evidence for this is thinner than the way I have phrased it suggests.
This follows post #29 rather than contradicting it.
Units: all calculators explicitly require units to be stated. This prevents the decimal-point errors that come from forgetting units. Always verify units in and out.
On reflection I would soften that slightly.