Re: Suggestion

On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists <antlists@youngman.org.uk>
wrote:

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

It's relative to the actual value, Wol.  A value of 1 is one unit.  A value
of .1 is 100 milliunits.

To address your need, however, it could be an add-in for a bias, indicating
that the value specified is already in nanounts, and therefore it adjusts
accordingly.


> 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 :-)

No.  If the value is .1234 then it is 123,400 micro-units because you
assume that 1.0 is in units.  But, as you indicate, it could be altered so
that there could be a bias to indicate the 1.0 value begins at some point.


> 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

I don't understand what you mean here.  I understand what a mantissa is,
but to truncate the mantissa means you are using the implicit-1 value,
which makes the binary fraction 1.000..., resulting in a value of 1.0 in
base-10.  This results in a single unit-value, which is what the current
Metric definition and example states, and would provide for.


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

I agree.  In the case of Metric, none of them would be converted except for
display.  It would indicate 123 units, 12.3 units, 1.23 units.  They would
remain unaltered internally.


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

In this case, it would be 12.3 units, 1.23 units, 123 milliunits.  The
purpose of Metric, by default, is to auto-range the values so you are not
looking at lengthy decimals with leading 0s, or lengthy values with
trailing 0s before the decimal point.  You get it into the appropriate
metric range, and view it there.  However, should you want to look at
everything in terms of millivolts, for example, then you can set that, and
then the values shown will all be relative to 0.001 being 1 millivolt.
And, based on what you've said above, a bias could be added so that the
base units is given already in milli-units, so that 1.0 would actually be 1
millivolt, but that would be additional information beyond my original
proposal, but still acceptable.

I have one other suggestion I'd like to add after this one, and it is to
include commas in the decimal component, so that a large value with a large
value would result in:  1,234,567,890.098,754,432,1

In this way, the ability to break out the Metric portions within the
fraction would be visible, and easily identifiable.  But, I may be content
to simply create that patch and post it online for anyone who wants it,
rather than feeding it back upstream to the mainline build.

Best regards,
Rick C. Hodgin



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