Re: [Python-Dev] Python-Dev Digest, Vol 69, Issue 143
Greg Ewing wrote:
Steven D'Aprano wrote:
it should be obvious in the same way that string concatenation is
different from numerical addition:
1 + 2 = 2 + 1
'1' + '2' != '2' + '1'
However, the proposed arithmetic isn't just non-
commutative, it's non-associative, which is a
much rarer and more surprising thing. We do
at least have
('1' + '2') + '3' == '1' + ('2' + '3')
But we don't have:
(1e40 + -1e40) + 1 == 1e40 + (-1e40 + 1)
Non-associativity is what makes for floating point headaches.
To my knowledge, floating point is at least commutative.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
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-Dev Digest, Vol 69, Issue 143
On Fri, Apr 17, 2009 at 3:58 PM, Scott David Daniels
scott.dani...@acm.org wrote:
Non-associativity is what makes for floating point headaches.
To my knowledge, floating point is at least commutative.
Well, mostly. :-)
from decimal import Decimal
x, y = Decimal('NaN123'), Decimal('-NaN456')
x + y
Decimal('NaN123')
y + x
Decimal('-NaN456')
Similar effects can happen with regular IEEE 754 binary doubles,
but Python doesn't expose NaN payloads or signs, so we don't
see those effects witihin Python.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
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-Dev Digest, Vol 69, Issue 143
Jared Grubb jared.gr...@gmail.com wrote: On 16 Apr 2009, at 11:42, Paul Moore wrote: The key thing missing (I believe) from dateutil is any equivalent of monthmod. I agree with that. It's well-defined and it makes a lot of sense. +1 But, I dont think monthdelta can be made to work... what should the following be? print(date(2008,1,30) + monthdelta(1)) 2008-02-29 print(date(2008,1,30) + monthdelta(2)) 2008-03-30 print(date(2008,1,30) + monthdelta(1) + monthdelta(1)) 2008-03-29 This is a perceptive observation: in the absence of parentheses to dictate a different order of operations, the third quantity will differ from the second. Furthermore, this won't _always_ be true, just for dates near the end of the month, which is nonintuitive. (Incidentally, this is another reason why this functionality should not just be lumped into timedelta; guarantees that have long existed for operations with timedelta would no longer hold if it tried to deal with months.) I find that date calculations involving months involve a certain amount of inherent confusion. I've tried to reduce this by introducing well-specified functionality that will allow accurate reasoning, as part of the core's included batteries. I think that one who uses these objects will develop an intuition and write accurate code quickly. It is nonintuitive that order of operation matters for addition of months, just as it matters for subtraction and division of all objects, but with the right tools we can deal with this. An interesting consequence is that if I want to determine if date b is more than a month after date a, sometimes I should use: b - monthdelta(1) a rather than a + monthdelta(1) b [Consider a list of run dates for a process that should run the last day of every month: a might be date(2008, 2, 29) while b is date(2008, 3, 31). In this case the two expressions would have different values.] cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 69, Issue 143
Jess Austin wrote: This is a perceptive observation: in the absence of parentheses to dictate a different order of operations, the third quantity will differ from the second. Another aspect of this is the use case mentioned right at the beginning of this discussion concerning a recurring event on a particular day of the month. If you do this the naive way by just repeatedly adding one of these monthdeltas to the previous date, and the date is near the end of the month, it will eventually end up drifting to the 28th of every month. -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 69, Issue 143
Actually, that's a point. If its' the 31st of Jan, then +1 monthdelta will be 28 Feb and another +1 will be 28 March whereas 31st Jan +2 monthdeltas will be 31 March. That's the kind of thing which really needs to be documented, or I think people really will make mistakes. For example, should a monthdelta include a goal-day so that the example above would go 31 Jan / 28 Feb / 31 March? -T On Fri, Apr 17, 2009 at 11:55 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Jess Austin wrote: This is a perceptive observation: in the absence of parentheses to dictate a different order of operations, the third quantity will differ from the second. Another aspect of this is the use case mentioned right at the beginning of this discussion concerning a recurring event on a particular day of the month. If you do this the naive way by just repeatedly adding one of these monthdeltas to the previous date, and the date is near the end of the month, it will eventually end up drifting to the 28th of every month. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 69, Issue 143
Tennessee If its' the 31st of Jan, then +1 monthdelta will be 28 Feb Tennessee and another +1 will be 28 March whereas 31st Jan +2 Tennessee monthdeltas will be 31 March. Other possible arithmetics: * 31 Jan 2008 + monthdelta(2) might be 31 Jan 2008 + 31 days (# days in Jan) + 29 days (# days in Feb) * 31 Jan 2008 + monthdelta(2) might be 31 Jan 2008 + 29 days (# days in Feb) + 31 days (# days in Mar) * Treat the day of the month of the base datetime as an offset from the end of the month. 29 Jan 2007 would thus have an EOM offset of -2. Adding monthdelta(2) would advance you into March with the resulting day being two from the end of the month, or 29 Mar 2007. OTOH, adding monthdelta(1) you'd wind up on 26 Feb 2007. * Consider the day of the month in the base datetime as an offset from the start of the month if it is closer to the start or as an offset from the end of the month if it is closer to the end. 12 Mar 2009 - monthdelta(2) would land you at 12 Jan 2009 whereas 17 Mar 2009 - monthdelta(1) would land you at 12 Feb 2009. My mind spins at all the possibilities. I suspect we've seen at least ten different monthdelta rules just in this thread. I don't know how much sense they all make, but we can probably keep dreaming up new ones until the cows come home. Except for completely wacko sets of rules you can probably find uses for most of them. Bake, baby, bake. pillsbury-doughboy-ly, y'rs, Skip ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 69, Issue 143
On Fri, 17 Apr 2009 12:10:59 pm Tennessee Leeuwenburg wrote: Actually, that's a point. If its' the 31st of Jan, then +1 monthdelta will be 28 Feb and another +1 will be 28 March whereas 31st Jan +2 monthdeltas will be 31 March. That's the kind of thing which really needs to be documented, or I think people really will make mistakes. It might be worth noting as an aside, but it should be obvious in the same way that string concatenation is different from numerical addition: 1 + 2 = 2 + 1 '1' + '2' != '2' + '1' For example, should a monthdelta include a goal-day so that the example above would go 31 Jan / 28 Feb / 31 March? No, that just adds complexity. Consider floating point addition. If you want to step through a loop while doing addition, you need to be aware of round-off error: x = 0.0 step = 0.001 for i in xrange(1000): ... x += step ... x 1.0007 The solution isn't to add a goal to the plus operator, but to fix your code to use a better algorithm: y = 0.0 for i in xrange(1, 1001): ... y = i*step ... y 1.0 Same with monthdelta. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
