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

Re: [Numpy-discussion] Newbie question

[Alan G I. <ai...@am...>]

On Wed, 23 Aug 2006, (GMT) Paul Midgley apparently wrote:=20
> I have been interested in using python for some time for=20
> carrying out calculations, but I have not been able to=20
> determine if it is possible to use it to print out=20
> a report at the end.=20

http://gael-varoquaux.info/computers/pyreport/

hth,
Alan Isaac

Re: [Numpy-discussion] Newbie question

[John B. <jo...@nn...>]

On Wednesday 23 August 2006 19:12, Paul Midgley wrote:
> Hello
>
> I have been interested in using python for some time for carrying out
> calculations, but I have not been able to determine if it is possible to
> use it to print out a report at the end. What I want is to use it similar
> to Mathcad producing structured equations in line with the text, graphs
> etc.
>
> I can produced decent reports using MS Word or open office, but these will
> not do the calculations and the anlysis work that can be done with python
> and similar languages.
>
> What I am trying to achieve is calculations in a template form where the
> raw data can be put into it and carries out the calculations and it can be
> printed out in the form of a report.
>

You may be able to use GNU TeXmacs with the Python plugin.  I've not tried=
=20
this so YMMV.

TeXmacs:
http://www.texmacs.org/

Python Plugin:
http://dkbza.org/tmPython.html

Enjoy!

John

[Numpy-discussion] Newbie question

[Paul M. <pau...@ya...>]

Hello

I have been interested in using python for some time for carrying out calculations, but I have not been able to determine if it is possible to use it to print out a report at the end. What I want is to use it similar to Mathcad producing structured equations in line with the text, graphs etc.

I can produced decent reports using MS Word or open office, but these will not do the calculations and the anlysis work that can be done with python and similar languages.

What I am trying to achieve is calculations in a template form where the raw data can be put into it and carries out the calculations and it can be printed out in the form of a report.

Any help would be appreciated.

Regards

Paul

[Numpy-discussion] Handling interrupts in NumPy extensions

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

I'm working on some macros that will allow extensions to be 
"interruptable" (i.e. with Ctrl-C).  The idea came from SAGE but the 
implementation is complicated by the possibility of threads and making 
sure to handle clean-up code correctly when the interrupt returns.

I'd like to get this in to 1.0 final.  Anything needed will not require 
re-compilation of extension modules built for 1.0b2 however.  This will 
be strictly "extra" and if an extension module doesn't use it there will 
be no problems.

Step 1:

Define the interface.  Here are a couple of draft proposals.  Please 
comment on them.

1) General purpose interface

NPY_SIG_TRY {
[code]
}
NPY_SIG_EXCEPT(signum) { 
[interrupt handling return]
}
NPY_SIG_ELSE
[normal return]

The idea of signum is to hold the signal actually caught.


2) Simpler interface

NPY_SIG_TRY {
[code]
}
NPY_SIG_EXCEPT_GOTO(label)
[normal return]

label:
  [interrupt handling return]


C-extensions often use the notion of a label to handle failure code.

If anybody has any thoughts on this, they would be greatly appreciated.


Step 2:

Implementation.  I have the idea to have a single interrupt handler 
(defined globally in NumPy) that basically uses longjmp to return to the 
section of code corresponding to the thread that is handling the 
interrupt.  I had thought to use a global variable containing a linked 
list of jmp_buf structures with a thread-id attached 
(PyThread_get_thread_ident()) so that the interrupt handler can search 
it to see if the thread has registered a return location.  If it has 
not, then the intterupt handler will just return normally.   In this way 
a thread that calls setjmpbuf will be sure to return to the correct 
place when it handles the interrupt.

Concern:

My thinking is that this mechanism should work whether or not the GIL is 
held so that we don't have to worry about whether or not the GIL is held 
except in the interrupt handling case (when Python exceptions are to be 
set).    But, honestly, this gets very confusing.

The sigjmp / longjmp mechanism for handling interrupts is not 
recommended under windows (not sure about mingw), but there we could 
possibly use Microsoft's __try and __except extension to implement.  
Initially, it would be "un-implemented" on platforms where it didn't work.

Any comments are greatly appreciated

-Travis

Re: [Numpy-discussion] Array pooling

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

Hi Carlos,

On 8/22/06, Carlos Pita <car...@ya...> wrote:
>
> One reason is to use operator syntax: buf1 = buf2 +  buf3, instead of
> add(buf2,buf3, buf1). The other is to spare the final user (synth
> programmer) any buffer bookkeeping.
>

I see.

My idea was to keep track of pooled buffers' reference counts, so that those
> currently unused would have a refcount of 1 and could be safely deleted
> (well, if pool policy variables allow it). But as buffers are acquired all
> the time, even a simple (pure-python) pooling policy implementation is
> pretty time consuming. In fact, I have benchmarked this against simply
> creating new zeros-arrays every time, and the non-pooling version just runs
> faster. That was when I thought that numpy could be doing some internal
> pooling by itself.
>

I think the language libraries themselves must do some sort of pooling, at
least the linux ones seem to. C++ programs do a lot of creation/destruction
of structures on the heap and I have found the overhead noticeable but
surprisingly small. Numpy arrays are a couple of layers of abstraction up,
so maybe not quite as fast.

Chuck

Re: [Numpy-discussion] Array pooling

[Carlos P. <car...@ya...>]

One reason is to use operator syntax: buf1 = buf2 +  buf3, instead of add(buf2,buf3, buf1). The other is to spare the final user (synth programmer) any buffer bookkeeping. My idea was to keep track of pooled buffers' reference counts, so that those currently unused would have a refcount of 1 and could be safely deleted (well, if pool policy variables allow it). But as buffers are acquired all the time, even a simple (pure-python) pooling policy implementation is pretty time consuming. In fact, I have benchmarked this against simply creating new zeros-arrays every time, and the non-pooling version just runs faster. That was when I thought that numpy could be doing some internal pooling by itself.

Regards,
Carlos

Is there any reason to keep allocating arrays if you are just using them as data buffers? It seems you should be able to reuse them. If you wanted to be fancy you could keep them in a list, which would retain a reference and keep them from being garbage collected.   




 		
---------------------------------
 Preguntá. Respondé. Descubrí.
 Todo lo que querías saber, y lo que ni imaginabas,
 está en Yahoo! Respuestas (Beta).
 Probalo ya! 

Re: [Numpy-discussion] Array pooling

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

On 8/22/06, Carlos Pita <car...@ya...> wrote:
>
> Hi! I'm writting a real time sound synthesis framework where processing
> units are interconnected via numpy arrays. These buffers are all the same
> size and type, so it would be easy and convenient pooling them in order to
> avoid excesive creation/destruction of arrays (consider that thousands of
> them are acquired and released per second, but just a few dozens used at the
> same time). But first I would like to know if numpy implements some pooling
> mechanism by itself. Could you give me some insight on this? Also, is it
> possible to obtain an uninitialized array? I mean, sometimes I don't feel
> like wasting valuable cpu clocks filling arrays with zeros, ones or
> whatever.
>

Is there any reason to keep allocating arrays if you are just using them as
data buffers? It seems you should be able to reuse them. If you wanted to be
fancy you could keep them in a list, which would retain a reference and keep
them from being garbage collected.

Chuck

Re: [Numpy-discussion] Array pooling

[Simon B. <si...@ar...>]

On Tue, 22 Aug 2006 23:51:01 -0300 (ART)
Carlos Pita <car...@ya...> wrote:


> Hi! I'm writting a real time sound synthesis framework where processing u=
nits are interconnected via numpy arrays. These buffers are all the same si=
ze and type, so it would be easy and convenient pooling them in order to av=
oid excesive creation/destruction of arrays (consider that thousands of the=
m are acquired and released per second, but just a few dozens used at the s=
ame time). But first I would like to know if numpy implements some pooling =
mechanism by itself.=20

I don't think so.

> Could you give me some insight on this? Also, is it possible to obtain an=
 uninitialized array?

numpy.empty

> I mean, sometimes I don't feel like wasting valuable cpu clocks filling a=
rrays with zeros, ones or whatever.
> Thank you in advance.
> Regards,
> Carlos

Sounds like fun.

Simon.

>=20
>=20
>=20
>  =20
>  	=09
> ---------------------------------
>  Pregunt=E1. Respond=E9. Descubr=ED.
>  Todo lo que quer=EDas saber, y lo que ni imaginabas,
>  est=E1 en Yahoo! Respuestas (Beta).
>  Probalo ya!=20


--=20
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com=20

[Numpy-discussion] Array pooling

[Carlos P. <car...@ya...>]

Hi! I'm writting a real time sound synthesis framework where processing units are interconnected via numpy arrays. These buffers are all the same size and type, so it would be easy and convenient pooling them in order to avoid excesive creation/destruction of arrays (consider that thousands of them are acquired and released per second, but just a few dozens used at the same time). But first I would like to know if numpy implements some pooling mechanism by itself. Could you give me some insight on this? Also, is it possible to obtain an uninitialized array? I mean, sometimes I don't feel like wasting valuable cpu clocks filling arrays with zeros, ones or whatever.
Thank you in advance.
Regards,
Carlos



  
 		
---------------------------------
 Preguntá. Respondé. Descubrí.
 Todo lo que querías saber, y lo que ni imaginabas,
 está en Yahoo! Respuestas (Beta).
 Probalo ya! 

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> This explains it - my specific function overloads only one of its two array 
> arguments (i.e. allow many different types)  - the second one must be a 
> C "int".    
> [(a 32bit int) - but SWIG  matches the "C signature" ] 
> But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
> But on 32bitLinux I get NPY_LONG because of that rule.
>
> My SWIG typemaps want to "double check" that a C function expecting c-type 
> "int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 
>   
Perhaps I can help you do what you want without making assumptions about 
the platform.   I'll assume you are matching on an int* signature and 
want to "translate" that to an integer array of the correct bit-width.  
So, you have a PyArrayObject as input I'll call self

Just check:

(PyArray_ISSIGNED(self) && PyArray_ITEMSIZE(self)==SIZEOF_INT)

For your type-map check.  This will work on all platforms and allow 
signed integers of the right type.

> I don't know what the solution should be  - but maybe the rule should be 
> changed based on the assumption that "int" in more common !?
>   
That's not going to happen at this point.  Besides in the Python world, 
the fact that Python integers are "long" means that the "long" is the 
more common 32-bit integer on 32-bit machines.

-Travis

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Thanks for the reply, see question below...
On Tuesday 22 August 2006 12:30, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > I just ran into more problems with my SWIG
> > typemaps.
> > In the C api the current enum for
> > NPY_INT is 5
> > NPY_LONG is 7
> >
> > to match overloaded function I need to check these type values.
> >
> > On 64bit all works fine:
> > my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> > my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
> >
> > but on 32bit Linux
> > the 32bit int  function matches NPY_LONG
> > there is no  NPY_INT  on 32bit
>
> Yes there is.  Both NPY_INT and NPY_LONG are always there.  One matches
> the int and one matches the long.
>
> Perhaps you are confused about what the special defines NPY_INT32 match to?
>
> The behavior is that the 'long' type gets "first-dibs" then the
> 'longlong' type gets a crack.  Finally, the 'int' type is chosen.  The
> first one that matches the bit-type is used.
>
This explains it - my specific function overloads only one of its two array 
arguments (i.e. allow many different types)  - the second one must be a 
C "int".    [(a 32bit int) - but SWIG  matches the "C signature" ] 
But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
But on 32bitLinux I get NPY_LONG because of that rule.

My SWIG typemaps want to "double check" that a C function expecting c-type 
"int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 

I don't know what the solution should be  - but maybe the rule should be 
changed based on the assumption that "int" in more common !?


> > that is: if I have a non overloaded C/C++ function that expects a C "int"
> >  - i.e. a 32bit int - I have write different function matching rules  !!!
>
> What you need to do is stop trying to match bit-widths and instead match
> c-types.  That's why NPY_INT and NPY_LONG are both there.
If you are referring to use of the sizeof() operator - I'm not doing that.

Thanks as always for your quick and careful replies.
- Sebastian

[Numpy-discussion] Version 1.0b3

[<kor...@id...>]

Since no one has downloaded 1.0b3 yet, if someone wants to put up the
windows version for python2.3 i would be more than happy to be the first
person to download it :)

Re: [Numpy-discussion] numpy/Numeric co-existence

[Robert K. <rob...@gm...>]

James Boyle wrote:
> I have some codes which require a Numeric array and others which 
> require a numpy array.
> I have no control over either code, and not the time to convert all to 
> numpy if I did.
> The problem is this - say I have a routine that returns a numpy array 
> as a result and I wish to do something to this array using a code that 
> uses Numeric.  Just passing the numpy array to the numeric code does 
> not work. In my case the Numeric code thinks that the numpy float is a 
> long int, this is not good. So what does one do in the interim? There 
> are some legacy codes which will never be converted to numpy.
> 
> I have seen discussion as to how to convert Numeric -> numpy, but not 
> how the two can play together. I can appreciate the strong desire to 
> eliminate having two systems, but the practical aspects of getting 
> things done must also be considered.
> 
> I am using numpy 1.0b1 and Numeric 23.7 .

Upgrade to Numeric 24.2 and use Numeric.asarray(numpy_array) and 
numpy.asarray(numeric_array) at the interfaces between your codes.

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

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for 
> NPY_INT is 5 
> NPY_LONG is 7
>
> to match overloaded function I need to check these type values.
>
> On 64bit all works fine: 
> my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
>   
As you noted below, this is not always the case.  You can't assume that 
64-bit means "long"

Let me assume that you are trying to write functions for each of the 
"data-types".  You can proceed in a couple of ways:

1) Use the basic c-types
2) Use "bit-width" types (npy_int32, npy_int64, etc...)

The advantage of the former is that it avoids any confusion in terms of 
what kind of c-type it matches.  This is really only important if you 
are trying to interface with external code that uses basic c-types.

The advantage of the latter is that you don't have to write a redundant 
routine (i.e. on 32-bit linux the int and long routines should be 
identical machine code), but you will have to be careful in matching to 
a c-type should you need to call some external routine.

The current system gives you as many choices as possible (you can either 
match external code using the c-types) or you can write to a particular 
bit-width.  This is accomplished through comprehensive checks defined in 
the arrayobject.h file.

-Travis

[Numpy-discussion] numpy/Numeric co-existence

[James B. <bo...@ll...>]

I have some codes which require a Numeric array and others which 
require a numpy array.
I have no control over either code, and not the time to convert all to 
numpy if I did.
The problem is this - say I have a routine that returns a numpy array 
as a result and I wish to do something to this array using a code that 
uses Numeric.  Just passing the numpy array to the numeric code does 
not work. In my case the Numeric code thinks that the numpy float is a 
long int, this is not good. So what does one do in the interim? There 
are some legacy codes which will never be converted to numpy.

I have seen discussion as to how to convert Numeric -> numpy, but not 
how the two can play together. I can appreciate the strong desire to 
eliminate having two systems, but the practical aspects of getting 
things done must also be considered.

I am using numpy 1.0b1 and Numeric 23.7 .

Thanks for any enlightenment - perhaps I am missing something obvious.

--Jim

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for 
> NPY_INT is 5 
> NPY_LONG is 7
>
> to match overloaded function I need to check these type values.
>
> On 64bit all works fine: 
> my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
>
> but on 32bit Linux
> the 32bit int  function matches NPY_LONG 
> there is no  NPY_INT  on 32bit
>   
Yes there is.  Both NPY_INT and NPY_LONG are always there.  One matches 
the int and one matches the long. 

Perhaps you are confused about what the special defines NPY_INT32 match to?

The behavior is that the 'long' type gets "first-dibs" then the 
'longlong' type gets a crack.  Finally, the 'int' type is chosen.  The 
first one that matches the bit-type is used.
> that is: if I have a non overloaded C/C++ function that expects a C "int"
>  - i.e. a 32bit int - I have write different function matching rules  !!!
>   

What you need to do is stop trying to match bit-widths and instead match 
c-types.  That's why NPY_INT and NPY_LONG are both there.

Let me know if you have further questions.  I don't really understand 
what the issue is.

-Travis

[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Hi,
I just ran into more problems with my SWIG
typemaps.
In the C api the current enum for 
NPY_INT is 5 
NPY_LONG is 7

to match overloaded function I need to check these type values.

On 64bit all works fine: 
my 32bit int  function matches NPY_INT  - which is "int" in C/C++
my 64bit int  function matches NPY_LONG  - which is "long" in C/C++

but on 32bit Linux
the 32bit int  function matches NPY_LONG 
there is no  NPY_INT  on 32bit

that is: if I have a non overloaded C/C++ function that expects a C "int"
 - i.e. a 32bit int - I have write different function matching rules  !!!

REQUEST:
Can a 32bit int array get the typenumber code NPY_INT
on 32bit Linux !?
Then it would work for both 32bit Linux and 64bit Linux the same !

(I don't know about 64bit windows - I have heard that both C int and C long 
are 64bit - so that is screwed in any case .... )

Thanks,
Sebastian Haase

 

Re: [Numpy-discussion] bug is arr.real for byteswapped array

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

Sebastian Haase wrote:
> Hi,
> probably related to this is that
> arr[2].real is read-only ...
>
> I noticed that you cannot assign 
> to arr[2].real :
>   
No, that's unrelated.  The problem is that arr[2] is a scalar and so it 
is immutable.  When an array scalar is created you get a *copy* of the 
data.  Setting it would not have the effect you imagine as the original 
data would go unchanged.

The only exception to this is the array of type "void" which *does not* 
copy the data.

-Travis

Re: [Numpy-discussion] bug is arr.real for byteswapped array

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

Hi,
probably related to this is that
arr[2].real is read-only ...

I noticed that you cannot assign 
to arr[2].real :

>>> a[2].real =6
Traceback (most recent call last):
  File "<input>", line 1, in ?
TypeError: attribute 'real' of 'genericscalar' objects is not writable
>>> a.real[2] =6
>>> 
>>> a[2].real.flags
  CONTIGUOUS : True
  FORTRAN : True
  OWNDATA : True
  WRITEABLE : False
  ALIGNED : True
  UPDATEIFCOPY : False
>>> a.real[2].flags
 <snipped unchanged fields>
  WRITEABLE : False
>>> 
>>> a.real.flags
  CONTIGUOUS : False
  FORTRAN : False
  OWNDATA : False
  WRITEABLE : True
>>> a[2].flags
  CONTIGUOUS : True
  FORTRAN : True
  OWNDATA : True
  WRITEABLE : False
  ALIGNED : True
  UPDATEIFCOPY : False

Is the "not writable" restriction necessary ?

Thanks,
Sebastian Haase



On Tuesday 22 August 2006 01:46, Albert Strasheim wrote:
> Hello all
>
> > <snip>
> >
> > >>> a = N.arange(4, dtype='>c8')
> > >>> a.imag.max()
> >
> > 4.60060298822e-41
>
> Confirmed on Windows 32-bit with 1.0b4.dev3050.
>
> I created a ticket here:
>
> http://projects.scipy.org/scipy/numpy/ticket/265
>
> Regards,
>
> Albert
>
>
> -------------------------------------------------------------------------
> 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

Re: [Numpy-discussion] bug is arr.real for byteswapped array

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

Sebastian Haase wrote:
> Hi,
> We just spend some time debugging some numpy image analysis code
> where we finally noticed that our file was byte-swapped ;-).
> Even though we got much crazier numbers, 
> the test below already shows one bug in the a.real.max() line.
> My numpy.__version__ is  '1.0b3.dev3015'  and this is run on pentium (little 
> endian) Linux  (both 64bit and 32bit version give same results):
>
>   
I just fixed two bugs with respect to this issue which were introduced 
at various stages of development

1) The real and imag attribute getting functions were not respecting the 
byte-order of the data-type object of the array on creation of the 
"floating-point" equivalent data-type --- this one was introduced on the 
change to have byteorder part of the data-type object itself.

2) The copyswapn function for complex arrays was not performing two sets 
of swaps.  It was performing one large swap (which had the effect of 
moving the real part to the imaginary part and vice-versa).

These bug-fixes will be in 1.0b4

-Travis

Re: [Numpy-discussion] (no subject)

[<mis...@ya...>]

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Re: [Numpy-discussion] bug is arr.real for byteswapped array

[Albert S. <fu...@gm...>]

Hello all

> <snip>
> 
> >>> a = N.arange(4, dtype='>c8')
> >>> a.imag.max()
> 4.60060298822e-41

Confirmed on Windows 32-bit with 1.0b4.dev3050.

I created a ticket here:

http://projects.scipy.org/scipy/numpy/ticket/265

Regards,

Albert

Re: [Numpy-discussion] bug is arr.real for byteswapped array

[Steve L. <lis...@ar...>]

Hi Sebastian,

> We just spend some time debugging some numpy image analysis code
> where we finally noticed that our file was byte-swapped ;-).
> Even though we got much crazier numbers,
> the test below already shows one bug in the a.real.max() line.
> My numpy.__version__ is  '1.0b3.dev3015'  and this is run on  
> pentium (little
> endian) Linux  (both 64bit and 32bit version give same results):

I'm getting the same results you are.

I just recompiled numpy to the latest svn (1.0b4.dev3050) and am  
running your example on intel (32 bit) Mac OS X.4.7.

-steve

[Numpy-discussion] bug is arr.real for byteswapped array

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

Hi,
We just spend some time debugging some numpy image analysis code
where we finally noticed that our file was byte-swapped ;-).
Even though we got much crazier numbers, 
the test below already shows one bug in the a.real.max() line.
My numpy.__version__ is  '1.0b3.dev3015'  and this is run on pentium (little 
endian) Linux  (both 64bit and 32bit version give same results):

>>> a = N.arange(4, dtype='>c8')
>>> a
[ 0. +0.00000000e+00j  0. +1.00000000e+00j  0. +2.00000000e+00j
  0. +3.00000000e+00j]
>>> a.max()
(3+0j)
>>> a.real.max()
0.0
>>> a.imag.max()
4.60060298822e-41
>>> 
>>> a = N.arange(4, dtype='<c8')
>>> a.max()
(3+0j)
>>> a.real.max()
3.0
>>> a.imag.max()
0.0
>>> 

Can someone test this on a newer SVN version ?

Thanks,
Sebastian Haase

Re: [Numpy-discussion] numpy.random.rand function doesn't take tuple

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

If you like, here's a rand function that takes either a sequence or a
tuple.  I use this for interactive sessions.

def rand(*shape):
    """
    Return an array of the given dimensions which is initialized to
    random numbers from a uniform distribution in the range [0,1).

    rand(d0, d1, ..., dn) -> random values
    or
    rand((d0, d1, ..., dn)) -> random values
    """
    if len(shape) == 0 or not hasattr(shape[0],'__getitem__'):
        return numpy.random.rand(*shape)
    else:
        if len(shape) != 1:
            raise TypeError('Argument should either be a tuple or an
argument list')
        else:
            return numpy.random.rand(*shape[0])


On 8/22/06, David Grant <dav...@gm...> wrote:
>
>
>
> On 8/21/06, Robert Kern <rob...@gm...> wrote:
> >
> > David Grant wrote:
> > > I was a bit surprised today to find that numpy.random.rand doesn't
> > > take in a tuple as input for the dimensions of the desired array. I am
> > > very used to using a tuple for zeros, ones. Also, wouldn't this mean
> > > that it would not be possible to add other non-keyword arguments to
> > > rand later?
> >
> > Don't use rand(), then. Use random(). rand()'s sole purpose in life is
> > to *not*
> > take a tuple. If you like, you can read the archives on the several
> > (long)
> > discussions on this and why things are the way they are now. We finally
> > achieved
> > something resembling consensus, so please let's not resurrect this
> > argument.
>
>
>
> Thanks everyone. My only question now is why there is random_sample and
> random. My guess is that one is there for compatibility with older releases
> and so I'm not bothered by it.
>