Export fields so that client code can customize $ output.

[c-blake]

This lets one do, for example, a simple script wrapper:

#!/bin/sh
: "${NR:=nim r}" # alias a='noglob THIS' => a (4.65+-0.01)*(4.650+-0.009) works
: "${NO:=--verbosity:0 --hints:off --warnings:off}"
(printf '%s\n' \
  'import measuremancer, std/[math, lenientops], cligen/strUt' \
  'converter f(x: SomeInteger): float = x.float' \
  'proc `^`[A, B](x: A, y: B): float = exp(x.float.ln * y.float)' \
  'proc `+-`[T: FloatLike](val,uncer: T): Measurement[T] = val ± uncer' \
  'proc `$`[T: FloatLike](m: Measurement[T]): string =' \
  '  result = fmtUncertain(m.val.float, m.uncer.float)' \
  '  when T isnot float: result.add " " & $T'
 printf '%s' 'echo ' "$@" ) | $NR $NO -

that then uses the uncertainty-driven precision formatting engine of cligen/strUt.fmtUncertain.

[Vindaar]

Thanks!

If you wish we can gladly add those helpers directly as well!
I even have some uncommitted code here with some -d:useCligen check that then uses fmtUncertain. I never committed it, because I wasn't sure about the details. So if you have a good idea on how we could handle that (e.g. do we want a compile time option? Default to it if cligen available, ...) we can even directly use it for the formatting as well.

[c-blake]

I agree using fmtUncertain is a more complete/principled approach to what is there now in terms of precision since the uncertainty informs as to the appropriate precision.

As to how to do that, it depends if you want cligen/strUt as A) a hard dependency in .nimble, B) a client code-directed -d:useCligen dependency, or C) an automatic "filesystem/installation"-directed one via when (compiles do: import cligen/strUt): ...

If you read that linked Forum thread, Araq's advice would be to just suck it up and have the hard dependency. I'm fine with anything, including just exporting the fields to let the user do their own $ as this PR does (or else writing accessors and letting the user import Measuremancer {.all.}).

[Vindaar]

Given that we currently manage without any external dependencies, maybe it's worthwhile to go with a client side selection for now? We can document the availability of it in the README and user's can simply put -d:useCligen into their nim.cfg.

Going from there to a hard dependency in the future shouldn't cause any problems if we decide to do it after all.

[c-blake]

FWIW, I do that client-directed thing in my adix/mvstat for the very same fmtUncertain* facility.

Also, the nimble guy Status has is trying to add conditional dependencies to nimble. So, it might (or might not!) in the near future be a short hop (or no hop) from -d:useCligen to nimble install --use:cligen Measuremancer or something similar.

So, ok. I'll back off on my minimally invasive idea and just do a PR to do that, then, including the README update.

[c-blake]

Well, in light of the fact that in spite of all the changes I just pushed a user might still want to customize their output, I think you should still export the two fields of the original PR. ( I guess I could have done a feature branch for this, but I don't intend to add any other features.. famous last words, I know! )

If you don't like something, feel free to merge and then hack away at it. I tested this with both nim-1.6.12 and nim-2/devel only.

[c-blake]

Beats me if literally anyone besides you & I will / do use this, but in case they do and they question "2 significant digits of uncertainty" as the driver for decimal place co-rounding of value & uncertainty, I added a citation: c-blake/cligen@ea40880 So, I thought I should maybe cross-ref that commit here. ISO itself charges hundreds of USD/euros for its documents (sigh) but BIPM seems to give them away. I think they're either the same thing or at least the same "GUM" (Guide To Uncertainty of Measurement) ultimate advice, but I'm not willing to pay $$ to find out. 😁

I toyed with the idea of a whole $LC_UNCERTAIN fancy format that let "ultimate end"-users select 1.234(56) style or ± style and how many digits and even how far from unity the exponent needs to be to switch to exponential notation. I fear a general syntax might be rather over-complex, though. "Ultimate end"-use control could also be some per-table-column bespoke syntax, but that would be out of band (client code would just call procs directly). And at the other extreme, env.var people might prefer just numbered formats 1..9 or something which I think Matlab does for various things. Anyway, something along those lines may someday still happen and if it does, fmtUncertain which is what I use here should probably be the omnibus entry point as it's the most "plain sounding" proc name. So, this code here should not need to change.

[c-blake]

Any remaining feedback on this PR or reasons to not merge?

[Vindaar]

Thanks a lot and sorry for the delay!