Dear sir,
Can we do multiple linear regression(MLR) in python is there any
inbuilt function for MLR
--
DILEEPKUMAR. R
J R F, IIT DELHI
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discus
Hi,
Running the test suite for one of our libraries, there seems to have
been a recent breakage of the behavior of dtype hashing.
This script:
import numpy as np
data0 = np.arange(10)
data1 = data0 - 10
dt0 = data0.dtype
dt1 = data1.dtype
assert dt0 == dt1 # always passes
assert hash(dt0) ==
On Wed, Mar 16, 2011 at 12:02 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Tue, Mar 15, 2011 at 9:29 PM, Ralf Gommers > wrote:
>
>>
>>
>> On Wed, Mar 16, 2011 at 2:31 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 15, 2011 at 12:26 PM,
On Wed, Mar 16, 2011 at 11:29 AM, Ralf Gommers
wrote:
>
>
> On Wed, Mar 16, 2011 at 2:31 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 15, 2011 at 12:26 PM, Mark Wiebe wrote:
>>
>> I pushed one more small API change to PyArray_NewLikeArray, adding a
>>> 'subok'
Example code:
from pylab import *
cos(random([1000,1000]))
Q1. Is there any reason that numpy doesn't automatically support
parallelization of element-wise operations like the example, even with Atlas
or MKL?
Q2. What is the most advisable way to parallelize(multi-thread) the example?
numexpr?
Hi,
On Tue, Mar 15, 2011 at 5:55 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Mar 15, 2011 at 5:30 PM, Christoph Gohlke wrote:
>>
>>
>> On 3/15/2011 5:13 PM, Matthew Brett wrote:
>>> Hi,
>>>
>>> On Tue, Mar 15, 2011 at 10:23 AM, Matthew Brett
>>> wrote:
Hi,
On Tue, Mar 15, 2011 at
On Tue, Mar 15, 2011 at 9:29 PM, Ralf Gommers
wrote:
>
>
> On Wed, Mar 16, 2011 at 2:31 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 15, 2011 at 12:26 PM, Mark Wiebe wrote:
>>
>>> On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers <
>>> ralf.gomm...@googlemail.com
On Wed, Mar 16, 2011 at 2:31 AM, Charles R Harris wrote:
>
>
> On Tue, Mar 15, 2011 at 12:26 PM, Mark Wiebe wrote:
>
>> On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers <
>> ralf.gomm...@googlemail.com> wrote:
>>
>>>
>>> Hi Mark, I see you just did this, but is there anything else you
>>> want/nee
Hi Matt,
Actually, based on what is happening under the covers I think this behavior
makes sense.
a['f2'] would in theory grab the whole column, and so 'f2' not existing is a
field error.
a[0] on the other hand grabs the first row from the full structured array
and treats this as (key, value) pa
Hi,
On Tue, Mar 15, 2011 at 5:30 PM, Christoph Gohlke wrote:
>
>
> On 3/15/2011 5:13 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Tue, Mar 15, 2011 at 10:23 AM, Matthew Brett
>> wrote:
>>> Hi,
>>>
>>> On Tue, Mar 15, 2011 at 10:12 AM, Pauli Virtanen wrote:
Tue, 15 Mar 2011 10:06:09 -0700, Mat
On 3/15/2011 5:13 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Mar 15, 2011 at 10:23 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> On Tue, Mar 15, 2011 at 10:12 AM, Pauli Virtanen wrote:
>>> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
Sorry to ask, and I ask partly because I'm in the mi
Hi,
I just wrote a short test for indexing into structured arrays with
strings and found this:
In [4]: a = np.zeros((1,), dtype=[('f1', 'i4')])
In [5]: a['f1']
Out[5]: array([0])
In [6]: a['f2'] # not present -> error
---
Va
Hi,
On Tue, Mar 15, 2011 at 10:23 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Mar 15, 2011 at 10:12 AM, Pauli Virtanen wrote:
>> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
>>> Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
>>> but is this the right fix to this
Charles R Harris wrote:
> On Tue, Mar 15, 2011 at 9:12 AM, Sturla Molden wrote:
>
>> Den 14.03.2011 23:10, skrev Matthieu Brucher:
>> > - Fortran 95 has an excellent array support, which is not currently
>> > available in C/C++ (perhaps with ArBB?)
>>
>> In C++ you can actually make array librar
On Tue, Mar 15, 2011 at 8:31 PM, Nadav Horesh wrote:
> Just downloaded and got the same problems. I'll try to debug and provide a
> decent analysis, but it would take some days as I am busy with other things.
Thanks, that'd be appreciated; I am able to load images using
freeimage without a probl
On Tue, Mar 15, 2011 at 12:25 PM, Sebastian Haase wrote:
>
> >
> > Log Message:
> > ---
> > ENH: Add 'subok' parameter to PyArray_NewLikeArray, np.empty_like,
> np.zeros_like, and np.ones_like
> >
> > This way, the sub-type can be avoided if necessary. This helps mitigate,
> > but doesn't
On Tue, Mar 15, 2011 at 3:25 PM, Sebastian Haase wrote:
> On Tue, Mar 15, 2011 at 7:22 PM, wrote:
>> Branch: refs/heads/master
>> Home: https://github.com/numpy/numpy
>>
>> Commit: aada93306acfb4e2eb816faf32652edf8825cf45
>>
>> https://github.com/numpy/numpy/commit/aada93306acfb4e2eb816faf
On Tue, Mar 15, 2011 at 7:22 PM, wrote:
> Branch: refs/heads/master
> Home: https://github.com/numpy/numpy
>
> Commit: aada93306acfb4e2eb816faf32652edf8825cf45
>
> https://github.com/numpy/numpy/commit/aada93306acfb4e2eb816faf32652edf8825cf45
> Author: Mark Wiebe
> Date: 2011-03-15 (Tue,
On 3/15/2011 11:34 AM, Christoph Gohlke wrote:
>
>
> On 3/15/2011 10:12 AM, Pauli Virtanen wrote:
>> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
>>> Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
>>> but is this the right fix to this problem? I was confused by
On 3/15/2011 10:12 AM, Pauli Virtanen wrote:
> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
>> Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
>> but is this the right fix to this problem? I was confused by the
>> presence of the old PyString_AsString function.
On Tue, Mar 15, 2011 at 12:26 PM, Mark Wiebe wrote:
> On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers <
> ralf.gomm...@googlemail.com> wrote:
>
>> On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe wrote:
>> > On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris
>> > wrote:
>> >>
>> >> On Sun, Mar 13, 201
Just downloaded and got the same problems. I'll try to debug and provide a
decent analysis, but it would take some days as I am busy with other things.
Thank you,
Nadav.
From: numpy-discussion-boun...@scipy.org [numpy-discussion-boun...@scipy.org]
On Tue, Mar 15, 2011 at 13:10, Mark Sienkiewicz wrote:
> Robert Kern wrote:
>> On Tue, Mar 15, 2011 at 12:39, Charles R Harris
>> wrote:
>>
>>
>>> Yes, I think it is a bug. IIRC, it also shows up for object arrays.
>>>
>>
>> It's extremely long-standing, documented, intentional behavior dating
>>
On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers
wrote:
> On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe wrote:
> > On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris
> > wrote:
> >>
> >> On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe wrote:
> >>>
> >>> On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers
> >>
Hi,
On Tue, Mar 15, 2011 at 11:07 AM, Pauli Virtanen wrote:
> Tue, 15 Mar 2011 10:23:35 -0700, Matthew Brett wrote:
> [clip]
>> OK - I realize I'm being very lazy here but, do you mean:
>>
>> PyErr_Format(PyExc_ValueError,
"field named %s not found.",
Robert Kern wrote:
> On Tue, Mar 15, 2011 at 12:39, Charles R Harris
> wrote:
>
>
>> Yes, I think it is a bug. IIRC, it also shows up for object arrays.
>>
>
> It's extremely long-standing, documented, intentional behavior dating
> back to Numeric.
>
> [~]
> |1> import Numeric
>
> [~]
> |2
Tue, 15 Mar 2011 10:23:35 -0700, Matthew Brett wrote:
[clip]
> OK - I realize I'm being very lazy here but, do you mean:
>
> PyErr_Format(PyExc_ValueError,
>>> "field named %s not found.",
>>> PyString_AsString(PyObject_Repr(index)));
>
>> The PyS
On Tue, Mar 15, 2011 at 12:39, Charles R Harris
wrote:
> Yes, I think it is a bug. IIRC, it also shows up for object arrays.
It's extremely long-standing, documented, intentional behavior dating
back to Numeric.
[~]
|1> import Numeric
[~]
|2> a = Numeric.array( [ 16.5069863163822 ] )
[~]
Den 15.03.2011 18:01, skrev Yung-Yu Chen:
> I really love the capabilities Fortran provides for quick array
> operations, especially floating-points. What I think Fortran is still
> lacking is better support of C pointers and structures.
Fortran 90 has user defined types, but they are not ABI
On Tue, Mar 15, 2011 at 10:20 AM, Mark Sienkiewicz wrote:
> The usual expectation is that (when possible) repr() returns a value
> that you can eval() to get the original data back. But,
>
> >>> from numpy import *
> >>> a = array( [ 16.5069863163822 ] )
> >>> b = eval(repr(a))
> >>> a-b
On Tue, Mar 15, 2011 at 11:12 AM, Pauli Virtanen wrote:
> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
> > Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
> > but is this the right fix to this problem? I was confused by the
> > presence of the old PyString_AsStr
Hi,
On Tue, Mar 15, 2011 at 10:12 AM, Pauli Virtanen wrote:
> Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
>> Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
>> but is this the right fix to this problem? I was confused by the
>> presence of the old PyString_AsSt
Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
> Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
> but is this the right fix to this problem? I was confused by the
> presence of the old PyString_AsString function.
It's not a correct fix. The original code seems als
Hi,
On Sun, Mar 13, 2011 at 12:07 PM, Matthew Brett wrote:
> Hi,
>
> On Sun, Mar 13, 2011 at 11:51 AM, Christoph Gohlke wrote:
>>
>>
>> On 3/13/2011 11:29 AM, Matthew Brett wrote:
>>>
>>> Hi
>>>
>>> On Sun, Mar 13, 2011 at 9:54 AM, Christoph Gohlke wrote:
On 3/13/2011 1:57 AM, Matthew
On Tue, Mar 15, 2011 at 12:10, Christopher Barker wrote:
> On 3/15/11 8:33 AM, Charles R Harris wrote:
> > There really isn't a satisfactory array library for C++. The fact that
> > every couple of years there is another project to produce one testifies
> > to that fact.
>
> And I think not just t
Den 15.03.2011 16:05, skrev Matthieu Brucher:
> BTW, instead of Blitzz++, you have vigra and Eigen that are the new
> equivalent libraries, and you may want to keep an eye on Intel's ArBB.
>
Intel's ArBB is interesting. But in order for this to work, there must
be an idustry standard that other
Den 15.03.2011 17:10, skrev Christopher Barker:
> I've been slowly arriving to the conclusion that that is no place for
> C++ in programming. If you really need to twiddle bits, use C. If you
> need high performance numerics, use Fortran. If you need high level
> complex data structures, use Python
Den 15.03.2011 16:33, skrev Charles R Harris:
>
> There really isn't a satisfactory array library for C++. The fact that
> every couple of years there is another project to produce one
> testifies to that fact.
In order to be competitive against Fortran 95, an array library for C++
must do all
The usual expectation is that (when possible) repr() returns a value
that you can eval() to get the original data back. But,
>>> from numpy import *
>>> a = array( [ 16.5069863163822 ] )
>>> b = eval(repr(a))
>>> a-b
array([ -3.6111e-09])
>>> import numpy.testing
>>> numpy.testing
On 3/15/11 8:33 AM, Charles R Harris wrote:
> There really isn't a satisfactory array library for C++. The fact that
> every couple of years there is another project to produce one testifies
> to that fact.
And I think not just the fact that there is not one, but that perhaps
C++ the language, or
On Tue, Mar 15, 2011 at 9:12 AM, Sturla Molden wrote:
> Den 14.03.2011 23:10, skrev Matthieu Brucher:
> > - Fortran 95 has an excellent array support, which is not currently
> > available in C/C++ (perhaps with ArBB?)
>
> In C++ you can actually make array libraries that behave almost like a
> Fo
Den 14.03.2011 23:10, skrev Matthieu Brucher:
> - Fortran 95 has an excellent array support, which is not currently
> available in C/C++ (perhaps with ArBB?)
In C++ you can actually make array libraries that behave almost like a
Fortran compiler (cf. Blitz++, Intel Array Building Blocks), but th
>
> C++ templates maks binaries almost impossible to debug.
>
Never had an issue with this and all my number crunching code is done
through metaprogramming (with vectorization, cache blocking...) So I have a
lot of complex template structures, and debugging them is easy.
Then, if someone doesn't w
Den 14.03.2011 23:10, skrev Matthieu Brucher:
>
> Intel Fortran is an excellent Fortran compiler. Why is Fortran still
> better than C and C++?
> - some rules are different, like arrays passed to functions are ALWAYS
> supposed to be independent in Fortran, whereas in C, you have to add a
> rest
Den 14.03.2011 23:02, skrev Sebastian Haase:
> Sturla has been writing so much about Fortran recently, and Ondrej now
> says he has done the move from C/C++ to Fortran -- I thought Fortran
> was dead ... !? ;-)
> What am I missing here
No, it is just that Fortran receives less hype. If Fortran
I think that I shall never see
a rotate right divide by three
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Ralf,
Actually, ATLAS isn't needed when using MKL.
http://software.intel.com/en-us/forums/showthread.php?t=81451&p=1#144534
I am going to try this link line out
$(MKLROOT)/lib/em64t/libmkl_solver_ilp64.a -Wl,--start-group
$(MKLROOT)/lib/em64t/libmkl_intel_ilp64.a
$(MKLROOT)/lib/em64t/libmkl_int
On Mon, 14 Mar 2011 23:10:13 +0100, Matthieu Brucher
wrote:
> Hi,
>
> Intel Fortran is an excellent Fortran compiler. Why is Fortran still better
> than C and C++?
> - some rules are different, like arrays passed to functions are ALWAYS
> supposed to be independent in Fortran, whereas in C, you
48 matches
Mail list logo
