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

[Ken Kundert]

All,
Armed with all of your requirements, suggestions and good ideas, I believe 
I am ready to try to put something together.

Thank you all, and once again let me apologize for 'all the drama'.
I'll let you know when I have something.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Wed, Aug 31, 2016 at 8:57 PM, Stephen J. Turnbull
 wrote:
> Random832 writes:
>
>  > Also, interesting quirk - it always rounds up. 1025 bytes is "1.1K", and
>  > in SI mode, 1001 bytes is "1.1k"
>
> That seems to be right approach: in system administration, these
> numbers are used mostly to understand resource usage, and
> underestimates are almost never what you want, while quite large
> overestimates are tolerable, and are typically limited because the
> actual precision of calculations is much higher than that of the
> "human-readable" output.

That would seem to apply to "space used" but not to "space available".

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

On 08/31/2016 01:07 PM, MRAB wrote:
> On 2016-08-31 17:19, Guido van Rossum wrote:
>> On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan  wrote:
>>> "h" would be a decent choice - it's not only a continuation of the
>>> e/f/g pattern, it's also very commonly used as a command line flag for
>>> "human-readable output" in system utilities that print numbers.
>>
>> I like it. So after all the drama we're just talking about adding an
>> 'h' format code that's like 'g' but uses SI scale factors instead of
>> exponents. I guess we need to debate what it should do if the value is
>> way out of range of the SI scale system -- what's it going to do when
>> I pass it 1e50? I propose that it should fall back to 'g' style then,
>> but use "engineering" style where exponents are always a multiple of
>> 3.)

Would you also want h to work with integers?

>>> The existing "alternate form" marker in string formatting could be
>>> used to request the use of the base 2 scaling prefixes rather than the
>>> base 10 ones: "#h".
>>
>> Not sure about this one.
>>

'#' already has a meaning for float's 'g' format:

>>> format(1.0, 'g')
'1'
>>> format(1.0, '#g')
'1.0'

So I think you'd want to pick another type character to mean base 2
scaling, or another character other than #. But it gets cryptic pretty
quickly.

You could indeed use type == 'b' for floats to mean base 2 scaling,
since it has no current meaning, but I'm not sure that's a great idea
because 'b' means binary for integers, and if you want to also be able
to scale ints (see above), then there's a conflict. Maybe type == 'z'?

Or, use something like '@' (or whatever) instead of '#' to mean "the
other alternate form", base 2 scaling.

> Does the 'type' have to be a single character?

As a practical matter, yes, it should just be a single character. You
could make a special case for 'h' and 'hb', but I would not recommend
that. Explaining it in the documentation would be confusing.

Eric.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

On Wed, Aug 31, 2016, at 13:43, Random832 wrote:
> And the actual -h behavior of those system utilities you mentioned is
> "123k", "1.2M", "12M", with the effect being that the value always fits
> within a four-character field width, but this isn't a fixed number of
> decimal places *or* significant digits.

I just did some testing... it can go to five characters when binary
prefixes are used for e.g. "1023K".

Also, interesting quirk - it always rounds up. 1025 bytes is "1.1K", and
in SI mode, 1001 bytes is "1.1k"
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

On Wed, Aug 31, 2016, at 12:19, Guido van Rossum wrote:
> On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan  wrote:
> > "h" would be a decent choice - it's not only a continuation of the
> > e/f/g pattern, it's also very commonly used as a command line flag for
> > "human-readable output" in system utilities that print numbers.
> 
> I like it. So after all the drama we're just talking about adding an
> 'h' format code that's like 'g' but uses SI scale factors instead of
> exponents. I guess we need to debate what it should do if the value is
> way out of range of the SI scale system -- what's it going to do when
> I pass it 1e50? I propose that it should fall back to 'g' style then,
> but use "engineering" style where exponents are always a multiple of
> 3.)

One thing to consider is that this is very likely to be used with a unit
(e.g. "%hA" intending to display in amperes), so maybe it should put a
space after it? Though really people are probably going to want "1 A" vs
"1 kA" in that case, rather than "1 A" vs "1kA".

Also, maybe consider that "1*10^50" [or, slightly less so, 1.0*10**50]
is more human-readable than "1e+50". Er, with engineering style it'd be
100e+48 etc, but same basic issue.

Also, is it really necessary to use single-character codes not shared
with any other language? The only rationale here seems to be a desire to
support everything in % and its limited grammar rather than requiring
anyone to use format. If this feature is only supported in format a more
verbose description of the desired format could be used. What if, for
example, you want engineering style without SI scale factors?

What should the "precision" field mean? %f takes a number of places
after the decimal point whereas %e/%g takes a number of significant
digits. Engineering or SI-scale-factor format suggests a third
possibility: number of decimal places to be shown after the displayed
decimal point, e.g. "%.1h" % 1.2345 * 10 ** x for x in range(10): "1.2",
"12.3", "123.5", "1.2k", "12.3k", "123.5k", "1.2M", "12.3M", "123.5M".

And the actual -h behavior of those system utilities you mentioned is
"123k", "1.2M", "12M", with the effect being that the value always fits
within a four-character field width, but this isn't a fixed number of
decimal places *or* significant digits.

> > The existing "alternate form" marker in string formatting could be
> > used to request the use of the base 2 scaling prefixes rather than the
> > base 10 ones: "#h".

If base 2 scaling prefixes are used, should "engineering style" mean
2**[multiple of 10] instead of 10**[multiple of 3]?

> Not sure about this one.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nikolaus Rath]

On Aug 29 2016, Ken Kundert 
 wrote:
> Nikolaus,
> I have belatedly realized that this kind of hyperbole is counter 
> productive.
> So let me back away from that statement and instead try to understand your
> reasons for not liking the proposal.
>
> Do you think there is no value to be able to naturally read and write numbers
> with SI scale factors from Python? Or is your issue with something about my
> proposal?

* I think there is no value gained by being able to write 32.3m instead
  of 32.3e6. I think the second one is clear to everyone who uses SI
  prefixes, while the first one just introduces a lot of
  complexities. Most of them have been mentioned already:

  - no deducible ordering if one doesn't know the prefixes
  - potential for ambiguity with Exa
  - question about base 2 vs base 10, e.g what do you expect to be
stored in *size* if you reed this:
"size = 10M # we need that many bytes" 
  - rather abitrary naming ("M" and "m" vs "T" and "p").

* I think having SI *Unit* support "32.3 kN" would be nice, but only if
  there is a space between number and unit, and only if the unit
  actually get's attached to the number. But your proposal would 
  result in 1km + 1µN == 2 being true.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2016-08-31 17:19, Guido van Rossum wrote:

On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan  wrote:

On 31 August 2016 at 17:07, Chris Angelico  wrote:

On Wed, Aug 31, 2016 at 2:08 PM, 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.
With the base 2 scale factors, b stands for binary.


"Real" has historically often been a synonym for "float", and it
doesn't really say that it'll be shown in engineering notation. But
then, we currently have format codes 'e', 'f', and 'g', and I don't
think there's much logic there beyond "exponential", "floating-point",
and... "general format"? I think that's a back-formation, frankly, and
'g' was used simply because it comes nicely after 'e' and 'f'. (C's
decision, not Python's, fwiw.) I'll stick with 'r' for now, but it
could just as easily become 'h' to avoid confusion with %r for repr.


"h" would be a decent choice - it's not only a continuation of the
e/f/g pattern, it's also very commonly used as a command line flag for
"human-readable output" in system utilities that print numbers.


I like it. So after all the drama we're just talking about adding an
'h' format code that's like 'g' but uses SI scale factors instead of
exponents. I guess we need to debate what it should do if the value is
way out of range of the SI scale system -- what's it going to do when
I pass it 1e50? I propose that it should fall back to 'g' style then,
but use "engineering" style where exponents are always a multiple of
3.)


The existing "alternate form" marker in string formatting could be
used to request the use of the base 2 scaling prefixes rather than the
base 10 ones: "#h".


Not sure about this one.


Does the 'type' have to be a single character?

If not, how about 'hb' for binary scaling?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2016-08-31 05:08, 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.
With the base 2 scale factors, b stands for binary.


'b' already means binary:

>>> '{:b}'.format(100)
'1100100'

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan  wrote:
> On 31 August 2016 at 17:07, Chris Angelico  wrote:
>> On Wed, Aug 31, 2016 at 2:08 PM, 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.
>>> With the base 2 scale factors, b stands for binary.
>>
>> "Real" has historically often been a synonym for "float", and it
>> doesn't really say that it'll be shown in engineering notation. But
>> then, we currently have format codes 'e', 'f', and 'g', and I don't
>> think there's much logic there beyond "exponential", "floating-point",
>> and... "general format"? I think that's a back-formation, frankly, and
>> 'g' was used simply because it comes nicely after 'e' and 'f'. (C's
>> decision, not Python's, fwiw.) I'll stick with 'r' for now, but it
>> could just as easily become 'h' to avoid confusion with %r for repr.
>
> "h" would be a decent choice - it's not only a continuation of the
> e/f/g pattern, it's also very commonly used as a command line flag for
> "human-readable output" in system utilities that print numbers.

I like it. So after all the drama we're just talking about adding an
'h' format code that's like 'g' but uses SI scale factors instead of
exponents. I guess we need to debate what it should do if the value is
way out of range of the SI scale system -- what's it going to do when
I pass it 1e50? I propose that it should fall back to 'g' style then,
but use "engineering" style where exponents are always a multiple of
3.)

> The existing "alternate form" marker in string formatting could be
> used to request the use of the base 2 scaling prefixes rather than the
> base 10 ones: "#h".

Not sure about this one.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Erik Bray]

On Tue, Aug 30, 2016 at 5:48 AM, Ken Kundert
 wrote:
> Erik,
> One aspect of astropy.units that differs significantly from what I am
> proposing is that with astropy.units a user would explicitly specify the scale
> factor along with the units, and that scale factor would not change even if 
> the
> value became very large or very small. For example:
>
> >>> from astropy import units as u
> >>> d_andromeda = 7.8e5 * u.parsec
> >>> print(d_andromeda)
> 78.0 pc
>
> >>> d_sun = 93e6*u.imperial.mile
> >>> print(d_sun.to(u.parsec))
> 4.850441695494146e-06 pc
>
> >>> print(d_andromeda.to(u.kpc))
> 780.0 kpc
>
> >>> print(d_sun.to(u.kpc))
> 4.850441695494146e-09 kpc
>
> I can see where this can be helpful at times, but it kind of goes against the
> spirit of SI scale factors, were you are generally expected to 'normalize' the
> scale factor (use the scale factor that results in the digits presented before
> the decimal point falling between 1 and 999). So I would expected
>
> d_andromeda = 780 kpc
> d_sun = 4.8504 upc
>
> Is the normalization available astropy.units and I just did not find it?
> Is there some reason not to provide the normalization?
>
> It seems to me that pre-specifying the scale factor might be preferred if one 
> is
> generating data for a table and all the magnitude of the values are known in
> advance to within 2-3 orders of magnitude.
>
> It also seems to me that if these assumptions were not true, then normalizing
> the scale factors would generally be preferred.
>
> Do you believe that?

Hi Ken,

I see what you're getting at, and that's a good idea.  There's also
nothing in the current implementation preventing it, and I think I'll
even suggest this to Astropy (with proper attribution)!  I think there
are reasons not to always do this, but it's a nice option to have.

Point being nothing about this particular feature requires special
support from the language, unless I'm missing something obvious.  And
given that Astropy (or any other units library) is third-party chances
are a feature like this will land in place a lot faster than it has
any chance of showing up in Python :)

Best,
Erik

> On Mon, Aug 29, 2016 at 03:05:50PM +0200, Erik Bray wrote:
>> Astropy also has a very powerful units package--originally derived
>> from pyunit I think but long since diverged and grown:
>>
>> http://docs.astropy.org/en/stable/units/index.html
>>
>> It was originally developed especially for astronomy/astrophysics use
>> and has some pre-defined units that many other packages don't have, as
>> well as support for logarithmic units like decibel and optional (and
>> customizeable) unit equivalences (e.g. frequency/wavelength or
>> flux/power).
>>
>> That said, its power extends beyond astronomy and I heard through last
>> week's EuroScipy that even some biology people have been using it.
>> There's been some (informal) talk about splitting it out from Astropy
>> into a stand-alone package.  This is tricky since almost everything in
>> Astropy has been built around it (dimensional calculations are always
>> used where possible), but not impossible.
>>
>> One of the other big advantages of astropy.units is the Quantity class
>> representing scale+dimension values.  This is deeply integrated into
>> Numpy so that units can be attached to Numpy arrays, and all Numpy
>> ufuncs can operate on them in a dimensionally meaningful way.  The
>> needs for this have driven a number of recent features in Numpy.  This
>> is work that, unfortunately, could never be integrated into the Python
>> stdlib.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

Thanks Chris.

I had misunderstood Steve's request, and I was thinking of something much more 
complicated.

Your code is very helpful.

-Ken


On Wed, Aug 31, 2016 at 05:07:11PM +1000, Chris Angelico wrote:
> On Wed, Aug 31, 2016 at 2:08 PM, 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.
> > With the base 2 scale factors, b stands for binary.
> 
> "Real" has historically often been a synonym for "float", and it
> doesn't really say that it'll be shown in engineering notation. But
> then, we currently have format codes 'e', 'f', and 'g', and I don't
> think there's much logic there beyond "exponential", "floating-point",
> and... "general format"? I think that's a back-formation, frankly, and
> 'g' was used simply because it comes nicely after 'e' and 'f'. (C's
> decision, not Python's, fwiw.) I'll stick with 'r' for now, but it
> could just as easily become 'h' to avoid confusion with %r for repr.
> 
> >> (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.
> >
> 
> AIUI, it's just giving the full word.
> 
> class ScaledNumber(float):
> invert = {"μ": 1e6, "m": 1e3, "": 1, "k": 1e-3, "M": 1e-6}
> words = {"μ": "micro", "m": "milli", "": "", "k": "kilo", "M": "mega"}
> aliases = {"u": "μ"}
> def autoscale(self):
> if self < 1e-6: return None
> if self < 1e-3: return "μ"
> if self < 1: return "m"
> if self < 1e3: return ""
> if self < 1e6: return "k"
> if self < 1e9: return "M"
> return None
> def __format__(self, fmt):
> if fmt == "r" or fmt == "R":
> scale = self.autoscale()
> fmt = fmt + scale if scale else "f"
> if fmt.startswith("r"):
> scale = self.aliases.get(fmt[1], fmt[1])
> return "%g%s" % (self * self.invert[scale], scale)
> if fmt.startswith("R"):
> scale = self.aliases.get(fmt[1], fmt[1])
> return "%g %s" % (self * self.invert[scale], self.words[scale])
> return super().__format__(self, fmt)
> 
> >>> range = ScaledNumber(50e3)
> >>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, range))
> Attenuation = -13.7 dB at 50km.
> >>> print('Attenuation = {:.1f} dB at {:R}meters.'.format(-13.7, range))
> Attenuation = -13.7 dB at 50 kilometers.
> >>> print('Attenuation = {:.1f} dB at {:rM}m.'.format(-13.7, range))
> Attenuation = -13.7 dB at 0.05Mm.
> >>> print('Attenuation = {:.1f} dB at {:RM}meters.'.format(-13.7, range))
> Attenuation = -13.7 dB at 0.05 megameters.
> 
> It's a minor flexibility, but could be very useful. As you see, it's
> still not at all unit-aware; but grammatically, these formats only
> make sense if followed by an actual unit name. (And not an SI base
> unit, necessarily - you have to use "gram", not "kilogram", lest you
> get silly constructs like "microkilogram" for milligram.)
> 
> Note that this *already works*. You do have to use an explicit class
> for your scaled numbers, since Python doesn't want you monkey-patching
> the built-in float type, but if you were to request that
> float.__format__ grow support for this, it'd be a relatively
> non-intrusive change. This class could live on PyPI until one day
> becoming subsumed into core, or just be a permanent third-party float
> formatting feature.
> 
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Wed, Aug 31, 2016 at 2:08 PM, 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.
> With the base 2 scale factors, b stands for binary.

"Real" has historically often been a synonym for "float", and it
doesn't really say that it'll be shown in engineering notation. But
then, we currently have format codes 'e', 'f', and 'g', and I don't
think there's much logic there beyond "exponential", "floating-point",
and... "general format"? I think that's a back-formation, frankly, and
'g' was used simply because it comes nicely after 'e' and 'f'. (C's
decision, not Python's, fwiw.) I'll stick with 'r' for now, but it
could just as easily become 'h' to avoid confusion with %r for repr.

>> (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.
>

AIUI, it's just giving the full word.

class ScaledNumber(float):
invert = {"μ": 1e6, "m": 1e3, "": 1, "k": 1e-3, "M": 1e-6}
words = {"μ": "micro", "m": "milli", "": "", "k": "kilo", "M": "mega"}
aliases = {"u": "μ"}
def autoscale(self):
if self < 1e-6: return None
if self < 1e-3: return "μ"
if self < 1: return "m"
if self < 1e3: return ""
if self < 1e6: return "k"
if self < 1e9: return "M"
return None
def __format__(self, fmt):
if fmt == "r" or fmt == "R":
scale = self.autoscale()
fmt = fmt + scale if scale else "f"
if fmt.startswith("r"):
scale = self.aliases.get(fmt[1], fmt[1])
return "%g%s" % (self * self.invert[scale], scale)
if fmt.startswith("R"):
scale = self.aliases.get(fmt[1], fmt[1])
return "%g %s" % (self * self.invert[scale], self.words[scale])
return super().__format__(self, fmt)

>>> range = ScaledNumber(50e3)
>>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, range))
Attenuation = -13.7 dB at 50km.
>>> print('Attenuation = {:.1f} dB at {:R}meters.'.format(-13.7, range))
Attenuation = -13.7 dB at 50 kilometers.
>>> print('Attenuation = {:.1f} dB at {:rM}m.'.format(-13.7, range))
Attenuation = -13.7 dB at 0.05Mm.
>>> print('Attenuation = {:.1f} dB at {:RM}meters.'.format(-13.7, range))
Attenuation = -13.7 dB at 0.05 megameters.

It's a minor flexibility, but could be very useful. As you see, it's
still not at all unit-aware; but grammatically, these formats only
make sense if followed by an actual unit name. (And not an SI base
unit, necessarily - you have to use "gram", not "kilogram", lest you
get silly constructs like "microkilogram" for milligram.)

Note that this *already works*. You do have to use an explicit class
for your scaled numbers, since Python doesn't want you monkey-patching
the built-in float type, but if you were to request that
float.__format__ grow support for this, it'd be a relatively
non-intrusive change. This class could live on PyPI until one day
becoming subsumed into core, or just be a permanent third-party float
formatting feature.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

> What's the mnemonic here? Why "r" for scale factor?

My thinking was that r stands for real like f stands for float.
With the base 2 scale factors, b stands for binary.

> (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.

>>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, 50e3))
Attenuation = -13.7 dB at 50 km.

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.

> (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.

> (3) Scientific notation and engineering notation?
> 
> (4) 1e5 versus 1×10^5 notation?

Ah, okay. But all of these require auto-scaling. And I was still thinking that 
we need to provide input and output capability (ie, we still need be able to 
convert whatever format we output back from strings into floats). Are you 
thinking that we should parse 1×10^5? And why 1×10^5 and not 1×10⁵?

> (5) Is this really something that format() needs to understand? We can get 
> a *much* richer and more powerful interface by turning it into a generalise 
> numeric pretty-printing library, at the cost of a little less convenience.

This is suddenly a much bigger project than what I was envisioning.

-Ken

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Warsaw]

On Aug 30, 2016, at 02:16 PM, Guido van Rossum wrote:

>Given that something like this gets proposed from time to time, I
>wonder if it would make sense to actually write up (1) and (2) as a
>PEP that is immediately marked rejected. The PEP should make it clear
>*why* it is rejected. This would be a handy reference doc to have
>around the next time the idea comes up.

There certainly is precedence: e.g. PEPs 404 and 666. :)

Cheers,
-Barry


pgpLLpPQDzqcA.pgp
Description: OpenPGP digital signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Tue, Aug 30, 2016 at 11:48 AM, Ken Kundert
 wrote:
> [...] Similarly when people refer to the length of
> the Olympic road race in Rio, they say 56km, not 56000m.

However I can't help to point out that if I said the distance to the
sun is 149.6 Gm, most people would do a double-take.

> This is really only an issue with output.

So maybe the proposal should be toned down to just a way to request SI
units when formatting numbers?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Sven R. Kunze writes:

 > And now we have '_' in numbers.
 > 
 > So much for "preferably one way".

Poor example.  There used to be no way to group long strings of
numerals for better readability.  Now there is exactly one way.

The Zen is not an axe.  It's a scalpel.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 30 August 2016 at 13:48, Ken Kundert  wrote:
> >>> d_sun = 93e6*u.imperial.mile
> >>> print(d_sun.to(u.parsec))
> 4.850441695494146e-06 pc

The "imperial.mile" example here highlights one key benefit that
expression based approaches enjoy over dedicated syntax: easy access
to Python's existing namespace features.

As a quick implementation sketch, consider something like:

>>> si_scaling = dict(k=1000, m=0.001)
>>> class SIScale:
... def __getattr__(self, key):
... return SIUnit(si_scaling[key])
...
>>> class SIUnit:
... def __init__(self, value):
... self.value = value
... def __getattr__(self, ignored):
... return self.value
...
>>> si = SIScale()
>>> 500 * si.k.m
50
>>> 500 * si.k.parsec
50
>>> 500 * si.m.m
0.5
>>> 500 * si.m.N
0.5

You could also relatively easily adapt that such that there there was
only one level of lookup, and you could write the examples without the
second dot (you'd just need to do some parsing of the key value in
__getattr__ to separate the SI prefix from the nominal units)

One particular benefit of this kind of approach is that you
automatically avoid the "E" ambiguity problem, since there's nothing
wrong with "si.E" from Python's perspective. You also gain an easy
hook to attach interactive help: "help(si)" (or si? in IPython terms)

Expanding out to full dimensional analysis with something like
astropy.units also becomes relatively straightforward, just by
changing the kind of value that __getattr__ returns.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nikolaus Rath]

On Aug 28 2016, Ken Kundert 
 wrote:
> So, in summary, you are suggesting that we tell the scientific and 
> engineering 
> communities that we refuse to provide native support for their preferred way 
> of 
> writing numbers because:

I think you're making some incorrect assumptions here. Who, exactly, do
you mean with "we" and "them"?

I consider myself part of the scientific community and think your
proposal is a bad idea, and Google finds some Python modules from you,
but no prior CPython contributions...

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

> I talked to astrophysicist about your comments, and what she said was:
> 1. She would love it if Python had built in support for real numbers with SI 
>scale factors
> 2. I told her about my library for reading and writing numbers with SI scale 
>factors, and she was much less enthusiastic because using it would require 
>convincing the rest of the group, which would be too much effort.
> 3. She was amused by the "kilo pico speed of light" comment, but she was 
> adamant 
>that the fact that you, or some system administrator, does not understand 
>what kpc means has absolutely no affect on her desired to use SI scale 
>factors. Her comment: I did not write it for him.
> 4. She pointed out that the software she writes and uses is intended either 
>for herself of other astrophysicists. No system administrators involved.

It has been pointed out to me that the above comes off as being condescending 
towards Steven, system administrators and language developers in general. For 
this I am profoundly sorry. It was not my intent. My only point was that the 
output of these numerical programs are often so highly specialized that only 
the 
authors and their peers understand it.

Let me go further in saying that if anything I have said in this discussion has 
come off as critical or insulting please know that that was not my intent.  
I have tremendous respect for what you all have accomplished and I am extremely 
appreciative of all the feedback and help you have given me.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alex Rudy]

> On Aug 29, 2016, at 06:08, Erik Bray  wrote:
> 
> On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray  > wrote:
>> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
>>  wrote:
>>> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
 On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
> On 2016-08-28 18:44, Ken Kundert wrote:
>> When working with a general purpose programming language, the above 
>> numbers
>> become:
>> 
>>780kpc -> 7.8e+05
 [...]
 
 For the record, I don't know what kpc might mean. "kilo pico speed of
 light"? So I looked it up using units, and it is kilo-parsecs. That
 demonstrates that unless your audience is intimately familiar with the
 domain you are working with, adding units (especially units that aren't
 actually used for anything) adds confusion.
 
 Python is not a specialist application targetted at a single domain. It
 is a general purpose programming language where you can expect a lot of
 cross-domain people (e.g. a system administrator asked to hack on a
 script in a domain they know nothing about).
>>> 
>>> I talked to astrophysicist about your comments, and what she said was:
>>> 1. She would love it if Python had built in support for real numbers with SI
>>>   scale factors
>>> 2. I told her about my library for reading and writing numbers with SI scale
>>>   factors, and she was much less enthusiastic because using it would require
>>>   convincing the rest of the group, which would be too much effort.
>>> 3. She was amused by the "kilo pico speed of light" comment, but she was 
>>> adamant
>>>   that the fact that you, or some system administrator, does not understand
>>>   what kpc means has absolutely no affect on her desired to use SI scale
>>>   factors. Her comment: I did not write it for him.
>>> 4. She pointed out that the software she writes and uses is intended either 
>>> for
>>>   herself of other astrophysicists. No system administrators involved.
>> 
>> Astropy also has a very powerful units package--originally derived
>> from pyunit I think but long since diverged and grown:
>> 
>> http://docs.astropy.org/en/stable/units/index.html
>> 
>> It was originally developed especially for astronomy/astrophysics use
>> and has some pre-defined units that many other packages don't have, as
>> well as support for logarithmic units like decibel and optional (and
>> customizeable) unit equivalences (e.g. frequency/wavelength or
>> flux/power).
>> 
>> That said, its power extends beyond astronomy and I heard through last
>> week's EuroScipy that even some biology people have been using it.
>> There's been some (informal) talk about splitting it out from Astropy
>> into a stand-alone package.  This is tricky since almost everything in
>> Astropy has been built around it (dimensional calculations are always
>> used where possible), but not impossible.
>> 
>> One of the other big advantages of astropy.units is the Quantity class
>> representing scale+dimension values.  This is deeply integrated into
>> Numpy so that units can be attached to Numpy arrays, and all Numpy
>> ufuncs can operate on them in a dimensionally meaningful way.  The
>> needs for this have driven a number of recent features in Numpy.  This
>> is work that, unfortunately, could never be integrated into the Python
>> stdlib.
> 
> I'll also add that syntactic support for units has rarely been an
> issue in Astropy.  The existing algebraic rules for units work fine
> with Python's existing order of operations.  It can be *nice* to be
> able to write "1m" instead of "1 * m" but ultimately it doesn't add
> much for clarity (and if really desired could be handled with a
> preparser--something I've considered adding for Astropy sources (via
> codecs).

I just want to add, as an astrophysicist who uses astropy.units: the astropy 
solution is pretty great, and I don’t mind the library overhead. I’d much 
rather have astropy.units, which does dimensional analysis, as well as handling 
SI prefixes for 2 reasons:
1. I don’t normally see or use SI prefixes without units, so bare SI prefixes 
are fairly worthless to me as a scientist. IF the units are going to be there, 
I’d much rather have a library that does a good job at dimensional analysis, 
and has taken my domain-specific concerns into account, for reasons fairly well 
covered in this thread.
2. I don’t find it cumbersome at all to use something like astropy.units which 
provides both the prefix and units for my code on input and output. The added 
syntactic weight of a single import, plus multiplication, is really not that 
big a burden, and makes it both clear what I am trying to write, and easy for 
the library to maintain this meaning when I use the variable later. e.g.
from astropy.units import *
distance = 10 * km

If that multiplication symbol is really 

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

[Sven R. Kunze]

I didn't follow the previous discussion so far, so excuse me if I repeat 
something somebody already mentioned. But these are intriguing points 
you made here.


On 29.08.2016 09:31, Ken Kundert wrote:

The reason why hexadecimal and octal are in general purpose languages and real
numbers with SI scale factors are not is because languages are developed by
computer scientists and not by scientists. I keep using SPICE and Verilog as
examples of a languages that supports SI scale factors, and that is because they
are the extremely rare cases where the languages were either developed or
specified by end users and not by computer scientists.

The reason why computer scientists tend to add hexadecimal and octal numbers to
their languages and not SI scale factors is that they use hexadecimal and octal
numbers, and as we have seen by this discussion, are rather unfamiliar with real
numbers with SI scale factors. It is easy for them to justify adding hex because
they know from personal experience that it is useful, but if you don't use
widely scaled real numbers day in and day out it is hard to understand just how
tedious exponential notation is and how useful it would be to use SI scale
factors.


I didn't know that THERE ARE languages that already feature SI factors. 
You could be right about their development.


I for one wouldn't have an issue with this being in Python for the 
following reasons:


1) I wouldn't use it as I don't have the use-cases right now
2) if I would need to read such code, it wouldn't hurt my reading 
experience as I am used to SI
3) there will be two classes of code here: a) code that has use for it 
and thus uses it quite extensively and code that doesn't; depending on 
where you work you will encounter this feature or you don't even know it 
exists (this is true for many features in Python which is a good thing: 
each domain should use what is the best tool for them)



The biggest issue I have is the following: SI scale factors without SI 
units do not make much sense, I think (especially considering those 
syntax changes). So, the potential, if any, can only illustrated in 
combination with them. But Python does not feature any SI units so far 
as those are provided by external packages. If you can resolve that I am 
+1 on this proposal, but otherwise just +0.


Sven


PS: If I think about it this way, I might have a use-case in a small 
side-project.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sven R. Kunze]

On 29.08.2016 11:37, Chris Angelico wrote:

That's why I keep asking you for code examples. Real-world code, taken
from important projects, that would be significantly improved by this
proposal.


There was no reasonable real-world code examples taken from important 
projects, that would be significantly improved by underscores in numbers.


Still, we got them, so your argument here is void.


It has to be Python 3 compatible (unless you reckon that
this is the killer feature that will make people take the jump from
2.7), and it has to be enough of an improvement that its authors will
be willing to drop support for <3.6 (which might be a trivial concern,
eg if the author expects to be the only person running the code).
All of those "has to be"s are optional (cf. underscores in numbers) and 
that's not different for this proposal.


Sven

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sven R. Kunze]

On 29.08.2016 05:40, Brendan Barnwell wrote:

On 2016-08-28 20:29, Ken Kundert wrote:

What is wrong with have two ways of doing things? We have many ways of
specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, 



Zen of Python: "There should be one-- and preferably only one 
--obvious way to do it."


If Python didn't have binary or octal notation and someone came 
here proposing it, I would not support it, for the same reasons I 
don't support your proposal.  If someone proposed eliminating binary 
or octal notation for Python 4 (or even maybe Python 3.8), I would 
probably support it for the same reason. Those notations are not 
useful enough to justify their existence. Hexadecimal is more 
justifiable as it is far more widely used, but I would be more open to 
removing hexadecimal than I would be to adding octal.


Also, "L" as a long-integer suffix is already gone in Python 3.



And now we have '_' in numbers.

So much for "preferably one way".


Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Erik Bray]

On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray  wrote:
> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
>  wrote:
>> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
>>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
>>> > On 2016-08-28 18:44, Ken Kundert wrote:
>>> > >When working with a general purpose programming language, the above 
>>> > >numbers
>>> > >become:
>>> > >
>>> > > 780kpc -> 7.8e+05
>>> [...]
>>>
>>> For the record, I don't know what kpc might mean. "kilo pico speed of
>>> light"? So I looked it up using units, and it is kilo-parsecs. That
>>> demonstrates that unless your audience is intimately familiar with the
>>> domain you are working with, adding units (especially units that aren't
>>> actually used for anything) adds confusion.
>>>
>>> Python is not a specialist application targetted at a single domain. It
>>> is a general purpose programming language where you can expect a lot of
>>> cross-domain people (e.g. a system administrator asked to hack on a
>>> script in a domain they know nothing about).
>>
>> I talked to astrophysicist about your comments, and what she said was:
>> 1. She would love it if Python had built in support for real numbers with SI
>>scale factors
>> 2. I told her about my library for reading and writing numbers with SI scale
>>factors, and she was much less enthusiastic because using it would require
>>convincing the rest of the group, which would be too much effort.
>> 3. She was amused by the "kilo pico speed of light" comment, but she was 
>> adamant
>>that the fact that you, or some system administrator, does not understand
>>what kpc means has absolutely no affect on her desired to use SI scale
>>factors. Her comment: I did not write it for him.
>> 4. She pointed out that the software she writes and uses is intended either 
>> for
>>herself of other astrophysicists. No system administrators involved.
>
> Astropy also has a very powerful units package--originally derived
> from pyunit I think but long since diverged and grown:
>
> http://docs.astropy.org/en/stable/units/index.html
>
> It was originally developed especially for astronomy/astrophysics use
> and has some pre-defined units that many other packages don't have, as
> well as support for logarithmic units like decibel and optional (and
> customizeable) unit equivalences (e.g. frequency/wavelength or
> flux/power).
>
> That said, its power extends beyond astronomy and I heard through last
> week's EuroScipy that even some biology people have been using it.
> There's been some (informal) talk about splitting it out from Astropy
> into a stand-alone package.  This is tricky since almost everything in
> Astropy has been built around it (dimensional calculations are always
> used where possible), but not impossible.
>
> One of the other big advantages of astropy.units is the Quantity class
> representing scale+dimension values.  This is deeply integrated into
> Numpy so that units can be attached to Numpy arrays, and all Numpy
> ufuncs can operate on them in a dimensionally meaningful way.  The
> needs for this have driven a number of recent features in Numpy.  This
> is work that, unfortunately, could never be integrated into the Python
> stdlib.

I'll also add that syntactic support for units has rarely been an
issue in Astropy.  The existing algebraic rules for units work fine
with Python's existing order of operations.  It can be *nice* to be
able to write "1m" instead of "1 * m" but ultimately it doesn't add
much for clarity (and if really desired could be handled with a
preparser--something I've considered adding for Astropy sources (via
codecs).

Best,
Erik
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Erik Bray]

On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
 wrote:
> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
>> > On 2016-08-28 18:44, Ken Kundert wrote:
>> > >When working with a general purpose programming language, the above 
>> > >numbers
>> > >become:
>> > >
>> > > 780kpc -> 7.8e+05
>> [...]
>>
>> For the record, I don't know what kpc might mean. "kilo pico speed of
>> light"? So I looked it up using units, and it is kilo-parsecs. That
>> demonstrates that unless your audience is intimately familiar with the
>> domain you are working with, adding units (especially units that aren't
>> actually used for anything) adds confusion.
>>
>> Python is not a specialist application targetted at a single domain. It
>> is a general purpose programming language where you can expect a lot of
>> cross-domain people (e.g. a system administrator asked to hack on a
>> script in a domain they know nothing about).
>
> I talked to astrophysicist about your comments, and what she said was:
> 1. She would love it if Python had built in support for real numbers with SI
>scale factors
> 2. I told her about my library for reading and writing numbers with SI scale
>factors, and she was much less enthusiastic because using it would require
>convincing the rest of the group, which would be too much effort.
> 3. She was amused by the "kilo pico speed of light" comment, but she was 
> adamant
>that the fact that you, or some system administrator, does not understand
>what kpc means has absolutely no affect on her desired to use SI scale
>factors. Her comment: I did not write it for him.
> 4. She pointed out that the software she writes and uses is intended either 
> for
>herself of other astrophysicists. No system administrators involved.

Astropy also has a very powerful units package--originally derived
from pyunit I think but long since diverged and grown:

http://docs.astropy.org/en/stable/units/index.html

It was originally developed especially for astronomy/astrophysics use
and has some pre-defined units that many other packages don't have, as
well as support for logarithmic units like decibel and optional (and
customizeable) unit equivalences (e.g. frequency/wavelength or
flux/power).

That said, its power extends beyond astronomy and I heard through last
week's EuroScipy that even some biology people have been using it.
There's been some (informal) talk about splitting it out from Astropy
into a stand-alone package.  This is tricky since almost everything in
Astropy has been built around it (dimensional calculations are always
used where possible), but not impossible.

One of the other big advantages of astropy.units is the Quantity class
representing scale+dimension values.  This is deeply integrated into
Numpy so that units can be attached to Numpy arrays, and all Numpy
ufuncs can operate on them in a dimensionally meaningful way.  The
needs for this have driven a number of recent features in Numpy.  This
is work that, unfortunately, could never be integrated into the Python
stdlib.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mark Lawrence via Python-ideas]

On 29/08/2016 13:35, Stephan Houben wrote:

Note that the Sage computer algebra system uses Python with some
syntactic changes implemented by a "pre-parser".

The current proposal could be implemented in a similar way and then
integrated in, say, Ipython.

If it would prove to be wildly popular, then it would make a stronger
case for incorporation in the core.

Stephan


Op 29 aug. 2016 2:12 p.m. schreef "Mark Lawrence via Python-ideas"
>:

On 29/08/2016 02:44, Ken Kundert wrote:


Changing Python so that it understands SI scale factors on real
numbers as first
class citizens innately requires a change to the base language;
it cannot be
done solely through libraries.  The question before you is,
should we do it?

No, no, no, if the people who provide this http://www.scipy.org/ can
do without it.

Now would you please be kind enough to give up with this dead horse
before I take a ride to the Clifton Suspension Bridge or Beachy
Head, whichever is closest.



As iPython is a core part of scipy, which I linked above, why would the 
developers want to incorporate this suggestion?  I'd have also thought 
that if this idea was to be "wildly popular" it would have been done 
years ago.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephan Houben]

Note that the Sage computer algebra system uses Python with some syntactic
changes implemented by a "pre-parser".

The current proposal could be implemented in a similar way and then
integrated in, say, Ipython.

If it would prove to be wildly popular, then it would make a stronger case
for incorporation in the core.

Stephan

Op 29 aug. 2016 2:12 p.m. schreef "Mark Lawrence via Python-ideas" <
python-ideas@python.org>:

> On 29/08/2016 02:44, Ken Kundert wrote:
>
>>
>> Changing Python so that it understands SI scale factors on real numbers
>> as first
>> class citizens innately requires a change to the base language; it cannot
>> be
>> done solely through libraries.  The question before you is, should we do
>> it?
>>
>>
> No, no, no, if the people who provide this http://www.scipy.org/ can do
> without it.
>
> Now would you please be kind enough to give up with this dead horse before
> I take a ride to the Clifton Suspension Bridge or Beachy Head, whichever is
> closest.
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mark Lawrence via Python-ideas]

On 29/08/2016 02:44, Ken Kundert wrote:


Changing Python so that it understands SI scale factors on real numbers as first
class citizens innately requires a change to the base language; it cannot be
done solely through libraries.  The question before you is, should we do it?



No, no, no, if the people who provide this http://www.scipy.org/ can do 
without it.


Now would you please be kind enough to give up with this dead horse 
before I take a ride to the Clifton Suspension Bridge or Beachy Head, 
whichever is closest.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

I teach working scientists about numeric computing on a daily basis. There
are a few special field where Ken's ideas are the norm, at least in
informal notation. The large majority of working scientists would find a
syntax change like he proposes an annoyance and nuisance.

Alienating and confusing everyone who isn't a circuit designer is a bad
goal. It's not going to happen in python.

If you really want this syntax, you need to use a different language, or
maybe write a preprocessor that turns a slightly different language back
into Python.

On Aug 29, 2016 4:09 AM, "Ken Kundert"  wrote:

> > > These do not seem like good reasons for not doing this.
> >
> > Not worded the way you have them, no, because you've aimed for an
> > extremely emotional argument instead of answering concrete questions
> > like "where's the code that this would improve". Find some real-world
> > code that would truly benefit from this. Show us how it's better.
>
> Sorry, I am trying very hard not to let my emotions show through, and
> instead
> provide answers, examples, and comments that are well reasoned and well
> supported. I do find it frustrating that I appear to be the only one
> involved in
> the conversation that has a strong background in numerical computation,
> meaning
> that I have to carry one side of the argument without any support. It is
> especially frustrating when that background is used as a reason to
> discount my
> position. Let me try to make the case in an unemotional way.
>
> It is hard to justify the need for SI scale factors being built into the
> language with an example because it is relatively simple to do the
> conversion.
> For example ...
>
> With built-in support for SI scale factors:
>
> h_line = 1.4204GHz
> print('hline = {:r}Hz'.format(h_line))
> ...
>
> In Python today:
>
> from engfmt import Quantity
> h_line = Quantity('1.4204GHz')
> print('hline = {:q}'.format(h_line))
> h_line = float(h_line)
> ...
>
> Not really much harder to use the library. This is very similar to the
> situation
> with octal numbers ...
>
> With built-in support for octal numbers:
>
> S_IFREG  = 0o10  # regular file
>
> With out built-in support for octal numbers:
>
> S_IFREG  = int('10', base=8)  # regular file
>
> So just giving a simple example is not enough to see the importance of
> native
> support. The problem with using a library is that you always have to
> convert
> from SI scale factors as the number is input and then converting back as
> the
> number is output. So you can spend a fair amount of effort converting too
> and
> from representations that support SI scale factors. Not a big deal if
> there is
> only a few, but can be burdensome if there is a large number. But the real
> benefit to building it in a native capability is that it puts pressure on
> the
> rest of the ecosystem to also adopt the new way of representing real
> numbers.
> For example, now the interchange packages and formats (Pickle, YaML, etc.)
> need
> to come up with a way of passing the information without losing its
> essential
> character.  This in turn puts pressure on other languages to follow suit.
> It
> would also put pressure on documenting and formatting packages, such as
> Sphinx,
> Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean
> documentation.  Also the interactive environments, such as ipython, need to
> adapt. The more this occurs, the better life gets for scientists and
> engineers.
>
>
> > Something that I don't think you've acknowledged is that the SI
> > scaling markers are *prefixes to units*, not *suffixes to numbers*.
> > That is to say, you don't have "132G" of a thing called a "pascal",
> > you have "132" of a thing called a "gigapascal". Outside of a
> > unit-based system, SI prefixes don't really have meaning. I don't
> > remember ever, in a scientific context, seeing a coefficient of
> > friction listed as "30 milli-something"; it's always "0.03". So if
> > unitless values are simply numbers, and Python's ints and floats are
> > unitless, they won't see much benefit from prefixes-on-nothing.
>
> Yeah, this is why I suggested that we support the ability for users to
> specify
> units with the numbers, but it is not a hard and fast rule. Once you add
> support
> for SI scale factors, people find them so convenient that they tend to use
> them
> whether they are units or not. For example, it is common for circuit
> designers
> to specify the gain of an amplifier using SI scale factors even though
> gain is
> often unitless. For example, gain=50k. Also, electrical engineers will
> often
> drop the units when they are obvious, especially if they are long. For
> example,
> it is common to see a resistance specified as 100k. When values are given
> in
> a table and all the values in a column have the same units, it is common
> to give
> numbers with scale factors by without units to save space.
>
> -Ken
> 

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

[Terry Reedy]

On 8/28/2016 9:44 PM, Ken Kundert wrote:


The way the scientific and engineering communities predominately write real
numbers is by using SI scale factors.


I don't believe it, not with naked scale factors as you have proposed. 
I have worked in science and I never saw naked scale factors until this 
proposal.  The scale factors are usually attached to units.



These numbers almost always represent
physical quantities, so it is common to write the number with scale factor and
units.


The scale factor is part of the unit, and people now learn this in grade 
school, I presume.



 So for example, the distance to Andromeda is 780kpc, the pressure at the
bottom of the Mariana Trench is 108MPa, the total power produced by a typical
hurricane is 600TW, the number of base pairs in human DNA is 3.2Gb, and the Bohr
radius is 53pm.


These are all scaled units and to me not relevant to the proposed 
addition of scale factors without units.


At this point I quit reading.

--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

> > These do not seem like good reasons for not doing this.
> 
> Not worded the way you have them, no, because you've aimed for an
> extremely emotional argument instead of answering concrete questions
> like "where's the code that this would improve". Find some real-world
> code that would truly benefit from this. Show us how it's better.

Sorry, I am trying very hard not to let my emotions show through, and instead 
provide answers, examples, and comments that are well reasoned and well 
supported. I do find it frustrating that I appear to be the only one involved 
in 
the conversation that has a strong background in numerical computation, meaning 
that I have to carry one side of the argument without any support. It is 
especially frustrating when that background is used as a reason to discount my 
position. Let me try to make the case in an unemotional way.

It is hard to justify the need for SI scale factors being built into the 
language with an example because it is relatively simple to do the conversion.  
For example ...

With built-in support for SI scale factors:

h_line = 1.4204GHz
print('hline = {:r}Hz'.format(h_line))
...

In Python today: 

from engfmt import Quantity
h_line = Quantity('1.4204GHz')
print('hline = {:q}'.format(h_line))
h_line = float(h_line)
...

Not really much harder to use the library. This is very similar to the 
situation 
with octal numbers ...

With built-in support for octal numbers:

S_IFREG  = 0o10  # regular file

With out built-in support for octal numbers:

S_IFREG  = int('10', base=8)  # regular file

So just giving a simple example is not enough to see the importance of native 
support. The problem with using a library is that you always have to convert 
from SI scale factors as the number is input and then converting back as the 
number is output. So you can spend a fair amount of effort converting too and 
from representations that support SI scale factors. Not a big deal if there is 
only a few, but can be burdensome if there is a large number. But the real 
benefit to building it in a native capability is that it puts pressure on the 
rest of the ecosystem to also adopt the new way of representing real numbers.  
For example, now the interchange packages and formats (Pickle, YaML, etc.) need 
to come up with a way of passing the information without losing its essential 
character.  This in turn puts pressure on other languages to follow suit. It 
would also put pressure on documenting and formatting packages, such as Sphinx,
Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean 
documentation.  Also the interactive environments, such as ipython, need to 
adapt. The more this occurs, the better life gets for scientists and engineers.


> Something that I don't think you've acknowledged is that the SI
> scaling markers are *prefixes to units*, not *suffixes to numbers*.
> That is to say, you don't have "132G" of a thing called a "pascal",
> you have "132" of a thing called a "gigapascal". Outside of a
> unit-based system, SI prefixes don't really have meaning. I don't
> remember ever, in a scientific context, seeing a coefficient of
> friction listed as "30 milli-something"; it's always "0.03". So if
> unitless values are simply numbers, and Python's ints and floats are
> unitless, they won't see much benefit from prefixes-on-nothing.

Yeah, this is why I suggested that we support the ability for users to specify 
units with the numbers, but it is not a hard and fast rule. Once you add 
support 
for SI scale factors, people find them so convenient that they tend to use them 
whether they are units or not. For example, it is common for circuit designers 
to specify the gain of an amplifier using SI scale factors even though gain is 
often unitless. For example, gain=50k. Also, electrical engineers will often 
drop the units when they are obvious, especially if they are long. For example, 
it is common to see a resistance specified as 100k. When values are given in 
a table and all the values in a column have the same units, it is common to 
give 
numbers with scale factors by without units to save space.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

On Mon, Aug 29, 2016 at 12:18:02AM -0700, Brendan Barnwell wrote:
> On 2016-08-29 00:07, Ken Kundert wrote:
> > > >I completely believe Ken that within a single tightly focussed user
> > > >community, using their expected conventions (including SI prefixes)
> > > >works really well. But Python users do not belong to a single tightly
> > > >focussed user community.
> > You think that Python is only used by generalists?  That is silly. Have you 
> > seen
> > SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is
> > written by astrophysicists for astrophysicists doing observations on radio
> > telescope arrays. That is pretty specialized.
> 
>   I think you misunderstand.  My position (reiterated by the text you 
> quote
> from Steven D'Aprano) is not that Python is used only by generalists.  It is
> that we shouldn't change Python in a way that ONLY helps specialists.
> 

But surely we should consider changing Python if the change benefits a wide 
variety of specialists, especially if the change is small and fits cleanly into 
the language.

In this case, our specialists come from most of the disciplines of science and 
engineering. That is a pretty big group.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

> There are other languages too that had hexadecimal and octal.
> 
> They've been around in programming languages for decades.
> 
> How many languages have scale factors?
> 
> Does Fortran? Not that I know of.
> 

The reason why hexadecimal and octal are in general purpose languages and real
numbers with SI scale factors are not is because languages are developed by
computer scientists and not by scientists. I keep using SPICE and Verilog as
examples of a languages that supports SI scale factors, and that is because they
are the extremely rare cases where the languages were either developed or
specified by end users and not by computer scientists.

The reason why computer scientists tend to add hexadecimal and octal numbers to
their languages and not SI scale factors is that they use hexadecimal and octal
numbers, and as we have seen by this discussion, are rather unfamiliar with real
numbers with SI scale factors. It is easy for them to justify adding hex because
they know from personal experience that it is useful, but if you don't use
widely scaled real numbers day in and day out it is hard to understand just how
tedious exponential notation is and how useful it would be to use SI scale
factors.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brendan Barnwell]

On 2016-08-29 00:07, Ken Kundert wrote:

>I completely believe Ken that within a single tightly focussed user
>community, using their expected conventions (including SI prefixes)
>works really well. But Python users do not belong to a single tightly
>focussed user community.

You think that Python is only used by generalists?  That is silly. Have you seen
SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is
written by astrophysicists for astrophysicists doing observations on radio
telescope arrays. That is pretty specialized.


	I think you misunderstand.  My position (reiterated by the text you 
quote from Steven D'Aprano) is not that Python is used only by 
generalists.  It is that we shouldn't change Python in a way that ONLY 
helps specialists.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
> > On 2016-08-28 18:44, Ken Kundert wrote:
> > >When working with a general purpose programming language, the above numbers
> > >become:
> > >
> > > 780kpc -> 7.8e+05
> [...]
> 
> For the record, I don't know what kpc might mean. "kilo pico speed of 
> light"? So I looked it up using units, and it is kilo-parsecs. That 
> demonstrates that unless your audience is intimately familiar with the 
> domain you are working with, adding units (especially units that aren't 
> actually used for anything) adds confusion.
> 
> Python is not a specialist application targetted at a single domain. It 
> is a general purpose programming language where you can expect a lot of 
> cross-domain people (e.g. a system administrator asked to hack on a 
> script in a domain they know nothing about).

I talked to astrophysicist about your comments, and what she said was:
1. She would love it if Python had built in support for real numbers with SI 
   scale factors
2. I told her about my library for reading and writing numbers with SI scale 
   factors, and she was much less enthusiastic because using it would require 
   convincing the rest of the group, which would be too much effort.
3. She was amused by the "kilo pico speed of light" comment, but she was 
adamant 
   that the fact that you, or some system administrator, does not understand 
   what kpc means has absolutely no affect on her desired to use SI scale 
   factors. Her comment: I did not write it for him.
4. She pointed out that the software she writes and uses is intended either for 
   herself of other astrophysicists. No system administrators involved.

> > You've continually repeated this assertion, but I don't buy it.  For 
> > the general case, exponential notation is easier to read because you can 
> > always see exactly what the exponent is as a number.  To read SI units, 
> > you have to know all the SI prefixes.  This may well be common within 
> > scientific communities, but to say that it is "easier" is really a bit 
> > much.  The same is true of "harder to type".  "kpc" is three characters; 
> > e+5 is also three (note that you don't need to write e+05), 
> 
> You don't have to write e+5 either, just e5 is sufficient.
> 
> > and one of 
> > those is a number that transparently indicates how many places to move 
> > the decimal, whereas all of the letters in "kpc" are opaque unless you 
> > already know what the number is meant to represent.
> > 
> > If you have concrete evidence (e.g., from actual user experience 
> > research) showing that it is across-the-board "easier" to read or type 
> > SI prefixes than exponential notation, that would be good to see.
> 
> I completely believe Ken that within a single tightly focussed user 
> community, using their expected conventions (including SI prefixes) 
> works really well. But Python users do not belong to a single tightly 
> focussed user community.

You think that Python is only used by generalists?  That is silly. Have you 
seen 
SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is 
written by astrophysicists for astrophysicists doing observations on radio 
telescope arrays. That is pretty specialized.

-Ken

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Mon, Aug 29, 2016 at 1:29 PM, Ken Kundert
 wrote:
> Because by focusing on the implementation details, we miss the big picture.  
> We
> have already done that, and we ended up going down countless ratholes.

They're important ratholes though. Without digging into those
questions, all you have is an emotive argument of "but we NEEED to
support SI prefixes as integer suffixes!".

>> > Don't Python's users in the scientific and engineering communities deserve
>> > the same treatment?  These are, after all, core communities for Python.
>>
>> Yes. That's why we have things like the @ matrix multiplication
>> operator (because the numeric computational community asked for it),
>> and %-formatting for bytes strings (because the networking, mainly
>> HTTP serving, community asked for it). Python *does* have a history of
>> supporting things that are needed by specific sub-communities of
>> Python coders. But there first needs to be a demonstrable need. How
>> much are people currently struggling due to the need to transform
>> "gigapascal" into "e+9"? Can you show convoluted real-world code that
>> would be made dramatically cleaner by language support?
>
> Can you show code that would have been convoluted if Python had used a library
> rather than built-in support for hexadecimal numbers?

See my other email, with examples of bit flags. It's not too bad if
you only ever work with a single bit at a time, but bit masks combine
beautifully in binary, fairly cleanly in hex, and really badly in
decimal. Hex is a great trade-off between clean bit handling and
compact representation. (Octal is roughly the same trade-off, and in
days of yore was the one obvious choice, but hex has overtaken it.)

> So, in summary, you are suggesting that we tell the scientific and engineering
> communities that we refuse to provide native support for their preferred way 
> of
> writing numbers because:
> 1. our way is better,

Is more general, yes. If all you have is SI prefixes, you're badly
scuppered. If all you have is exponential notation, you can do
everything.

> 2. their way is bad because some uneducated person might see the numbers and 
> not
>understand them,

Is, again, less general. It's a way of writing numbers that makes
sense only in a VERY narrow area.

> 3. we already have way of representing numbers that we came up with in the 
> '60s
>and we simply cannot do another,

False.

> 4. well we could do it, but we have decided that if you would only adapt to 
> this
>new way of doing things that we just came up with, then we would not have 
> to
>do any work, and that is better for us. Oh and this this new way of writing
>numbers, it only works in the program itself. Your out of luck when it 
> comes
>to IO.

I'm not sure what you mean by "IO" here, but if you're writing a
program that accepts text strings and prints text strings, it's free
to do whatever it wants.

> These do not seem like good reasons for not doing this.

Not worded the way you have them, no, because you've aimed for an
extremely emotional argument instead of answering concrete questions
like "where's the code that this would improve". Find some real-world
code that would truly benefit from this. Show us how it's better.

Something that I don't think you've acknowledged is that the SI
scaling markers are *prefixes to units*, not *suffixes to numbers*.
That is to say, you don't have "132G" of a thing called a "pascal",
you have "132" of a thing called a "gigapascal". Outside of a
unit-based system, SI prefixes don't really have meaning. I don't
remember ever, in a scientific context, seeing a coefficient of
friction listed as "30 milli-something"; it's always "0.03". So if
unitless values are simply numbers, and Python's ints and floats are
unitless, they won't see much benefit from prefixes-on-nothing.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 29 August 2016 at 13:40, Brendan Barnwell  wrote:
> On 2016-08-28 20:29, Ken Kundert wrote:
>>
>> What is wrong with have two ways of doing things? We have many ways of
>> specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, 
>
>
> Zen of Python: "There should be one-- and preferably only one
> --obvious way to do it."
>
> If Python didn't have binary or octal notation and someone came here
> proposing it, I would not support it, for the same reasons I don't support
> your proposal.  If someone proposed eliminating binary or octal notation for
> Python 4 (or even maybe Python 3.8), I would probably support it for the
> same reason.  Those notations are not useful enough to justify their
> existence.  Hexadecimal is more justifiable as it is far more widely used,
> but I would be more open to removing hexadecimal than I would be to adding
> octal.

Octal literals were on the Python 3 chopping block, with only two
things saving them:

- *nix file permissions (i.e. the existing sysadmin user base)
- the proposal to switch to "0o" as the prefix

The addition of "0b" was to make bitwise operators easier to work
with, rather than requiring folks to mentally convert between binary
and hexadecimal just to figure out how to set a particular bit flag,
with the requirement to understand binary math being seen as an
essential requirement for working with computers at the software
development level (since it impacts so many things, directly and
indirectly). Hexadecimal then sticks around as a way of more concisely
writing binary literals

However, the readability-as-a-general-purpose-language argument in the
case of SI scaling factors goes as follows:

- exponential notation (both the scientific and engineering variants)
falls into the same "required to understand computers" category as
binary and hexadecimal notation
- for folks that have memorised the SI scaling factors, the
engineering notation equivalents should be just as readable
- for folks that have not memorised the SI scaling factors, the
engineering notation equivalents are *more* readable
- therefore, at the language level, this is a style guide
recommendation to use engineering notation for quantitative literals
over scientific notation (since engineering notation is easier to
mentally convert to SI prefixes)

However, once we're talking domain specific languages (like circuit
design), rather than a general purpose programming language, then
knowledge of the SI prefixes can be included in the assumed set of
user knowledge, and made a language level feature.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brendan Barnwell]

On 2016-08-28 20:29, Ken Kundert wrote:

What is wrong with have two ways of doing things? We have many ways of
specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, 


	Zen of Python: "There should be one-- and preferably only one --obvious 
way to do it."


	If Python didn't have binary or octal notation and someone came here 
proposing it, I would not support it, for the same reasons I don't 
support your proposal.  If someone proposed eliminating binary or octal 
notation for Python 4 (or even maybe Python 3.8), I would probably 
support it for the same reason.  Those notations are not useful enough 
to justify their existence.  Hexadecimal is more justifiable as it is 
far more widely used, but I would be more open to removing hexadecimal 
than I would be to adding octal.


Also, "L" as a long-integer suffix is already gone in Python 3.

--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ken Kundert]

On Mon, Aug 29, 2016 at 12:33:16PM +1000, Chris Angelico wrote:
> On Mon, Aug 29, 2016 at 11:44 AM, Ken Kundert
>  wrote:
> > When working with a general purpose programming language, the above numbers
> > become:
> >
> > 780kpc -> 7.8e+05
> > 108MPa -> 1.08e+08
> > 600TW  -> 6e+14
> > 3.2Gb  -> 3.2e+09
> > 53pm   -> 5.3e-11
> > $8G-> 8e+09
> >
> > Notice that the numbers become longer, harder to read, harder to type, 
> > harder to
> > say, and harder to hear.
> >
> 
> And easier to compare. The SI prefixes are almost consistent in using
> uppercase for larger units and lowercase for smaller, but not quite;
> and there's no particular pattern in which letter is larger. For
> someone who isn't extremely familiar with them, that makes them
> completely unordered - which is larger, peta or exa? Which is smaller,
> nano or pico? Plus, there's a limit to how far you can go with these
> kinds of numbers, currently yotta at e+24. Exponential notation scales
> to infinity (to 1e308 in IEEE 64-bit binary floats, but plenty further
> in decimal.Decimal - I believe its limit is about 1e+(1e6), and REXX
> on OS/2 had a limit of 1e+(1e10) for its arithmetic), remaining
> equally readable at all scales.
> 
> So we can't get rid of exponential notation, no matter what happens.
> Mathematics cannot usefully handle a system in which we have to
> represent large exponents with ridiculous compound scale factors:
> 
> sys.float_info.max = 179.76931348623157*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*E
> 
> (It's even worse if the Exa collision means you stop at Peta.
> 179.76931348623157*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*M, anyone?)
> 
> Which means that these tags are a duplicate way of representing a
> specific set of exponents.
> 

Yes, of course.  No one is suggesting abandoning exponential notation. I am not 
suggesting we force people to use SI scale factors, only that we allow them to. 
 
What I am suggesting is that we stop saying to them things like 'you must use 
exponential notation because we have decided that its better. See, you can 
easily compare the size of numbers by looking at the exponents.'

What is wrong with have two ways of doing things? We have many ways of 
specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, 

> > Before we expend any more effort on this topic, let's put aside the 
> > question 
> > of
> > how it should be done, or how it will be used after its done, and just 
> > focus on
> > whether we do it at all. Should Python support real numbers specified with 
> > SI
> > scale factors as first class citizens?
> 
> Except that those are exactly the important questions to be answered.
> How *could* it be done? With the units stripped off, your examples
> become:
> 
> 780k == 7.8e+05 == 780*k
> 108M == 1.08e+08 == 108*M
> 600T == 6e+14 == 600*T
> 3.2G == 3.2e+09 == 3.2*G
> 53p == 5.3e-11 == 53*p
> 8G == 8e+09 == 8*G
> 
> Without any support whatsoever, you can already use the third column
> notation, simply by creating this module:
> 
> # si.py
> k, M, G, T, P, E, Z, Y = 1e3, 1e6, 1e9, 1e12, 1e15, 1e18, 1e21, 1e24
> m, μ, n, p, f, a, z, y = 1e-3, 1e-6, 1e-9, 1e-12, 1e-15, 1e-18, 1e-21, 1e-24
> u = μ
> K = k
> 
> And using it as "from si import *" at the top of your code. Do we see
> a lot of code in the wild doing this? "[H]ow it will be used after
> it's done" is exactly the question that this would answer.

Because by focusing on the implementation details, we miss the big picture.  We 
have already done that, and we ended up going down countless ratholes.

> 
> > Don't Python's users in the scientific and engineering communities deserve
> > the same treatment?  These are, after all, core communities for Python.
> 
> Yes. That's why we have things like the @ matrix multiplication
> operator (because the numeric computational community asked for it),
> and %-formatting for bytes strings (because the networking, mainly
> HTTP serving, community asked for it). Python *does* have a history of
> supporting things that are needed by specific sub-communities of
> Python coders. But there first needs to be a demonstrable need. How
> much are people currently struggling due to the need to transform
> "gigapascal" into "e+9"? Can you show convoluted real-world code that
> would be made dramatically cleaner by language support?

Can you show code that would have been convoluted if Python had used a library 
rather than built-in support for hexadecimal numbers?


So, in summary, you are suggesting that we tell the scientific and engineering 
communities that we refuse to provide native support for their preferred way of 
writing numbers because:
1. our way is better,
2. their way is bad because some uneducated person might see the numbers and 
not 
   understand them,
3. we already have way of representing numbers that we came up with in the '60s 
   and we simply cannot do another,
4. well we could do it, but we 

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

[Brendan Barnwell]

On 2016-08-28 18:44, Ken Kundert wrote:

When working with a general purpose programming language, the above numbers
become:

 780kpc -> 7.8e+05
 108MPa -> 1.08e+08
 600TW  -> 6e+14
 3.2Gb  -> 3.2e+09
 53pm   -> 5.3e-11
 $8G-> 8e+09

Notice that the numbers become longer, harder to read, harder to type, harder to
say, and harder to hear.


	You've continually repeated this assertion, but I don't buy it.  For 
the general case, exponential notation is easier to read because you can 
always see exactly what the exponent is as a number.  To read SI units, 
you have to know all the SI prefixes.  This may well be common within 
scientific communities, but to say that it is "easier" is really a bit 
much.  The same is true of "harder to type".  "kpc" is three characters; 
e+5 is also three (note that you don't need to write e+05), and one of 
those is a number that transparently indicates how many places to move 
the decimal, whereas all of the letters in "kpc" are opaque unless you 
already know what the number is meant to represent.


	If you have concrete evidence (e.g., from actual user experience 
research) showing that it is across-the-board "easier" to read or type 
SI prefixes than exponential notation, that would be good to see.  In 
the absence of that, these assertions are just doubling down on the same 
initial claim, namely that adding SI units to Python would make things 
more convenient *for those using it to compute with literally-entered 
quantities in SI units*.  I quite agree that that is likely true, but to 
my mind that is not enough to justify the disruption of adding it at the 
syntactic level.  (Unless, again, you have some actual evidence showing 
that this particular kind of use of numeric literals occurs in a large 
proportion of Python code.)


> Before we expend any more effort on this topic, let's put aside the 
question of
> how it should be done, or how it will be used after its done, and 
just focus on
> whether we do it at all. Should Python support real numbers specified 
with SI

> scale factors as first class citizens?

	My current opinion is no.  There are lots of things that are common. 
(Should we include a spellchecker in Python because many people 
frequently make spelling errors?)  The fact that SI units are de rigeur 
in the physical science community isn't enough.  I would want to see 
some actual attempt to quantify how much benefit there would be in the 
PYTHON community (which of course includes, but is not limited to, those 
using Python for physical-science computations).


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] real numbers with SI scale factors

[Ken Kundert]

Wow, things have suddenly turned very negative. I understand that this is very 
normal for these types of forums where it is easy to lose sight of the big 
picture. So let me try to refocus this discussion again.


MOTIVATION

The way the scientific and engineering communities predominately write real 
numbers is by using SI scale factors.  These numbers almost always represent 
physical quantities, so it is common to write the number with scale factor and 
units.  So for example, the distance to Andromeda is 780kpc, the pressure at 
the 
bottom of the Mariana Trench is 108MPa, the total power produced by a typical 
hurricane is 600TW, the number of base pairs in human DNA is 3.2Gb, and the 
Bohr 
radius is 53pm.  These numbers are the language of science and engineering, but 
in recent years they have also entered the realm of popular culture. For 
example, an article by Ars Technica that calculates that the value of the music 
that can fit on a classic iPod as over $8G (that is the total penalty that can 
be accessed if they were all stolen copyright works).

http://arstechnica.com/tech-policy/2012/06/from-gigabytes-to-petadollars-copyright-math-begets-copyright-currency/

In all of these examples the numbers are either very large or very small, and 
they employ the use of SI scale factors to make them easy to write and 
communicate.  This way of writing numbers is so well established that it was
formally standardized as part of the International System of Units (the Système 
international d'unités) in 1960.

The problem is that most general purpose programming languages do not support 
this way of writing numbers. Instead they force people to convert the numbers 
to 
and from exponential notation, which is rather inconvenient and hard to read, 
write, say, or hear (it is much easier to say or hear 53 picometers than 
5.3e-11 
meters).

When working with a general purpose programming language, the above numbers 
become:

780kpc -> 7.8e+05
108MPa -> 1.08e+08
600TW  -> 6e+14
3.2Gb  -> 3.2e+09
53pm   -> 5.3e-11
$8G-> 8e+09

Notice that the numbers become longer, harder to read, harder to type, harder 
to 
say, and harder to hear.


NEXT STEP

So the question is, should Python accommodate this widely used method of 
writing 
real numbers? Python already has many ways of writing numbers. For example, 
Python allows integers to be written in binary, octal, decimal and hex. Any 
number you can write in one form you can write in another, so the only real 
reason for providing all these ways is the convenience of the users. Don't 
Python's users in the scientific and engineering communities deserve the same 
treatment?  These are, after all, core communities for Python.

Now, Python is a very flexible language, and it is certainly possible to add 
simple libraries to make it easy to read and write numbers with SI scale 
factors. I have written such a library (engfmt). But with such libraries this 
common form of writing numbers remains a second class citizen. The language 
itself does not understand SI scale factors, instead any time you want to input 
or output numbers in their natural form you must manually convert them yourself.

Changing Python so that it understands SI scale factors on real numbers as 
first 
class citizens innately requires a change to the base language; it cannot be 
done solely through libraries.  The question before you is, should we do it?

The same question confronted the developers of Python when it was decided to 
add 
binary, octal and hexadecimal number support to Python. You could have done it 
with libraries, but you didn't because binary, octal and hexadecimal numbers 
were too common and important to be left as second class citizens. Well, use of 
binary, octal and hexadecimal numbers is tiny compared to the use of real 
numbers with SI scale factors.

Before we expend any more effort on this topic, let's put aside the question of 
how it should be done, or how it will be used after its done, and just focus on 
whether we do it at all. Should Python support real numbers specified with SI 
scale factors as first class citizens?

What do you think?

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/