Re: [Python-Dev] Optional delta argument for assertAlmostEqual
On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote: > Perhaps not just absolute but relative tolerance, e.g.: > > def isclose(x, y, rtol=1.e-5, atol=1.e-8): > return abs(x-y) <= atol + rtol * abs(y) I'm not sure why you add the tolerances like that. Surely a more appropriate approach is to compare the values against the tolerances individually, and return True if they meet either condition. For what it's worth, here's a recipe I wrote for approximately equal, following someone's complaint on comp.lang.python that Python has no approximately-equal operator. http://code.activestate.com/recipes/577124-approximately-equal/ Comments and criticism welcome. I've never found unittest.TestCase.assertAlmostEqual to be useful. I generally write my own comparison function, then call: assert_(compare(x, y)) as needed. I'm +0.5 on Michael's suggested change -- it will make assertAlmostEqual marginally more useful, which is a plus, but I'm not sure that absolute tolerances are better than relative. But how general do we want to be? "Almost equal" means something different to everyone. > On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord wrote: > > Hello all, > > > > A user has suggested an optional argument to > > unittest.TestCase.assertAlmostEqual for specifying a maximum > > difference between the expected and actual values, instead of using > > rounding. [snip] -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
A good summary on floating point comparison algorithms can be found at http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html I, too, redefine almostEquals so that the comparison is more robust +1 On Sun, Mar 28, 2010 at 2:06 AM, Steven D'Aprano wrote: > On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote: > > Perhaps not just absolute but relative tolerance, e.g.: > > > > def isclose(x, y, rtol=1.e-5, atol=1.e-8): > > return abs(x-y) <= atol + rtol * abs(y) > > I'm not sure why you add the tolerances like that. Surely a more > appropriate approach is to compare the values against the tolerances > individually, and return True if they meet either condition. > > For what it's worth, here's a recipe I wrote for approximately equal, > following someone's complaint on comp.lang.python that Python has no > approximately-equal operator. > > http://code.activestate.com/recipes/577124-approximately-equal/ > > Comments and criticism welcome. > > I've never found unittest.TestCase.assertAlmostEqual to be useful. I > generally write my own comparison function, then call: > > assert_(compare(x, y)) > > as needed. I'm +0.5 on Michael's suggested change -- it will make > assertAlmostEqual marginally more useful, which is a plus, but I'm not > sure that absolute tolerances are better than relative. But how general > do we want to be? "Almost equal" means something different to everyone. > > > > > On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord > wrote: > > > Hello all, > > > > > > A user has suggested an optional argument to > > > unittest.TestCase.assertAlmostEqual for specifying a maximum > > > difference between the expected and actual values, instead of using > > > rounding. > [snip] > > > > -- > Steven D'Aprano > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail.com > -- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
On Fri, Mar 26, 2010 at 8:59 PM, Michael Foord wrote: > Hello all, > > A user has suggested an optional argument to > unittest.TestCase.assertAlmostEqual for specifying a maximum difference > between the expected and actual values, instead of using rounding. > > This sounds great to me as the default implementation of assertAlmostEqual > has *never* been useful to me (YMMV). In fact one of the first things I do > on setting up a test suite is provide a TestCase that overrides > assertAlmostEqual with an implementation that uses a delta rather than > rounding. > > The implementation would be effectively: > > assert abs(actual - expected) < delta > > This has the advantage that it allows things like: > > self.assertAlmostEqual(timeStamp, expected, > delta=datetime.timedelta(seconds=5)) > > The issue is this would make the signature of assertAlmostEqual (and its > negative counterpart): > > def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None) > > Note that delta comes after msg, which is different to other assert methods. > To put delta before msg would be backwards incompatible with existing uses > passing arguments positionally. In Python 3.2 we can make delta a keyword > argument. Passing both places and delta would be an error (TypeError). > > Anyway, unless there are strenuous objections I intend to do this. > > All the best, > > Michael +1, this would be very helpful to me. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl
Well, it's been a couple of days, and nobody has stepped forward to speak in favor of my aggressive PyCapsule schedule. So I will bow to the wishes of those who have spoken up, and scale it back. Specifically, I propose writing a patch that will: * allow the CObject API to (unsafely) dereference a capsule * add support for the new files added by capsule to the Visual Studio builds (fixes an unrelated second complaint about my checkin) * add a -3 warning for calls to CObject * add a PendingDeprecation warning to CObject I've gotten in the habit of doing code reviews at work, and I now greatly prefer working that way. Can I get a volunteer to review the patch when it's ready? Please email me directly. Thanks! M.-A. Lemburg wrote: Just as reminder of the process we have in place for such changes: Please discuss any major breakage on python-dev before checking in the patch. I'm aware this is a good idea. I simply didn't consider this a major breakage. Recompiling against the 2.7 header files fixes it for everybody. (Except external users of pyexpat, if any exist. Google doesn't show any, though this is not proof that they don't exist.) If you suggest that any breakage with previous versions is worth mentioning, no matter how small, then I'll remember that in the future. Certainly the Python community has had many thrilling and dynamic conversations over minutae, so I guess it wouldn't be that surprising if this were true. 1. The CObject API isn't safe. It's easy to crash Python 2.6 in just a few lines by mixing and matching CObjects. Switching Python to capsules prevents a class of exploits. I've included a script at the bottom of this message that demonstrates three such crashes. The script runs in Python 2 and 3, but 3.1 doesn't crash because it's using capsules. That's good, but then again: deliberate wrong use of APIs will always cause crashes and at least I don't know of any report about PyCObjects posing a problem in all their years of existence. [...] we've been happy with this vulnerability for years, just as we've been happy with the fact that it's easy to crash the VM by passing hand-crafted byte-code to it, or using ctypes to call an OS function with the wrong parameters, etc. I'm surprised you find that acceptable. I thought the community was in agreement: our goal is to make the interpreter uncrashable from pure Python. I would describe ctypes as "impure" Python. If you wanted to allow untrusted developers to run code through a Python interpreter, you'd harden it: take away ctypes, and the ability to feed in arbitrary bytecode, and reduce the stack limit. You probably wouldn't take away "datetime", "cStringIO", and "cPickle"--yet I can crash 2.6 using those. Third, I've been pondering writing a set of preprocessor macros, shipped in their own header file distributed independently of Python and released to the public domain, that would make it easy to use either CObjects or capsules depending on what version of Python you were compiling against. Obviously, using these macros would require a source code change in the third-party library. But these macros would make it a five-minute change. This could compliment the first or second approaches. I'm not sure whether that would worth the effort. 3rd party modules for Python 2.x are likely not going to use them, since they typically have to support more than just Python 2.7. The point of these macros would be to support older versions of Python. The macros would boil down to either PyCapsule or CObject calls, depending on what version of Python you were compiling against. For Python 2.6 and before it would alway use CObjects. One set of macros would switch to PyCapsule when building against 2.7; another would use CObject permanently in 2.x. (Or maybe it should switch in 2.8? 2.9? But now we're in the realm of speculative fiction.) I'd be happy to write these if there was demand, but my sneaking suspicion is that nobody would use them. If you're genuinely interested in these macros please email me privately. /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
On Sun, 28 Mar 2010 05:32:46 pm Adam Olsen wrote:
> On Sat, Mar 27, 2010 at 18:27, Robert Kern
wrote:
> > On 2010-03-27 13:36 , Adam Olsen wrote:
> >> What's the flaw in using isnan()?
> >
> > There are implicit comparisons being done inside
> > list.__contains__() and other such methods. They do not, and should
> > not, know about isnan().
>
> Those methods should raise an exception. Conceptually, NaN should
> contaminate the result and make list.__contains__() return some
> "unsortable", but we don't want to bend the whole language backwards
> just for one obscure feature, especially when we have a much better
> approach most of the time (exceptions).
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception. Comparing NANs for equality isn't
an error.
+1 on leaving the behaviour alone -- the surprising behaviour people
have pointed out with NANs in lists, dicts and sets occurs more often
in theory than in practice.
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
Steven D'Aprano wrote:
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception.
Yes, I don't think anyone would disagree that NaN should compare
unequal to anything that isn't a NaN. Problems only arise when
comparing two NaNs.
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl
On Sun, Mar 28, 2010 at 3:25 PM, Larry Hastings wrote: > M.-A. Lemburg wrote: > > Just as reminder of the process we have in place for such changes: > Please discuss any major breakage on python-dev before checking in > the patch. > > > I'm aware this is a good idea. I simply didn't consider this a major > breakage. Recompiling against the 2.7 header files fixes it for everybody. > (Except external users of pyexpat, if any exist. Google doesn't show any, > though this is not proof that they don't exist.) > > If you suggest that any breakage with previous versions is worth mentioning, > no matter how small, then I'll remember that in the future. Certainly the > Python community has had many thrilling and dynamic conversations over > minutae, so I guess it wouldn't be that surprising if this were true. I'm curious what is considered reasonable/unreasonable breakage. If this breakage just requires a recompile, then doesn't it just introduce an ABI incompatibility? Aren't those allowed every minor (point) release? Or do people believe that this is more than an ABI change? Reid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
On Sun, Mar 28, 2010 at 17:55, Greg Ewing wrote:
> Steven D'Aprano wrote:
>
>> I disagree -- if I ask:
>>
>> 3.0 in [1.0, 2.0, float('nan'), 3.0]
>>
>> I should get True, not an exception.
>
> Yes, I don't think anyone would disagree that NaN should compare
> unequal to anything that isn't a NaN. Problems only arise when
> comparing two NaNs.
NaN includes real numbers. Although a NaN is originally produced for
results that are not real numbers, further operations could produce a
real number; we'd never know as NaN has no precision. Extending with
complex numbers instead gives enough precision to show how this can
happen.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for commit access
On Wed, Mar 24, 2010 at 12:34 AM, "Martin v. Löwis" wrote: > > Procedurally, I wonder where people got the notion from that you can or > need to apply for commit access. IIUC, it used to be the case that you > would be recommended for commit access, by some (more or less senior) > fellow committer. That person then would work on actually getting commit > access to the new committer - perhaps by first asking other people in > private, to avoid any public embarrassment if access is ultimately > denied. IMO, that committer should then also mentor the new guy, both by > helping out in difficult cases, and by closely following commits to see > whether (possibly unstated) conventions are being followed. That's an ideal case, but it doesn't work, because more or less senior committers are already too busy. If they do not even have time to review issues, followup on patches - how can they monitor who reached the appropriate karma level? -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
On Sun, Mar 28, 2010 at 9:28 AM, Robert Kern wrote: > On 2010-03-27 00:32 , David Cournapeau wrote: >> >> On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger >> wrote: >>> >>> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote: >>> >>> How about raising an exception instead of creating nans in the first >>> place, >>> except maybe within specific contexts (so that the IEEE-754 minded can >>> get >>> their nans working as they currently do)? >>> >>> -1 >>> The numeric community uses NaNs as placeholders in vectorized >>> calculations. >> >> But is this relevant to python itself ? In Numpy, we indeed do use and >> support NaN, but we have much more control on what happens compared to >> python float objects. We can control whether invalid operations raises >> an exception or not, we had isnan/isfinite for a long time, and the >> fact that nan != nan has never been a real problem AFAIK. > > Nonetheless, the closer our float arrays are to Python's float type, the > happier I will be. Me too, but I don't see how to reconcile this with the intent of simplifying nan handling because they are not intuitive, which seems to be the goal of this discussion. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for commit access
> That's an ideal case, but it doesn't work, because more or less senior > committers are already too busy. If they do not even have time to > review issues, followup on patches - how can they monitor who reached > the appropriate karma level? The practice proves to be different. In the recent additions, the new developer had been approached by some committer, suggesting that they apply. So the initiative actually started from a committer who thought that the karma level was appropriate. All I'm asking for is that then this committer takes the issues in his own hands, rather than letting the new developer ask for himself. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
