Wols Lists antlists at
Wed Jan 13 10:24:50 PST 2016

On 13/01/16 17:37, Rick C. Hodgin wrote:
> Wol, I don't understand your objection.  You have seen the spreadsheet I
> created which demonstrates the various behaviors.  Which one of them is
> incorrect?

Sorry, I haven't seen the spreadsheet ...
> The whole purpose of the Metric add-on is to auto-range by default, but
> to allow a user to explicitly set a range.  I know in semiconductors,
> for example, that I'll be working in nanoseconds or picoseconds.  As
> such, I want all of my cells to be in those ranges, so I will set that
> option.  I want to see things from that base, while maintaining the real
> number in memory.
> This is what Metric would do.  It would maintain the real value in
> memory, and then display it adjusted for the appropriate metric base.
> You'll have to give me an example of what you're talking about because
> right now I don't understand.  Remember also that every cell can have
> its own settings, so it would be inappropriate to not have auto-ranging
> values when surrounding values nearby might be in completely different
> bases.  It is more appropriate to have auto-ranging values by default,
> and then to have an explicitly-set range when required (such as always
> displaying nanoseconds, or picoseconds, so that everything is then in
> the common form for easy comparison).

Okay, copying your example that I've just found ...

> The important part of the Metric feature is that it always wraps the
value to the
> nearest power of 3, and shows values in those powers.  0.1234 would be
> as 123.4 milliunits, or 1,234 microunits,

Correction:  should be 123,400 microunits.

If the user does NOT EXPLICITLY choose units, milli-units, or
micro-units then BOTH of the first two examples are CORRECT and the last
one is wrong.

That is, if the user has not told you, how do you choose between 0.1234
units, or 123.4 milli-units. The correct answer is you cannot. At
school, I would have been expected to use 123.4 milli-units. Other
people would have said "hey, it's 0.1234 units".

But if the user hasn't said anything, then 123,400 micro-units is wrong
by all standards :-)

Basically, what I am saying is that if the user does not explicitly
specify what units they are asking for, then the following equation MUST
be true ...


(Whether the constant is TRUE or FALSE is a matter of convention. This
should presumably be a spreadsheet-wide setting.)

Put otherwise, if I present you with three numbers, 123, 12.3 and 1.23
you can either leave them ALL alone, or convert them ALL to 0.123e3,
0.0123e3 and 0.00123e3. What you mustn't do is convert some of them.

Likewise, if you're given 12.3, 1.23, and 0.123 you then MUST convert
SOME of them, to 12.3, 1.23, and 123e-3, OR to 0.0123e3, 0.00123e3, and

(Here's hoping I've got my exponents right :-)

> Best regards,
> Rick C. Hodgin
> On Wed, Jan 13, 2016 at 11:49 AM, Wols Lists <antlists at
> <mailto:antlists at>> wrote:
>     On 12/01/16 21:11, Rick C. Hodgin wrote:
>     > The values won't round.
>     You misunderstand me. They shouldn't round.
>     And based on what the user has selected, they
>     > will display to the nearest power of 3 (10^(k*3)), or in an explicit
>     > form.  The default option will be to auto-range the values into their
>     > metric named range.
>     That's the point. THIS BEHAVIOUR IS WRONG. You should NOT range to the
>     *nearest* power of three, you should range to the *most* *appropriate*
>     power of three.
>     Let's say I have two numbers, 1.234^x and 0.1234^x. One is less than 1,
>     one is greater than 1. Forget the exponent x, the point is you should
>     NEVER mix mantissae like that. It's not that one is wrong and the other
>     is right, it's that consistency is important, some people insist on one,
>     others insist on the other.
>     If the user explicitly says they want nano-units, then give them
>     nano-units, fine. But if you're auto-ranging it, you should NEVER mix
>     mantissae - you can force it to 0.001234^(x+3) and 0.1234^x, or you can
>     force it to 1.234^x and 123.4^(x-3).
>     You can see - the mantissae are BOTH greater than 1, or BOTH less than
>     1. Some situations demand the first, some situations demand the second.
>     I think at school in Physics I always used the second - the mantissa had
>     to be greater than 1. I've been in situations where people insisted it
>     had to be less than 1.
>     (You see the same argument when using "Exponential Notation" - is the
>     integer part of your mantissa ALWAYS zero eg 0.1234^x, or NEVER zero eg
>     1.234^x).
>     Cheers,
>     Wol
>     >
>     > Here are some examples:
>     >
>     >
>     > Best regards,
>     > Rick C. Hodgin
>     >
>     >
>     > On Tue, Jan 12, 2016 at 2:55 PM, Anthonys Lists
>     > <antlists at <mailto:antlists at>
>     <mailto:antlists at <mailto:antlists at>>>
>     wrote:
>     >
>     >     On 12/01/2016 13:22, Rick C. Hodgin wrote:
>     >
>     >         The important part of the Metric feature is that it always wraps
>     >         the value to the nearest power of 3, and shows values in those
>     >         powers.  0.1234 would be shown as 123.4 milliunits, or 1,234
>     >         microunits, for example (however the user has set it up), and
>     >         not as "0.1234 u" (unless they are explicitly stating to use
>     >         "Units", which would be something they'd have to do manually).
>     >
>     >
>     >     I'm not sure of the name, but the user might not want it to be in
>     >     whole units. Note that 0.1234 is a power of 3, and the user might
>     >     want it to be *0*.1234 UNITS.
>     >
>     >     So yes, I like the idea of displaying it to a power of three, but it
>     >     needs a switch to say "greater than one or less than 1?", so that
>     >     0.012 units might stay 0.012 units, or might become 12 milliunits.
>     >
>     >     imho rounding to the *nearest* power of 3 is a mistake - users
>     >     invariably want either greater, or less, than one, but NEVER a mix
>     >     of both.
>     >
>     >     Cheers,
>     >     Wol
>     >
>     >     _______________________________________________
>     >     LibreOffice mailing list
>     >     LibreOffice at
>     <mailto:LibreOffice at>
>     >     <mailto:LibreOffice at
>     <mailto:LibreOffice at>>
>     >
>     >
>     >

More information about the LibreOffice mailing list