numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] ***[Possible UCE]*** Bug in memmap/python allocation code?

[Travis O. <oli...@ie...>]

Mike Ressler wrote:
> I'm trying to work with memmaps on very large files, i.e. > 2 GB, up 
> to 10 GB. The files are data cubes of images (my largest is 
> 1290(x)x1024(y)x2011(z)) and my immediate task is to strip the data 
> from 32-bits down to 16, and to rearrange some of the data on a 
> per-xy-plane basis. I'm running this on a Fedora Core 5 64-bit system, 
> with python-2.5b2 (that I believe I compiled in 64-bit mode) and 
> numpy-1.0b1. The disk has 324 GB free space.
I just discovered the problem.  All the places where 
PyObject_As<Read/Write>Buffer is used needs to have the final argument 
changed to Py_ssize_t (which in arrayobject.h is defined as int if you 
are using less than Python 2.5). 

This should be fixed in SVN shortly....

-Travis

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Damien M. <dj...@mi...>]

On Fri, 21 Jul 2006, Travis Oliphant wrote:

> 
> I've created the 1.0b1 release tag in SVN and will be uploading files 
> shortly to Sourceforge.

FYI numpy-1.0b1 builds fine and passes all its regression tests
on OpenBSD -current.

-d

[Numpy-discussion] numpy scalar types

[Sebastian H. <ha...@ms...>]

Hi,
I just ran a simple test which I think would be of general interest.
It's about types and what there names are in the numpy module
(and how many different names there are for a given type !!)
Cheers, Sebastian Haase
       (maybe there is a good place in the wiki for this !?)
 >>> N.csingle
<type 'complex64scalar'>
 >>> N.cdouble
<type 'complex128scalar'>
 >>> N.cfloat
<type 'complex128scalar'>

and all together !!
 >>> for tt in N.ScalarType:
...     l=[k for k,v in N.__dict__.iteritems() if v == tt]
...     print len(l), tt, l
...
0 <type 'int'> []
0 <type 'float'> []
0 <type 'complex'> []
0 <type 'long'> []
0 <type 'bool'> []
0 <type 'str'> []
0 <type 'unicode'> []
0 <type 'buffer'> []
2 <type 'int64scalar'> ['longlong', 'int64']
2 <type 'int16scalar'> ['int16', 'short']
2 <type 'int32scalar'> ['int32', 'int_']
2 <type 'uint32scalar'> ['uint', 'uint32']
2 <type 'unicodescalar'> ['unicode_', 'unicode0']
2 <type 'complex64scalar'> ['complex64', 'csingle']
3 <type 'int32scalar'> ['intp', 'intc', 'int0']
4 <type 'complex128scalar'> ['cfloat', 'complex_', 'cdouble', 'complex128']
3 <type 'stringscalar'> ['string', 'str_', 'string0']
3 <type 'float96scalar'> ['float96', 'longfloat', 'longdouble']
2 <type 'uint16scalar'> ['ushort', 'uint16']
2 <type 'objectscalar'> ['object0', 'object_']
3 <type 'float64scalar'> ['double', 'float64', 'float_']
2 <type 'int8scalar'> ['byte', 'int8']
2 <type 'uint8scalar'> ['uint8', 'ubyte']
2 <type 'boolscalar'> ['bool8', 'bool_']
2 <type 'float32scalar'> ['float32', 'single']
3 <type 'complex192scalar'> ['complex192', 'clongdouble', 'clongfloat']
3 <type 'uint32scalar'> ['uintc', 'uint0', 'uintp']
2 <type 'uint64scalar'> ['uint64', 'ulonglong']
2 <type 'voidscalar'> ['void', 'void0']

Re: [Numpy-discussion] (no subject)

[<em...@ya...>]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/?010
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*

お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?010
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/?010

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/?010

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/?010
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/?010

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.bz/pc/?010

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.bz/pc/?010


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/?010

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/?010

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?010
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/?010
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892

Re: [Numpy-discussion] how to get an array with "varying" poisson distribution

[Charles R H. <cha...@gm...>]

Hi Sebastian,

On 7/24/06, Sebastian Haase <ha...@ms...> wrote:
>
> Hi,
> Essentially I'm looking  for the equivalent of what was in numarray:
>     from numarray import random_array
>     random_array.poisson(arr)
>
> That is: if for example arr is a 256x256 array of positive integers, then
> this
> returns a new array of random numbers than are drawn according to the
> poisson
> statistics  where arr's value at coordinate y,x  determines the mean of
> the
> poisson distribution used  to generate  a new value for y,x.
>
> [[This is needed e.g. to simulate quantum noise in CCD images. Each pixel
> has
> different amount of noise depending of what it's (noise-free) "input"
> value
> was.]]


How accurate do you want the distribution to be and what sort of  offset is
there? If the number of counts is greater that about 10 and you don't care
too much about the poisson tail then a gaussian will work fine. If you have
very large counts (>1e6), which I doubt, the  accuracy of the poisson
distribution becomes a tricky matter because it needs care to compute the
factorial to the needed accuracy. The factorial turns up in the rejection
methods used in the algorithms. Most of the algorithms also compute special
constants that depend on the mean of the distribution, so while efficient
for a fixed mean they are less so for varying means like you want.

I tend to just go with gaussian noise most of the time.

Thanks,
> Sebastian Haase
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] (no subject)

[<yuk...@ya...>]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/?02
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/?02

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/?02
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.jp/pc/?06

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.jp/pc/?06


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

お問い合わせ先はこちら↓
広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892

Re: [Numpy-discussion] 1.0b1 problem on Solaris

[Bill B. <wb...@gm...>]

Howdy,
Instructions for compiling your own SciPy can be found here.
   http://www.scipy.org/Installing_SciPy

I think the 0.4.9 source will probably work.  But getting it from SVN
is probably safer.
--bb

On 7/25/06, Mathew Yeates <my...@jp...> wrote:
> Where is the source? Do I just use the 0.4.9 source?
>
>
> Bill Baxter wrote:
> > Yep, scipy needs to be recompiled against the 1.0b1 version of numpy.
> > I think they should have an updated version on the web site in a few
> > days or so if you don't feel like compiling yourself.
> >
> > --bb
> >
> > On 7/25/06, Mathew Yeates <my...@jp...> wrote:
> >> I installed numpy-1.0b1 and now >import numpy produces a segv. According
> >> to gdb it's happening after a failure to import scipy.optimize.minpack2.
> >> Eventually, Py_FatalError is called followed by abort,raise and
> >> thr_kill. Then the SEGV.
> >>
> >> Any ideas? Do I need a different version of scipy? I currently use 0.4.9
> >>
> >>
> >> Mathew
> >>
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] 1.0b1 problem on Solaris

[Mathew Y. <my...@jp...>]

Where is the source? Do I just use the 0.4.9 source?


Bill Baxter wrote:
> Yep, scipy needs to be recompiled against the 1.0b1 version of numpy.
> I think they should have an updated version on the web site in a few
> days or so if you don't feel like compiling yourself.
>
> --bb
>
> On 7/25/06, Mathew Yeates <my...@jp...> wrote:
>> I installed numpy-1.0b1 and now >import numpy produces a segv. According
>> to gdb it's happening after a failure to import scipy.optimize.minpack2.
>> Eventually, Py_FatalError is called followed by abort,raise and
>> thr_kill. Then the SEGV.
>>
>> Any ideas? Do I need a different version of scipy? I currently use 0.4.9
>>
>>
>> Mathew
>>
>

Re: [Numpy-discussion] 1.0b1 problem on Solaris

[Bill B. <wb...@gm...>]

Yep, scipy needs to be recompiled against the 1.0b1 version of numpy.
I think they should have an updated version on the web site in a few
days or so if you don't feel like compiling yourself.

--bb

On 7/25/06, Mathew Yeates <my...@jp...> wrote:
> I installed numpy-1.0b1 and now >import numpy produces a segv. According
> to gdb it's happening after a failure to import scipy.optimize.minpack2.
> Eventually, Py_FatalError is called followed by abort,raise and
> thr_kill. Then the SEGV.
>
> Any ideas? Do I need a different version of scipy? I currently use 0.4.9
>
>
> Mathew
>

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Bill B. <wb...@gm...>]

On 7/25/06, Andrew Straw <str...@as...> wrote:
> 1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1
> for most tools out there.

I like that best.  Save the 1.1 prefix until it's actually released as such.

The numbering scheme needs to deal with what to call the patch tip of
the stable release branch, too.  I.e. the maintenance release after
1.0 with only critical patches for anyone who demands strict 1.0
compatibility.  The third number would be good for that.
Right now I see 1.1.2881 as my version.  I think this should probably
have an extra .0 in it: 1.1.0.2881.  That third number would be a
maintenance release number.

I also like the Linux even-odd system.  Then 1.0.0.1234 can mean "SVN
version on the 1.0 branch, leading up to maintenance release 1.0.1",
and 1.1.0.1234 can mean "SVN version on the trunk, leading up to 1.2
release."

--bb

Re: [Numpy-discussion] trivial question: how to compare dtype - but ignoring byteorder ?

[Christopher B. <Chr...@no...>]

Sebastian Haase wrote:
> Which is why I was trying to change the str() representation of a type to 
> something more intuitive. 
> If nothing else one could even leave 
> repr(a.dtype)  --> '<i4'
> but 
> str(a.dtype)    --> 'int32 (little endian)'

+1

that's the whole point of __str__. It should be human readable!

-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...

[Numpy-discussion] Bug in memmap/python allocation code?

[Mike R. <mik...@gm...>]

I'm trying to work with memmaps on very large files, i.e. > 2 GB, up to 10
GB. The files are data cubes of images (my largest is
1290(x)x1024(y)x2011(z)) and my immediate task is to strip the data from
32-bits down to 16, and to rearrange some of the data on a per-xy-plane
basis. I'm running this on a Fedora Core 5 64-bit system, with
python-2.5b2(that I believe I compiled in 64-bit mode) and
numpy-1.0b1. The disk has 324 GB free space.

The log from a minimal case is as follows:

ressler > python2.5
Python 2.5b2 (r25b2:50512, Jul 18 2006, 12:58:29)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> data=np.memmap('temp_file',mode='w+',shape=(2011,1280,1032),dtype='h')
size = 2656450560
bytes = 5312901120
len(mm) = 5312901120
(2011, 1280, 1032) h 0 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/site-packages/numpy/core/memmap.py", line
75, in __new__
    offset=offset, order=order)
TypeError: buffer is too small for requested array
>>>

If I have a small number of frames (z=800 rather than 2011), this all works
fine. I've added a few lines to memmap.py to print some diagnostic
information - the error occurs on line 71 in the original memmap.py file,
not 75. The "size =" and "bytes =" lines show that memmap.py is calculating
the correct size for the buffer, and the len(mm) shows that the python
mmap.mmap call on line 67 is returning a buffer of the correct size. The
"(2011, 1280, 1032) h 0 0" bit is from a print statement that was left in
the source file by the authors, and indicates what the following "self =
ndarray.__new__" call is trying to do. However, it is the ndarray.__new__
call that is breaking down, and I don't really have enough skill to continue
chasing it down. I took a quick look at the C source, but I couldn't figure
out where the ndarray.__new__ is actually defined.

Any suggestions to help me past this? Thanks.

Mike

-- 
mik...@al...

Re: [Numpy-discussion] trivial question: how to compare dtype - but ignoring byteorder ?

[Sebastian H. <ha...@ms...>]

On Monday 24 July 2006 16:42, Bill Baxter wrote:
> > > And I think byteorder matters when comparing dtypes:
> > > >>> numpy.dtype('>f4') == numpy.dtype('<f4')
> > >
> > > False
>
> Ohhhhh -- that '<' part is indicating *byte order* ?!
> I thought it was odd that numpy could only tell me the type was "less
> than f4", which I assumed must be shorthand for "less than or equal to
> f4".  Makes much more sense now!
>
> --bb
Which is why I was trying to change the str() representation of a type to 
something more intuitive. 
If nothing else one could even leave 
repr(a.dtype)  --> '<i4'
but 
str(a.dtype)    --> 'int32 (little endian)'

I do now understand that (as opposed to numarray and numeric) the byteorder is 
now part of the data-type  - but I would really encourage keeping the string 
for such an important (and often used !) thing more readable than
"<i4".   
Most people will thankfully never have to think about byteorder - it should be 
like an implementation detail that numpy can transparently handle ! 

What what it's worth ,
Sebastian Haase

[Numpy-discussion] 1.0b1 problem on Solaris

[Mathew Y. <my...@jp...>]

I installed numpy-1.0b1 and now >import numpy produces a segv. According 
to gdb it's happening after a failure to import scipy.optimize.minpack2. 
Eventually, Py_FatalError is called followed by abort,raise and 
thr_kill. Then the SEGV.

Any ideas? Do I need a different version of scipy? I currently use 0.4.9


Mathew

Re: [Numpy-discussion] matrix-related bug in 1.0b1

[Bill B. <wb...@gm...>]

On 7/25/06, Sven Schreiber <sve...@gm...> wrote:
> Travis Oliphant schrieb:
> > Sven Schreiber wrote:
> >>
> > The change was trying to fix up some cases but did break this one.  The
> > problem is that figuring out whether or not to transpose the result is a
> > bit tricky.  I've obviously still got it wrong.

Is there some test case that demonstrates the problem it was intended
to fix?  Or can you remember off the top of your head?  I tried as
many things as I could think of but nothing I tried gave the wrong
answer with the fix of removing the 'not' on line 140.

> p.s.: Is there going to be a new beta soon? Or is there a quick fix to
> this slicing problem in the meantime? Thanks.

Sven, if you were happy with the behavior under numpy 0.9.8 then all
you have to do is just cut and paste its matrix.__getitem__ method
into your current site-packages/numpy/core/defmatrix.py.

--bill

Re: [Numpy-discussion] trivial question: how to compare dtype - but ignoring byteorder ?

[Bill B. <wb...@gm...>]

> > And I think byteorder matters when comparing dtypes:
> > >>> numpy.dtype('>f4') == numpy.dtype('<f4')
> > False

Ohhhhh -- that '<' part is indicating *byte order* ?!
I thought it was odd that numpy could only tell me the type was "less
than f4", which I assumed must be shorthand for "less than or equal to
f4".  Makes much more sense now!

--bb

Re: [Numpy-discussion] numpy.prod() vs. numpy.product()

[Bill B. <wb...@gm...>]

I can't answer why, but in oldnumeric.py, you can see there's two
different fuctions with basically identical code, so yes they are
distinct, but no they are not different.  Seems like prod could be
replaced by prod=product.

def product (x, axis=0, dtype=None):
    """Product of the array elements over the given axis."""
    try:
        prod = x.prod
    except AttributeError:
        return _wrapit(x, 'prod', axis, dtype)
    return prod(axis, dtype)

def prod(a, axis=0, dtype=None):
    """Return the product of the elements along the given axis
    """
    try:
        prod = a.prod
    except AttributeError:
        return _wrapit(a, 'prod', axis, dtype)
    return prod(axis, dtype)


--bb

On 7/25/06, Sebastian Haase <ha...@ms...> wrote:
> Hi,
> Are numpy.product() and numpy.prod()
> doing the exact same thing ? If yes, why are they pointing to two different
> functions ?
> >>> N.prod
> <function prod at 0x43cef56c>
> >>> N.product
> <function product at 0x43cef304>
>
> Thanks,
> Sebastian Haase
>

Re: [Numpy-discussion] Please comment on SVN versioning convention

[David M. C. <co...@ph...>]

On Mon, Jul 24, 2006 at 04:03:13PM -0700, Andrew Straw wrote:
> Sasha wrote:
> 
> >On 7/24/06, Andrew Straw <str...@as...> wrote:
> >
> >>BTW, Fernando, all this is so that we can still have the svn revision
> >>number in __version__, but so that it doesn't screw up sorting.
> >
> >Sorting __version__ is screwed up regardless of svn revision number:
> >
> >>>>'1.9' < '1.10'
> >>>>        
> >>>>
> >False
> >
> Not if you parse __version__ with something that understands version
> numbers.

...and we've already got something for that: distutils.version.LooseVersion
(or StrictVersion).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Sasha <nd...@ma...>]

On 7/24/06, Andrew Straw <str...@as...> wrote:

> Yes, I only brought up version numbers as strings because you did. I'm
> not proposing we solve that problem. I see setuptools, in particular, as
> the biggest thing to support, because it lets you have multiple versions
> installed simultaneously. And I don't know how to force its hand, or
> even if it's possible.

I am not familiar with setuptools and I expect that many others who
care about __version__ conventions are not either.  Please explain
exactly how setuptools depend on what is stored in __version__  and
why using 'final' in place of svn revision number in file names will
not solve your problems.

I would be against any change that will affect  map(int,
__version__.split('.')[:3]).

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Andrew S. <str...@as...>]

Sasha wrote:

>On 7/24/06, Andrew Straw <str...@as...> wrote:
>
>  
>
>>BTW, Fernando, all this is so that we can still have the svn revision
>>number in __version__, but so that it doesn't screw up sorting.
>>    
>>
>
>Sorting __version__ is screwed up regardless of svn revision number:
>
>  
>
>>>>'1.9' < '1.10'
>>>>        
>>>>
>False
>
Not if you parse __version__ with something that understands version
numbers.

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Andrew S. <str...@as...>]

Sasha wrote:

>On 7/24/06, Andrew Straw <str...@as...> wrote:
>[snip]
>  
>
>>The concern is that there are a bazillion ways of sorting version
>>numbers but the version numbers from numpy's current svn tree don't sort
>>with (m)any of them. Sorting strings in Python is one way, using
>>setuptools or debian's dpkg are other ways.
>>    
>>
>
>Sorting numbers as strings is a problem no matter what tools you use.
>'1000' is sorted before '999' in every tool I know of. The only proper
>way to solve this problem is to make svn revision available as an
>integer and sort them as integers. This integer may go in version_info
>tuple or in a separate variable.  The same information may be encoded
>into a sortable string using appropriate padding, but I don't see much
>need for that.  
>
Yes, I only brought up version numbers as strings because you did. I'm
not proposing we solve that problem. I see setuptools, in particular, as
the biggest thing to support, because it lets you have multiple versions
installed simultaneously. And I don't know how to force its hand, or
even if it's possible.

>Do you expect creating debian's dpkg from a
>non-release version?
>  
>
Yes. I do personally (see http://debs.astraw.com/dapper/ for example)
and I'm sure others do, as well. You can see from that archive that I've
been dealing with this issue by adding appropriate suffixes or prefixes.
(Forcing its hand.)

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Sasha <nd...@ma...>]

On 7/24/06, Andrew Straw <str...@as...> wrote:

> BTW, Fernando, all this is so that we can still have the svn revision
> number in __version__, but so that it doesn't screw up sorting.

Sorting __version__ is screwed up regardless of svn revision number:

>>> '1.9' < '1.10'
False

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Sasha <nd...@ma...>]

On 7/24/06, Andrew Straw <str...@as...> wrote:
[snip]
> The concern is that there are a bazillion ways of sorting version
> numbers but the version numbers from numpy's current svn tree don't sort
> with (m)any of them. Sorting strings in Python is one way, using
> setuptools or debian's dpkg are other ways.

Sorting numbers as strings is a problem no matter what tools you use.
'1000' is sorted before '999' in every tool I know of. The only proper
way to solve this problem is to make svn revision available as an
integer and sort them as integers. This integer may go in version_info
tuple or in a separate variable.  The same information may be encoded
into a sortable string using appropriate padding, but I don't see much
need for that.  Do you expect creating debian's dpkg from a
non-release version?

Re: [Numpy-discussion] Please comment on SVN versioning convention

[Andrew S. <str...@as...>]

Sasha wrote:

>On 7/24/06, Travis Oliphant <oli...@ie...> wrote:
>  
>
>>Andrew Straw has emphasized that the current strategy of appending the
>>SVN version number to development versions of the SVN tree makes it hard
>>to do version sorting.
>>    
>>
>
>I am not sure what the problem is, but if the concern is that
>
>  
>
>>>>'0.9.9.2803' > '0.9.9'
>>>>        
>>>>
>True
>
>I suggest fixing that by appending '.final' to the release version string:
>  
>
The concern is that there are a bazillion ways of sorting version
numbers but the version numbers from numpy's current svn tree don't sort
with (m)any of them. Sorting strings in Python is one way, using
setuptools or debian's dpkg are other ways.

Remember, all this is only a concern for those working from SVN versions
-- the releases are stripped of these numbers, anyway.

I don't really care what we use, it's just that if we want to make life
easy for people working from SVN, these automated tools should have a
way of knowing that what we currently call numpy 1.1.2881 precedes numpy
1.1 (these are current examples from the SVN tree). Here are some
proposals for this version:

1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1
for most tools out there.
1.0.post2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before
1.1 for most tools out there, but is perhaps more clear.
1.1.dev-r2881 - this wouldn't solve the problem for Debian, but it would
for setuptools, which has special treatment for ".dev-r" (see
http://peak.telecommunity.com/DevCenter/setuptools). This has the
advantage of being only a minimal change from the current scheme.
1.0+1.1.2881 - I also think this would sort OK with most tools, and is
also a fairly minimal change. My only concern is the '+' might cause
some filesystems or tools to freak out.

BTW, Fernando, all this is so that we can still have the svn revision
number in __version__, but so that it doesn't screw up sorting.

Cheers!
Andrew

[Numpy-discussion] weave - was:Re: how to get an array with "varying" poisson distribution

[Sebastian H. <ha...@ms...>]

On Monday 24 July 2006 14:20, Robert Kern wrote:
> Sebastian Haase wrote:
> > Hi,
> > Essentially I'm looking  for the equivalent of what was in numarray:
> >     from numarray import random_array
> >     random_array.poisson(arr)
> >
> > That is: if for example arr is a 256x256 array of positive integers, then
> > this returns a new array of random numbers than are drawn according to
> > the poisson statistics  where arr's value at coordinate y,x  determines
> > the mean of the poisson distribution used  to generate  a new value for
> > y,x.
>
> I'm afraid that at this point in time, the distributions only accept scalar
> values for the parameters. I've thought about reimplementing the
> distribution functions as ufuncs, but that's a hefty chunk of work that
> won't happen for 1.0.
>
> I'm afraid that, for now, you're stuck with iterating over the values.

Thanks for the reply -
maybe this my time to get into weave ;-)

Question about distributing and/or making "python-only-changes".
How can one distribute modules using weave to other people who might NOT have 
a C compiler installed ?
And further: when I change parts of that module that should not require a 
recompiling of the C part  - is weave smart enough to recognise this ?

Thanks,
Sebastian

(Oops, I just realized that this would be a question maybe for the SciPy 
list ... I'll assume that it's OK)