Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #111216 > unrolled thread

Quick poll: gmean or geometric_mean

Back to article view | Back to comp.lang.python

Contents

  Quick poll: gmean or geometric_mean Steven D'Aprano <steve@pearwood.info> - 2016-07-09 15:26 +1000
    Re: Quick poll: gmean or geometric_mean Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-09 08:43 +0300
    Re: Quick poll: gmean or geometric_mean Random832 <random832@fastmail.com> - 2016-07-09 01:49 -0400
    Re: Quick poll: gmean or geometric_mean Ethan Furman <ethan@stoneleaf.us> - 2016-07-08 23:27 -0700
    Re: Quick poll: gmean or geometric_mean Peter Otten <__peter__@web.de> - 2016-07-09 11:04 +0200
      Re: Quick poll: gmean or geometric_mean Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-12 15:13 -0700
        Re: Quick poll: gmean or geometric_mean Chris Angelico <rosuav@gmail.com> - 2016-07-13 08:17 +1000
    Re: Quick poll: gmean or geometric_mean Stefan Behnel <stefan_ml@behnel.de> - 2016-07-09 12:23 +0200
    Re: Quick poll: gmean or geometric_mean Ethan Furman <ethan@stoneleaf.us> - 2016-07-09 06:51 -0700
    Re: Quick poll: gmean or geometric_mean Jason Friedman <jsf80238@gmail.com> - 2016-07-09 08:16 -0600
    Re: Quick poll: gmean or geometric_mean Michael Selik <michael.selik@gmail.com> - 2016-07-09 16:13 +0000
    Re: Quick poll: gmean or geometric_mean Robert Kern <robert.kern@gmail.com> - 2016-07-09 17:53 +0100
    Re: Quick poll: gmean or geometric_mean Michael Selik <michael.selik@gmail.com> - 2016-07-09 18:31 +0000
    Re: Quick poll: gmean or geometric_mean Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-09 17:39 -0400
    Re: Quick poll: gmean or geometric_mean Chris Angelico <rosuav@gmail.com> - 2016-07-10 07:45 +1000
    Re: Quick poll: gmean or geometric_mean Rustom Mody <rustompmody@gmail.com> - 2016-07-10 00:28 -0700
      Re: Quick poll: gmean or geometric_mean Steven D'Aprano <steve@pearwood.info> - 2016-07-10 18:51 +1000
        Re: Quick poll: gmean or geometric_mean Michael Selik <michael.selik@gmail.com> - 2016-07-10 09:24 +0000
          Re: Quick poll: gmean or geometric_mean Steven D'Aprano <steve@pearwood.info> - 2016-07-10 20:08 +1000
            Re: Quick poll: gmean or geometric_mean Chris Angelico <rosuav@gmail.com> - 2016-07-10 21:07 +1000
            Re: Quick poll: gmean or geometric_mean Rustom Mody <rustompmody@gmail.com> - 2016-07-10 07:29 -0700
              Re: Quick poll: gmean or geometric_mean Rustom Mody <rustompmody@gmail.com> - 2016-07-10 07:44 -0700
              Re: Quick poll: gmean or geometric_mean Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-10 08:55 -0600
                Re: Quick poll: gmean or geometric_mean Marko Rauhamaa <marko@pacujo.net> - 2016-07-10 18:03 +0300
                  Re: Quick poll: gmean or geometric_mean Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-10 11:15 -0600
                    Re: Quick poll: gmean or geometric_mean Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-12 15:17 -0700
                      Re: Quick poll: gmean or geometric_mean alister <alister.ware@ntlworld.com> - 2016-07-12 22:57 +0000
                        Re: Quick poll: gmean or geometric_mean Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-12 18:42 -0700
                          Re: Quick poll: gmean or geometric_mean Gene Heskett <gheskett@shentel.net> - 2016-07-12 21:58 -0400
                          Re: Quick poll: gmean or geometric_mean alister <alister.ware@ntlworld.com> - 2016-07-13 13:03 +0000
                        Re: Quick poll: gmean or geometric_mean Steven D'Aprano <steve@pearwood.info> - 2016-07-13 12:25 +1000
                  Re: Quick poll: gmean or geometric_mean Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-10 19:21 -0400
              Re: Quick poll: gmean or geometric_mean Random832 <random832@fastmail.com> - 2016-07-10 12:08 -0400
              Re: Quick poll: gmean or geometric_mean Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-12 15:19 -0700
            Re: Quick poll: gmean or geometric_mean Michael Selik <michael.selik@gmail.com> - 2016-07-10 15:43 +0000
    Re: Quick poll: gmean or geometric_mean Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-10 01:28 -0600
      Re: Quick poll: gmean or geometric_mean Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-10 11:01 +0300
        Re: Quick poll: gmean or geometric_mean Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-10 09:04 -0600

Page 2 of 2 — ← Prev page 1 [2]

#111245

On Sunday, July 10, 2016 at 3:39:02 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 10 Jul 2016 07:24 pm, Michael Selik wrote:
> 
> > On Sun, Jul 10, 2016, 4:56 AM Steven D'Aprano  wrote:
> > 
> >> On Sun, 10 Jul 2016 05:28 pm, Rustom Mody wrote:
> >>
> >> > From fuzzy memory of sitting in statistics classes decades ago
> >> > filled with μ-σ etc I'd suggest μ gμ hμ
> >>
> >> In all the stats books and references I've seen, μ is always the
> >> population mean (implicitly the arithmetic mean). When discussing the
> >> different kinds of mean, A, G and H are used for arithmetic, geometric
> >> and harmonic means. (Other means are rarely discussed.)
> >>
> >> I don't think I've ever seen gµ or hµ. They're sort of backwards... I'd
> >> expect µ subscript-g or subscript-h, not the other way.
> >>
> > 
> > I'm glad you brought up textbooks as it reminded me to say that most
> > scientific software is still struggling to shake off the legacy of
> > abbreviation.
> > 
> > Now even the basic IPython shell has autocomplete :-)
> 
> Not all shells or editors are IPython, and not all abbreviations are bad.
> Would you rather print, or
> write_values_as_strings_to_the_predefined_standard_output_file?
> 
> :-)

Newton's law F = -Gm₁m₂/r²

Better seen in its normal math form:
https://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Modern_form

De-abbreviated

Force is given by the negative of the universal_gravitational_constant times
the mass_of_first_body times mass_of_second_body divided by the square of the distance_between_the_bodies

Cobol anyone?

Ok with typical python naming

Force = (universal_gravitational_constant * mass_of_first_body * mass_of_second_body) / (distance_between_the_bodies*distance_between_the_bodies)

[toc] | [prev] | [next] | [standalone]

#111246

On Sunday, July 10, 2016 at 8:00:00 PM UTC+5:30, Rustom Mody wrote:
> Newton's law F = -Gm₁m₂/r²
> 
> Better seen in its normal math form:
> https://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Modern_form
> 
> De-abbreviated
> 
> Force is given by the negative of the universal_gravitational_constant times
> the mass_of_first_body times mass_of_second_body divided by the square of the distance_between_the_bodies
> 
> Cobol anyone?

Actually I do injustice to Cobol.
Cobol allowed hyphenated names -- more readable than underscored:

Force is given by the negative of the universal-gravitational-constant times
the mass-of-first-body times mass-of-second-body divided by the square of the distance-between-the-bodies

[toc] | [prev] | [next] | [standalone]

#111247

On Sun, Jul 10, 2016 at 8:29 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Newton's law F = -Gm₁m₂/r²
>
> Better seen in its normal math form:
> https://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Modern_form
>
> De-abbreviated
>
> Force is given by the negative of the universal_gravitational_constant times
> the mass_of_first_body times mass_of_second_body divided by the square of the distance_between_the_bodies
>
> Cobol anyone?
>
> Ok with typical python naming
>
> Force = (universal_gravitational_constant * mass_of_first_body * mass_of_second_body) / (distance_between_the_bodies*distance_between_the_bodies)

That's still excessive by any reasonable standards. Names should be
descriptive, but no more verbose than necessary. How about:

force_N = -G * mass1_kg * mass2_kg / distance_m ** 2

I'm fine with "G" as is because it's the standard name for the value
in physics contexts, and it's presumably defined in the code as a
constant. It's every bit as clear as "pi".

[toc] | [prev] | [next] | [standalone]

#111248

Ian Kelly <ian.g.kelly@gmail.com>:

> That's still excessive by any reasonable standards. Names should be
> descriptive, but no more verbose than necessary. How about:
>
> force_N = -G * mass1_kg * mass2_kg / distance_m ** 2

Why bother with tagging the names with standard units?

Somewhat related: Many programming frameworks standardize on
milliseconds when expressing durations. Python does the honorable thing
and uses the standard unit, the second, for the purpose. For example,

    coroutine asyncio.wait(futures, *, loop=None, timeout=None,
                           return_when=ALL_COMPLETED)

       [...]

       timeout can be used to control the maximum number of seconds to
       wait before returning. timeout can be an int or float. If timeout
       is not specified or None, there is no limit to the wait time.

   <URL: https://docs.python.org/3/library/asyncio-task.html?highligh
   t=asyncio.wait>


Not only is a universal standard followed but the API is future proof as
it allows for (almost) arbitrary granularity. Want to timeout after 17
femtoseconds? Just specify timeout=17e-15.


Marko

[toc] | [prev] | [next] | [standalone]

#111254

On Sun, Jul 10, 2016 at 9:03 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> That's still excessive by any reasonable standards. Names should be
>> descriptive, but no more verbose than necessary. How about:
>>
>> force_N = -G * mass1_kg * mass2_kg / distance_m ** 2
>
> Why bother with tagging the names with standard units?

The point of the example was to demonstrate descriptive names. For
local variables I usually wouldn't bother with the units, but in
general it's a good practice to help avoid crashing your orbiter into
Mars.

> Shouldn't it be G_N_m2_per_kg2, given your strategy for identifying the
> units associated with the other variables?

To me, the use of the standard name implies standard units, so no, "G"
is sufficient. YMMV.

[toc] | [prev] | [next] | [standalone]

#111357

On Monday, July 11, 2016 at 5:16:53 AM UTC+12, Ian wrote:

> For local variables I usually wouldn't bother with the units, but in
> general it's a good practice to help avoid crashing your orbiter into
> Mars.

The Mars Climate Orbiter fiasco wasn’t a problem with using the wrong units (dimensional analysis would have picked that up), but with using wrong unit _systems_.

Ironic to see a country that fought a war to liberate itself from an empire, still stay so wedded to “imperial” units...

[toc] | [prev] | [next] | [standalone]

#111360

On Tue, 12 Jul 2016 15:17:58 -0700, Lawrence D’Oliveiro wrote:

> On Monday, July 11, 2016 at 5:16:53 AM UTC+12, Ian wrote:
> 
>> For local variables I usually wouldn't bother with the units, but in
>> general it's a good practice to help avoid crashing your orbiter into
>> Mars.
> 
> The Mars Climate Orbiter fiasco wasn’t a problem with using the wrong
> units (dimensional analysis would have picked that up), but with using
> wrong unit _systems_.
> 
> Ironic to see a country that fought a war to liberate itself from an
> empire, still stay so wedded to “imperial” units...

The are not.

a US gallon is smaller than an Imperial Gallon
a US Mile is shorter than an Imperial mile
and probably most importantly (because it means they keep serving me 
short measures) a US pint is smaller than an Imperial Pint



-- 
Those who cannot remember the past are condemned to repeat it.
		-- George Santayana

[toc] | [prev] | [next] | [standalone]

#111368

On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:

> a US gallon is smaller than an Imperial Gallon
> a US Mile is shorter than an Imperial mile
> and probably most importantly (because it means they keep serving me 
> short measures) a US pint is smaller than an Imperial Pint

I thought everything was bigger in the USA...

[toc] | [prev] | [next] | [standalone]

#111369

On Tuesday 12 July 2016 21:42:44 Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:
> > a US gallon is smaller than an Imperial Gallon
> > a US Mile is shorter than an Imperial mile
> > and probably most importantly (because it means they keep serving me
> > short measures) a US pint is smaller than an Imperial Pint
>
> I thought everything was bigger in the USA...

Only the lies the pols tell us thru the mainsleaze media we loosely call 
news.  And although Texas is indeed pretty good sized, they still use 
the std definition for a foot, mile or gallon.  Been there, checked it 
out personally.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#111394

On Tue, 12 Jul 2016 18:42:44 -0700, Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:
> 
>> a US gallon is smaller than an Imperial Gallon a US Mile is shorter
>> than an Imperial mile and probably most importantly (because it means
>> they keep serving me short measures) a US pint is smaller than an
>> Imperial Pint
> 
> I thought everything was bigger in the USA...



well the us fluid ounce is bigger but the US pint is only 16 oz.

that is why they keep giving me short measures unless I go to the correct 
places (The Pub in the Montecarlo Las Vegas offers both sizes :-) ) 

-- 
The more you complain, the longer God lets you live.

[toc] | [prev] | [next] | [standalone]

#111370

On Wed, 13 Jul 2016 08:57 am, alister wrote:

> a US gallon is smaller than an Imperial Gallon
> a US Mile is shorter than an Imperial mile
> and probably most importantly (because it means they keep serving me
> short measures) a US pint is smaller than an Imperial Pint

That's okay, they charge you more to make up for it being smaller.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111258

On Sun, 10 Jul 2016 11:15:59 -0600, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:

>The point of the example was to demonstrate descriptive names. For
>local variables I usually wouldn't bother with the units, but in
>general it's a good practice to help avoid crashing your orbiter into
>Mars.
>
	That was a fault in the external documentation... the code was
perfectly consistent... using ft/sec, slugs, etc. rather than metric. <G>

	The names internally would have had no effect if the documentation to
the users never mentioned the units in use.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#111252

On Sun, Jul 10, 2016, at 10:55, Ian Kelly wrote:
> force_N = -G * mass1_kg * mass2_kg / distance_m ** 2
> 
> I'm fine with "G" as is because it's the standard name for the value
> in physics contexts, and it's presumably defined in the code as a
> constant. It's every bit as clear as "pi".

Shouldn't it be G_N_m2_per_kg2, given your strategy for identifying the
units associated with the other variables?

[toc] | [prev] | [next] | [standalone]

#111358

On Monday, July 11, 2016 at 2:30:00 AM UTC+12, Rustom Mody wrote:

> Force is given by the negative of the universal_gravitational_constant times
> the mass_of_first_body times mass_of_second_body divided by the square of
> the distance_between_the_bodies
> 
> Cobol anyone?

Look at it this way: the ancients (Greeks, Babylonians etc) were doing their maths in the equivalent of Cobol.

The reason why mathematicians invented short names for things was because it made the structure easier to see. Being able to easily manipulate that structure is key to solving mathematical problems.

[toc] | [prev] | [next] | [standalone]

#111251

On Sun, Jul 10, 2016, 5:08 AM Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Jul 10, 2016 at 8:08 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
> >> Now even the basic IPython shell has autocomplete :-)
> >
> > Not all shells or editors are IPython, and not all abbreviations are bad.
> > Would you rather print, or
> > write_values_as_strings_to_the_predefined_standard_output_file?
>
> Also: Interesting that the IPython shell is "basic". I thought the
> basic Python shell was the one you get when you type "python" with no
> args. Idle or IPython or anything else is a layer on top of that.
>

It is. I meant the basic terminal version of IPython, rather than the QT or
Jupyter version.

IPython 5 switched from readline to prompt_toolkit, so it gained a few nice
features.

>

[toc] | [prev] | [next] | [standalone]

#111239

On Sat, Jul 9, 2016 at 3:45 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jul 9, 2016 at 3:26 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> I'd like to get a quick show of hands regarding the names. Which do you
>> prefer?
>>
>> hmean and gmean
>>
>> harmonic_mean and geometric_mean
>
> I'd prefer the shorter names.

I'd prefer the longer. Anybody who wants gmean can easily type:

    from statistics import geometric_mean as gmean

[toc] | [prev] | [next] | [standalone]

#111240

Ian Kelly <ian.g.kelly@gmail.com> writes:

> On Sat, Jul 9, 2016 at 3:45 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Jul 9, 2016 at 3:26 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>> I'd like to get a quick show of hands regarding the names. Which do you
>>> prefer?
>>>
>>> hmean and gmean
>>>
>>> harmonic_mean and geometric_mean
>>
>> I'd prefer the shorter names.
>
> I'd prefer the longer. Anybody who wants gmean can easily type:
>
>     from statistics import geometric_mean as gmean

That argument goes both ways with equal force. Possibly very slightly in
favour of the *shorter* names, for those who are happy to import the
function with its eventual name as is.

I did say "very slightly".

[toc] | [prev] | [next] | [standalone]

#111249

On Sun, Jul 10, 2016 at 2:01 AM, Jussi Piitulainen
<jussi.piitulainen@helsinki.fi> wrote:
> Ian Kelly <ian.g.kelly@gmail.com> writes:
>
>> On Sat, Jul 9, 2016 at 3:45 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Sat, Jul 9, 2016 at 3:26 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>>> I'd like to get a quick show of hands regarding the names. Which do you
>>>> prefer?
>>>>
>>>> hmean and gmean
>>>>
>>>> harmonic_mean and geometric_mean
>>>
>>> I'd prefer the shorter names.
>>
>> I'd prefer the longer. Anybody who wants gmean can easily type:
>>
>>     from statistics import geometric_mean as gmean
>
> That argument goes both ways with equal force. Possibly very slightly in
> favour of the *shorter* names, for those who are happy to import the
> function with its eventual name as is.
>
> I did say "very slightly".

No, it doesn't. That the user can alias the name in their own code is
not an advantage at all for picking a non-descriptive name. It doesn't
change the fact that you have a non-descriptive name for the function
in the docs, the examples, and as the default. And do you really think
that anybody would ever choose an alias to make the name of a function
*longer*?

If you start out with the descriptive name though, then you get all
the benefits of such, and users who want to can easily shorten it. And
then even in code where it's been aliased to be shorter, the full
descriptive name is still visible in at least one place -- the import
statement -- which is at least somewhat helpful to anybody reading the
module who isn't familiar with the "gmean" function.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web