Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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
shown
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 ...

( TRUNCATE( MANTISSA) == 0 ) IS CONSTANT

(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
0.123.

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

Cheers,
Wol

Best regards,
Rick C. Hodgin


On Wed, Jan 13, 2016 at 11:49 AM, Wols Lists <antlists@youngman.org.uk
<mailto:antlists@youngman.org.uk>> 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:
    > http://www.libsf.org/misc/libreoffice_metric_example.ods
    >
    > Best regards,
    > Rick C. Hodgin
    >
    >
    > On Tue, Jan 12, 2016 at 2:55 PM, Anthonys Lists
    > <antlists@youngman.org.uk <mailto:antlists@youngman.org.uk>
    <mailto:antlists@youngman.org.uk <mailto:antlists@youngman.org.uk>>>
    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@lists.freedesktop.org
    <mailto:LibreOffice@lists.freedesktop.org>
    >     <mailto:LibreOffice@lists.freedesktop.org
    <mailto:LibreOffice@lists.freedesktop.org>>
    >     http://lists.freedesktop.org/mailman/listinfo/libreoffice
    >
    >




Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.