Re: [Numpy-discussion] (no subject)

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

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


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

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

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

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

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

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


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

□-

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

□-

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

□-

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

□-

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

□-

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

□-

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

□-

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

□-


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

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







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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] int64 wierdness

2006-06-28 Thread Vincent Schut
Andrew Straw wrote:
 An SVN checkout from a week or two ago looks OK on my amd64 machine:

 [EMAIL PROTECTED]:~$ python
 Python 2.4.3 (#2, Apr 27 2006, 14:43:32)
 [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
 Type help, copyright, credits or license for more information.
   import numpy
   numpy.__version__
 '0.9.9.2631'
   numpy.int64(9)**2
 81
  
   
Confirmed to be fixed on my gentoo amd64 machine, numpy svn of couple of
days ago:
 numpy.int64(9)**2
81
 numpy.__version__
'0.9.9.2665'

Cheers,
Vincent.

 EI wrote:

   
 numpy.__version__ says 0.9.8.

 Python 2.4.2, GCC 4.1, OpenSuSE 10.1 (x86_64).

 Thanks Travis,
 Eugene

 On 6/27/06, *Travis Oliphant*  [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:

 EI wrote:
  Hi,
 
  I'm running python 2.4 on a 64bit linux and get strange results:
  (int(9))**2 is equal to 81, as it should, but
  (int64(9))**2 is equal to 0

 Thanks for the bug-report.  Please provide the version of NumPy
 you are
 using so we can track it down, or suggest an upgrade.

 -Travis


 

 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=lnkkid=120709bid=263057dat=121642

 

 ___
 Numpy-discussion mailing list
 Numpy-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/numpy-discussion
  

 


 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=lnkkid=120709bid=263057dat=121642
 ___
 Numpy-discussion mailing list
 Numpy-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/numpy-discussion
   


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


[Numpy-discussion] fread codes versus numpy types

2006-06-28 Thread Glen W. Mabey

Hello,

I see the following character codes defined in scipy (presumably) for
use with scipy.io.fread() :


In [20]:scipy.Complex
Out[20]:'D'

In [21]:scipy.Complex0
Out[21]:'D'

In [22]:scipy.Complex128
Out[22]:'G'

In [23]:scipy.Complex16
Out[23]:'F'

In [24]:scipy.Complex32
Out[24]:'F'

In [25]:scipy.Complex64
Out[25]:'D'

In [26]:scipy.Complex8
Out[26]:'F'


Then I see the following scalar types also defined:


In [27]:scipy.complex64
Out[27]:type 'complex64scalar'

In [28]:scipy.complex128
Out[28]:type 'complex128scalar'

In [29]:scipy.complex256
Out[29]:type 'complex256scalar'


which correspond to types that exist within the numpy module.  These
names seem to conflict in that (unless I misunderstand what's going on)
scipy.complex64 actually occupies 64 bits of data (a 32-bit float for
each of {real, imag}) whereas scipy.Complex64 looks like it occupies 128
bits of data (a 64-bit double for each of {real, imag}).

Is there something I'm missing, or is this a naming inconsistency?

Glen

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] fread codes versus numpy types

2006-06-28 Thread Robert Kern
Glen W. Mabey wrote:
 Hello,
 
 I see the following character codes defined in scipy (presumably) for
 use with scipy.io.fread() :
 
 In [20]:scipy.Complex
 Out[20]:'D'
 
 In [21]:scipy.Complex0
 Out[21]:'D'
 
 In [22]:scipy.Complex128
 Out[22]:'G'
 
 In [23]:scipy.Complex16
 Out[23]:'F'
 
 In [24]:scipy.Complex32
 Out[24]:'F'
 
 In [25]:scipy.Complex64
 Out[25]:'D'
 
 In [26]:scipy.Complex8
 Out[26]:'F'
 
 Then I see the following scalar types also defined:
 
 In [27]:scipy.complex64
 Out[27]:type 'complex64scalar'
 
 In [28]:scipy.complex128
 Out[28]:type 'complex128scalar'
 
 In [29]:scipy.complex256
 Out[29]:type 'complex256scalar'
 
 which correspond to types that exist within the numpy module.  These
 names seem to conflict in that (unless I misunderstand what's going on)
 scipy.complex64 actually occupies 64 bits of data (a 32-bit float for
 each of {real, imag}) whereas scipy.Complex64 looks like it occupies 128
 bits of data (a 64-bit double for each of {real, imag}).
 
 Is there something I'm missing, or is this a naming inconsistency?

The Capitalized versions are actually old typecodes for backwards compatibility 
with Numeric. In recent development versions of numpy, they are no longer 
exposed except through the numpy.oldnumeric compatibility module. A decision 
was 
made for numpy to use the actual width of a type in its name instead of the 
width of its component parts (when it has parts).

Code in scipy which still requires actual string typecodes is a bug. Please 
report such cases on the Trac:

   http://projects.scipy.org/scipy/scipy

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth.
   -- Umberto Eco


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] fread codes versus numpy types

2006-06-28 Thread Fernando Perez
On 6/28/06, Robert Kern [EMAIL PROTECTED] wrote:

 The Capitalized versions are actually old typecodes for backwards 
 compatibility
 with Numeric. In recent development versions of numpy, they are no longer
 exposed except through the numpy.oldnumeric compatibility module. A decision 
 was
 made for numpy to use the actual width of a type in its name instead of the
 width of its component parts (when it has parts).

 Code in scipy which still requires actual string typecodes is a bug. Please
 report such cases on the Trac:

http://projects.scipy.org/scipy/scipy

Well, an easy way to make all those poke their ugly heads in a hurry
would be to remove line 32 in scipy's init:

longs[Lib] grep -n oldnum *py
__init__.py:31:import numpy.oldnumeric as _num
__init__.py:32:from numpy.oldnumeric import *


If we really want to push for the new api, I think it's fair to change
those two lines by simply

from numpy import oldnumeric

so that scipy also exposes oldnumeric, and let all deprecated names be
hidden there.

I just tried this change:

Index: __init__.py
===
--- __init__.py (revision 2012)
+++ __init__.py (working copy)
@@ -29,9 +29,8 @@

 # Import numpy symbols to scipy name space
 import numpy.oldnumeric as _num
-from numpy.oldnumeric import *
-del lib
-del linalg
+from numpy import oldnumeric
+
 __all__ += _num.__all__
 __doc__ += 
 Contents


and scipy's test suite still passes (modulo the test_cobyla thingie
Nils is currently fixing, which is not related to this).

Should I apply this patch, so we push the cleaned-up API even a bit harder?

Cheers,

f

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] Numpy Benchmarking

2006-06-28 Thread David M. Cooke
On Wed, 28 Jun 2006 03:22:28 -0500
Robert Kern [EMAIL PROTECTED] wrote:

 [EMAIL PROTECTED] wrote:
  Hi,
  
   [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
   [TO]: 
   [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
   [TO]: NumPy wrapper).
   [TO]: 
   [TO]: The numpy.dual library exists so you can use the SciPy calls if
  the [TO]: person has SciPy installed or the NumPy ones otherwise.  It
  exists [TO]: precisely for the purpose of seamlessly taking advantage of 
   [TO]: algorithms/interfaces that exist in NumPy but  are improved in
  SciPy.
  
  This strikes me as a little bit odd. Why not just provide the
  best-performing function to both SciPy and NumPy? Would NumPy be more
  difficult to install if the SciPy algorithm for inv() was incorporated?
 
 That's certainly the case for the FFT algorithms. Scipy wraps more (and
 more complicated) FFT libraries that are faster than FFTPACK.
 
 Most of the linalg functionality should probably be wrapping the same
 routines if an optimized LAPACK is available. However, changing the routine
 used in numpy in the absence of an optimized LAPACK would require
 reconstructing the f2c'ed lapack_lite library that we include with the
 numpy source. That hasn't been touched in so long that I would hesitate to
 do so. If you are willing to do the work and the testing to ensure that it
 still works everywhere, we'd probably accept the change.

Annoying to redo (as tracking down *good* LAPACK sources is a chore), but
hardly as bad as it was.

I added the scripts I used to generated lapack_lite.c et al to
numpy/linalg/lapack_lite in svn. These are the same things that were used to
generate those files in recent versions of Numeric (which numpy uses). You
only need to specify the top-level routines; the scripts find the
dependencies.

I'd suggest using the source for LAPACK that Debian uses; the maintainer, Camm
Maguire, has done a bunch of work adding patches to fix routines that have
been floating around. For instance, eigenvalues works better than before (lot
fewer segfaults).

With this, the hard part is writing the wrapper routines. If someone wants to
wrap extra routines, I can do the the lapack_lite generation for them.

-- 
||\/|
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] indexing bug in numpy r2694

2006-06-28 Thread Travis Oliphant
Keith Goodman wrote:

On 6/28/06, Pau Gargallo [EMAIL PROTECTED] wrote:
  

i don't know why 'where' is returning matrices.
if you use:



idx = where(y.A  0.5)[0]
  

everything will work fine (I guess)



What about the second issue? Is this expected behavior?

  

idx
  

array([0, 1, 2])

  

y
  


matrix([[ 0.63731308],
   [ 0.34282663],
   [ 0.53366791]])

  

y[idx]
  


matrix([[ 0.63731308],
   [ 0.34282663],
   [ 0.53366791]])

  

y[idx,0]
  

matrix([[ 0.63731308,  0.34282663,  0.53366791]])

I was expecting a column vector.

  

This should be better behaved now in SVN.  Thanks for the reports.

-Travis


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] fread codes versus numpy types

2006-06-28 Thread Fernando Perez
On 6/28/06, David M. Cooke [EMAIL PROTECTED] wrote:
 On Wed, 28 Jun 2006 11:22:38 -0600
 Fernando Perez [EMAIL PROTECTED] wrote:
  Should I apply this patch, so we push the cleaned-up API even a bit harder?

 Yes please. I think all the modules that still use the oldnumeric names
 actually import numpy.oldnumeric themselves.

Done, r2017.  I also committed the simple one-liner:

Index: weave/inline_tools.py
===
--- weave/inline_tools.py   (revision 2016)
+++ weave/inline_tools.py   (working copy)
@@ -402,7 +402,7 @@
 def compile_function(code,arg_names,local_dict,global_dict,
  module_dir,
  compiler='',
- verbose = 0,
+ verbose = 1,
  support_code = None,
  headers = [],
  customize = None,

from a discussion we had a few weeks ago, I'd forgotten to put it in.
I did it as a separate patch (r 2018) so it can be reverted separately
if anyone objects.

Cheers,

f

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] Setuptools leftover junk

2006-06-28 Thread David M. Cooke
On Wed, 28 Jun 2006 13:32:15 -0500
Robert Kern [EMAIL PROTECTED] wrote:

 Fernando Perez wrote:
 
  Is it really necessary to have all that setuptools junk left around,
  for those of us who aren't asking for it explicitly?  My personal
  opinions on setuptools aside, I think it's just a sane practice not to
  create this kind of extra baggage unless explicitly requested.
  
  I scoured my home directory for any .file which might be triggering
  this inadvertedly, but I can't seem to find any, so I'm going to guess
  this is somehow being caused by numpy's own setup.  If it's my own
  mistake, I'll be happy to be shown how to coexist peacefully with
  setuptools.
  
  Since this also affects user code (I think via f2py or something
  internal to numpy, since all I'm calling is f2py in my code), I really
  think it would be nice to clean it.
 
 numpy.distutils uses setuptools if it is importable in order to make sure
 that the two don't stomp on each other. It's probable that that test could
 probably be done with Andrew Straw's method:
 
if 'setuptools' in sys.modules:
  have_setuptools = True
  from setuptools import setup as old_setup
else:
  have_setuptools = False
  from distutils.core import setup as old_setup
 
 Tested patches welcome.

Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
with an import of setuptools (it's based on the one used in matplotlib).

easy_install still works, also.

-- 
||\/|
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] fread codes versus numpy types

2006-06-28 Thread David M. Cooke
On Wed, 28 Jun 2006 11:22:38 -0600
Fernando Perez [EMAIL PROTECTED] wrote:

 On 6/28/06, Robert Kern [EMAIL PROTECTED] wrote:
 
  The Capitalized versions are actually old typecodes for backwards
  compatibility with Numeric. In recent development versions of numpy, they
  are no longer exposed except through the numpy.oldnumeric compatibility
  module. A decision was made for numpy to use the actual width of a type
  in its name instead of the width of its component parts (when it has
  parts).
 
  Code in scipy which still requires actual string typecodes is a bug.
  Please report such cases on the Trac:
 
 http://projects.scipy.org/scipy/scipy
 
 Well, an easy way to make all those poke their ugly heads in a hurry
 would be to remove line 32 in scipy's init:
 
 longs[Lib] grep -n oldnum *py
 __init__.py:31:import numpy.oldnumeric as _num
 __init__.py:32:from numpy.oldnumeric import *
 
 
 If we really want to push for the new api, I think it's fair to change
 those two lines by simply
 
 from numpy import oldnumeric
 
 so that scipy also exposes oldnumeric, and let all deprecated names be
 hidden there.
 
 I just tried this change:
 
 Index: __init__.py
 ===
 --- __init__.py (revision 2012)
 +++ __init__.py (working copy)
 @@ -29,9 +29,8 @@
 
  # Import numpy symbols to scipy name space
  import numpy.oldnumeric as _num
 -from numpy.oldnumeric import *
 -del lib
 -del linalg
 +from numpy import oldnumeric
 +
  __all__ += _num.__all__
  __doc__ += 
  Contents
 
 
 and scipy's test suite still passes (modulo the test_cobyla thingie
 Nils is currently fixing, which is not related to this).
 
 Should I apply this patch, so we push the cleaned-up API even a bit harder?

Yes please. I think all the modules that still use the oldnumeric names
actually import numpy.oldnumeric themselves.

-- 
||\/|
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] Setuptools leftover junk

2006-06-28 Thread Fernando Perez
On 6/28/06, David M. Cooke [EMAIL PROTECTED] wrote:

 Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
 with an import of setuptools (it's based on the one used in matplotlib).

 easy_install still works, also.

You beat me to it :)

However, your patch has slightly different semantics from mine: if
bdist_egg fails to import, the rest of setuptools is still used.  I
don't know if that's safe.  My patch would consider /any/ failure in
the setuptools imports as a complete setuptools failure, and revert
out to basic distutils.

Let me know if you want me to put in my code instead, here's a patch
from my code against current svn (after your patch), in case you'd
like to try it out.

Cheers,

f



Index: core.py
===
--- core.py (revision 2701)
+++ core.py (working copy)
@@ -1,20 +1,30 @@
-
 import sys
 from distutils.core import *

-if 'setuptools' in sys.modules:
-have_setuptools = True
-from setuptools import setup as old_setup
-# easy_install imports math, it may be picked up from cwd
-from setuptools.command import develop, easy_install
+# Don't pull setuptools in unless the user explicitly requests by having it
+# imported (Andrew's trick).
+have_setuptools = 'setuptools' in sys.modules
+
+# Even if setuptools is in, do a few things carefully to make sure the version
+# is recent enough to have everything we need before assuming we can proceed
+# using setuptools throughout
+if have_setuptools:
 try:
-# very old versions of setuptools don't have this
+from setuptools import setup as old_setup
+# very old setuptools don't have this
 from setuptools.command import bdist_egg
+# easy_install imports math, it may be picked up from cwd
+from setuptools.command import develop, easy_install
 except ImportError:
+# Any failure here is probably due to an old or broken setuptools
+# leftover in sys.modules, so treat it as if it simply weren't
+# available.
 have_setuptools = False
-else:
+
+# If setuptools was flagged as unavailable due to import problems, we need the
+# basic distutils support
+if not have_setuptools:
 from distutils.core import setup as old_setup
-have_setuptools = False

 from numpy.distutils.extension import Extension
 from numpy.distutils.command import config

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] Numpy Benchmarking

2006-06-28 Thread Travis Oliphant
[EMAIL PROTECTED] wrote:

Hi,

 [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
 [TO]: 
 [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
 [TO]: NumPy wrapper).
 [TO]: 
 [TO]: The numpy.dual library exists so you can use the SciPy calls if the 
 [TO]: person has SciPy installed or the NumPy ones otherwise.  It exists 
 [TO]: precisely for the purpose of seamlessly taking advantage of 
 [TO]: algorithms/interfaces that exist in NumPy but  are improved in SciPy.

This strikes me as a little bit odd. Why not just provide the best-performing 
function to both SciPy and NumPy? Would NumPy be more difficult to install
if the SciPy algorithm for inv() was incorporated?
  


The main issue is that SciPy can take advantage and use Fortran code, 
but NumPy cannot as it must build without a Fortran compiler.   This is 
the primary driver to the current duality.

-Travis


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] indexing bug in numpy r2694

2006-06-28 Thread Keith Goodman
On 6/28/06, Travis Oliphant [EMAIL PROTECTED] wrote:
 Keith Goodman wrote:

 On 6/28/06, Pau Gargallo [EMAIL PROTECTED] wrote:
 
 
 i don't know why 'where' is returning matrices.
 if you use:
 
 
 
 idx = where(y.A  0.5)[0]
 
 
 everything will work fine (I guess)
 
 
 
 What about the second issue? Is this expected behavior?
 
 
 
 idx
 
 
 array([0, 1, 2])
 
 
 
 y
 
 
 
 matrix([[ 0.63731308],
[ 0.34282663],
[ 0.53366791]])
 
 
 
 y[idx]
 
 
 
 matrix([[ 0.63731308],
[ 0.34282663],
[ 0.53366791]])
 
 
 
 y[idx,0]
 
 
 matrix([[ 0.63731308,  0.34282663,  0.53366791]])
 
 I was expecting a column vector.
 
 
 
 This should be better behaved now in SVN.  Thanks for the reports.

Now numpy can do

y[y  0.5]

instead of

y[where(y.A  0.5)[0]]

where, for example, y = asmatrix(rand(3,1)).

I know I'm pushing my luck here. But one more feature would make this perfect.

Currently y[y0.5,:] returns the first column even if y has more than
one column. Returning all columns would make it perfect.

Example:

 y

matrix([[ 0.38828902,  0.91649964],
   [ 0.41074001,  0.7105919 ],
   [ 0.15460833,  0.16746956]])

 y[y[:,1]0.5,:]

matrix([[ 0.38828902],
   [ 0.41074001]])

A better answer for matrix users would be:

 y[(0,1),:]

matrix([[ 0.38828902,  0.91649964],
   [ 0.41074001,  0.7105919 ]])

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] Setuptools leftover junk

2006-06-28 Thread David M. Cooke
On Wed, 28 Jun 2006 13:18:35 -0600
Fernando Perez [EMAIL PROTECTED] wrote:

 On 6/28/06, David M. Cooke [EMAIL PROTECTED] wrote:
 
  Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
  with an import of setuptools (it's based on the one used in matplotlib).
 
  easy_install still works, also.
 
 You beat me to it :)
 
 However, your patch has slightly different semantics from mine: if
 bdist_egg fails to import, the rest of setuptools is still used.  I
 don't know if that's safe.  My patch would consider /any/ failure in
 the setuptools imports as a complete setuptools failure, and revert
 out to basic distutils.

Note that your patch will still import setuptools if the import of bdist_egg
fails. And you can't get around that by putting the bdist_egg import first,
as that imports setuptools first.

(I think bdist_egg was added sometime after 0.5; if your version of
setuptools is *that* old, you'd be better off not having it installed.)

The use of setuptools by numpy.distutils is in two forms: explicitly
(controlled by this patch of code), and implicitly (because setuptools goes
and patches distutils). Disabling the explicit use won't actually fix your
problem with the 'install' command leaving .egg_info directories (which,
incidentally, are pretty small), as that's done by the implicit behaviour.

[Really, distutils sucks. I think (besides refactoring) it needs it's API
documented better, or least good conventions on where to hook into.
setuptools and numpy.distutils do their best, but there's only so much you
can do before everything goes fragile and breaks in unexpected ways.]

With the if 'setuptools' in sys.modules test, if you *are* using
setuptools, you must have explicitly requested that, and so I think a failure
on import of setuptools shouldn't be silently passed over.

-- 
||\/|
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] matlab translation

2006-06-28 Thread Mathew Yeates
I've been looking at a project called ANTLR (www.antlr.org) to do the 
translation. Unfortunately, although I may have a Matlab grammar, it 
would still be a lot of work to use ANTLR. I'll look at some of the 
links that have posted.

Mathew


Robert Kern wrote:
 Vinicius Lobosco wrote:
   
 Let's just let those who want to try to do that and give our support? I 
 would be happy if I could some parts of my old matlab programs 
 translated to Scipy.
 

 I do believe that, Show me, is an *encouragement*. I am explicitly 
 encouraging 
 Mathew to work towards that end. Sheesh.

   


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] indexing bug in numpy r2694

2006-06-28 Thread Keith Goodman
On 6/28/06, Travis Oliphant [EMAIL PROTECTED] wrote:
 This should be better behaved now in SVN.  Thanks for the reports.

I'm impressed by how quickly features are added and bugs are fixed.
And by how quick it is to install a new version of numpy.

Thank you.

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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Re: [Numpy-discussion] matlab translation

2006-06-28 Thread Erin Sheldon
ANTLR was also used for GDL http://gnudatalanguage.sourceforge.net/
with amazing results.

Erin

On 6/28/06, Mathew Yeates [EMAIL PROTECTED] wrote:
 I've been looking at a project called ANTLR (www.antlr.org) to do the
 translation. Unfortunately, although I may have a Matlab grammar, it
 would still be a lot of work to use ANTLR. I'll look at some of the
 links that have posted.

 Mathew


 Robert Kern wrote:
  Vinicius Lobosco wrote:
 
  Let's just let those who want to try to do that and give our support? I
  would be happy if I could some parts of my old matlab programs
  translated to Scipy.
 
 
  I do believe that, Show me, is an *encouragement*. I am explicitly 
  encouraging
  Mathew to work towards that end. Sheesh.
 
 


 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=lnkkid=120709bid=263057dat=121642
 ___
 Numpy-discussion mailing list
 Numpy-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/numpy-discussion


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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion