[Numpy-discussion] תשובה: [OT] any image io module that works with python3?

[Nadav Horesh]

The instillation is OK. The problem is that on my wok PC I do not have PIL 
installed. So:
In [6]: import scikits.image.io as io
---
ImportError   Traceback (most recent call last)
/home/nadav/ in ()
> 1 import scikits.image.io as io

/usr/lib64/python3.1/site-packages/scikits.image-0.3dev-py3.1-linux-x86_64.egg/scikits/image/io/__init__.py
 in ()
 11 # Add this plugin so that we can read images by default

 12 use_plugin('null')
---> 13 use_plugin('pil')
 14 
 15 from .sift import *

/usr/lib64/python3.1/site-packages/scikits.image-0.3dev-py3.1-linux-x86_64.egg/scikits/image/io/_plugins/plugin.py
 in use(name, kind)
122 
123 if not name in available(loaded=True):
--> 124 _load(name)
125 
126 for k in kind:

/usr/lib64/python3.1/site-packages/scikits.image-0.3dev-py3.1-linux-x86_64.egg/scikits/image/io/_plugins/plugin.py
 in _load(plugin)
178 modname = plugin_module_name[plugin]
179 plugin_module = __import__('scikits.image.io._plugins.' + 
modname,
--> 180fromlist=[modname])
181 
182 provides = plugin_provides[plugin]

/usr/lib64/python3.1/site-packages/scikits.image-0.3dev-py3.1-linux-x86_64.egg/scikits/image/io/_plugins/pil_plugin.py
 in ()
  6 from PIL import Image
  7 except ImportError:
> 8 raise ImportError("The Python Image Library could not be found. "
  9   "Please refer to http://pypi.python.org/pypi/PIL/ 
"
 10   "for further instructions.")

ImportError: The Python Image Library could not be found. Please refer to 
http://pypi.python.org/pypi/PIL/ for further instructions.

Shouldn't it skip quietly on missing plugins?
(It is easy to bypass by a patch, but  I am sure you has some design 
considerations here.

  Nadav.


-הודעה מקורית-
מאת: numpy-discussion-boun...@scipy.org 
[mailto:numpy-discussion-boun...@scipy.org] בשם Stéfan van der Walt
נשלח: Monday, March 14, 2011 00:16
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] [OT] any image io module that works with python3?

Hi Nadav

On Sun, Mar 13, 2011 at 8:20 PM, Nadav Horesh  wrote:
> Jest tested the installation (after git clone ...). I had to correct the 
> following lines in _build.py to pass installation:
> lines 72, and 75 should be:
>    f0 = open(f0,'br')
>    f1 = open(f1,'br')

Thanks so much for testing and for the patch; I've pushed your changes:

https://github.com/stefanv/scikits.image/commit/b47ae98ffb92e2de33d9e530201e402e04d865d3

Are you able to load images now?

Cheers
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.6: branching and release notes

[Mark Wiebe]

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
> >>>  wrote:
> 
>  Hi all,
> 
>  On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the
>  first beta. So please get your last commits for 1.6 in by Monday
>  evening.
> 
>  Also, please review and add to the 1.6.0 release notes. I put in
>  headers for several items that need a few lines in the notes, I hope
>  this can be filled in by the authors of those features (Charles:
>  Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of
>  stuff).
> >>>
> >>> I've added a few more things, and made a small change to the iterator
> >>> construction API that I've discovered is useful, but would be more
> difficult
> >>> to do later. The Python exposure of the iterator is renamed from
> 'newiter'
> >>> to 'nditer', is that a reasonable name or does anyone have a better
> >>> suggestion?
> >>
> >> I think nditer is fine, certainly better than newiter. I don't see where
> >> nditer appears in the changes though, the test still uses newiter.
> >
> > I didn't rename the files, I can do that too.
>
> Hi Mark, I see you just did this, but is there anything else you
> want/need to do? If it's necessary I can postpone the first beta by a
> couple of days. Better that than rush things too much and end up with
> an API you have reservations about.
>

I've committed one other change I wanted, renaming
NPY_ITER_NO_INNER_ITERATION to something hopefully a bit more intuitive.
Nothing else was nagging at me, but it would be great if some people went
through the iterator documentation to see if all the names fit their
intuition. We should also come to a consensus on what to call index tuples,
and rename ravel_coords, NPY_ITER_COORDS, NpyIter_GotoCoords, and
NpyIter_GetGetCoords based on the chosen name.

-Mark


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] doc wiki edit rights (was: Inaccuracy in documentation of np.linalg.pinv)

[Ralf Gommers]

On Sat, Mar 12, 2011 at 10:50 AM, Hao Xiong  wrote:
> Hi Ralf,
>
> I am happy to edit it, although I will have to do it later as I won't
> have much free time recently.
>
> I have registered as haoxiong on docs.scipy.org and would like
> to request edit rights to the pinv page.

Hi, can someone with permissions on the doc server give Hao Xiong edit rights?

Thanks,
Ralf

>
> On 03/09/11 04:16, Ralf Gommers wrote:
>> Hi Hao,
>>
>> On Wed, Mar 9, 2011 at 9:01 AM, Hao Xiong  wrote:
>>> I think the documentation for np.linalg.pinv contains some inaccuracies.
>> Thanks for your comments. Are you interested to make some improvements
>> yourself? It's quite easy to do on the numpy doc wiki:
>> http://docs.scipy.org/numpy/docs/numpy.linalg.linalg.pinv/
>> Just ask for edit rights on this list after registering a username.
>>
>> Cheers,
>> Ralf
>>
>>
>>> Most importantly, Moore-Penrose is not defined by the solution to the
>>> least-square
>>> problem. It was defined by the unique solution to 4 equations. Since SVD
>>> can be easily shown to satisfy the same 4 equations, it is the
>>> Moore-Penrose inverse.
>>>
>>> Another way that definition is wrong is that the least-square problem
>>> does not have to have
>>> unique solution. In fact, it can have infinitely many. In this case,
>>> Moore-Penrose is the minimum
>>> norm solution.
>>>
>>> All of this is discussed in the Matlab documentation of pinv, which is
>>> very good.
>>>
>>>
>>> Hao
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.6: branching and release notes

[John Salvatier]

If they return a tuple of indexes I think 'mulitiindex' sounds quite good.
That is exactly what a multiindex is (
http://en.wikipedia.org/wiki/Multi-index_notation).

On Mon, Mar 14, 2011 at 1:14 AM, 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, 2011 at 8:23 PM, Mark Wiebe  wrote:
>> >>>
>> >>> On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers
>> >>>  wrote:
>> 
>>  Hi all,
>> 
>>  On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the
>>  first beta. So please get your last commits for 1.6 in by Monday
>>  evening.
>> 
>>  Also, please review and add to the 1.6.0 release notes. I put in
>>  headers for several items that need a few lines in the notes, I hope
>>  this can be filled in by the authors of those features (Charles:
>>  Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of
>>  stuff).
>> >>>
>> >>> I've added a few more things, and made a small change to the iterator
>> >>> construction API that I've discovered is useful, but would be more
>> difficult
>> >>> to do later. The Python exposure of the iterator is renamed from
>> 'newiter'
>> >>> to 'nditer', is that a reasonable name or does anyone have a better
>> >>> suggestion?
>> >>
>> >> I think nditer is fine, certainly better than newiter. I don't see
>> where
>> >> nditer appears in the changes though, the test still uses newiter.
>> >
>> > I didn't rename the files, I can do that too.
>>
>> Hi Mark, I see you just did this, but is there anything else you
>> want/need to do? If it's necessary I can postpone the first beta by a
>> couple of days. Better that than rush things too much and end up with
>> an API you have reservations about.
>>
>
> I've committed one other change I wanted, renaming
> NPY_ITER_NO_INNER_ITERATION to something hopefully a bit more intuitive.
> Nothing else was nagging at me, but it would be great if some people went
> through the iterator documentation to see if all the names fit their
> intuition. We should also come to a consensus on what to call index tuples,
> and rename ravel_coords, NPY_ITER_COORDS, NpyIter_GotoCoords, and
> NpyIter_GetGetCoords based on the chosen name.
>
> -Mark
>
> 
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numeric 24.2 incompatible with Windows7 SP1

[Douglas Ronne]

Frank Conradie  qfin.net> writes:

> 
> Hi
> 
> I know Numeric 24.2 is really old and probably unsupported by now, but I 
> thought it might be of interest that Service Pack 1 for Windows 7 has 
> "broken" Numeric 24.2.
[pruned]
> 
> Thanks!
> Frank Conradie
> 

Yes, I have had the exact same error, python 2.4, numeric 24.2.  The error is 
in 
multiarray.  Just discovered it this morning.  If you have any luck, please let 
me know!

--Douglas


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] תשובה: [OT] any image io module that works with python3?

[Stéfan van der Walt]

On Mon, Mar 14, 2011 at 9:55 AM, Nadav Horesh  wrote:
> The instillation is OK. The problem is that on my wok PC I do not have PIL 
> installed. So:

Thanks, you are right of course: no plugin should be required upon
import.  I now put the "use_plugin" statement inside a try: except:
block.

Cheers
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numeric 24.2 incompatible with Windows7 SP1

[Frank Conradie]

Hi Douglas, simply recompiling the affected modules "fixes" this issue 
for me, but unfortunately for me I am having trouble recompiling some 
old 3rd party compiled libraries. What are the chances all module 
owners/maintainers will go back and recompile their Python 2.3/2.4 
modules - not very high I would guess.
- Frank

On 14/03/2011 7:45 AM, Douglas Ronne wrote:
> Frank Conradie  qfin.net>  writes:
>
>> Hi
>>
>> I know Numeric 24.2 is really old and probably unsupported by now, but I
>> thought it might be of interest that Service Pack 1 for Windows 7 has
>> "broken" Numeric 24.2.
> [pruned]
>> Thanks!
>> Frank Conradie
>>
> Yes, I have had the exact same error, python 2.4, numeric 24.2.  The error is 
> in
> multiarray.  Just discovered it this morning.  If you have any luck, please 
> let
> me know!
>
> --Douglas
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] rewriting NumPy code in C or C++ or similar

[Jason McCampbell]

Hi Dan,

I am just catching up with the mailing list after falling behind getting a
release.  I am the PM for Enthought's part of refactoring NumPy.  The first
phase of the refactoring project is done except for some clean up and the
new version of NumPy is quite stable.  (25 regression failures against the
core, largely corner cases).  If you want to take a look at it, the code is
in the Numpy github repository: https://github.com/numpy/numpy-refactor

Under the root of the tree, look in
the 'libndarray' directory.  This is the Python-independent core and might
be helpful for what you are trying to do. It has not been released as a part
of an official numpy release yet (under consideration as the core of 2.0)
but has been released as the first beta version of NumPy and SciPy for .NET.

Regards,
Jason


On Mon, Mar 7, 2011 at 5:36 PM, Dan Halbert  wrote:

> We currently have some straightforward NumPy code that indirectly
> implements a C API defined by a third party. We built a Cython layer that
> directly provides the API in a .a library, and then calls Python. The
> layering looks like this:
>
>  C main program -> API in Cython -> Python -> NumPy
>
> This is difficult to package for distribution, because of the Python and
> NumPy dependencies. We may need to reimplement our library so it factors out
> the Python dependency, and I would like to explore the alternatives.
> (Performance may also be a reason to do this, but that is not the main issue
> right now.)
>
> Do you all have some recommendations about tools, libraries, or languages
> that you have used to rewrite NumPy code easily into something that's more
> self-contained and callable from C? For instance, are there some nice C++
> linear algebra libraries that map closely to NumPy? Or is there some
> higher-level compiled array language that looks something like NumPy code? I
> apologize if the answers are obvious: I am not very familiar with the tools
> in this space.
>
> Thanks,
> Dan
>
> (I saw the NumPy Refactoring project discussion from earlier. When that is
> finished, the resulting Python-independent library might be a nice way to
> handle this, but I am thinking shorter-term.)
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
*Jason McCampbell*
Enthought, Inc.
512.850.6069
jmccampb...@enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] תשובה: [OT] any image io module that works with python3?

[Nadav Horesh]

After the following corrections, it works on both 2.7 and 3.1 python versions. 
My limited test included:
python2.7: imread and imshow usng pil, freeimage and qt
python3.1 imread via freeimage and imshow via qt

 Thank you very much,
   Nadav

(The file _build.patch is a patch for _build.py)



From: numpy-discussion-boun...@scipy.org [numpy-discussion-boun...@scipy.org] 
On Behalf Of Stéfan van der Walt [ste...@sun.ac.za]
Sent: 14 March 2011 17:09
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] תשובה: [OT] any image io module that works with 
python3?

On Mon, Mar 14, 2011 at 9:55 AM, Nadav Horesh  wrote:
> The instillation is OK. The problem is that on my wok PC I do not have PIL 
> installed. So:

Thanks, you are right of course: no plugin should be required upon
import.  I now put the "use_plugin" statement inside a try: except:
block.

Cheers
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion



freeimage_plugin.py
Description: freeimage_plugin.py


_build.patch
Description: _build.patch
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [OT] any image io module that works with python3?

[Christoph Gohlke]

On 3/12/2011 9:56 PM, Nadav Horesh wrote:
> This lead to another error probably due to line 68 in map.h. As much as I 
> could trace it, ob_type is a member of PyObject,  not of PyTypeObject. I have 
> no clue how to resolve this.

I just tried PIL-1.1.7-py3 on an Ubuntu 64 bit system: after one change 
to map.c it builds OK (without sane support) and passes all tests but 
one numpy int64 bit related test. Please download again from 
 to make sure you have 
the same sources and try build again.

Christoph

>
>  Nadav.
> 
> From: numpy-discussion-boun...@scipy.org [numpy-discussion-boun...@scipy.org] 
> On Behalf Of Christoph Gohlke [cgoh...@uci.edu]
> Sent: 13 March 2011 00:37
> To: numpy-discussion@scipy.org
> Subject: Re: [Numpy-discussion] [OT] any image io   module  thatworks 
>   withpython3?
>
> On 3/12/2011 12:47 PM, Nadav Horesh wrote:
>> After the  replacement of ö with o, the installation went without errors, 
>> but:
>>
>> nadav@nadav_home ~ $ python3
>> Python 3.1.3 (r313:86834, Feb 25 2011, 11:08:33)
>> [GCC 4.4.4] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
> import _imaging
>> Traceback (most recent call last):
>> File "", line 1, in
>> ImportError: /usr/lib64/python3.1/site-packages/PIL/_imaging.so: undefined 
>> symbol: Py_FindMethod
>
> Py_FindMethod should be excluded by `#ifndef PY3` or similar
> preprocessor statements. There is a typo in map.c line 65: change
> `#ifdef PY3` to `#ifndef PY3` and clean your build directory before
> rebuilding.
>
> Christoph
>
>>
>>Thank you,
>>
>>   Nadav.
>> 
>> From: numpy-discussion-boun...@scipy.org 
>> [numpy-discussion-boun...@scipy.org] On Behalf Of Christoph Gohlke 
>> [cgoh...@uci.edu]
>> Sent: 12 March 2011 21:49
>> To: numpy-discussion@scipy.org
>> Subject: Re: [Numpy-discussion] [OT] any image io module that   works   with 
>>python3?
>>
>> On 3/12/2011 8:45 AM, Nadav Horesh wrote:
>>> I forgot to mention that I work on linux (gentoo x86-64).Here are my 
>>> achievements till now:
>>>
>>> 1. PythonMagick: Needs boost which I do not have it avaiable on python3
>> Boost works on Python 3.1. You might need to compile it.
>>> 2. Pygame: I have the stable version(1.9.1) should it work?
>> You need the developer version from svn.
>>> 3. FreeImage: I installed FreeImagePy on python3, but it doesn't work yet.
>> FreeImagePy is unmaintained, does not work on Python 3, and has problems
>> on 64 bit platforms. Just wrap the functions you need in ctypes.
>>> 4. PIL: I patched setup.py and map.c so "python3 setup.py build" is 
>>> working, but:
>> Try replace "Hans Häggström" with "Hans Haggstrom" in PIL/WalImageFile.py
>>
>> Christoph
>>
>>>
>>> nadav@nadav_home /dev/shm/PIL-1.1.7-py3 $ sudo python3.1  setup.py install
>>> /usr/lib64/python3.1/distutils/dist.py:259: UserWarning: Unknown 
>>> distribution option: 'ext_comp_args'
>>>  warnings.warn(msg)
>>> running install
>>> running build
>>> running build_py
>>> running build_ext
>>> 
>>> PIL 1.1.7 SETUP SUMMARY
>>> 
>>> version   1.1.7
>>> platform  linux2 3.1.3 (r313:86834, Feb 25 2011, 11:08:33)
>>>  [GCC 4.4.4]
>>> 
>>> --- TKINTER support available
>>> --- JPEG support available
>>> --- ZLIB (PNG/ZIP) support available
>>> --- FREETYPE2 support available
>>> --- LITTLECMS support available
>>>
>>> .
>>> .
>>> .
>>>
>>> byte-compiling /usr/lib64/python3.1/site-packages/PIL/WalImageFile.py to 
>>> WalImageFile.pyc
>>> Traceback (most recent call last):
>>>  File "setup.py", line 520, in
>>>setup(*(), **configuration)  # old school :-)
>>>  File "/usr/lib64/python3.1/distutils/core.py", line 149, in setup
>>>dist.run_commands()
>>>  File "/usr/lib64/python3.1/distutils/dist.py", line 919, in 
>>> run_commands
>>>self.run_command(cmd)
>>>  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
>>>cmd_obj.run()
>>>  File "/usr/lib64/python3.1/distutils/command/install.py", line 592, in 
>>> run
>>>self.run_command(cmd_name)
>>>  File "/usr/lib64/python3.1/distutils/cmd.py", line 315, in run_command
>>>self.distribution.run_command(command)
>>>  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
>>>cmd_obj.run()
>>>  File "/usr/lib64/python3.1/distutils/command/install_lib.py", line 98, 
>>> in run
>>>self.byte_compile(outfiles)
>>>  File "/usr/lib64/python3.1/distutils/command/install_lib.py", line 
>>> 135, in byte_compile
>>>dry_run=self.dry_run)
>>>  File "/usr/lib64/python3.1/distutils/util.py", line 560, in 
>>> byte_com

Re: [Numpy-discussion] rewriting NumPy code in C or C++ or similar

[Ondrej Certik]

Hi Sturla,

On Tue, Mar 8, 2011 at 6:25 AM, Sturla Molden  wrote:
> Den 08.03.2011 05:05, skrev Dan Halbert:
>> Thanks, that's a good suggestion. I have not written Fortran since 1971,
>> but it's come a long way. I was a little worried about the row-major vs
>> column-major issue, but perhaps that can be handled just by remembering
>> to reverse the subscript order between C and Fortran.
>
> In practice this is not a problem. Most numerical libraries for C assume
> Fortran-ordering, even OpenGL assumes Fortran-ordering. People program
> MEX files for Matlab in C all the time. Fortran-ordering is assumed in
> MEX files too.
>
> In ANSI C, array bounds must be known at compile time, so a Fortran
> routine with the interface
>
>     subroutine foobar( lda, A )
>         integer lda
>         double precision A(lda,*)
>     end subroutine
>
> will usually be written like
>
>     void foobar( int lda, double A[]);
>
> in C, ignoring different calling convention for lda.
>
> Now we would index A(row,col) in Fortran and A[row + col*lda] in C. Is
> that too difficult to remember?
>
> In ANSI C the issue actually only arises with small "array of arrays"
> having static shape, or convoluted contructs like "pointer to an array
> of pointers to arrays". Just avoid those and stay with 1D arrays in C --
> do the 1D to 2D mapping in you mind.
>
> In C99 arrays are allowed to have dynamic size, which mean we can do
>
>    void foobar( int lda, double *pA )
>    {
>       typedef double row_t [lda];
>       vector_t *A = (vector_t*)((void*)&pA[0]);
>
> Here we must index A[k][i] to match A(i,k) in Fortran. I still have not
> seen anyone use C99 like this, so I think it is merely theoretical.
>
> Chances are if you know how to do this with C99, you also know how to
> get the subscripts right. If you are afraid to forget "to reverse the
> subscript order between C and Fortran", it just tells me you don't
> really know what you are doing when using C, and should probably use
> something else.
>
> Why not Cython? It has "native support" for NumPy arrays.
>
> Personally I prefer Fortran 95, but that is merely a matter of taste.

+1 to all that you wrote about Fortran. I am pretty much switching to
it from C/C++ for all my numerical work, and then I use Cython to call
it from Python, as well as cmake for the build system.

Ondrej
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] how to compile Fortran using setup.py

[Ondrej Certik]

Hi Pearu!

On Sat, Mar 12, 2011 at 2:30 AM, Pearu Peterson
 wrote:
>
>
> On Fri, Mar 11, 2011 at 3:58 AM, Ondrej Certik  wrote:
>>
>> Hi,
>>
>> I spent about an hour googling and didn't figure this out. Here is my
>> setup.py:
>>
>> setup(
>>    name = "libqsnake",
>>    cmdclass = {'build_ext': build_ext},
>>    version = "0.1",
>>    packages = [
>>        'qsnake',
>>        'qsnake.calculators',
>>        'qsnake.calculators.tests',
>>        'qsnake.data',
>>        'qsnake.mesh2d',
>>        'qsnake.tests',
>>        ],
>>    package_data = {
>>        'qsnake.tests': ['phaml_data/domain.*'],
>>        },
>>    include_dirs=[numpy.get_include()],
>>    ext_modules = [Extension("qsnake.cmesh", [
>>        "qsnake/cmesh.pyx",
>>        "qsnake/fmesh.f90",
>>        ])],
>>    description = "Qsnake standard library",
>>    license = "BSD",
>> )
>>
>
> You can specify Fortran code, that you don't want to process with f2py, in
> the libraries list
> and then use the corresponding library in the extension, for example:
>
> setup(...
>    libraries = [('foo', dict(sources=['qsnake/fmesh.f90']))],
>    ext_modules = [Extension("qsnake.cmesh",
>   sources =
> ["qsnake/cmesh.pyx"],
>   libraries = ['foo']
>     )],
>   ...
> )
>
> See also scipy/integrate/setup.py that resolves the same issue but just
> using the configuration function approach.

Indeed, I just tried it and it works! Thanks. I am now able to compile
fortran code into the extension module.

The only problem is that I am not able to convince Cython to also
parse the .pyx files, it clashes with the numpy's implementation of
build_ext. Which usually is not a problem, as long as one doesn't need
to compile Fortran and .pyx at the same time.

So cmake seems like the only robust option anyway.

Ondrej
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] how to compile Fortran using setup.py

[Robert Bradshaw]

On Mon, Mar 14, 2011 at 1:44 PM, Ondrej Certik  wrote:
> Hi Pearu!
>
> On Sat, Mar 12, 2011 at 2:30 AM, Pearu Peterson
>  wrote:
>>
>>
>> On Fri, Mar 11, 2011 at 3:58 AM, Ondrej Certik  wrote:
>>>
>>> Hi,
>>>
>>> I spent about an hour googling and didn't figure this out. Here is my
>>> setup.py:
>>>
>>> setup(
>>>    name = "libqsnake",
>>>    cmdclass = {'build_ext': build_ext},
>>>    version = "0.1",
>>>    packages = [
>>>        'qsnake',
>>>        'qsnake.calculators',
>>>        'qsnake.calculators.tests',
>>>        'qsnake.data',
>>>        'qsnake.mesh2d',
>>>        'qsnake.tests',
>>>        ],
>>>    package_data = {
>>>        'qsnake.tests': ['phaml_data/domain.*'],
>>>        },
>>>    include_dirs=[numpy.get_include()],
>>>    ext_modules = [Extension("qsnake.cmesh", [
>>>        "qsnake/cmesh.pyx",
>>>        "qsnake/fmesh.f90",
>>>        ])],
>>>    description = "Qsnake standard library",
>>>    license = "BSD",
>>> )
>>>
>>
>> You can specify Fortran code, that you don't want to process with f2py, in
>> the libraries list
>> and then use the corresponding library in the extension, for example:
>>
>> setup(...
>>    libraries = [('foo', dict(sources=['qsnake/fmesh.f90']))],
>>    ext_modules = [Extension("qsnake.cmesh",
>>   sources =
>> ["qsnake/cmesh.pyx"],
>>   libraries = ['foo']
>>     )],
>>   ...
>> )
>>
>> See also scipy/integrate/setup.py that resolves the same issue but just
>> using the configuration function approach.
>
> Indeed, I just tried it and it works! Thanks. I am now able to compile
> fortran code into the extension module.
>
> The only problem is that I am not able to convince Cython to also
> parse the .pyx files, it clashes with the numpy's implementation of
> build_ext. Which usually is not a problem, as long as one doesn't need
> to compile Fortran and .pyx at the same time.

In the current Cython tip you can do

ext_modules = cythonize([Extension("qsnake.cmesh", [
"qsnake/cmesh.pyx",
"qsnake/fmesh.f90",
])]),

which will translate the .pyx file to a .c file before hitting distutils.

> So cmake seems like the only robust option anyway.
>
> Ondrej
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Not importing polynomial implementation functions by default

[Charles R Harris]

On Sun, Mar 13, 2011 at 5:01 AM, Ralf Gommers
wrote:

> On Sun, Mar 13, 2011 at 1:57 PM, David Warde-Farley
>  wrote:
> >
> > On 2011-03-12, at 9:32 PM, Charles R Harris wrote:
> >
> >> I'd like to change the polynomial package to only import the Classes,
> leaving the large number of implementation functions to be imported directly
> from the different modules if needed. I always regarded those functions as
> implementation helpers and kept them separate from the class so that others
> could use them to build their own classes if they desired. For most purposes
> I think the classes are more useful. So I think it was a mistake to import
> the functions by; default and I'm looking for a graceful and acceptable way
> out. Any suggestions.
>
> How about just deprecating in 1.6 and removing from the polynomial
> namespace in 2.0? Then you do need to add to the docs explicitly that
> the submodules contain these functions, that they are part of the
> public API and are not going anywhere.
>
>
Is there a clever way to deprecate the functions only in that namespace? I
wrote a script that writes a lot of dummy functions that call the original
with a deprecation message, but I'd sure welcome a cleaner way to do things.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Fortran was dead ... [was Re: rewriting NumPy code in C or C++ or similar]

[Sebastian Haase]

On Mon, Mar 14, 2011 at 9:24 PM, Ondrej Certik  wrote:
> Hi Sturla,
>
> On Tue, Mar 8, 2011 at 6:25 AM, Sturla Molden  wrote:
>> Den 08.03.2011 05:05, skrev Dan Halbert:
>>> Thanks, that's a good suggestion. I have not written Fortran since 1971,
>>> but it's come a long way. I was a little worried about the row-major vs
>>> column-major issue, but perhaps that can be handled just by remembering
>>> to reverse the subscript order between C and Fortran.
>>
>> In practice this is not a problem. Most numerical libraries for C assume
>> Fortran-ordering, even OpenGL assumes Fortran-ordering. People program
>> MEX files for Matlab in C all the time. Fortran-ordering is assumed in
>> MEX files too.
>>
>> In ANSI C, array bounds must be known at compile time, so a Fortran
>> routine with the interface
>>
>>     subroutine foobar( lda, A )
>>         integer lda
>>         double precision A(lda,*)
>>     end subroutine
>>
>> will usually be written like
>>
>>     void foobar( int lda, double A[]);
>>
>> in C, ignoring different calling convention for lda.
>>
>> Now we would index A(row,col) in Fortran and A[row + col*lda] in C. Is
>> that too difficult to remember?
>>
>> In ANSI C the issue actually only arises with small "array of arrays"
>> having static shape, or convoluted contructs like "pointer to an array
>> of pointers to arrays". Just avoid those and stay with 1D arrays in C --
>> do the 1D to 2D mapping in you mind.
>>
>> In C99 arrays are allowed to have dynamic size, which mean we can do
>>
>>    void foobar( int lda, double *pA )
>>    {
>>       typedef double row_t [lda];
>>       vector_t *A = (vector_t*)((void*)&pA[0]);
>>
>> Here we must index A[k][i] to match A(i,k) in Fortran. I still have not
>> seen anyone use C99 like this, so I think it is merely theoretical.
>>
>> Chances are if you know how to do this with C99, you also know how to
>> get the subscripts right. If you are afraid to forget "to reverse the
>> subscript order between C and Fortran", it just tells me you don't
>> really know what you are doing when using C, and should probably use
>> something else.
>>
>> Why not Cython? It has "native support" for NumPy arrays.
>>
>> Personally I prefer Fortran 95, but that is merely a matter of taste.
>
> +1 to all that you wrote about Fortran. I am pretty much switching to
> it from C/C++ for all my numerical work, and then I use Cython to call
> it from Python, as well as cmake for the build system.
>
> Ondrej


Hi,
this is quite amazing...
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 ?
Apparently (from what I was able to read-up so far) there is a BIG
difference between FORTRAN 77 and F95.
But isn't gcc or gfortran still only supporting F77 ?
How about IntelCC's Fortran ?  Is that superior?
Do you guys have any info / blogs / docs where one could get an
up-to-date picture?
Like:
1. How about debugging - does gdb work or is there somthing better ?
2. How is the move of the F77 community to F95 in general ?   How many
people / projects are switching.
3. Or is the move rather going like Fortran 77 -> C -> Python ->
Fortran 95   !?  ;-)

Thanks,
Sebastian Haase
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fortran was dead ... [was Re: rewriting NumPy code in C or C++ or similar]

[Matthieu Brucher]

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 have to add a
restrict keyword
- due to the last fact, Fortran is a language where its compiler could do
more work (vectorization, autoparallelization...)
- Fortran 95 has an excellent array support, which is not currently
available in C/C++ (perhaps with ArBB?)

Nevertheless, when you know C++ correctly, when you want to do something
really efficient, you don't use Fortran. You can be as efficient as in C++,
and you can do fancy stuff (I/O, network...). Class and templates are also
better supported in C++.

Matthieu

2011/3/14 Sebastian Haase 

> On Mon, Mar 14, 2011 at 9:24 PM, Ondrej Certik  wrote:
> > Hi Sturla,
> >
> > On Tue, Mar 8, 2011 at 6:25 AM, Sturla Molden  wrote:
> >> Den 08.03.2011 05:05, skrev Dan Halbert:
> >>> Thanks, that's a good suggestion. I have not written Fortran since
> 1971,
> >>> but it's come a long way. I was a little worried about the row-major vs
> >>> column-major issue, but perhaps that can be handled just by remembering
> >>> to reverse the subscript order between C and Fortran.
> >>
> >> In practice this is not a problem. Most numerical libraries for C assume
> >> Fortran-ordering, even OpenGL assumes Fortran-ordering. People program
> >> MEX files for Matlab in C all the time. Fortran-ordering is assumed in
> >> MEX files too.
> >>
> >> In ANSI C, array bounds must be known at compile time, so a Fortran
> >> routine with the interface
> >>
> >> subroutine foobar( lda, A )
> >> integer lda
> >> double precision A(lda,*)
> >> end subroutine
> >>
> >> will usually be written like
> >>
> >> void foobar( int lda, double A[]);
> >>
> >> in C, ignoring different calling convention for lda.
> >>
> >> Now we would index A(row,col) in Fortran and A[row + col*lda] in C. Is
> >> that too difficult to remember?
> >>
> >> In ANSI C the issue actually only arises with small "array of arrays"
> >> having static shape, or convoluted contructs like "pointer to an array
> >> of pointers to arrays". Just avoid those and stay with 1D arrays in C --
> >> do the 1D to 2D mapping in you mind.
> >>
> >> In C99 arrays are allowed to have dynamic size, which mean we can do
> >>
> >>void foobar( int lda, double *pA )
> >>{
> >>   typedef double row_t [lda];
> >>   vector_t *A = (vector_t*)((void*)&pA[0]);
> >>
> >> Here we must index A[k][i] to match A(i,k) in Fortran. I still have not
> >> seen anyone use C99 like this, so I think it is merely theoretical.
> >>
> >> Chances are if you know how to do this with C99, you also know how to
> >> get the subscripts right. If you are afraid to forget "to reverse the
> >> subscript order between C and Fortran", it just tells me you don't
> >> really know what you are doing when using C, and should probably use
> >> something else.
> >>
> >> Why not Cython? It has "native support" for NumPy arrays.
> >>
> >> Personally I prefer Fortran 95, but that is merely a matter of taste.
> >
> > +1 to all that you wrote about Fortran. I am pretty much switching to
> > it from C/C++ for all my numerical work, and then I use Cython to call
> > it from Python, as well as cmake for the build system.
> >
> > Ondrej
>
>
> Hi,
> this is quite amazing...
> 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 ?
> Apparently (from what I was able to read-up so far) there is a BIG
> difference between FORTRAN 77 and F95.
> But isn't gcc or gfortran still only supporting F77 ?
> How about IntelCC's Fortran ?  Is that superior?
> Do you guys have any info / blogs / docs where one could get an
> up-to-date picture?
> Like:
> 1. How about debugging - does gdb work or is there somthing better ?
> 2. How is the move of the F77 community to F95 in general ?   How many
> people / projects are switching.
> 3. Or is the move rather going like Fortran 77 -> C -> Python ->
> Fortran 95   !?  ;-)
>
> Thanks,
> Sebastian Haase
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Information System Engineer, Ph.D.
Blog: http://matt.eifelle.com
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] תשובה: [OT] any image io module that works with python3?

[Stéfan van der Walt]

On Mon, Mar 14, 2011 at 8:04 PM, Nadav Horesh  wrote:
> After the following corrections, it works on both 2.7 and 3.1 python 
> versions. My limited test included:
> python2.7: imread and imshow usng pil, freeimage and qt
> python3.1 imread via freeimage and imshow via qt

Thanks, I tried to fix the filename problem using numpy.compat.asbytes.  I'm
now building scipy under Py3 before I can test the changes, but I hope
they're ok.

Regards
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] doc wiki edit rights (was: Inaccuracy in documentation of np.linalg.pinv)

[Stéfan van der Walt]

Hi Ralf

On Mon, Mar 14, 2011 at 10:28 AM, Ralf Gommers
 wrote:
> Hi, can someone with permissions on the doc server give Hao Xiong edit rights?

You now have admin status.  I've also set Hao up as an editor.

Regards
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] finding atlas

[Mag Gam]

Trying to compile Numpy with Intel's MKL. I have exported the proper
paths for BLAS and LAPACK and I think the build script found it.
However, I am having a lot of trouble with ATLAS. What library file
should I use for it?

tia
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] sage: isscalar can't hear quacks

[D. S. McNeil]

(Sending upstream from http://trac.sagemath.org/sage_trac/ticket/10928)

sage: import numpy
sage: m = numpy.matrix(numpy.arange(6)).reshape(3,2)
sage: m[:,int(0)]
matrix([[0],
[2],
[4]])
sage: m[:,0]
matrix([[0, 2, 4]])

That is, Python ints produce a column but Sage Integers produce a row!
 This happens because

sage: numpy.isscalar(int(0))
True
sage: numpy.isscalar(Integer(0))
False

where isscalar simply tries

   if isinstance(num, generic):
return True
else:
return type(num) in ScalarType

Since Sage Integers (or Python Fractions, or any other unknown scalar)
aren't instances of generic or listed in ScalarType, isscalar returns
False, and there's an unintended fallthrough in matrix.__getitem__.
ISTM either __getitem__ needs to change or isscalar needs to become
more accepting, or both.. but the former might leave some other
unexpected isscalar-related issues elsewhere and I don't know enough
about numpy internals to know if broadening isscalar would cause
problems of its own.

Recommendations?


Doug

--
Department of Earth Sciences
University of Hong Kong
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Add New Functionality for Indexing Along an Axis to Numpy?

[Jonathan Taylor]

Please excuse the double post as I suspect people who may have
thoughts on the inclusion of such functionality in numpy were not
following the discussion due to the old subject.  I am perfectly happy
keeping this functionality locally but some of my colleagues have also
indicated that they have resorted to loops in the past to solve this
not uncommon use case so perhaps it would be helpful to more people if
it (or something similar?) was included in numpy?

Jonathan.

On Thu, Mar 10, 2011 at 12:00 PM, Jonathan Taylor
 wrote:
> I see.
>
> Should functionality like this be included in numpy?
>
> Jon.
>
>
> On Tue, Mar 8, 2011 at 3:39 PM,   wrote:
>> On Tue, Mar 8, 2011 at 3:03 PM, Jonathan Taylor
>>  wrote:
>>> I am wanting to use an array b to index into an array x with dimension
>>> bigger by 1 where the element of b indicates what value to extract
>>> along a certain direction.  For example, b = x.argmin(axis=1).
>>> Perhaps I want to use b to create x.min(axis=1) but also to index
>>> perhaps another array of the same size.
>>>
>>> I had a difficult time finding a way to do this with np.take easily
>>> and even with fancy indexing the resulting line is very complicated:
>>>
>>> In [322]: x.shape
>>> Out[322]: (2, 3, 4)
>>>
>>> In [323]: x.min(axis=1)
>>> Out[323]:
>>> array([[ 2,  1,  7,  4],
>>>       [ 8,  0, 15, 12]])
>>>
>>> In [324]: x[np.arange(x.shape[0])[:,np.newaxis,np.newaxis],
>>> idx[:,np.newaxis,:], np.arange(x.shape[2])]
>>> Out[324]:
>>> array([[[ 2,  1,  7,  4]],
>>>
>>>       [[ 8,  0, 15, 12]]])
>>>
>>> In any case I wrote myself my own function for doing this (below) and
>>> am wondering if this is the best way to do this or if there is
>>> something else in numpy that I should be using? -- I figure that this
>>> is a relatively common usecase.
>>>
>>> Thanks,
>>> Jon.
>>>
>>> def mytake(A, b, axis):
>>>    assert len(A.shape) == len(b.shape)+1
>>>
>>>    idx = []
>>>    for i in range(len(A.shape)):
>>>        if i == axis:
>>>            temp = b.copy()
>>>            shapey = list(temp.shape)
>>>            shapey.insert(i,1)
>>>        else:
>>>            temp = np.arange(A.shape[i])
>>>            shapey = [1]*len(b.shape)
>>>            shapey.insert(i,A.shape[i])
>>>        shapey = tuple(shapey)
>>>        temp = temp.reshape(shapey)
>>>        idx += [temp]
>>>
>>>    return A[tuple(idx)].squeeze()
>>>
>>>
>>> In [319]: util.mytake(x,x.argmin(axis=1), 1)
>>> Out[319]:
>>> array([[ 2,  1,  7,  4],
>>>       [ 8,  0, 15, 12]])
>>>
>>> In [320]: x.min(axis=1)
>>> Out[320]:
>>> array([[ 2,  1,  7,  4],
>>>       [ 8,  0, 15, 12]])
>>
>> fewer lines but essentially the same thing and no shortcuts, I think
>>
> x= np.random.randint(5, size=(2, 3, 4))
> x
>> array([[[3, 1, 0, 1],
>>        [4, 2, 2, 1],
>>        [2, 3, 2, 2]],
>>
>>       [[2, 1, 1, 1],
>>        [0, 2, 0, 3],
>>        [2, 3, 3, 1]]])
>>
> idx = [np.arange(i) for i in x.shape]
> idx = list(np.ix_(*idx))
> idx[axis]=np.expand_dims(x.argmin(axis),axis)
> x[idx]
>> array([[[2, 1, 0, 1]],
>>
>>       [[0, 1, 0, 1]]])
>>
> np.squeeze(x[idx])
>> array([[2, 1, 0, 1],
>>       [0, 1, 0, 1]])
>>
> mytake(x,x.argmin(axis=1), 1)
>> array([[2, 1, 0, 1],
>>       [0, 1, 0, 1]])
>>
>> Josef
>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Add New Functionality for Indexing Along an Axis to Numpy?

[John Salvatier]

The new iteration functionality will be providing this in the near future
(along with many other things). See
https://github.com/numpy/numpy/blob/master/doc/neps/new-iterator-ufunc.rst

On Mon, Mar 14, 2011 at 6:30 PM, Jonathan Taylor <
jonathan.tay...@utoronto.ca> wrote:

> Please excuse the double post as I suspect people who may have
> thoughts on the inclusion of such functionality in numpy were not
> following the discussion due to the old subject.  I am perfectly happy
> keeping this functionality locally but some of my colleagues have also
> indicated that they have resorted to loops in the past to solve this
> not uncommon use case so perhaps it would be helpful to more people if
> it (or something similar?) was included in numpy?
>
> Jonathan.
>
> On Thu, Mar 10, 2011 at 12:00 PM, Jonathan Taylor
>  wrote:
> > I see.
> >
> > Should functionality like this be included in numpy?
> >
> > Jon.
> >
> >
> > On Tue, Mar 8, 2011 at 3:39 PM,   wrote:
> >> On Tue, Mar 8, 2011 at 3:03 PM, Jonathan Taylor
> >>  wrote:
> >>> I am wanting to use an array b to index into an array x with dimension
> >>> bigger by 1 where the element of b indicates what value to extract
> >>> along a certain direction.  For example, b = x.argmin(axis=1).
> >>> Perhaps I want to use b to create x.min(axis=1) but also to index
> >>> perhaps another array of the same size.
> >>>
> >>> I had a difficult time finding a way to do this with np.take easily
> >>> and even with fancy indexing the resulting line is very complicated:
> >>>
> >>> In [322]: x.shape
> >>> Out[322]: (2, 3, 4)
> >>>
> >>> In [323]: x.min(axis=1)
> >>> Out[323]:
> >>> array([[ 2,  1,  7,  4],
> >>>   [ 8,  0, 15, 12]])
> >>>
> >>> In [324]: x[np.arange(x.shape[0])[:,np.newaxis,np.newaxis],
> >>> idx[:,np.newaxis,:], np.arange(x.shape[2])]
> >>> Out[324]:
> >>> array([[[ 2,  1,  7,  4]],
> >>>
> >>>   [[ 8,  0, 15, 12]]])
> >>>
> >>> In any case I wrote myself my own function for doing this (below) and
> >>> am wondering if this is the best way to do this or if there is
> >>> something else in numpy that I should be using? -- I figure that this
> >>> is a relatively common usecase.
> >>>
> >>> Thanks,
> >>> Jon.
> >>>
> >>> def mytake(A, b, axis):
> >>>assert len(A.shape) == len(b.shape)+1
> >>>
> >>>idx = []
> >>>for i in range(len(A.shape)):
> >>>if i == axis:
> >>>temp = b.copy()
> >>>shapey = list(temp.shape)
> >>>shapey.insert(i,1)
> >>>else:
> >>>temp = np.arange(A.shape[i])
> >>>shapey = [1]*len(b.shape)
> >>>shapey.insert(i,A.shape[i])
> >>>shapey = tuple(shapey)
> >>>temp = temp.reshape(shapey)
> >>>idx += [temp]
> >>>
> >>>return A[tuple(idx)].squeeze()
> >>>
> >>>
> >>> In [319]: util.mytake(x,x.argmin(axis=1), 1)
> >>> Out[319]:
> >>> array([[ 2,  1,  7,  4],
> >>>   [ 8,  0, 15, 12]])
> >>>
> >>> In [320]: x.min(axis=1)
> >>> Out[320]:
> >>> array([[ 2,  1,  7,  4],
> >>>   [ 8,  0, 15, 12]])
> >>
> >> fewer lines but essentially the same thing and no shortcuts, I think
> >>
> > x= np.random.randint(5, size=(2, 3, 4))
> > x
> >> array([[[3, 1, 0, 1],
> >>[4, 2, 2, 1],
> >>[2, 3, 2, 2]],
> >>
> >>   [[2, 1, 1, 1],
> >>[0, 2, 0, 3],
> >>[2, 3, 3, 1]]])
> >>
> > idx = [np.arange(i) for i in x.shape]
> > idx = list(np.ix_(*idx))
> > idx[axis]=np.expand_dims(x.argmin(axis),axis)
> > x[idx]
> >> array([[[2, 1, 0, 1]],
> >>
> >>   [[0, 1, 0, 1]]])
> >>
> > np.squeeze(x[idx])
> >> array([[2, 1, 0, 1],
> >>   [0, 1, 0, 1]])
> >>
> > mytake(x,x.argmin(axis=1), 1)
> >> array([[2, 1, 0, 1],
> >>   [0, 1, 0, 1]])
> >>
> >> Josef
> >>
> >>> ___
> >>> NumPy-Discussion mailing list
> >>> NumPy-Discussion@scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>>
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Not importing polynomial implementation functions by default

[Ralf Gommers]

On Tue, Mar 15, 2011 at 5:41 AM, Charles R Harris
 wrote:
>
>
> On Sun, Mar 13, 2011 at 5:01 AM, Ralf Gommers 
> wrote:
>>
>> On Sun, Mar 13, 2011 at 1:57 PM, David Warde-Farley
>>  wrote:
>> >
>> > On 2011-03-12, at 9:32 PM, Charles R Harris wrote:
>> >
>> >> I'd like to change the polynomial package to only import the Classes,
>> >> leaving the large number of implementation functions to be imported 
>> >> directly
>> >> from the different modules if needed. I always regarded those functions as
>> >> implementation helpers and kept them separate from the class so that 
>> >> others
>> >> could use them to build their own classes if they desired. For most 
>> >> purposes
>> >> I think the classes are more useful. So I think it was a mistake to import
>> >> the functions by; default and I'm looking for a graceful and acceptable 
>> >> way
>> >> out. Any suggestions.
>>
>> How about just deprecating in 1.6 and removing from the polynomial
>> namespace in 2.0? Then you do need to add to the docs explicitly that
>> the submodules contain these functions, that they are part of the
>> public API and are not going anywhere.
>>
>
> Is there a clever way to deprecate the functions only in that namespace? I
> wrote a script that writes a lot of dummy functions that call the original
> with a deprecation message, but I'd sure welcome a cleaner way to do things.

Seems clean to me if you're using numpy.deprecate for it. Can you
commit that today?

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.6: branching and release notes

[Ralf Gommers]

On Mon, Mar 14, 2011 at 9:11 PM, John Salvatier
 wrote:
> If they return a tuple of indexes I think 'mulitiindex' sounds quite good.
> That is exactly what a multiindex is
> (http://en.wikipedia.org/wiki/Multi-index_notation).
>
> On Mon, Mar 14, 2011 at 1:14 AM, Mark Wiebe  wrote:
>>
>> 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
>>> >>>  wrote:
>>> 
>>>  Hi all,
>>> 
>>>  On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the
>>>  first beta. So please get your last commits for 1.6 in by Monday
>>>  evening.
>>> 
>>>  Also, please review and add to the 1.6.0 release notes. I put in
>>>  headers for several items that need a few lines in the notes, I hope
>>>  this can be filled in by the authors of those features (Charles:
>>>  Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of
>>>  stuff).
>>> >>>
>>> >>> I've added a few more things, and made a small change to the iterator
>>> >>> construction API that I've discovered is useful, but would be more
>>> >>> difficult
>>> >>> to do later. The Python exposure of the iterator is renamed from
>>> >>> 'newiter'
>>> >>> to 'nditer', is that a reasonable name or does anyone have a better
>>> >>> suggestion?
>>> >>
>>> >> I think nditer is fine, certainly better than newiter. I don't see
>>> >> where
>>> >> nditer appears in the changes though, the test still uses newiter.
>>> >
>>> > I didn't rename the files, I can do that too.
>>>
>>> Hi Mark, I see you just did this, but is there anything else you
>>> want/need to do? If it's necessary I can postpone the first beta by a
>>> couple of days. Better that than rush things too much and end up with
>>> an API you have reservations about.
>>
>> I've committed one other change I wanted, renaming
>> NPY_ITER_NO_INNER_ITERATION to something hopefully a bit more intuitive.
>> Nothing else was nagging at me, but it would be great if some people went
>> through the iterator documentation to see if all the names fit their
>> intuition. We should also come to a consensus on what to call index tuples,
>> and rename ravel_coords, NPY_ITER_COORDS, NpyIter_GotoCoords, and
>> NpyIter_GetGetCoords based on the chosen name.

MultiIndex / multi_index works for me too. Can you rename that today
if no one comes up with something better?

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] finding atlas

[Ralf Gommers]

On Tue, Mar 15, 2011 at 8:12 AM, Mag Gam  wrote:
> Trying to compile Numpy with Intel's MKL. I have exported the proper
> paths for BLAS and LAPACK and I think the build script found it.
> However, I am having a lot of trouble with ATLAS. What library file
> should I use for it?

That's not very specific. Can you send us your site.cfg, build log and
details like platform, python version, etc?

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.6: branching and release notes

[Mark Wiebe]

On Mon, Mar 14, 2011 at 8:24 PM, Ralf Gommers
wrote:

> On Mon, Mar 14, 2011 at 9:11 PM, John Salvatier
>  wrote:
> > If they return a tuple of indexes I think 'mulitiindex' sounds quite
> good.
> > That is exactly what a multiindex is
> > (http://en.wikipedia.org/wiki/Multi-index_notation).
> >
> > On Mon, Mar 14, 2011 at 1:14 AM, Mark Wiebe  wrote:
> >>
> >> 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
> >>> >>>  wrote:
> >>> 
> >>>  Hi all,
> >>> 
> >>>  On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag
> the
> >>>  first beta. So please get your last commits for 1.6 in by Monday
> >>>  evening.
> >>> 
> >>>  Also, please review and add to the 1.6.0 release notes. I put in
> >>>  headers for several items that need a few lines in the notes, I
> hope
> >>>  this can be filled in by the authors of those features (Charles:
> >>>  Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch
> of
> >>>  stuff).
> >>> >>>
> >>> >>> I've added a few more things, and made a small change to the
> iterator
> >>> >>> construction API that I've discovered is useful, but would be more
> >>> >>> difficult
> >>> >>> to do later. The Python exposure of the iterator is renamed from
> >>> >>> 'newiter'
> >>> >>> to 'nditer', is that a reasonable name or does anyone have a better
> >>> >>> suggestion?
> >>> >>
> >>> >> I think nditer is fine, certainly better than newiter. I don't see
> >>> >> where
> >>> >> nditer appears in the changes though, the test still uses newiter.
> >>> >
> >>> > I didn't rename the files, I can do that too.
> >>>
> >>> Hi Mark, I see you just did this, but is there anything else you
> >>> want/need to do? If it's necessary I can postpone the first beta by a
> >>> couple of days. Better that than rush things too much and end up with
> >>> an API you have reservations about.
> >>
> >> I've committed one other change I wanted, renaming
> >> NPY_ITER_NO_INNER_ITERATION to something hopefully a bit more intuitive.
> >> Nothing else was nagging at me, but it would be great if some people
> went
> >> through the iterator documentation to see if all the names fit their
> >> intuition. We should also come to a consensus on what to call index
> tuples,
> >> and rename ravel_coords, NPY_ITER_COORDS, NpyIter_GotoCoords, and
> >> NpyIter_GetGetCoords based on the chosen name.
>
> MultiIndex / multi_index works for me too. Can you rename that today
> if no one comes up with something better?


I've pushed a patch with the rename. Can someone review it to check that
it's all good?

-Mark

>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion