Re: Suggestion

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

> On 13/01/16 18:33, Rick C. Hodgin wrote:
> > On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists <antlists@youngman.org.uk
> > <mailto: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.
>
> 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
> > point.
> 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.

The user would've explicitly asked for it by changing the cell formatting
to "Metric" instead of the default "Number," right?


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

Of course. :-)  I assume at some point in the code there's a dp =
obj->getCurrencySeparator(_DECIMAL_POINT); and a cp =
obj->GetCurrencySeparator(_THOUSANDS_PLACE); or some equivalent. :-)

FWIW, I've been working on a follow-on to Visual FoxPro since it went
defunct in 2009.  I've been working on it as my exclusive project since
2012.  You can see where I have something similar here:

If you search for "_INDEX_SET_MARK" on this page you'll see the comma
symbol, and you'll find similar references (_INDEX_SET_CURRENCY for the $
symbol, _INDEX_SET_POINT for the decimal point) -- they're all near the
bottom, beginning around line 5,649 as of the time of this writing:

https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/objects/accessors.h


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

Hope so. :-)


> Cheers,
> Wol
Best regards,
Rick C. Hodgin