Hi,
when compiling numpy-1.40 with the Sun Studio Compilers (v12 Update 1) on Linux
(an OpenSUSE 11.1 in my case), about 30 tests in numpy.test() fail; all
failures are related to the arctan2 function.
I've found that in r7732 a patch was applied to
trunk/numpy/core/src/private/npy_config.h i
Hello!
I ran into the following problem:
I have easy_installable packages which list numpy as a dependency. numpy itself
is installed in the system's site-packages directory and works fine.
When running a python setup.py install of the package with numpy v1.2.0
installed, everything works fin
Hello,
I tried to compile and install numpy 1.3.0b1 on a Suse Linux 10.3 with Python
2.5.x and an Intel C and Fortran compilers 10.1 as well as the MKL 10.0. The
distutils do find the compilers and the MKL (when using similar settings as I
used successfully for all previous numpy versions sonce
Hello,
I tried to compile and install numpy 1.3.0b1 on a Suse Linux 10.3 with Python
2.5.x and an Intel C and Fortran compilers 10.1 as well as the MKL 10.0. The
distutils do find the compilers and the MKL (when using similar settings as I
used successfully for all previous numpy versions sonce
the .src files converted?
Many thanks,
Christian.
- "Charles R Harris" wrote:
>
>
>
> On Thu, Mar 26, 2009 at 6:25 PM, Christian Marquardt < christ...@marquardt.sc
> > wrote:
>
Hello,
>
> I tried to compile and install numpy 1.3.0b1 on a
seem recognize
other packages which are only available there (e.g., scipy or netCDF4 if
specified as a requirement for the install... strange. It also doesn't seem
to work for tables (2.1, so not the newest version)).
Any ideas on what might be going on?
Thanks a lot,
Christian.
-
huck
>
>
>
> _______ Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Dr. Christian Marquardt Email: christ...@marquardt.sc
Wilhelm-Leuschner-Str. 27 Tel.: +
omplex64)
------
Ran 2029 tests in 19.729s
FAILED (KNOWNFAIL=1, failures=4)
MEDEA /home/marq>
- "Charles R Harris" wrote:
>
>
>
> On Thu, Mar 26, 2009 at 9:06 PM, Charles R Harris < charles
Hi David,
> I *guess* that the compiler command line does not work with your
> changes, and that distutils got confused, and fails somewhere later
> (or sooner, who knows). Without actually seeing the errors you got, it
> is difficult to know more - but I would make sure the command line
> argumen
They are, also in v1..3.0rc1
Many thanks!
Christian
- "Charles R Harris" wrote:
>
>
>
> 2009/3/27 Christian Marquardt < christ...@marquardt.sc >
>
> Error messages? Sure;-)
>
> python -c 'import numpy; numpy.test()'
>
Hi,
I've been carrying these modifcations of the build-in compiler
command line arguments for the 32-bit Intel compilers for quite
some while now; maybe they are interesting for other people as
well... I've been using this with ifort (IFORT) 10.1 20080801
on a Suse Linux 10.3.
Rationale for in
Dear list,
apologies if the answer to my question is obvious...
Is the following intentional?
$>python
Python 2.4 (#1, Mar 22 2005, 21:42:42)
[GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import num
Very nice!
> """
> one-line summary not using variable names or the function name
I would personally prefer that the first name contains the function (but
nor arguments) - that way, when you are scrolling back in your terminal,
or have a version printed out, you know what function/method the
doc
On Wed, 2007-01-10 at 17:53 -0600, Robert Kern wrote:
> How are you viewing the docstrings that wouldn't associate the docstring with
> the function?
print .__doc__
Like so:
Python 2.4 (#1, Mar 22 2005, 21:42:42)
[GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2
Type "help", "co
Dear rex,
I'll try to explain... I hope it's not too basic.
Python is searching for its modules along the PYTHONPATH, i.e. a list
of directories where it expects to find whatever it needs. This is the
same as the Unix shell (or the DOC command.com) is looking in the PATH in
order
to find programs
Dear list,
attached is a patch for the original pycdf-0.6.2-rc1 distribution as
available through sourceforge - and a little shell script illustrating
how to install it. After applyng the patch, it should be configured for
numpy. Note that the "installation" script uses an environment variable
PRE
X/lib) and header
files (in $PREFIX/include/hdf), so it it almost certainly needs to be
adapted to the location of the actual HDF libraries and headers.
Regards,
Christian.
On Fri, February 9, 2007 22:00, Christian Marquardt wrote:
> Dear list,
>
> attached is a patch for the original
On Fri, February 9, 2007 22:28, Christopher Barker wrote:
>> Andre Gosselin (the guy who wrote pycdf) also wrote an interface to HDF4
>> (not 5) named pyhdf.
>
> Is he still maintaining these packages? Have you submitted the patches
> to him?
a) Don't know; the last releases of pycdf and pyhdf are
Oops!
> a) Don't know; the last releases of pycdf and pyhdf are from February 2001
pycdf is from 2006, of course. Sorry!
Chris.
___
Numpy-discussion mailing list
Numpy-dis
Hello,
I've run into a problem building numpy-1.0.2 on AIX (using gcc and native
Fortran compilers). The problem on that platform in general is that the
process for building shared libraries is different from what's normally
done (and it's a pain...)
Anyway. Core python has a dedicated script cal
:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christian Marquardt wrote:
>> Hello,
>>
>> I've run into a problem building numpy-1.0.2 on AIX (using gcc and
>> native
>> Fortran compilers). The problem on that platform in general is that the
>> pr
Sun has recently released their compilers under an opensource license for
Linux as well (Sun Studio Express or something), including their perflib -
which includes Blas and Lapack. Has somebody tried how that combination
performs, compared to Intel MKL or Atlas? I think they are free even for
comme
Yes,
that worked - many thanks!
Christian.
On Thu, April 19, 2007 22:38, David M. Cooke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christian Marquardt wrote:
>> Dear David,
>>
>> the svn version of numpy does indeed build cleanly on AIX. M
Hello,
The following is what I expected...
>>> y = 1234
>>> x = array([1], dtype = "uint64")
>>> print x + y, (x + y).dtype.type
[1235]
but is this the way it should be? (numpy 1.0.2, Linux, Intel comilers)
>>> print x[0] + y, type(x[0] + y)
1235.0
Thanks,
Christian.
__
On Mon, April 23, 2007 01:28, Charles R Harris wrote:
> Looks like a bug to me:
>
> In [5]: x = array([1],dtype=uint64)
>
> In [6]: type(x[0])
> Out[6]:
>
> In [7]: type(x[0]+1)
> Out[7]:
>
> Chuck
Yeah. Especially as it works apparently fine for uint32 and int64.
Christian.
__
Dear all,
this is odd:
>>> import numpy as np
>>> fact = 2825L * 86400L
>>> nn = np.array([-20905000L])
>>> nn
array([-20905000], dtype=int64)
>>> nn[0] // fact
0
But:
>>> long(nn[0]) // fact
-1L
Is this a bug in numpy, or in python's implementation of longs? I w
Actually,
it happens for normal integers as well:
>>> n = np.array([-5, -100, -150])
>>> n // 100
array([ 0, -1, -1])
>>> -5//100, -100//100, -150//100
(-1, -1, -2)
On Mon, April 23, 2007 22:20, Christian Marquardt wrote:
> Dear all,
>
> this i
Hmmm,
On Mon, April 23, 2007 22:29, Christian Marquardt wrote:
> Actually,
>
> it happens for normal integers as well:
>
>>>> n = np.array([-5, -100, -150])
>>>> n // 100
>array([ 0, -1, -1])
>>>> -5//100, -100//100, -150//
Restore the invariant, and follow python.
This
>>> -5 // 6
-1
and
>>> array([-5])[0] // 6
0
simply doesn't make sense - in any language, you would expect that
all basic operators provide you with the same same answer when
applied to the same number, no?
Christian.
On Tue, Apri
On Tue, April 24, 2007 23:08, Robert Kern wrote:
> Christian Marquardt wrote:
>> Restore the invariant, and follow python.
>>
>> This
>>
>>>>> -5 // 6
>>-1
>>
>> and
>>
>>>>> array([-5])[0] // 6
>&g
On Tue, April 24, 2007 23:31, Christian Marquardt wrote:
> On Tue, April 24, 2007 23:08, Robert Kern wrote:
>> Christian Marquardt wrote:
>>> Restore the invariant, and follow python.
>>>
>>> This
>>>
>>>>>> -5 // 6
&g
On Wed, May 2, 2007 23:36, James Boyle wrote:
> OS X 10.4.9, python 2.5, numpy 1.0.3.dev3726, netcdf 3.6.2
>
> /usr/bin/ld: warning /Users/boyle5/netcdf-3.6.2/lib/libnetcdf.a
> archive's cputype (7, architecture i386) does not match cputype (18)
> for specified -arch flag: ppc (can't load from
Hi,
I think the default for the standard python distutils is to use the
compiler and the compiler settings for the C compiler that were used to
build Python itself. There might be ways to specify other compilers; but
if you have a shared python library build with one compiler and modules
build wit
On Fri, June 15, 2007 06:01, David Cournapeau wrote:
> I think it is important to separate different issues: object code
> compatibility, runtime compatibility, etc... Those are different issues.
> First, mixing ICC compiled code and gcc code *has* to be possible (I
> have never tried), otherwise,
34 matches
Mail list logo
