<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 1:47 PM, Wols Lists <span dir="ltr"><<a href="mailto:antlists@youngman.org.uk" target="_blank">antlists@youngman.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 13/01/16 18:33, Rick C. Hodgin wrote:<br>
><br>
><br>
> On Wed, Jan 13, 2016 at 1:24 PM, Wols Lists <<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a>>> wrote:<br>
><br>
>     On 13/01/16 17:37, Rick C. Hodgin wrote:<br>
>     > Wol, I don't understand your objection.  You have seen the spreadsheet I<br>
>     > created which demonstrates the various behaviors.  Which one of them is<br>
>     > incorrect?<br>
><br>
>     Sorry, I haven't seen the spreadsheet ...<br>
>     ><br>
>     > The whole purpose of the Metric add-on is to auto-range by default, but<br>
>     > to allow a user to explicitly set a range.  I know in semiconductors,<br>
>     > for example, that I'll be working in nanoseconds or picoseconds.  As<br>
>     > such, I want all of my cells to be in those ranges, so I will set that<br>
>     > option.  I want to see things from that base, while maintaining the real<br>
>     > number in memory.<br>
>     ><br>
>     > This is what Metric would do.  It would maintain the real value in<br>
>     > memory, and then display it adjusted for the appropriate metric base.<br>
>     ><br>
>     > You'll have to give me an example of what you're talking about because<br>
>     > right now I don't understand.  Remember also that every cell can have<br>
>     > its own settings, so it would be inappropriate to not have auto-ranging<br>
>     > values when surrounding values nearby might be in completely different<br>
>     > bases.  It is more appropriate to have auto-ranging values by default,<br>
>     > and then to have an explicitly-set range when required (such as always<br>
>     > displaying nanoseconds, or picoseconds, so that everything is then in<br>
>     > the common form for easy comparison).<br>
><br>
>     Okay, copying your example that I've just found ...<br>
><br>
>     > The important part of the Metric feature is that it always wraps the<br>
>     value to the<br>
>     > nearest power of 3, and shows values in those powers.  0.1234 would be<br>
>     shown<br>
>     > as 123.4 milliunits, or 1,234 microunits,<br>
><br>
>     Correction:  should be 123,400 microunits.<br>
><br>
>     If the user does NOT EXPLICITLY choose units, milli-units, or<br>
>     micro-units then BOTH of the first two examples are CORRECT and the last<br>
>     one is wrong.<br>
><br>
><br>
> It's relative to the actual value, Wol.  A value of 1 is one unit.  A<br>
> value of .1 is 100 milliunits.<br>
<br>
</div></div>No no no - I get that.<br>
<span class="">><br>
> To address your need, however, it could be an add-in for a bias,<br>
> indicating that the value specified is already in nanounts, and<br>
> therefore it adjusts accordingly.<br>
><br>
><br>
><br>
>     That is, if the user has not told you, how do you choose between 0.1234<br>
>     units, or 123.4 milli-units. The correct answer is you cannot. At<br>
>     school, I would have been expected to use 123.4 milli-units. Other<br>
>     people would have said "hey, it's 0.1234 units".<br>
><br>
>     But if the user hasn't said anything, then 123,400 micro-units is wrong<br>
>     by all standards :-)<br>
><br>
><br>
> No.  If the value is .1234 then it is 123,400 micro-units because you<br>
> assume that 1.0 is in units.  But, as you indicate, it could be altered<br>
> so that there could be a bias to indicate the 1.0 value begins at some<br>
> point.<br>
><br>
</span>If the the value is .1234 then yes it is 123,400 micro-units. But to<br>
DISPLAY it as 123,400 micro-units (unless the user has explicitly asked<br>
for it) is wrong. THAT is what I'm getting at.<br></blockquote><div><br></div><div>The user would've explicitly asked for it by changing the cell formatting to "Metric" instead of the default "Number," right?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">><br>
>     Basically, what I am saying is that if the user does not explicitly<br>
>     specify what units they are asking for, then the following equation MUST<br>
>     be true ...<br>
><br>
>     ( TRUNCATE( MANTISSA) == 0 ) IS CONSTANT<br>
><br>
><br>
> I don't understand what you mean here.  I understand what a mantissa is,<br>
> but to truncate the mantissa means you are using the implicit-1 value,<br>
> which makes the binary fraction 1.000..., resulting in a value of 1.0 in<br>
> base-10.  This results in a single unit-value, which is what the current<br>
> Metric definition and example states, and would provide for.<br>
><br>
><br>
>     (Whether the constant is TRUE or FALSE is a matter of convention. This<br>
>     should presumably be a spreadsheet-wide setting.)<br>
><br>
>     Put otherwise, if I present you with three numbers, 123, 12.3 and 1.23<br>
>     you can either leave them ALL alone, or convert them ALL to 0.123e3,<br>
>     0.0123e3 and 0.00123e3. What you mustn't do is convert some of them.<br>
><br>
><br>
> I agree.  In the case of Metric, none of them would be converted except<br>
> for display.  It would indicate 123 units, 12.3 units, 1.23 units.  They<br>
> would remain unaltered internally.<br>
><br>
</span>Sorry, that formula applies to the DISPLAY format. So if my convention<br>
is FALSE, I can NOT display 0.1234 as "0.1234 units" because the<br>
DISPLAYED truncated mantissa is 0. I have to coerce the DISPLAY to 123.4<br>
milli-units, because the truncated mantissa is now 123 and that's okay.<br>
<span class="">><br>
>     Likewise, if you're given 12.3, 1.23, and 0.123 you then MUST convert<br>
>     SOME of them, to 12.3, 1.23, and 123e-3, OR to 0.0123e3, 0.00123e3, and<br>
>     0.123.<br>
><br>
><br>
> In this case, it would be 12.3 units, 1.23 units, 123 milliunits.  The<br>
> purpose of Metric, by default, is to auto-range the values so you are<br>
> not looking at lengthy decimals with leading 0s, or lengthy values with<br>
> trailing 0s before the decimal point.  You get it into the appropriate<br>
> metric range, and view it there.  However, should you want to look at<br>
> everything in terms of millivolts, for example, then you can set that,<br>
> and then the values shown will all be relative to 0.001 being 1<br>
> millivolt.  And, based on what you've said above, a bias could be added<br>
> so that the base units is given already in milli-units, so that 1.0<br>
> would actually be 1 millivolt, but that would be additional information<br>
> beyond my original proposal, but still acceptable.<br>
><br>
> I have one other suggestion I'd like to add after this one, and it is to<br>
> include commas in the decimal component, so that a large value with a<br>
> large value would result in:  1,234,567,890.098,754,432,1<br>
<br>
</span>That's good. But bear in mind national conventions. We're using a dot to<br>
indicate a decimal point, and we use either commas or spaces to indicate<br>
thousand separators. Bear in mind, however, that some cultures (many<br>
European) use the dot as a thousand separator and a comma as the decimal<br>
point. So that needs to be configurable too.<br></blockquote><div><br></div><div>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. :-)<br><br></div><div>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:<br><br></div><div>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:<br><br><a href="https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/objects/accessors.h">https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/objects/accessors.h</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">> In this way, the ability to break out the Metric portions within the<br>
> fraction would be visible, and easily identifiable.  But, I may be<br>
> content to simply create that patch and post it online for anyone who<br>
> wants it, rather than feeding it back upstream to the mainline build.<br>
><br>
> Best regards,<br>
> Rick C. Hodgin<br>
><br>
</span>Hope that clears it up.<br></blockquote><div><br></div><div>Hope so. :-)<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Cheers,<br>
Wol<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">Best regards,<br></div><div class="gmail_extra">Rick C. Hodgin<br><br></div></div>