Menu
▾
▴
numpy-discussion — Discussion list for all users of Numerical Python
You can subscribe to this list here.
| 2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
| 2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
| 2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
| 2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
| 2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
| 2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
|
From: Charles R H. <cha...@gm...> - 2006-10-12 22:28:11
|
On 10/12/06, Charles R Harris <cha...@gm...> wrote:
>
>
>
> On 10/12/06, Greg Willden <gre...@gm...> wrote:
> >
> > On 10/12/06, Charles R Harris <cha...@gm... > wrote:
> > >
> > > I'm guessing that the rcond number in the lstsq version (default
> > > 1e-10) is the difference. Generally the lstsq version should work better
> > > than the MPL version because at*a is not as well conditioned and vandermonde
> > > matrices are notoriously ill conditioned anyway for higher degree fits. It
> > > would help if you attached the data files in ascii form unless they happen
> > > to contain thousands of data items. Just the x will suffice, zip it up if
> > > you have to.
> > >
> >
> >
> > Here are the files.
> >
> > Since the two algorithms behave differently and each has it place then
> > can both be included in numpy?
> > i.e. numpy.polyfit(x,y,N, mode='alg1')
> > numpy.polyfit (x,y,N, mode='alg2')
> >
> > replacing alg1 and alg2 with meaningful names.
> >
>
> The polyfit function looks seriously busted. If I do the fits by hand I
> get the same results using the (not so hot) MPL version or lstsq. I don't
> know what the problem is. The docstring is also incorrect for the method.
> Hmmm...
>
Polyfit seems overly conservative in its choice of rcond.
In [101]: lin.lstsq(v,y,1e-10)[0]
Out[101]:
array([ 5.84304475e-07, -5.51513630e-03, 1.51465472e+01,
3.05631361e-02])
In [107]: polyfit(x,y,3)
Out[108]:
array([ 5.84304475e-07, -5.51513630e-03, 1.51465472e+01,
3.05631361e-02])
Compare
In [112]: lin.lstsq(v,y,1e-12)[0]
Out[112]:
array([ -5.42970700e-07, 1.61425067e-03, 1.99260667e+00,
6.51889107e+03])
In [113]: dot(lin.inv(vtv),dot(v.T,y))
Out[113]:
array([ -5.42970700e-07, 1.61425067e-03, 1.99260667e+00,
6.51889107e+03])
So the default needs to be changed somewhere. Probably polyfit shoud accept
rcond as a keyword. Where the actual problem lies is a bit obscure as the
normal rcond default for lin.lstsq is 1e-12. Maybe some sort of import error
somewhere down the line.
Chuck
|
|
From: Charles R H. <cha...@gm...> - 2006-10-12 22:03:06
|
On 10/12/06, Greg Willden <gre...@gm...> wrote: > > On 10/12/06, Charles R Harris <cha...@gm...> wrote: > > > > I'm guessing that the rcond number in the lstsq version (default 1e-10) > > is the difference. Generally the lstsq version should work better than the > > MPL version because at*a is not as well conditioned and vandermonde matrices > > are notoriously ill conditioned anyway for higher degree fits. It would help > > if you attached the data files in ascii form unless they happen to contain > > thousands of data items. Just the x will suffice, zip it up if you have to. > > > > > Here are the files. > > Since the two algorithms behave differently and each has it place then can > both be included in numpy? > i.e. numpy.polyfit(x,y,N, mode='alg1') > numpy.polyfit (x,y,N, mode='alg2') > > replacing alg1 and alg2 with meaningful names. > The polyfit function looks seriously busted. If I do the fits by hand I get the same results using the (not so hot) MPL version or lstsq. I don't know what the problem is. The docstring is also incorrect for the method. Hmmm... Chuck |
|
From: Greg W. <gre...@gm...> - 2006-10-12 21:15:36
|
Mgo0CjAKMTYKMQozCjE0CjE3CjEyCjEzCjgKNwo1CjExCjIzCjE5CjI0CjkKMTgKMTUKNDQKMjIK MjAKMjUKMjcKMTAKNDEKNDUKMjYKNDAKMjEKNTAKMjkKMzgKMjgKMzcKNTMKNDgKNTcKNzgKNTQK NjEKMzkKNjQKNjUKNTgKNDMKMzUKNTUKNDcKNjAKNjYKNDYKNjgKNTIKNTEKNDIKNzUKOTMKNTYK ODcKNzQKNTkKNzEKODQKNDkKNzIKODEKNzMKNjMKOTQKNjcKMzYKODAKMzAKNzAKMTA2CjY5CjYy Cjc3Cjc2CjkwCjk4CjEwMwo2CjE3Mgo3OQo4Mwo4MgozMQo4NQo5NwoxMDUKOTEKMTIxCjg5Cjk1 CjEwMQoxMTYKMTM1CjkyCjEwMgo5Ngo4OAoxMjAKMTM3CjEzNgozNAozODkKNDk5CjQ4OQo1NjUK NDc5CjU1NQo0MTIKMzkwCjQ0Mwo0NDIKNDU2CjM2NQo0MDQKNTkzCjQ1NwozNjQKMzc1CjQ0MQoz NjcKMzYwCjQ1MwozNzYKNDgyCjU3Ngo1NTAKNDQ1CjQwOQo2NTgKMzYzCjQzNQozODEKNDc3CjU0 OQozOTYKNDYwCjU0NAo2MDEKNDY2CjM4NAo1NTcKMzkxCjQ2MQo1MTEKNjQyCjU0Nwo1NTgKNTQy CjYxMAo2MDgKNjM5CjQzOAo1OTEKNTUxCjM3OAo1OTkKNTUyCjM5Nwo1NjkKNTc4CjQzNwo2NDMK MzYxCjM4NQozOTkKNTM4CjYwMAozOTUKNTYxCjYwMgo2NDkKNDU0CjQ2NAo0NDcKMzg2CjUzNQo1 NTQKNTc3CjU5Ngo2ODYKNjM1CjQ1OQo1MTQKNjI4CjQ0OAo1ODMKNDA3CjQwOAo2MDMKMzc5CjYy Ngo0MTAKNTAwCjU3MAo0NDkKNTgyCjQzNAo0MDEKNDE3CjUwMQo0NjIKNTY2CjM2NgozOTQKNjMx CjQ4NQozODIKNTYzCjM2OQo3ODQKNzgxCjgyNAo4MzgKNzgzCjgyNgo4MjUKODU0Cjg2Nwo3NjMK ODAxCjc5OQo4NzkKNzk1Cjc1OQo4NTIKODcyCjgzMQo4MDIKNzY5Cjg3Mwo3NzMKNzYyCjc3OQo3 NzIKNzg5CjgzNgo4ODEKODM5CjgyNwo3OTYKODgyCjg1MQo3ODYKNzk3Cjc1NQo3MjYKODQxCjg5 Ngo4NjUKODkwCjgzNwo4NTcKNzc1Cjg1Mwo3NjcKNzg1Cjc1Ngo3NTAKNzU0Cjg4Nwo4NjEKODk0 Cjc3MAo3NDkKNzcxCjg0MAo4NDQKNzgyCjc4MAo4NzcKODU5Cjc3NAo4MzIKODcxCjczMAo3MjIK OTAxCjc5NAo4ODQKODQ2Cjc2MAo4NDgKNzI5Cjg3Ngo3MjQKNzIwCjc1Nwo4MzAKNzk4Cjg1MAo4 MTgKNzY0Cjg3NQo3ODcKODI5Cjg5OQo4ODUKODc0Cjk2MAo4MTUKODY0Cjc3Nwo3MjMKODIwCjg5 MQo3NDcKNzUxCjcyNQo4MjEKNzc2CjgyMwo4NjYKODAwCjgzMwo3ODgKNzU4Cjg3OAoxNDExCjEz NTAKMTM1OAoxMzUzCjEzNjIKMTM3OAoxMzI2CjEzNDgKMTMyMQoxMzU1CjEzNTcKMTM0OQoxMzUy CjEzNDYKMTM3MwoxNDMwCjE0MDgKMTM1MQoxMzEwCjE0MTgKMTI4MQoxMzM2CjE0MTYKMTQyOAox NDIzCjE0MzYKMTM2NAoxNDMyCjE0MTkKMTM3NwoxNDIxCjEzNTkKMTI3OQoxNDAxCjE0MjQKMTMy MwoxMzQwCjEzMjIKMTMzOQoxNDA3CjE0MzgKMTQyNwoxMjQ3CjE0MzUKMTI5MAoxMzExCjEyNjIK MTM0MwoxMzA3CjE0MzcKMTM2OQoxMzE1CjEyODgKMTM1NgoxNDEyCjEzMDkKMTMyNwoxMjc2CjEz NjcKMTMyNQoxNDI1CjE0MjAKMTM0NAoxMzYxCjEzMzcKMTM2OAoxMzE0CjE0MTUKMTMzNQoxMjc4 CjEzMjAKMTI4MAoxMzgyCjEyODIKMTQzNAoxMzI4CjEyNzMKMTMzMgoxNDEwCjEzNDcKMTI4NAox MzM4CjE0MTcKMTM1NAoxMzYwCjEzMjkKMTI3MAoxMzA1CjEzNzUKMTQxNAoxMjg3CjEyOTEKMTQy OQoxMzc5CjEyNTYKMTM3MgoxMzcwCjEyODkKMTMwNgoxMjc1CjEzNDIKMTI3NAoxMjg2CjEzMTMK MTI3MQoxMjQ4CjEzMTkKMTI2OAoxNDc5CjE0NDAKMTQ1MgoxNDQ5CjE0NDEKMTU0MgoxNDQ0CjE0 NDcKMTY0NQoxNTY5CjE0ODUKMTUzNwoxNTI3CjE1MjIKMTQ2MgoxNDYxCjE1NTQKMTY1MQoxNDQ4 CjE2NTIKMTUzOAoxNTI5CjE1MTAKMTQ1MQoxNjM5CjE1NzAKMTQ4NgoxNzM3CjE0ODEKMTYyMwox NzI1CjE0NTMKMTQ1OAoxNDU5CjE2ODAKMTQ4NAoxNDQ1CjE2NzEKMTQ2MAoxNTI0CjE2NzMKMTY2 NgoxNjI3CjE1NDAKMTU2NAoxNjI2CjE2NzIKMTQ5OQoxNjc0CjE1NjEKMTU1NQoxNTE5CjE0NzIK MTYzMgoxNTM0CjE1NDgKMTY1MAoxNDcwCjE2NTYKMTYzNwoxNjQ4CjE3MTcKMTY2MQoxNTIxCjE3 MjQKMTc1NQoxNjMxCjE3MzUKMTUxNwoxNjY3CjE1NTEKMTcyOAoxNTY2CjE1NzUKMTUxNQoxNTM5 CjE1MzEKMTU0MQoxNTYzCjE1NTgKMTY0MwoxNDU0CjE1NDkKMTc1OAoxNDgzCjE3NjEKMTcxNAox NjM4CjE1MDUKMTY1NAoxNjY0CjE0NzUKMTU1NgoxNDczCjE1MjgKMTUxNgoxNTUyCjE0NDMKMTcw OQoxNTUzCjE3OTQKMTU3MQoxNjQ0CjE1MjAKMTcxOAoxNzQyCjE0OTgKMTczNgoyMTQ5CjIwNTIK MjEyOAoyMTQxCjIwMTkKMjEwOAoyMTI1CjE5OTgKMjA1NQoyMDg3CjIxMDYKMjEyMwoyMDI5CjIw MzYKMTk2MAoyMTIxCjIwNDkKMTk0NQoyMTMyCjIwNTgKMjAzNQoyMTQ0CjIwNTMKMjEwOQoxOTYz CjE5NDkKMTk2NgoyMTM3CjIwNjAKMjE1MwoyMTQ3CjE5NTYKMjEyNgoyMTE1CjIxMzAKMjEyOQox ODA4CjIwMjEKMjAzOAoxODA0CjIwNjQKMjEwNAoxOTUyCjIxMDcKMTkxMQoxOTU4CjIxMTYKMTgx MAoyMDMxCjE5NDAKMjE0OAoyMTE3CjIxNTAKMTgxNAoyMDU5CjE5MTYKMjAxMAoyMDI2CjE4MDkK MTk2NAoyMTAzCjIwMzIKMjAzOQoyMTE4CjIxNTEKMTk3MwoyMTUyCjE5NTEKMjA4NAoyMDExCjIw NjUKMjEwNQoyMDI4CjIxMTIKMjA0NAoyMDQwCjIxMjIKMjAzMwoxODEyCjE5NDEKMTk0NgoxOTg3 CjE5OTYKMjEyNwoyMTEzCjIwNDgKMTk5NQoxOTUwCjIxNTUKMTk1OQoyMTM4CjE4MDMKMTk3MAox OTYxCjIwMjAKMjAwOAoxODExCjE5NjgKMTk2NQoxOTQ3CjE4MTkKMjAzNwoyMDYzCjE4MTcKMjEz MwoxOTY3CjIxNDAKMjA0NwoyMTg1CjIxNjEKMjIxNwoyMjQxCjIxNjMKMjE2NAoyMjEyCjIyMjAK MjI0NwoyMTYyCjIyMDgKMjI0OAoyMjI1CjIyNTUKMjIwNgoyMTkxCjIyMTgKMjE2NQoyMjM4CjIy MzcKMjE2NgoyMjMxCjIyMTEKMjE5MgoyMjU4CjIyMzMKMjIwMQoyMjIxCjIyMzkKMjI1MQoyMjQ5 CjIyMTkKMjE4NgoyMTk3CjIyNDYKMjIxMAoyMTk5CjIxODQKMjIyNgoyMjQzCjIxODgKMjI0MAoy MjUwCjIyMDQKMjIwNQoyMTkzCjIyNjAKMjE2MAoyMjM2CjIxODcKMjIyOAoyMTgyCjIyMjMKMjIx NQoyMjI0CjIyMzUKMjIxMwoyMTk4CjIxNjgKMjIwMgoyMTk1CjIxODMKMjI1MwoyMjA5CjIyMzQK MjI4OAoyMjYxCjIyNTYKMjI1NAoyMjAwCjIyNTcKMjI0MgoyMTY3CjIyODAKMjI1MgoyMjQ1CjIy MDcKMjI2MwoyMjE2CjIyNzcKMjI4NAoyMjQ0CjIxOTAKMjI1OQoyMjY2CjIyNjcKMjE4MAoyMjI3 CjIxOTYKMjIyOQoyMjk3CjIxODkKMjE2OQoyMjk2CjIxODEKMjI3OQoyMjgxCjIxNzkKMjE3OAoy MTk0CjIyODcKMjIyMgoyMjg1CjIyMzIKMjMwMQoyMjY0CjIyMTQKMjI4OQoyNzg3CjI3MTQKMjgy MwoyNTkxCjI2NDAKMjcxNwoyNjUwCjI2MTIKMjgzOAoyNjMwCjI4MjcKMjU4OAoyNjg1CjI2ODQK MjY3NwoyNzIwCjI2MTMKMjg3MgoyNzI5CjI4MDQKMjYyMgoyODQxCjI2NDIKMjY5NAoyODY3CjI2 OTMKMjg2NQoyNjAxCjI4MDgKMjg3MAoyNjkxCjI2MDcKMjg3NwoyNjIwCjI4MzYKMjgzNQoyNTc2 CjI1OTYKMjYzNgoyODA1CjI4MDIKMjYwMwoyNTc5CjI3OTcKMjYxMAoyNTc3CjI3MTYKMjgzMgoy NjI2CjI2NzYKMjY3OAoyODczCjI3ODUKMjYzMgoyNjA4CjI2OTIKMjY0MwoyNzI2CjI4MTMKMjYx NAoyNjc1CjI3OTEKMjgwMwoyNjQ0CjI3MDEKMjgwMQoyNTk0CjI3MzcKMjYyNQoyODI2CjI4MzkK MjY0OQoyNzAwCjI3OTkKMjYzNAoyNjk1CjI3MzAKMjU5MgoyODc0CjI2NjcKMjY0NwoyNjgzCjI1 ODYKMjcyMgoyNjc5CjI2NjkKMjYyOQoyODcxCjI1NDkKMjczMwoyNTgyCjI2MzEKMjgwNwoyNjA2 CjI2NDEKMjcyNwoyNzI0CjI2NTIKMjYyMwoyNzgzCjI2NDYKMjgyMQoyNjAyCjI3MDIKMjcwOAoy NTg5CjI4MTUKMjg0MgozMjIyCjMyMzAKMzIyOQoyODk4CjMyMjgKMzIxNAozMjMyCjMyMDgKMzIx MwoyOTMxCjMyMDIKMjg4NgoyOTIyCjMyMDUKMzIyMQozMjM1CjMyMTIKMzIwNAoyODg3CjI4OTMK MzIwOQoyOTA3CjI5MjEKMzIzMQoyODkxCjI5MTQKMzIyMwozMjI0CjI4OTAKMjkxMQozMTg5CjI4 OTYKMzIzMwoyOTA5CjI5MTcKMzIyMAozMTk4CjMyMDcKMzIyNgozMjI3CjI5MDAKMjg4OQozMjI1 CjI5MjMKMjg4NAozMjAzCjMxOTIKMjkxMAoyOTI2CjMyMTAKMjg4NQoyOTA1CjI5MTMKMjg5NQoy ODk3CjI5MTgKMjkyNAozMjAwCjI5MjcKMjkzNAozMjM0CjI5MTIKMzIwNgozMTg3CjMyMzYKMzE5 NgoyODgxCjMyMzgKMzE5MAozMjE5CjI4OTkKMjkzNgozMjM3CjMxOTkKMjkxOQoyOTE1CjI4ODIK MzIxNQozMTg4CjI5MDIKMjkzNwoyOTA2CjI5MzAKMjkwMQoyODgzCjMxOTcKMjkwOAoyOTA0CjMx OTMKMzIwMQozMjE4CjI5MjUKMjg5MgoyOTE2CjMxOTQKMjkzOQozMTk1CjI4ODgKMzE5MQoyODgw CjI4OTQKMjkzNQoyOTMyCjI5NDQKMjkyMAoyOTI4CjI5MjkKMjkzOAozNTgxCjM1NzYKMzU3Mgoz NTcxCjM1NjgKMzU3NQozNTY5CjM1NjYKMzU2MgozNTc0CjM1NzcKMzU2NQozNTcwCjM1NTkKMzU1 MAozNTgyCjM1NzgKMzU4NQozNTgzCjM1NjAKMzU3MwozNTYzCjM1ODAKMzU4OAozNTg2CjM1ODQK MzU3OQozNTY0CjM1NjcKMzU2MQozNTQ5CjM1ODcKMzU1MQozNTkwCjM1OTEKMzU4OQozNTU4CjM1 MTUKMzUyMwozNTExCjM1MjYKMzU1MgozNTEyCjM1NDcKMzUxMAozNTA4CjM1MjAKMzUwMwozNTI0 CjM1MDkKMzUxOAozNTU3CjM1NDUKMzU0OAozNTE0CjM1OTIKMzUxNwozNTE5CjM1MjgKMzUxMwoz NTIyCjM0ODgKMzUyMQozNDg3CjM1MTYKMzU0NAozNDk3CjM1NTMKMzUwNwozNTI1CjM1MDQKMzU0 NgozNDk5CjM0OTAKMzUyNwozNDkyCjM0OTQKMzUwMQozNDg5CjM1MDAKMzU5MwozNDkxCjM0OTYK MzMxMQozNDU4CjMzMDYKMzU5NAozNDk1CjMzOTQKMzU0MwozNDk4CjMyNzcKMzQ4NgozNTAyCjMz NzAKMzUwNQozMzA4CjM0NjAKMzQ2OQozNDU5CjM0NjYKMzQ4MwozMzY2CjM0ODIKMzI2OQozMzIz CjMyNjQKMzQ4NQo= |
|
From: Rob H. <he...@ta...> - 2006-10-12 20:59:23
|
>>>numpy.test(10,10) : : : Ran 512 tests in 0.995s OK <unittest.TextTestRunner object at 0x344ded0> >>> numpy.__version__ '1.0.dev3320' on Intel Mac OS X 10.4.8, macpython 2.5 [Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)] -Rob On Oct 12, 2006, at 2:24 PM, Tim Hochberg wrote: > > I just checked in a couple of changes to SVN. I was going to check in > errstate, but it looks like Travis beat me to it, so I contented > myself > with adding a docstring and some tests. These tests are only run > under > 2.5; things seem to work fine here, but if someone on a Linux box > whose > running Python 2.5 could try it out I'd appreciate it. I'm > suspicous of > Linux/Windows differences right now because of my run in with them > earlier today in the tests for test_multiarray (which I believe it now > fixed -- at least everything is working here OK). > > -tim > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion ---- Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 |
|
From: Charles R H. <cha...@gm...> - 2006-10-12 20:51:09
|
On 10/12/06, Greg Willden <gre...@gm...> wrote: > > Hi All, > I'm using numpy.polyfit and it is giving me some really strange results > when evaluated near 0. So I compared it with polyfit in matplotlib and the > code and docstrings are nearly identical. However the slight differences in > the code make a huge difference on my data. > > Here is the Numpy version with line numbers added: > 1 x = NX.asarray(x)+0. > 2 y = NX.asarray(y)+0. > 3 y = NX.reshape(y, (len(y), 1)) > 4 X = vander(x, N+1) > 5 c, resids, rank, s = _lstsq(X, y) > 6 c.shape = (N+1,) > 7 return c > > > And here is the MPL version with line numbers added: > 1 x = asarray(x)+0. > 2 y = asarray(y)+0. > 3 y = reshape(y, (len(y),1)) > 4 X = Matrix(vander(x, N+1)) > 5 Xt = Matrix(transpose(X)) > 6 c = array(linear_algebra.inverse(Xt*X)*Xt*y) # convert back to array > 7 c.shape = (N+1,) > 8 return c > > > So lines 1-4 are basically the same. > The MPL version produces a much more stable representation of my data > > Can someone please comment on the differences? > Should these two be exactly the same? > If not, what are the advantages to each algorithm? I'm guessing that the rcond number in the lstsq version (default 1e-10) is the difference. Generally the lstsq version should work better than the MPL version because at*a is not as well conditioned and vandermonde matrices are notoriously ill conditioned anyway for higher degree fits. It would help if you attached the data files in ascii form unless they happen to contain thousands of data items. Just the x will suffice, zip it up if you have to. Chuck |
|
From: Tim H. <tim...@ie...> - 2006-10-12 20:09:07
|
Albert Strasheim wrote: > Hello all > > >> -----Original Message----- >> From: num...@li... [mailto:numpy- >> dis...@li...] On Behalf Of Tim Hochberg >> Sent: 12 October 2006 21:24 >> To: numpy-discussion >> Subject: [Numpy-discussion] More SVN testing >> >> >> I just checked in a couple of changes to SVN. I was going to check in >> errstate, but it looks like Travis beat me to it, so I contented myself >> with adding a docstring and some tests. These tests are only run under >> 2.5; things seem to work fine here, but if someone on a Linux box whose >> running Python 2.5 could try it out I'd appreciate it. I'm suspicous of >> Linux/Windows differences right now because of my run in with them >> earlier today in the tests for test_multiarray (which I believe it now >> fixed -- at least everything is working here OK). >> > > This probably fixes the issue I reported here: > > http://projects.scipy.org/scipy/numpy/ticket/286 > > Maybe you can check that the test counts match up on Python 2.4 and 2.5 on > Windows on your system and close that ticket. > Yep, that's the same one I ran into and it's fixed now on windows. It sounds like it didn't occur at all on Linux. Their are now actually two more tests under 2.5 than under 2.4, but that's on purpose -- I can't test 'with errstate' under 2.4, so I skip those tests. I went ahead and closed the ticket. -tim |
|
From: Albert S. <fu...@gm...> - 2006-10-12 19:53:06
|
Hello all > -----Original Message----- > From: num...@li... [mailto:numpy- > dis...@li...] On Behalf Of Tim Hochberg > Sent: 12 October 2006 21:24 > To: numpy-discussion > Subject: [Numpy-discussion] More SVN testing > > > I just checked in a couple of changes to SVN. I was going to check in > errstate, but it looks like Travis beat me to it, so I contented myself > with adding a docstring and some tests. These tests are only run under > 2.5; things seem to work fine here, but if someone on a Linux box whose > running Python 2.5 could try it out I'd appreciate it. I'm suspicous of > Linux/Windows differences right now because of my run in with them > earlier today in the tests for test_multiarray (which I believe it now > fixed -- at least everything is working here OK). This probably fixes the issue I reported here: http://projects.scipy.org/scipy/numpy/ticket/286 Maybe you can check that the test counts match up on Python 2.4 and 2.5 on Windows on your system and close that ticket. Cheers, Albert |
|
From: Tim H. <tim...@ie...> - 2006-10-12 19:32:41
|
Travis Oliphant wrote: > Tim Hochberg wrote: > > >>> >>> >>> >>> >> Still there with a clean checkout. Blech! I hate weird import problems. >> I'll try to look into it, but if anyone has any good ideas, let me know >> >> >> > Show us the errors, I may be able to help. It's possible some recent > changes messed things up. > I just checked in a fix. I think it was some case problem in the paths that got set in set_local_path(). In any event, applying normpath to the merged path fixed the problem and I didn't feel like pursuing it further. -tim |
|
From: Travis O. <oli...@ee...> - 2006-10-12 19:27:35
|
Tim Hochberg wrote: >> >> >> >Still there with a clean checkout. Blech! I hate weird import problems. >I'll try to look into it, but if anyone has any good ideas, let me know > > Show us the errors, I may be able to help. It's possible some recent changes messed things up. -Travis |
|
From: Tim H. <tim...@ie...> - 2006-10-12 19:24:41
|
I just checked in a couple of changes to SVN. I was going to check in errstate, but it looks like Travis beat me to it, so I contented myself with adding a docstring and some tests. These tests are only run under 2.5; things seem to work fine here, but if someone on a Linux box whose running Python 2.5 could try it out I'd appreciate it. I'm suspicous of Linux/Windows differences right now because of my run in with them earlier today in the tests for test_multiarray (which I believe it now fixed -- at least everything is working here OK). -tim |
|
From: Travis O. <oli...@ee...> - 2006-10-12 19:19:30
|
Charles Hanot wrote: > Hello, > > I’ve a program using Numpy and I would like to compile it with Py2exe > but I’ve some problems. When I try to compile my program, some modules > generated by numpy are not loaded. I’ve already asked to the py2exe > community if they have a solution for that and the answer was that it > was possible to compile numpy modules with py2exe but I should ask to > the Numpy community J > > So my question is, is there something special to do in order to > compile a program using numpy module? > The only thing I remember is that you have to explicitly make sure _internal.py file gets copied over as it is not possible to discern that by looking at the import statements in .py files. -Travis |
|
From: Travis O. <oli...@ee...> - 2006-10-12 19:16:13
|
David Goldsmith wrote: >Got it. And if I understand correctly, the import order you specify in >the little mynumpy example you included in your latest response to >Fernando will result in any "overlap" between numpy and >numpy.lib.scimath to call the latter's version of things rather than the >former's, yes? > > Right. The last import will be used for any common-names (variables get re-bound to the new functions...) -Travis |
|
From: Paul D. <pfd...@gm...> - 2006-10-12 18:50:16
|
Historical note. When Cleve Moler first created 'matlab' as a tool for teaching at the University of New Mexico, all numbers were complex. And, in fact, there was a limit of 10,000 numbers. There was a fixed array where these 10,000 numbers were stored. I got pretty excited about his project and wanted to use it to get eigenvalues etc. for matrices of interest from our codes. But I had a Cray 1 with an entire megaword of memory and my matrices wouldn't fit. So I set out to hack the code to add a memory manager so that we could use the entire memory. This was a big success. Then I decided it was sad that I had to write the matrices out of the code onto a disk and then read them into matlab, so I got the idea of making something similar as the front end of the code, only with data types (because I hated only being able to use half my Cray since my data was real, and our codes were often memory bound) and a full programming language like Fortran with array syntax for speed. This idea resulted in Basis (basis.llnl.gov). My interest in Python (and hence numpy) evolved from that as OOP arrived. |
|
From: Sebastian H. <ha...@ms...> - 2006-10-12 18:46:01
|
Hi, On Thursday 12 October 2006 10:49, Christopher Barker wrote: > As someone on this list (sorry to quick with the delete button) said: <snip> I think I might agree with everything (!) you that - very well written . > Travis Oliphant wrote: > > Now, it would be possible to give ufuncs a dtype keyword argument that > > allowed you to specify which underlying loop was to be used for the > > calculation. > > > > sqrt(a, dtype=complex). > > I like this OK, and isn't is similar to the dtype argument in the > accumulating methods? (sum, etc.). However, it's probably not worth the > C-api change -- is it that different than calling: > > sqrt(a.astype(complex)) ? > It is very late in the game - obvious ! (one week before the announced final release). But I think adding the dtype argument to ufuncs would be a very useful addition !! It is very nice to look at ! And it saves (temporary) memory and should be noticeably faster than "sqrt(a.astype(complex))". This dtype addition might address many of the issues I have raised before on this list. Travis, be courageous and change the C-API one last time before putting it in stone for 1.0 final !!! > As for scipy, I heartily agree that scipy should be a superset of numpy, > and NOT change the behavior of numpy functions and methods. We're taking > the opportunity at this point for numpy to break backward compatibility > with Numeric/numarray -- this is probably the best time to do the same > for scipy. > > couldn't we at least introduce new names? > > numpy.scimath.csqrt() > > for instance? > > -Chris It has to be very well documented what the 12 functions (the last 3%) are were scipy and numpy differ. --- if at all possible I would prefer a name change like csqrt (or better sqrtc - I always like seen things together when sorted alphabetically ;-) ) [by the way: I like sqrt(-1) == nan just fine] Thanks for the great work. - Sebastian |
|
From: Lisandro D. <da...@gm...> - 2006-10-12 18:40:50
|
On 10/12/06, Michele Vallisneri <va...@va...> wrote:
> Does anybody here have experience about offering the array interface
> from a SWIG-wrapped C struct?
I have.
> I have tried the following, borrowing code from numpy's arrayobject.c:
>
> %extend real_vec_t {
> PyObject *__array_struct__() {
> /* From numpy/arrayobject.c/array_struct_get */
You are extending real_vec_t with a new METHOD, but what numpy
requests is an ATTRIBUTE. So, numpy simply queries your vec like:
arrstr =3D vec.__array_struct__
and not with a method call like this
arrstr =3D vec.__array_struct__()
So here is what I would do (can fail with some SWIG optimizations)
%extend Vec {
PyObject* __array_struct__ () { /* ... */ }
%pythoncode {
__array_struct__ =3D property(__array_struct__,
doc=3D'Array protocol')
}
}
Hope you got the idea.
--=20
Lisandro Dalc=EDn
---------------
Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC)
Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC)
Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET)
PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
|
|
From: Tim H. <tim...@ie...> - 2006-10-12 18:35:49
|
Tim Hochberg wrote: > Gerard Vermeulen wrote: > >> On Thu, 12 Oct 2006 11:04:55 -0700 >> Tim Hochberg <tim...@ie...> wrote: >> >> >> >>> Is any one else seeing the multiarray tests all get skipped because of >>> an import error when compiling under python 2.5. Everything else seems >>> to work and all the tests go fine under 2.4. >>> >>> >> Everything looks fine here: >> >> > > Thanks. > > I suppose that means it's either Windows specific or I gummed up my > build tree somehow. I'll make a clean checkout and see if it goes away. > > Still there with a clean checkout. Blech! I hate weird import problems. I'll try to look into it, but if anyone has any good ideas, let me know -tim |
|
From: Neal B. <ndb...@gm...> - 2006-10-12 18:33:25
|
It appears the problem with getting a numpy-1.0 built with RPM is caused by using 2 step process: python setup.py build python setup.py install --skip-build --root $RPM_BUILD_ROOT This doesn't seem to work correctly! If I change it to just do: python setup.py install it works OK. |
|
From: David M. C. <co...@ph...> - 2006-10-12 18:30:50
|
On Thu, 12 Oct 2006 14:03:31 -0400 Tom Loredo <lo...@as...> wrote: > Hi folks, > > I've just upgraded my G4 (PPC) from Pather to Tiger, and just > installed MacPython. I now need to build a slew of numerical extensions. > I'm building them from source (I have lots of custom extensions > to build from source in any case). I see the binaries available > for Tiger are built with gcc 3.3 for PPC and gcc 4 for Intel; I > think they may be tied to ActivePython but I'm not sure. When > I start MacPython, I see it is built with gcc 4. Is this what > I should be using? I'll also be compiling fortran extensions; > I presume I should use gfortran rather than g77 for this (g77 > is what worked with gcc 3.3). Is this correct? For Intel, yes, you need to use gfortran, and it has to be the prelease version (4.2): 4.1 and earlier don't build on Intel Macs. g77 (and gcc 3.x) won't build either, unfortunately. If you're using MacPorts (previously DarwinPorts), you'll want the gcc42 port. Or, you can grab binaries at http://hpc.sourceforge.net/ -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Tim H. <tim...@ie...> - 2006-10-12 18:22:20
|
Gerard Vermeulen wrote: > On Thu, 12 Oct 2006 11:04:55 -0700 > Tim Hochberg <tim...@ie...> wrote: > > >> Is any one else seeing the multiarray tests all get skipped because of >> an import error when compiling under python 2.5. Everything else seems >> to work and all the tests go fine under 2.4. >> > > Everything looks fine here: > Thanks. I suppose that means it's either Windows specific or I gummed up my build tree somehow. I'll make a clean checkout and see if it goes away. -tim |
|
From: Gerard V. <ger...@gr...> - 2006-10-12 18:13:51
|
On Thu, 12 Oct 2006 11:04:55 -0700 Tim Hochberg <tim...@ie...> wrote: > > Is any one else seeing the multiarray tests all get skipped because of > an import error when compiling under python 2.5. Everything else seems > to work and all the tests go fine under 2.4. Everything looks fine here: >>> sys.version '2.5 (r25:51908, Oct 8 2006, 07:23:15) \n[GCC 4.1.1 (Gentoo 4.1.1)]' >>> np.version.version '1.0.dev3317' >>> np.test() Found 13 tests for numpy.core.umath Found 9 tests for numpy.lib.arraysetops Found 36 tests for numpy.core.ma Found 3 tests for numpy.fft.helper Found 4 tests for numpy.ctypeslib Found 2 tests for numpy.lib.polynomial Found 8 tests for numpy.core.records Found 26 tests for numpy.core.numeric Found 5 tests for numpy.distutils.misc_util Found 3 tests for numpy.lib.getlimits Found 31 tests for numpy.core.numerictypes Found 4 tests for numpy.core.scalarmath Found 1 tests for numpy.lib.ufunclike Found 12 tests for numpy.lib.twodim_base Found 47 tests for numpy.lib.shape_base Found 4 tests for numpy.lib.index_tricks Found 32 tests for numpy.linalg.linalg Found 42 tests for numpy.lib.type_check Found 176 tests for numpy.core.multiarray Found 10 tests for numpy.core.defmatrix Found 41 tests for numpy.lib.function_base Found 0 tests for __main__ ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. ---------------------------------------------------------------------- Ran 509 tests in 0.265s OK <unittest.TextTestRunner object at 0x2aaaaed6a650> >>> Gerard |
|
From: Tim H. <tim...@ie...> - 2006-10-12 18:05:20
|
Is any one else seeing the multiarray tests all get skipped because of an import error when compiling under python 2.5. Everything else seems to work and all the tests go fine under 2.4. -tim |
|
From: Tom L. <lo...@as...> - 2006-10-12 18:03:37
|
Hi folks, I've just upgraded my G4 (PPC) from Pather to Tiger, and just installed MacPython. I now need to build a slew of numerical extensions. I'm building them from source (I have lots of custom extensions to build from source in any case). I see the binaries available for Tiger are built with gcc 3.3 for PPC and gcc 4 for Intel; I think they may be tied to ActivePython but I'm not sure. When I start MacPython, I see it is built with gcc 4. Is this what I should be using? I'll also be compiling fortran extensions; I presume I should use gfortran rather than g77 for this (g77 is what worked with gcc 3.3). Is this correct? Thanks, Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ |
|
From: Christopher B. <Chr...@no...> - 2006-10-12 17:49:33
|
As someone on this list (sorry to quick with the delete button) said:
"numpy is closer to the metal than MATLAB"
MATLAB aside, numpy is somewhat "close to the metal". I think this is
clearly part of its design philosophy, and also something I personally
like about out.
Getting back to MATLAB (at least version 4, the last one I used
regularly) -- everything in MATLAB is a matrix of double precision
Floating points. (or complex - that does get weird!). This makes things
simpler for a lot of use, but restricts the power and flexibility
substantially.
Everything in numpy is an array of arbitrary shape and many possible
data types -- this is more to think about, but give you a lot of power
and flexibility. In any case, that is what numpy is. Period.
Given that, arrays of different types behave differently -- that's
something you'd darn well better understand pretty soon in your numpy
career:
>>> a = N.array((1,2,3), dtype=N.uint8)
>>> a *= 200
>>> a
array([200, 144, 88], dtype=uint8)
Oh my gosh! 2 * 200 isn't 144! what happened?
This isn't any different than sqrt(-1) resulting in NaN or an error. In
fact, there are all sorts of places where upcasting is not happening
automagically -- in fact, I think that's become more consistent in the
new numpy. So, in numpy you need to choose the datatype appropriate for
your problem at hand. I know I always know whether I want to work in the
complex plane or not.
Another change recently made is to make doubles the default in more
places -- I like that change.
So, given the entire philosophy and current status of how numpy works,
the ONLY question that is legitimate here is:
Should the "default" datatype be complex or double? I vote double.
Travis Oliphant wrote:
> Now, it would be possible to give ufuncs a dtype keyword argument that
> allowed you to specify which underlying loop was to be used for the
> calculation.
> sqrt(a, dtype=complex).
I like this OK, and isn't is similar to the dtype argument in the
accumulating methods? (sum, etc.). However, it's probably not worth the
C-api change -- is it that different than calling:
sqrt(a.astype(complex)) ?
As for scipy, I heartily agree that scipy should be a superset of numpy,
and NOT change the behavior of numpy functions and methods. We're taking
the opportunity at this point for numpy to break backward compatibility
with Numeric/numarray -- this is probably the best time to do the same
for scipy.
couldn't we at least introduce new names?
numpy.scimath.csqrt()
for instance?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: Michele V. <va...@va...> - 2006-10-12 17:42:20
|
Does anybody here have experience about offering the array interface
from a SWIG-wrapped C struct?
I have tried the following, borrowing code from numpy's arrayobject.c:
%extend real_vec_t {
PyObject *__array_struct__() {
/* From numpy/arrayobject.c/array_struct_get */
PyArrayInterface *inter;
inter = (PyArrayInterface *)_pya_malloc(sizeof(PyArrayInterface));
inter->two = 2;
inter->nd = 1;
inter->typekind = 'f';
inter->itemsize = sizeof(float);
inter->flags = (NPY_CONTIGUOUS | NPY_OWNDATA | NPY_ALIGNED |
NPY_NOTSWAPPED);
inter->shape = (intp *)_pya_malloc(2*sizeof(intp));
inter->strides = inter->shape + 1;
*(inter->shape) = self->n;
*(inter->strides) = 1;
inter->data = (void *)(self->d);
inter->descr = 0;
return PyCObject_FromVoidPtr(inter,0);
}
%}
When passing such a SWIG real_vec_t object to numpy.array, numpy gets
a PyArrayInterface that fails to check correctly as a Python C
object. Three comments:
- The original numpy/arrayobject.c code actually gets its return
value from PyCObject_FromVoidPtrAndDesc(inter,self,...); but in this
context self does not point to a PyObject, but rather to the C
struct, so I don't think I can use that form.
- The code above does not deal with properly destructing the
PyArrayInterface, setting refcounts, etc. But I was going to worry
about those later.
- My problem is probably with SWIG rather than numpy... but I thought
the people in this forum (rather than those at the SWIG forum) would
be most likely to have encountered a situation similar to these.
Thanks a lot for any help, or just for reading this post.
Michele
|
|
From: Christopher B. <Chr...@no...> - 2006-10-12 17:34:19
|
Travis Oliphant wrote:
> I made some fixes to the "asbuffer" code which let me feel better about
> exposing it in NumPy (where it is now named int_asbuffer).
>
> This code takes a Python integer and a size and returns a buffer object
> that points to that memory.
If I understand this correctly, maybe it should be called something like:
int_asbuffer_pointer
or something with "pointer" in it.
I sure didn't expect that meaning from "asbuffer" or in-asbuffer"
Otherwise -- nice idea!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
258 messages has been excluded from this view by a project administrator.
