This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients mark.dickinson, martin.panter, ned.deily, rhettinger, serhiy.storchaka, steven.daprano, tim.peters, vstinner
Date 2016-08-28.22:02:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1472421755.82.0.248640101852.issue27761@psf.upfronthosting.co.za>
In-reply-to
Content
As I said, the last code I posted is "fast enough" - I can't imagine a real application can't live with being able to do "only" tens of thousands of roots per second.  A geometric mean is typically an output summary statistic, not a transformation applied billions of times to input data.

To get a 100% guarantee of 100% portability (although still confined to IEEE 754 format boxes), we can't use the libm pow() at all.  Then you can kiss speed goodbye.  Mark's `nroot` is portable in that way, but can take tens of thousands of times longer to compute a root.

Here's another way, but routinely 100 times slower (than the last code I posted):

    import decimal
    c = decimal.DefaultContext.copy()
    c.prec = 25

    def slow(x, n,
             D=decimal.Decimal,
             pow=c.power,
             div=c.divide,    
             d1=decimal.Decimal(1)):
        return float(pow(D(x), div(d1, n)))

    del decimal, c

Too slow for my tastes, but at least it's obvious ;-)
History
Date User Action Args
2016-08-28 22:02:35tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, vstinner, ned.deily, steven.daprano, martin.panter, serhiy.storchaka
2016-08-28 22:02:35tim.peterssetmessageid: <1472421755.82.0.248640101852.issue27761@psf.upfronthosting.co.za>
2016-08-28 22:02:35tim.peterslinkissue27761 messages
2016-08-28 22:02:35tim.peterscreate