[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [sc-dev] Proposal of a new format character from engineer's/scientist's prospective



On Thu, Jan 22, 2004 at 09:15:32AM -0500, Kohei Yoshida wrote:
> Hi Niklas,
> 
> On Thu, 2004-01-22 at 04:58, Niklas Nebel wrote:
> > 
> > Somehow this is getting out of hand. For maximum flexibility, what you 
> > need is the possibility of more conditions in a number format, and an 
> > arbitrary scaling factor.
> 
> I re-read your comment.  Now I see what you mean here.  So, instead of
> totally abandoning the current scheme, your suggestion is to start from
> the current, but make it more flexible so that we are not restricted to
> the current three condition limit (separated by semi-colons) and scaling
> factor that's powers of 3.  Do I understand it correct?

Hmm, I'm not at all sure that is a good way to go.  Ignoring how we
would express arbitrary scaling that leads us towards
    [>1000]0 km;[>1]0 m;[>.01]0 cm; ....
Which is seems untenably complex to me.  Even the other proposal of
    si:k-cm
seemed prone to error.  Our goals seem to be
    a) select from a hard coded set of prefix/scale factors
    b) provide a unitstring with no semantic knowledge of what that
       unit is.
    b) provide a min/max useful unit prefix
    c) avoid using a less common prefix sometimes (dm)

[%scale_factor_set;max_prefix;min_prefix;comma seperated list of exclusions]
So your example would be
    [%si;k;m;d]
The main limitation here would be localization.  Are there any
translations that use different names for 'si' or its associated
prefixes ?  This is more general than my generic 'use si' approach,
but less powerful than your pre-prefix selection.

PS
    There is a limit of 3 conditions within a format string ?
    That's silly.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]