antlists at youngman.org.uk
Wed Jan 13 10:47:08 PST 2016
On 13/01/16 18:33, Rick C. Hodgin wrote:
> On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists <antlists at youngman.org.uk
> <mailto:antlists at 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
> > 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.
No no no - I get that.
> 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
If the the value is .1234 then yes it is 123,400 micro-units. But to
DISPLAY it as 123,400 micro-units (unless the user has explicitly asked
for it) is wrong. THAT is what I'm getting at.
> 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.
Sorry, that formula applies to the DISPLAY format. So if my convention
is FALSE, I can NOT display 0.1234 as "0.1234 units" because the
DISPLAYED truncated mantissa is 0. I have to coerce the DISPLAY to 123.4
milli-units, because the truncated mantissa is now 123 and that's okay.
> 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
> 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
That's good. But bear in mind national conventions. We're using a dot to
indicate a decimal point, and we use either commas or spaces to indicate
thousand separators. Bear in mind, however, that some cultures (many
European) use the dot as a thousand separator and a comma as the decimal
point. So that needs to be configurable too.
> 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
Hope that clears it up.
More information about the LibreOffice