You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(9) 

2001 
_{Jan}
(1) 
_{Feb}
(2) 
_{Mar}
(3) 
_{Apr}
(30) 
_{May}
(18) 
_{Jun}

_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2002 
_{Jan}
(7) 
_{Feb}
(2) 
_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}
(3) 
_{Jul}
(13) 
_{Aug}

_{Sep}
(23) 
_{Oct}
(180) 
_{Nov}
(291) 
_{Dec}
(95) 
2003 
_{Jan}
(338) 
_{Feb}
(352) 
_{Mar}
(97) 
_{Apr}
(46) 
_{May}
(226) 
_{Jun}
(184) 
_{Jul}
(145) 
_{Aug}
(141) 
_{Sep}
(69) 
_{Oct}
(161) 
_{Nov}
(96) 
_{Dec}
(90) 
2004 
_{Jan}
(66) 
_{Feb}
(87) 
_{Mar}
(98) 
_{Apr}
(132) 
_{May}
(115) 
_{Jun}
(68) 
_{Jul}
(150) 
_{Aug}
(92) 
_{Sep}
(59) 
_{Oct}
(52) 
_{Nov}
(17) 
_{Dec}
(75) 
2005 
_{Jan}
(84) 
_{Feb}
(191) 
_{Mar}
(133) 
_{Apr}
(114) 
_{May}
(158) 
_{Jun}
(185) 
_{Jul}
(62) 
_{Aug}
(28) 
_{Sep}
(36) 
_{Oct}
(88) 
_{Nov}
(65) 
_{Dec}
(43) 
2006 
_{Jan}
(85) 
_{Feb}
(62) 
_{Mar}
(92) 
_{Apr}
(75) 
_{May}
(68) 
_{Jun}
(101) 
_{Jul}
(73) 
_{Aug}
(37) 
_{Sep}
(91) 
_{Oct}
(65) 
_{Nov}
(30) 
_{Dec}
(39) 
2007 
_{Jan}
(24) 
_{Feb}
(28) 
_{Mar}
(10) 
_{Apr}
(2) 
_{May}
(18) 
_{Jun}
(16) 
_{Jul}
(21) 
_{Aug}
(6) 
_{Sep}
(30) 
_{Oct}
(31) 
_{Nov}
(153) 
_{Dec}
(31) 
2008 
_{Jan}
(63) 
_{Feb}
(70) 
_{Mar}
(47) 
_{Apr}
(24) 
_{May}
(59) 
_{Jun}
(22) 
_{Jul}
(12) 
_{Aug}
(7) 
_{Sep}
(14) 
_{Oct}
(26) 
_{Nov}
(5) 
_{Dec}
(5) 
2009 
_{Jan}
(10) 
_{Feb}
(41) 
_{Mar}
(70) 
_{Apr}
(88) 
_{May}
(49) 
_{Jun}
(62) 
_{Jul}
(34) 
_{Aug}
(15) 
_{Sep}
(55) 
_{Oct}
(40) 
_{Nov}
(67) 
_{Dec}
(21) 
2010 
_{Jan}
(60) 
_{Feb}
(17) 
_{Mar}
(26) 
_{Apr}
(26) 
_{May}
(29) 
_{Jun}
(4) 
_{Jul}
(21) 
_{Aug}
(21) 
_{Sep}
(10) 
_{Oct}
(12) 
_{Nov}
(3) 
_{Dec}
(19) 
2011 
_{Jan}
(3) 
_{Feb}
(13) 
_{Mar}
(8) 
_{Apr}
(8) 
_{May}
(17) 
_{Jun}
(20) 
_{Jul}
(21) 
_{Aug}
(7) 
_{Sep}

_{Oct}

_{Nov}
(9) 
_{Dec}
(11) 
2012 
_{Jan}
(3) 
_{Feb}

_{Mar}

_{Apr}
(5) 
_{May}
(4) 
_{Jun}
(14) 
_{Jul}
(5) 
_{Aug}
(2) 
_{Sep}
(15) 
_{Oct}
(2) 
_{Nov}
(23) 
_{Dec}
(1) 
2013 
_{Jan}
(8) 
_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}
(5) 
_{Jun}
(1) 
_{Jul}
(5) 
_{Aug}
(4) 
_{Sep}

_{Oct}
(12) 
_{Nov}
(10) 
_{Dec}
(3) 
2014 
_{Jan}
(7) 
_{Feb}
(14) 
_{Mar}
(2) 
_{Apr}

_{May}
(2) 
_{Jun}
(11) 
_{Jul}
(10) 
_{Aug}
(4) 
_{Sep}

_{Oct}
(8) 
_{Nov}
(1) 
_{Dec}
(2) 
2015 
_{Jan}
(9) 
_{Feb}
(7) 
_{Mar}
(1) 
_{Apr}

_{May}
(7) 
_{Jun}

_{Jul}
(5) 
_{Aug}
(6) 
_{Sep}

_{Oct}
(1) 
_{Nov}
(4) 
_{Dec}

2016 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(4) 
_{Apr}
(2) 
_{May}
(1) 
_{Jun}

_{Jul}
(6) 
_{Aug}
(8) 
_{Sep}
(21) 
_{Oct}
(17) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(4) 
2

3

4
(2) 
5
(6) 
6
(4) 
7

8
(1) 
9
(9) 
10
(6) 
11

12
(5) 
13
(1) 
14

15

16
(2) 
17
(6) 
18
(6) 
19
(9) 
20
(1) 
21
(3) 
22

23

24
(2) 
25

26

27

28

29

30
(1) 
31




From: Robert Brown <brownr@uc...>  20060517 18:39:12

I'm looking for a list of type signature strings for use with pyobjc.ivar() to specify the type. Any links? Thanks  Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada 
From: Brian O'Brien <bobrien@uc...>  20060517 16:00:39

On 17May06, at 9:51 AM, Bob Ippolito wrote: > > On May 17, 2006, at 5:02 PM, Koen Bok wrote: > >> Thank you for this lesson. While it has to be accepted by an >> accountant, I'll go for the decimal method. >> >> One for the record. >> >> Is it even possible that the accumilated error will be greater >> then .005 when you use currency values (number with max two >> decimals)? > > Sure, consider small numbers > > x = 0.01 * 0.01 * 10 > > Depending on the precision used and the order of operations that > could be zero. > I love these discussions on .01 and .02 etc.. i.e. their floating point precision or in other words the approximation of that number. The number .01 is not perfectly translatable into binary. I seem to remember a story of bank fraud based on the rounding errors going into peoples bank accounts... > bob > > > > >  > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with preintegrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.asus.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Pyobjcdev mailing list > Pyobjcdev@... > https://lists.sourceforge.net/lists/listinfo/pyobjcdev 
From: Bob Ippolito <bob@re...>  20060517 15:51:36

On May 17, 2006, at 5:02 PM, Koen Bok wrote: > Thank you for this lesson. While it has to be accepted by an > accountant, I'll go for the decimal method. > > One for the record. > > Is it even possible that the accumilated error will be greater > then .005 when you use currency values (number with max two decimals)? Sure, consider small numbers x = 0.01 * 0.01 * 10 Depending on the precision used and the order of operations that could be zero. bob 
From: Koen Bok <koen@ma...>  20060517 15:02:44

Thank you for this lesson. While it has to be accepted by an accountant, I'll go for the decimal method. One for the record. Is it even possible that the accumilated error will be greater then . 005 when you use currency values (number with max two decimals)? Koen > This is normal, and has nothing to do with PyObjC, but rather is the > consequence of how floating point values are stored by a computer. > > When you write "76.68", you mean "76 + 68/100". The decimal system of > writing number can thus only express exactly some subset of all > rational > numbers. For example, "1/3" is a rational number, but you can't > write it > in decimal. If you try, you find it is "0.333333333333...". > > Likewise, computers store floating point values somewhat like > fractions, > only instead of powers of 10 as the denominator, they use powers of 2. > Thus, some numbers that can be written in a base 10 decimal system cat > not be written with a finite number of digits in a base 2 decimal > system. > > When whatever language you use (python in this case) parses "76.68" or > whatever in your source code, it picks the binary representation > that is > closest to that number, which might be very slightly different. > This is > why your calculations are 0.00000000000001 in error. > > To avoid this issue, you have at least two solutions: > >  Round the final results to two decimal places, and hope that the > accumilated error will never be more than 0.005 in error. > Accountants > will glare at you since this is a gamble, but it is the easiest to > code, and fastest to compute. > >  Use a class designed for doing base 10 decimal arithmetic. Python > has > the decimal module, Foundation has NSDecimalNumber. This is only a > little more coding effort, but your results will be identical to the > results you would have obtained doing the math with traditional > methods on paper. Arithmetic operations are signifantly slower to > compute, but if you are just adding and multiplying a handfull of > numbers, we are talking in terms of microseconds. 
From: Phil Frost <indigo@bi...>  20060517 14:51:37

On Wed, May 17, 2006 at 04:22:32PM +0200, Koen Bok wrote: > I have this very simple unit test, but it fails! > > Is this normal? > > import unittest > > class OrderProduct(object): > def total(self): > return self.quantity * self.price > > class CaseCheck(unittest.TestCase): > > def setUp(self): > self.orderproduct = OrderProduct() > self.orderproduct.product = Product() > self.orderproduct.product.tax = 19 > > self.test_data = [ > {'quantity': 6, 'price': 12.78, 'total': 76.68}, > {'quantity': 78, 'price': 12.78, 'total': 996.84}, > ] > > def testTaxSanity(self): > """Description of the test""" > for t in self.test_data: > self.orderproduct.quantity = t['quantity'] > self.orderproduct.price = t['price'] > self.assertEqual(self.orderproduct.total(), > t['total']) > > if __name__ == "__main__": > unittest.main() > > F > ====================================================================== > FAIL: Description of the test >  > Traceback (most recent call last): > File "/Users/koen/unit_test.py", line 21, in testTaxSanity > self.assertEqual(self.orderproduct.total(), t['total']) > AssertionError: 76.679999999999993 != 76.680000000000007 > >  > Ran 1 test in 0.001s > > FAILED (failures=1) This is normal, and has nothing to do with PyObjC, but rather is the consequence of how floating point values are stored by a computer. When you write "76.68", you mean "76 + 68/100". The decimal system of writing number can thus only express exactly some subset of all rational numbers. For example, "1/3" is a rational number, but you can't write it in decimal. If you try, you find it is "0.333333333333...". Likewise, computers store floating point values somewhat like fractions, only instead of powers of 10 as the denominator, they use powers of 2. Thus, some numbers that can be written in a base 10 decimal system cat not be written with a finite number of digits in a base 2 decimal system. When whatever language you use (python in this case) parses "76.68" or whatever in your source code, it picks the binary representation that is closest to that number, which might be very slightly different. This is why your calculations are 0.00000000000001 in error. To avoid this issue, you have at least two solutions:  Round the final results to two decimal places, and hope that the accumilated error will never be more than 0.005 in error. Accountants will glare at you since this is a gamble, but it is the easiest to code, and fastest to compute.  Use a class designed for doing base 10 decimal arithmetic. Python has the decimal module, Foundation has NSDecimalNumber. This is only a little more coding effort, but your results will be identical to the results you would have obtained doing the math with traditional methods on paper. Arithmetic operations are signifantly slower to compute, but if you are just adding and multiplying a handfull of numbers, we are talking in terms of microseconds. 
From: Koen Bok <koen@ma...>  20060517 14:22:44
