[Python-ideas] real numbers with SI scale factors: next steps

[Steven D'Aprano]

On Tue, Aug 30, 2016 at 09:08:01PM -0700, Ken Kundert wrote:
> > What's the mnemonic here? Why "r" for scale factor?
> 
> My thinking was that r stands for real like f stands for float.

Hmmm. Do you know many mathematicians who use SI prefixes when talking 
about real numbers? I don't think "real number" is relevant to SI 
prefixes.


> With the base 2 scale factors, b stands for binary.

Well, obviously :-)


> > (1) Why no support for choosing a particular scale? If this only auto-scales, 
> > I'm not interested.
> 
> Auto-scaling is kind of the point. There is really little need for a special 
> mechanism if your going to specify the scale factor yourself.

The point is not to have to repeat yourself. If I have to scale numbers 
in lots of places, I don't want to have to re-write the same code in 
each of them. I want to call a function.

Understand that I'm not against auto-scaling. I think it is a good idea. 
But I strongly disagree that it is the *only* way to do this. If there's 
code in the std lib to format numbers to some scale, I should be able to 
loop through a bunch of numbers and format them all in a consistent unit 
if I so choose, without having to do my own formatting.

Its not that I don't want you to be able to auto-scale. I just want the 
choice of being able to use a consistent scale or not.

[...]
> If you wanted to force the second number to be in km, you use a %f format and 
> scale the argument:
> 
>     >>> print('Attenuation = {:.1f} dB at {:.1f} km.'.format(-13.7, 50e3/1e3))
>     Attenuation = -13.7 dB at 50 km.

*shrug* Well, you could do exactly the same thing. You only need a short 
function that determines the scale you want, and then scale it yourself. 
The point of making this a standard function is so that we don't have to 
keep re-writing the same code.


> > (2) Support for full prefix names, so we can format (say) "kilograms" as well 
> > as "kg"?
> 
> This assumes that somehow this code can access the units so that it can switch 
> between long form 'grams' and short form 'g'. That is a huge expansion in the 
> complexity for what seems like a small benefit.

No, I'm talking about chosing between "M" or "mega". The actual unit 
itself is up to the caller to supply.

You have definitely prodded my interest in the output side of this. I'm 
rather busy at the moment, but in the coming weeks I think I'll brush 
the cobwebs off byteformat and see what can be done.

https://pypi.python.org/pypi/byteformat

in case you want to have a play with it.


-- 
Steve