On Wed, Jan 13, 2016 at 1:47 PM, Wols Lists <antli...@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 <antli...@youngman.org.uk > > <mailto:antli...@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
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
