This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 72 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1GUFPK-0001wW-5k
The date of the message is:
Bruce Southey wrote:
> Hi,
> I think what you are after is the multivariate normal distribution.
>
Indeed
> Assuming I have it correctly, it is clearer to see (and probably more
> accurate to compute) in the log form as:
>
> -(N/2)*log(2*PI) - 0.5*log(determinant of V) - 0.5*(transpose of
> (x-m
Sebastian Haase wrote:
>If scipy is going to be installable as separate sub-packages maybe
>all window functions can be moved to scipy ;-)
>
>In other words, if the ones in numpy are there only for "historical
>reasons" maybe they should be cleaned out before the 1.0 release.
>All arguments seem
Travis Oliphant wrote:
> Greg Willden wrote:
>
>> Hello All,
>> I introduced myself on the Scipy list and I have a feeling that most
>> of the subscribers here are also on Scipy-devel. Anyway I just
>> submitted my first patch to numpy (ticket #316). I added the
>> blackman-harris, Nuttall an
Greg Willden wrote:
> Hello All,
> I introduced myself on the Scipy list and I have a feeling that most
> of the subscribers here are also on Scipy-devel. Anyway I just
> submitted my first patch to numpy (ticket #316). I added the
> blackman-harris, Nuttall and Flat Top windowing functions a
Hello All,I introduced myself on the Scipy list and I have a feeling that most of the subscribers here are also on Scipy-devel. Anyway I just submitted my first patch to numpy (ticket #316). I added the blackman-harris, Nuttall and Flat Top windowing functions and added "See also" sections to the
Hi,
I just compiled CVS numpy on OSX 10.4 (tiger). Runs fine.
I was surprised when I tried to run the same mode on 10.3 (panther?)
and got a importError (dyld:...) related to missing acoshl (long double)
functions:
ImportError: Failure linking new module: :
dyld:
/Library/Frameworks/Python.fr
Tim Hochberg wrote:
>David M. Cooke wrote:
>
>
>>On Wed, 04 Oct 2006 10:19:08 -0700
>>Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>>>Ivan Vilata i Balaguer wrote:
>>>
>>>
>>>
It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
so, but I have co
On Wed, 4 Oct 2006 10:23:25 -0700
Sebastian Haase <[EMAIL PROTECTED]> wrote:
> On Wednesday 04 October 2006 10:13, Tim Hochberg wrote:
> > Sebastian Haase wrote:
> > > Quick question hopefully somewhat related to this:
> > > Does numexpr fully support float32 arrays ?
> >
> > I don't recall. At on
David M. Cooke wrote:
> On Wed, 04 Oct 2006 10:19:08 -0700
> Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>> Ivan Vilata i Balaguer wrote:
>>
>>> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
>>> so, but I have come across some alignment or striding problems which c
On Wed, 04 Oct 2006 10:19:08 -0700
Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Ivan Vilata i Balaguer wrote:
> > It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> > so, but I have come across some alignment or striding problems which can
> > be seen with the following code::
On Wednesday 04 October 2006 10:13, Tim Hochberg wrote:
> Sebastian Haase wrote:
> > Quick question hopefully somewhat related to this:
> > Does numexpr fully support float32 arrays ?
>
> I don't recall. At one point there was a tentative plan to support
> float32 by casting them a block at a time
Sorry I didn't post earlier. VisIt is used extensively at LLNL for our 3D apps. I will try to get someone who uses it to comment.On 04 Oct 2006 09:42:20 -0700,
Torgil Svensson <[EMAIL PROTECTED]> wrote:
Sourceforge mailing list doesn't like me. Here's another try.I've managed to use visit through
Ivan Vilata i Balaguer wrote:
> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> so, but I have come across some alignment or striding problems which can
> be seen with the following code::
I looked at this just a little bit and clearly this bit from interp_body
cannot wor
Sebastian Haase wrote:
> Quick question hopefully somewhat related to this:
> Does numexpr fully support float32 arrays ?
>
I don't recall. At one point there was a tentative plan to support
float32 by casting them a block at a time to float64, operating on them
and them casting them back. Tha
Quick question hopefully somewhat related to this:
Does numexpr fully support float32 arrays ?
-Sebastian
On Wednesday 04 October 2006 09:32, Tim Hochberg wrote:
> Ivan Vilata i Balaguer wrote:
> > It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> > so, but I have come acr
Sourceforge mailing list doesn't like me. Here's another try.
I've managed to use visit through it's cli and giving it data through
pyvtk so that this code
if __name__=='__main__':
from numpy import *
from numpy.random import randn
n=1
t=linspace(0,1,n)+randn(n)*0.01
a=t+t
Ivan Vilata i Balaguer wrote:
> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> so, but I have come across some alignment or striding problems which can
> be seen with the following code::
>
> import numpy
> import numexpr
>
> array_length = 10
> array_desc
Hi,
I think what you are after is the multivariate normal distribution.
Assuming I have it correctly, it is clearer to see (and probably more
accurate to compute) in the log form as:
-(N/2)*log(2*PI) - 0.5*log(determinant of V) - 0.5*(transpose of
(x-mu))*inverse(V)*(x-mu)
where N is the number o
Hi,
On 10/2/06, Albert Strasheim <[EMAIL PROTECTED]> wrote:
> I recently started looking at David Cournapeau's PyEM package,
> specifically his implementation of the K-Means algorithm. He
> implemented part of this algorithm with in pure Python version and
> also provided a Pyrex alternative that
It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
so, but I have come across some alignment or striding problems which can
be seen with the following code::
import numpy
import numexpr
array_length = 10
array_descr = [('c1', numpy.int32), ('c2', numpy.uint16)
David Cournapeau wrote:
> Here we are (the difference may not seem that much between the two
> multiple_ga, but in reality, _diag_gauss_den is an internal function
> which is done in C, and is much faster... By writing this example, I've
> just realized that the function _diag_gauss_den may be s
Tim Hochberg wrote:
>>
>>
>> I guess the problem is coming from the fact that y being C order, y[:,
>> i] needs accessing data in a non 'linear' way. Is there a way to speed
>> this up ? I did something like this:
>>
>> y = N.zeros((K, n))
>> for i in range(K):
>> y[i] = gauss_den
23 matches
Mail list logo
