Hi folks,
I sent the collected feedback on this issue to python-dev:
http://mail.python.org/pipermail/python-dev/2008-November/083493.html
If you are interested, at this point please follow up any further
discussion directly on python-dev. I'll do my best to answer any
questions there, but I'd
Hi all,
Thank you for your replies.
Thanks
On Fri, 2008-10-31 at 12:49 -0500, Robert Kern wrote:
> On Fri, Oct 31, 2008 at 12:20, Wu, Kejia <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I tried the example code here:
> > http://numpy.scipy.org/numpydoc/numpy-20.html#71863
> > But failed:
> > --
On Fri, Nov 7, 2008 at 13:34, Marek Wojciechowski <[EMAIL PROTECTED]> wrote:
> Hi!
> I'm trying to compile fortran code with f2py using the --fcompiler=intel flag
> but the follwoing weird error occurs:
>
> Found executable /opt/intel/fce/10.0.026/bin/ifort
> warning: build_ext: f77_compiler=intel
Hi!
I'm trying to compile fortran code with f2py using the --fcompiler=intel flag
but the follwoing weird error occurs:
Found executable /opt/intel/fce/10.0.026/bin/ifort
warning: build_ext: f77_compiler=intel is not available.
building '_beameb' extension
error: extension '_beameb' has Fortran s
> I also get the same on my 64-bit linux Fedora rawhide with
> ...
Thanks, I've submitted this as ticket #952.
James
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
James Philbin wrote:
> Anyone?
>
> James
>
> On Thu, Nov 6, 2008 at 2:53 PM, James Philbin <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> I might be doing something stupid so I thought i'd check here before
>> filing a bug report.
>> Firstly:
>> In [8]: np.__version__
>> Out[8]: '1.3.0.dev5883'
>>
>>
Anyone?
James
On Thu, Nov 6, 2008 at 2:53 PM, James Philbin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I might be doing something stupid so I thought i'd check here before
> filing a bug report.
> Firstly:
> In [8]: np.__version__
> Out[8]: '1.3.0.dev5883'
>
> Basically, pickling an element from a reca
Hi,
The PIL has some fundamental architectural problems that prevent it
from dealing easily with 16-bit TIFFs, which are exacerbated on little-
endian platforms. Add to this a thin sheen of various byte-order bugs
and other problems in the __array_interface__, and it's really hard to
get co
I can not figure out the format specifications, but the following function
might be a good starting point:
def lst_to_file(lst, filename, fmt='%08d'):
'''
lst: list of arrays to write
filename: output file name
fmt: The format of single item
'''
st
On Thursday 17 July 2008 19:41:51 Anthony Floyd wrote:
> > > What I need to know is how I can trick pickle or Numpy to
> >
> > put the old class into the new class.
> >
> > If you have an example data-file, send it to me off-list and I'll
> > figure out what to do. Maybe it is as simple as
> >
> >
On Fri, Nov 7, 2008 at 8:10 PM, T J <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 7, 2008 at 2:16 AM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
>>
>> And you have no site.cfg at all ?
>>
>
> Wow. I was too focused on the current directory and didn't realize I
> had an old site.cfg in ~/.
>
> Two poi
On Fri, Nov 7, 2008 at 2:16 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
>
> And you have no site.cfg at all ?
>
Wow. I was too focused on the current directory and didn't realize I
had an old site.cfg in ~/.
Two points:
1) Others (myself included) might catch such silliness sooner if the
loc
T J wrote:
>
> I fear I am overlooking something obvious.
>
No, I mixed up the names, I meant libatlas-base-dev.
> It looks like I have the important ones:
>libatlas-base-dev
>libatlas-headers
>libatlas-sse2-dev
>libatlas3gf-base
>libatlas3gf-sse2
>
I have only libatlas-
On Fri, Nov 7, 2008 at 1:48 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
>
> It works for me on Intrepid (64 bits). Did you install
> libatlas3gf-base-dev ? (the names changed in intrepid).
>
I fear I am overlooking something obvious.
$ sudo aptitude search libatlas
p libatlas-3dnow-dev
T J wrote:
> On Fri, Nov 7, 2008 at 1:58 AM, T J <[EMAIL PROTECTED]> wrote:
>
>> That the fortran wrappers were compiled using g77 is also apparent via
>> what is printed out during setup when ATLAS is detected:
>>
>> gcc -pthread _configtest.o -L/usr/lib/atlas -llapack -lblas -o _configtest
>>
T J wrote:
> With r5986, atlas is
> still only detected if I declare ATLAS:
>
> $ ATLAS=/usr/lib python setup.py build
>
> versus
>
> $ unset ATLAS; python setup.py build
>
It works for me on Intrepid (64 bits). Did you install
libatlas3gf-base-dev ? (the names changed in intrepid).
cheers,
On Fri, Nov 7, 2008 at 1:58 AM, T J <[EMAIL PROTECTED]> wrote:
>
> That the fortran wrappers were compiled using g77 is also apparent via
> what is printed out during setup when ATLAS is detected:
>
> gcc -pthread _configtest.o -L/usr/lib/atlas -llapack -lblas -o _configtest
> ATLAS version 3.6.0 b
On Fri, Nov 7, 2008 at 1:26 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> David Cournapeau wrote:
>>
>> Ok, I took a brief look at this: I forgot that Ubuntu and Debian added
>> an aditional library suffix to libraries depending on gfortran ABI. I
>> added support for this in numpy.distutils -
David Cournapeau wrote:
>
> Ok, I took a brief look at this: I forgot that Ubuntu and Debian added
> an aditional library suffix to libraries depending on gfortran ABI. I
> added support for this in numpy.distutils - which was looking for
> libraries explicitely; could you retry *without* a site.cf
On 6-Nov-08, at 11:15 PM, Angus McMorland wrote:
> 2008/11/6 Robert Kern <[EMAIL PROTECTED]>:
>> On Thu, Nov 6, 2008 at 21:54, Angus McMorland <[EMAIL PROTECTED]>
>> wrote:
>>> Hi all,
>>>
>>> I'm trying to import a 16-bit tiff image into a numpy array. I have
>>> found, using google, suggestio
20 matches
Mail list logo
