Suggestion

[Rick C. Hodgin]

On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin <rick.c.hodgin at gmail.com>
wrote:

>
>
> On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <erack at redhat.com> wrote:
>
>> Hi Rick,
>>
>> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
>>
>> > The category is called *"Metric."*
>> >
>> > When conveying fractional values, such that 1.2345E-08 (which is
>> > 0.000,000,012,345), it would do so in a metric-relative way using the
>> > standard milli (10^-3), micro (10^-6), nano (10^-9), pico (10^-12), and
>> so
>> > on...
>> >
>> > In the example, the *Metric* display would cause the value to show up
>> > as "*12,345
>> > pu*" (pico-units) if the thousands separator was used.
>>
>> Could you give some examples what you think how the format code actually
>> should look like?
>>
> Eike, I never heard back from you after my reply.
>
> The format would be "Metric" with "Metric:seconds" given for a specific
> override for the units name.  And there are a few other options that I
> would like to append including a bias that the data may already be in, such
> as kilo-units ("Metric[:seconds][:bias=kilo]") and an override base to use,
> such as always displaying in milli-units
> ("Metric[:seconds][:bias=kilo][affix:milli]").
>

Please forgive my dyslexia.  It should be:
Metric[:seconds][:bias=kilo][:affix=milli]

Each of the [] portions are optional, and would actually appear in a form
like this:

Metric:seconds:bias=kilo:affix=milli

This would mean units will be:  teraseconds, gigaseconds, megaseconds,
kiloseconds, seconds, milliseconds, microseconds, nanoseconds, picoseconds
And the units in each cell are already sitting in kilosecond values.
And we are to base everything in milliseconds, meaning a value of 1.0 in
the cell, is biased to be actually 1 kilosecond, which is 1,000 seconds,
which is then translated to milliseconds, to reveal the display value of
one million milliseconds, as in:

1 kilosecond = 1,000 seconds = 1,000,000 milliseconds

Make sense/


> In this way the base is always there:  "Metric"
> Based on options, additional values are tagged on with colons:
> :unitName
> :bias=[tera,giga,mega,kilo,milli,micro,nano,pico]
> :affix=[tera,giga,mega,kilo,milli,micro,nano,pico]
>
> Is this acceptable?  Am I ready to begin coding? :-)
>
>
>> > There would be an
>> > option to override the default "u" character in use, changing it into
>> > something that may have significance for the cell, such as "s" or
>> "seconds"
>> > for seconds, "m" or "meters" for meters, and so on.
>>
>> So, the unit itself would be a cell property, which replaces the generic
>> "u"?
>>
>> That sounds related to the feature branch Markus already mentioned.
>>
>> > An ability to lock in a working range would also exist, such as *"show
>> > everything in nano-units"* so that everything is adjusted to that
>> base.  In
>> > such a case, the above example above would present as "*12.345 nu*"
>> instead
>> > of in its default *pu*.
>>
>> Where/how should that "lock-in" happen? By applying a different number
>> format to that range?
>>
>>
>> One main problem with inventing new format code features is, that they
>> don't survive an Excel roundtrip unless Excel has the same feature.
>> I guess it doesn't.
>>
>>   Eike
>>
>> --
>> LibreOffice Calc developer. Number formatter stricken i18n
>> transpositionizer.
>> GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563
>> 2D3A
>> Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
>> Care about Free Software, support the FSFE
>> https://fsfe.org/support/?erack
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20160125/d9e754f3/attachment.html>