<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 1:24 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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> </span>Sorry, I haven't seen the spreadsheet ...<br> <span class="">><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> </span>Okay, copying your example that I've just found ...<br> <span class=""><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> </span><span class="">Correction: should be 123,400 microunits.<br> <br> </span>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></blockquote><div><br></div><div>It's relative to the actual value, Wol. A value of 1 is one unit. A value of .1 is 100 milliunits.<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (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></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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></blockquote><div><br></div><div>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.<br><br></div><div>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<br><br></div><div>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.<br><br></div><div>Best regards,<br></div><div>Rick C. Hodgin<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (Here's hoping I've got my exponents right :-)<br> <br> Cheers,<br> Wol<br> <span class="">><br> > Best regards,<br> > Rick C. Hodgin<br> ><br> ><br> > On Wed, Jan 13, 2016 at 11:49 AM, 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 12/01/16 21:11, Rick C. Hodgin wrote:<br> > > The values won't round.<br> ><br> > You misunderstand me. They shouldn't round.<br> ><br> > And based on what the user has selected, they<br> > > will display to the nearest power of 3 (10^(k*3)), or in an explicit<br> > > form. The default option will be to auto-range the values into their<br> > > metric named range.<br> ><br> > That's the point. THIS BEHAVIOUR IS WRONG. You should NOT range to the<br> > *nearest* power of three, you should range to the *most* *appropriate*<br> > power of three.<br> ><br> > Let's say I have two numbers, 1.234^x and 0.1234^x. One is less than 1,<br> > one is greater than 1. Forget the exponent x, the point is you should<br> > NEVER mix mantissae like that. It's not that one is wrong and the other<br> > is right, it's that consistency is important, some people insist on one,<br> > others insist on the other.<br> ><br> > If the user explicitly says they want nano-units, then give them<br> > nano-units, fine. But if you're auto-ranging it, you should NEVER mix<br> > mantissae - you can force it to 0.001234^(x+3) and 0.1234^x, or you can<br> > force it to 1.234^x and 123.4^(x-3).<br> ><br> > You can see - the mantissae are BOTH greater than 1, or BOTH less than<br> > 1. Some situations demand the first, some situations demand the second.<br> > I think at school in Physics I always used the second - the mantissa had<br> > to be greater than 1. I've been in situations where people insisted it<br> > had to be less than 1.<br> ><br> > (You see the same argument when using "Exponential Notation" - is the<br> > integer part of your mantissa ALWAYS zero eg 0.1234^x, or NEVER zero eg<br> > 1.234^x).<br> ><br> > Cheers,<br> > Wol<br> > ><br> > > Here are some examples:<br> > > <a href="http://www.libsf.org/misc/libreoffice_metric_example.ods" rel="noreferrer" target="_blank">http://www.libsf.org/misc/libreoffice_metric_example.ods</a><br> > ><br> > > Best regards,<br> > > Rick C. Hodgin<br> > ><br> > ><br> > > On Tue, Jan 12, 2016 at 2:55 PM, Anthonys Lists<br> > > <<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a> <mailto:<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a>><br> </div></div>> <mailto:<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a> <mailto:<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a>>>><br> <span class="">> wrote:<br> > ><br> > > On 12/01/2016 13:22, Rick C. Hodgin wrote:<br> > ><br> > > The important part of the Metric feature is that it always wraps<br> > > the value to the nearest power of 3, and shows values in those<br> > > powers. 0.1234 would be shown as 123.4 milliunits, or 1,234<br> > > microunits, for example (however the user has set it up), and<br> > > not as "0.1234 u" (unless they are explicitly stating to use<br> > > "Units", which would be something they'd have to do manually).<br> > ><br> > ><br> > > I'm not sure of the name, but the user might not want it to be in<br> > > whole units. Note that 0.1234 is a power of 3, and the user might<br> > > want it to be *0*.1234 UNITS.<br> > ><br> > > So yes, I like the idea of displaying it to a power of three, but it<br> > > needs a switch to say "greater than one or less than 1?", so that<br> > > 0.012 units might stay 0.012 units, or might become 12 milliunits.<br> > ><br> > > imho rounding to the *nearest* power of 3 is a mistake - users<br> > > invariably want either greater, or less, than one, but NEVER a mix<br> > > of both.<br> > ><br> > > Cheers,<br> > > Wol<br> > ><br> > > _______________________________________________<br> > > LibreOffice mailing list<br> > > <a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br> > <mailto:<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a>><br> </span>> > <mailto:<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br> > <mailto:<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a>>><br> > > <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br> > ><br> > ><br> ><br> ><br> <br> </blockquote></div><br></div></div>