Re: [Numpy-discussion] Hiring: Software Developer, Scientific Applications

[David Goldsmith]

Is telecommuting an option?

DG

On Wed, Mar 24, 2010 at 4:44 PM, Amenity Applewhite
 wrote:
>
> Enthought is hiring a Software Developer.
> See the description below, or on our
> website: http://www.enthought.com/company/sd-scientific-app.php
> Best,
> Amenity
> --
> Amenity Applewhite
> Enthought, Inc.
> Scientific Computing Solutions
> www.enthought.com
>
>
>
> Software Developer
>
> The Software Developer at Enthought, Inc. participates in the development of
> scientific and technical applications involving GUIs, 2-D and 3-D graphics,
> workflow and pipeline architecture, and numerical algorithms.   The position
> also involves some interaction with clients. Some travel may be required.
>
> We are interested both in experienced applicants as well as in recent
> graduates. Applicants should have a BS, MS, or PhD degree with a strong
> background in science and mathematics, as well as real experience developing
> quality software, either commercial or open source. More experienced
> applicants should also have demonstrated project management skills and the
> ability to lead a team of strong developers with highly technical
> backgrounds.
>
> Applicants will be measured against the following qualifications:
>
> • (Required) Bachelor's Degree in Computer Science or other scientific or
> engineering field with preferably an M.S. or Ph.D. degree.
> • (Required) Minimum 2 years of technical lead or development experience
> with 4 or more years preferred.
> • Ability to understand a problem domain and then conceive of and implement
> an intuitive user interface geared toward the scientist or engineer user.
> • Discipline, pride, and professionalism to write readable, documented, and
> unit-tested code that serves as an example to others who later study your
> work.
> • Strong work ethic and commitment to satisfying the customer.
> • Experience with Python, and a strong understanding of how to apply its
> capabilities to develop GUI frameworks, work flow frameworks, and elegant
> scientific applications.
> • Strong understanding of statistics, optimization, image processing, signal
> processing, or other technical area.
> • Experience with the following:
> • GUI frameworks such as NetBeans or Eclipse
> • wxPython, Qt
> • Low-level 2-D graphics APIs such as Quartz or GDI+
> • 3-D graphics, preferably using VTK
> • Developing or working with plotting APIs
> • Experience using (and interest in contributing to) SciPy
> • numeric algorithms
> Enthought offers competitive salaries and the opportunity to work on varied
> and interesting technical projects. We are located in Austin, TX,
> consistently rated as one of the best places to live in the US.  Benefits
> include health, dental, vision and a 401k plan.
>
> If you are interested in applying, submit a resume to j...@enthought.com.
> Code samples and links to previous work are encouraged but not required.
>
>
>
>
>
> ___
> 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] Hiring: Software Developer, Scientific Applications

[David Goldsmith]

On Thu, Mar 25, 2010 at 1:21 AM, David Goldsmith
 wrote:
> Is telecommuting an option?
>
> DG

Sorry, I didn't mean to send that to the list. :-(

DG

> On Wed, Mar 24, 2010 at 4:44 PM, Amenity Applewhite
>  wrote:
>>
>> Enthought is hiring a Software Developer.
>> See the description below, or on our
>> website: http://www.enthought.com/company/sd-scientific-app.php
>> Best,
>> Amenity
>> --
>> Amenity Applewhite
>> Enthought, Inc.
>> Scientific Computing Solutions
>> www.enthought.com
>>
>>
>>
>> Software Developer
>>
>> The Software Developer at Enthought, Inc. participates in the development of
>> scientific and technical applications involving GUIs, 2-D and 3-D graphics,
>> workflow and pipeline architecture, and numerical algorithms.   The position
>> also involves some interaction with clients. Some travel may be required.
>>
>> We are interested both in experienced applicants as well as in recent
>> graduates. Applicants should have a BS, MS, or PhD degree with a strong
>> background in science and mathematics, as well as real experience developing
>> quality software, either commercial or open source. More experienced
>> applicants should also have demonstrated project management skills and the
>> ability to lead a team of strong developers with highly technical
>> backgrounds.
>>
>> Applicants will be measured against the following qualifications:
>>
>> • (Required) Bachelor's Degree in Computer Science or other scientific or
>> engineering field with preferably an M.S. or Ph.D. degree.
>> • (Required) Minimum 2 years of technical lead or development experience
>> with 4 or more years preferred.
>> • Ability to understand a problem domain and then conceive of and implement
>> an intuitive user interface geared toward the scientist or engineer user.
>> • Discipline, pride, and professionalism to write readable, documented, and
>> unit-tested code that serves as an example to others who later study your
>> work.
>> • Strong work ethic and commitment to satisfying the customer.
>> • Experience with Python, and a strong understanding of how to apply its
>> capabilities to develop GUI frameworks, work flow frameworks, and elegant
>> scientific applications.
>> • Strong understanding of statistics, optimization, image processing, signal
>> processing, or other technical area.
>> • Experience with the following:
>> • GUI frameworks such as NetBeans or Eclipse
>> • wxPython, Qt
>> • Low-level 2-D graphics APIs such as Quartz or GDI+
>> • 3-D graphics, preferably using VTK
>> • Developing or working with plotting APIs
>> • Experience using (and interest in contributing to) SciPy
>> • numeric algorithms
>> Enthought offers competitive salaries and the opportunity to work on varied
>> and interesting technical projects. We are located in Austin, TX,
>> consistently rated as one of the best places to live in the US.  Benefits
>> include health, dental, vision and a 401k plan.
>>
>> If you are interested in applying, submit a resume to j...@enthought.com.
>> Code samples and links to previous work are encouraged but not required.
>>
>>
>>
>>
>>
>> ___
>> 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] draft release guide

[Francesc Alted]

A Thursday 25 March 2010 02:00:36 David Cournapeau escrigué:
> Hosted compiler refers to the platform the compiler itself runs on (so
> here I mean a native 64 bits compiler, instead of a 32 bits compiler
> which targets 64 bits). It is nice that mingw-w64 gives a 64 bits
> hosted, that's recent.

Yeah, but unfortunately it is not enough for numpy to work.  After creating 
the binary package (thanks for the "build -c mingw32 bdist_wininst" trick), 
and installing nose, I get a big crash when running the test units.  When 
trying to use gdb to see the backtrace, I got:

C:\Users\francesc\Desktop\NumPy>gdb python
GNU gdb (GDB) 7.1.50.20100318-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
...
Reading symbols from \Python26_64/python.exe...(no debugging symbols 
found)...done.
(gdb) r
Starting program: \Python26_64/python.exe
[New Thread 2880.0x410]
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] 
on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
C:\Python26_64\lib\site-packages\numpy\core\__init__.py:5: Warning: Numpy 
built
with MINGW-W64 on Windows 64 bits is experimental, and only available for
testing. You are advised not to use it for production.

CRASHES ARE TO BE EXPECTED - PLEASE REPORT THEM TO NUMPY DEVELOPERS
  import multiarray
>>> numpy.test()
Running unit tests for numpy
NumPy version 1.4.0
NumPy is installed in C:\Python26_64\lib\site-packages\numpy
Python version 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit 
(AMD
64)]
nose version 0.11.3
Forcing DISTUTILS_USE_SDK=1
.warning: HEAP[python.exe]:
warning: Invalid address specified to RtlFreeHeap( 0224, 
00C
25110 )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x76fa6061 in ntdll!DbgBreakPoint ()
   from C:\Windows\system32\ntdll.dll
(gdb) bt
#0  0x76fa6061 in ntdll!DbgBreakPoint ()
   from C:\Windows\system32\ntdll.dll
#1  0x76ffe17a in ntdll!EtwEventProviderEnabled ()
   from C:\Windows\system32\ntdll.dll
#2  0x022af0d8 in ?? ()
#3  0x5104095c in ?? ()
#4  0x00219a08 in ?? ()
#5  0x0e040001 in ?? ()
#6  0x0224 in ?? ()
#7  0x76fe27a1 in ntdll!MD4Final () from C:\Windows\system32\ntdll.dll
#8  0x76fb9630 in ntdll!LdrGetProcedureAddress ()
   from C:\Windows\system32\ntdll.dll
#9  0x76fb9500 in ntdll!LdrGetProcedureAddress ()
   from C:\Windows\system32\ntdll.dll
#10 0x0224 in ?? ()
#11 0x00c25110 in ?? ()
#12 0x0224 in ?? ()
#13 0x0623f197 in ?? ()
#14 0x0224 in ?? ()
#15 0x770151a9 in ntdll!RtlTraceDatabaseCreate ()
   from C:\Windows\system32\ntdll.dll
#16 0x in ?? ()
(gdb)

So, it is still exactly as you said: it seems like gdb cannot introspect MS 
debug symbols.  Unfortunately I don't think solving this would be easy at all 
:-/  Perhaps reporting this to mingw-w64 would help...

> > With it, and with some fixes in numpy sources (very few), I achieved to
> > pass the build phase.  I can provide the patch in case someone is
> > interested.
> 
> Building should work out of the box, actually - what are the issues ?

I'm attaching the patch.  Caveat emptor: the patch is *very* crude, and it is 
just meant to allow a clean compile with mingw-w64.  A more elaborated patch 
should be implemented in case we want it to go into numpy.

> But the main problem is not to build numpy (the 1.3.0 64 bits msi was
> built with mingw-w64 already) - it is to find out what causes the
> various crashes people encountered. Some were due to bugs in mingw which
> have been fixed since then.

Exactly.  OK, I think I'm done with this try for the moment.  It is a pity 
because mingw-w64 does an excellent job with my preliminary tests with Blosc 
compressor (it achieves 4x better performance than mingw-w32 and 2x better 
than MSVC 2008 32-bit).  But before going MSVC 64-bit route, I'd like to test 
Intel compiler 64-bit.  Anyone knows if it can cope with numpy?  A quick look 
at setup.py seems to say that only 32-bit Intel compiler is supported.

Thanks,

-- 
Francesc Alted
Index: numpy/core/setup_common.py
===
--- numpy/core/setup_common.py	(revision 8300)
+++ numpy/core/setup_common.py	(working copy)
@@ -243,5 +243,9 @@
 if saw is not None:
 raise ValueError("Unrecognized format (%s)" % saw)
 else:
+# XXX The case for mingw64 falls here, but as a 64-bit platform
+# I'd say the result should be 'INTE

Re: [Numpy-discussion] draft release guide

[David Cournapeau]

Francesc Alted wrote:

> 
> C:\Users\francesc\Desktop\NumPy>gdb python
> GNU gdb (GDB) 7.1.50.20100318-cvs
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from \Python26_64/python.exe...(no debugging symbols 
> found)...done.
> (gdb) r
> Starting program: \Python26_64/python.exe
> [New Thread 2880.0x410]
> Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] 
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
 import numpy
> C:\Python26_64\lib\site-packages\numpy\core\__init__.py:5: Warning: Numpy 
> built
> with MINGW-W64 on Windows 64 bits is experimental, and only available for
> testing. You are advised not to use it for production.
> 
> CRASHES ARE TO BE EXPECTED - PLEASE REPORT THEM TO NUMPY DEVELOPERS
>   import multiarray
 numpy.test()
> Running unit tests for numpy
> NumPy version 1.4.0
> NumPy is installed in C:\Python26_64\lib\site-packages\numpy
> Python version 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit 
> (AMD
> 64)]
> nose version 0.11.3
> Forcing DISTUTILS_USE_SDK=1
> .warning: HEAP[python.exe]:
> warning: Invalid address specified to RtlFreeHeap( 0224, 
> 00C
> 25110 )
> 
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x76fa6061 in ntdll!DbgBreakPoint ()
>from C:\Windows\system32\ntdll.dll
> (gdb) bt
> #0  0x76fa6061 in ntdll!DbgBreakPoint ()
>from C:\Windows\system32\ntdll.dll
> #1  0x76ffe17a in ntdll!EtwEventProviderEnabled ()
>from C:\Windows\system32\ntdll.dll
> #2  0x022af0d8 in ?? ()
> #3  0x5104095c in ?? ()
> #4  0x00219a08 in ?? ()
> #5  0x0e040001 in ?? ()
> #6  0x0224 in ?? ()
> #7  0x76fe27a1 in ntdll!MD4Final () from C:\Windows\system32\ntdll.dll
> #8  0x76fb9630 in ntdll!LdrGetProcedureAddress ()
>from C:\Windows\system32\ntdll.dll
> #9  0x76fb9500 in ntdll!LdrGetProcedureAddress ()
>from C:\Windows\system32\ntdll.dll
> #10 0x0224 in ?? ()
> #11 0x00c25110 in ?? ()
> #12 0x0224 in ?? ()
> #13 0x0623f197 in ?? ()
> #14 0x0224 in ?? ()
> #15 0x770151a9 in ntdll!RtlTraceDatabaseCreate ()
>from C:\Windows\system32\ntdll.dll
> #16 0x in ?? ()
> (gdb)

Believe it or not, but this is already much better than what I had last 
time I looked at it (the stack was corrupted after two items, and gdb 
often crashed). I had to build custom mingw runtimes to get there last 
year :)

> 
> So, it is still exactly as you said: it seems like gdb cannot introspect MS 
> debug symbols.

And for completeness, the MS tools of course cannot read the mingw 
debugging symbols, but the contrary would have been surprising. It does 
not help that debugging things inside the MS C runtime is a nightmare 
(because you have to rebuild everything, including python). I wonder if 
MS makes the sources of their runtime available under some license to 
look more into it.

I also thought about using valgrind, but then there are some issues 
running wine in 64 bits mode under valgrind (maybe solved since then: 
https://bugs.kde.org/show_bug.cgi?id=197259).

> 
> Exactly.  OK, I think I'm done with this try for the moment.  It is a pity 
> because mingw-w64 does an excellent job with my preliminary tests with Blosc 
> compressor (it achieves 4x better performance than mingw-w32 and 2x better 
> than MSVC 2008 32-bit).  But before going MSVC 64-bit route, I'd like to test 
> Intel compiler 64-bit.  Anyone knows if it can cope with numpy?

What works well is MS compiler + Intel Fortran compiler (at least with 
numscons). Surprisingly, when I tried using the Intel C compiler + Intel 
Fortran compiler, I also had a lot of issues, not unlike the ones with 
mingw. What I am afraid is that the C runtimes issues are unsolvable on 
win64 because of python, and that we have to use the MS compiler (for C 
and C++).

cheers,

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

Re: [Numpy-discussion] draft release guide

[Francesc Alted]

A Thursday 25 March 2010 10:53:34 David Cournapeau escrigué:
> Believe it or not, but this is already much better than what I had last
> time I looked at it (the stack was corrupted after two items, and gdb
> often crashed). I had to build custom mingw runtimes to get there last
> year :)

Well, I've reported the problem just in case:

https://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3638920

> What works well is MS compiler + Intel Fortran compiler (at least with
> numscons). Surprisingly, when I tried using the Intel C compiler + Intel
> Fortran compiler, I also had a lot of issues, not unlike the ones with
> mingw. What I am afraid is that the C runtimes issues are unsolvable on
> win64 because of python, and that we have to use the MS compiler (for C
> and C++).

Ok.  So it seems the MS compiler venue for 64-bit is unavoidable (at this 
moment, at least).  One question though: is a fortran compiler really 
necessary for compiling just numpy?  If so, why?

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

Re: [Numpy-discussion] draft release guide

[David Cournapeau]

On Thu, Mar 25, 2010 at 9:33 PM, Francesc Alted  wrote:

>
> Ok.  So it seems the MS compiler venue for 64-bit is unavoidable (at this
> moment, at least).  One question though: is a fortran compiler really
> necessary for compiling just numpy?

No, but I personally have little interest in numpy without scipy. You
can build numpy with MS compilers on 64 bits since 1.3.0, this is
entirely supported.

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

[Numpy-discussion] partial autocorrelation function

[Mark Bakker]

Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?

Thanks,

Mark

ps. I know, not too difficult, but if it is around I'd be happy to use it.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] partial autocorrelation function

[josef . pktd]

On Thu, Mar 25, 2010 at 11:10 AM, Mark Bakker  wrote:
> Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?
>
> Thanks,
>
> Mark
>
> ps. I know, not too difficult, but if it is around I'd be happy to use it.
>
> ___
> 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] partial autocorrelation function

[Skipper Seabold]

On Thu, Mar 25, 2010 at 11:10 AM, Mark Bakker  wrote:
> Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?
>
> Thanks,
>
> Mark
>
> ps. I know, not too difficult, but if it is around I'd be happy to use it.
>

I'm sure there's another version somewhere, but I couldn't find one
and wrote pacorr

http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tsa/stattools.py#L92

It relies on statsmodels, but could easily be made to work without it.
 You can roll your own OLS,  add_constant just adds a column of ones,
and you can see lagmat here:

http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tools/tools_tsa.py

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

Re: [Numpy-discussion] partial autocorrelation function

[josef . pktd]

On Thu, Mar 25, 2010 at 11:14 AM,   wrote:
> On Thu, Mar 25, 2010 at 11:10 AM, Mark Bakker  wrote:
>> Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?
>>
>> Thanks,
>>
>> Mark
>>
>> ps. I know, not too difficult, but if it is around I'd be happy to use it.

We have partial autocorrelation in scikits.statsmodels, based on ols
or on yule walker.

I think it's possible to get them more efficiently with
Levinson-Durbin recursion e.g. in scikits.talkbox, but I haven't
figured out yet how to recover it.

(I hit the wrong button in the previous message)
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

Re: [Numpy-discussion] partial autocorrelation function

[josef . pktd]

On Thu, Mar 25, 2010 at 11:20 AM, Skipper Seabold  wrote:
> On Thu, Mar 25, 2010 at 11:10 AM, Mark Bakker  wrote:
>> Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?
>>
>> Thanks,
>>
>> Mark
>>
>> ps. I know, not too difficult, but if it is around I'd be happy to use it.
>>
>
> I'm sure there's another version somewhere, but I couldn't find one
> and wrote pacorr
>
> http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tsa/stattools.py#L92
>
> It relies on statsmodels, but could easily be made to work without it.
>  You can roll your own OLS,  add_constant just adds a column of ones,
> and you can see lagmat here:
>
> http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tools/tools_tsa.py

My versions are in the last release

scikits.statsmodels.sandbox.tsa.pacf_ols
scikits.statsmodels.sandbox.tsa.pacf_yw

difference in the third (I think) decimal compared to matlab, where I
didn't find out the reason

Josef

>
> Skipper
> ___
> 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] partial autocorrelation function

[Skipper Seabold]

On Thu, Mar 25, 2010 at 11:25 AM,   wrote:
> On Thu, Mar 25, 2010 at 11:20 AM, Skipper Seabold  wrote:
>> On Thu, Mar 25, 2010 at 11:10 AM, Mark Bakker  wrote:
>>> Anybody know of a partial autocorrelation function in numpy? Maybe in scipy?
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>> ps. I know, not too difficult, but if it is around I'd be happy to use it.
>>>
>>
>> I'm sure there's another version somewhere, but I couldn't find one
>> and wrote pacorr
>>
>> http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tsa/stattools.py#L92
>>
>> It relies on statsmodels, but could easily be made to work without it.
>>  You can roll your own OLS,  add_constant just adds a column of ones,
>> and you can see lagmat here:
>>
>> http://bazaar.launchpad.net/~jsseabold/statsmodels/statsmodels-skipper/annotate/head%3A/scikits/statsmodels/sandbox/tools/tools_tsa.py
>
> My versions are in the last release
>
> scikits.statsmodels.sandbox.tsa.pacf_ols
> scikits.statsmodels.sandbox.tsa.pacf_yw
>
> difference in the third (I think) decimal compared to matlab, where I
> didn't find out the reason
>
> Josef
>

Ah, there they are.  To be clear, use these then, as I'll be removing the other.

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

[Numpy-discussion] should ndarray implement __round__ for py3k?

[Darren Dale]

A simple test in python 3:

>>> import numpy as np
>>> round(np.arange(10))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: type numpy.ndarray doesn't define __round__ method

Here is some additional context: http://bugs.python.org/issue7261

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

Re: [Numpy-discussion] should ndarray implement __round__ for py3k?

[Robert Kern]

On Thu, Mar 25, 2010 at 15:01, Darren Dale  wrote:
> A simple test in python 3:
>
 import numpy as np
 round(np.arange(10))
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: type numpy.ndarray doesn't define __round__ method
>
> Here is some additional context: http://bugs.python.org/issue7261

I'd put that in the "would be nice, but not a priority" category.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] should ndarray implement __round__ for py3k?

[Pauli Virtanen]

Darren Dale wrote:
> A simple test in python 3:
>
> > > > import numpy as np
> > > > round(np.arange(10))
> Traceback (most recent call last):
>    File "", line 1, in 
> TypeError: type numpy.ndarray doesn't define __round__ method

I implemented this for array scalars already, but forgot about arrays. Anyway, 
it could be nice to have.

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

Re: [Numpy-discussion] should ndarray implement __round__ for py3k?

[Charles R Harris]

On Thu, Mar 25, 2010 at 2:58 PM, Pauli Virtanen  wrote:

> Darren Dale wrote:
> > A simple test in python 3:
> >
> > > > > import numpy as np
> > > > > round(np.arange(10))
> > Traceback (most recent call last):
> >File "", line 1, in 
> > TypeError: type numpy.ndarray doesn't define __round__ method
>
> I implemented this for array scalars already, but forgot about arrays.
> Anyway, it could be nice to have.
>
>
I like the fact that python >= 3.1 returns integers when rounding floats.

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

[Numpy-discussion] f2py: "could not crack entity declaration"

[David Warde-Farley]

I decided to give wrapping this code a try:

http://morrislab.med.utoronto.ca/~dwf/GLMnet.f90

I'm afraid my Fortran skills are fairly limited, but I do know that  
gfortran compiles it fine. f2py run on this file produces lots of  
errors of the form,

Reading fortran codes...
Reading file 'GLMnet.f90' (format:fix)
Line #263 in GLMnet.f90:"  real  
x(no,ni),y(no),w(no),vp(ni),ca(nx,nlam)  353"
updatevars: could not crack entity declaration "ca(nx,nlam)353".  
Ignoring.
Line #264 in GLMnet.f90:"  real  
ulam(nlam),a0(nlam),rsq(nlam),alm(nlam)  354"
updatevars: could not crack entity declaration "alm(nlam)354".  
Ignoring.
Line #265 in GLMnet.f90:"  integer  
jd(*),ia(nx),nin(nlam)355"
updatevars: could not crack entity declaration "nin(nlam)355".  
Ignoring.
Line #289 in GLMnet.f90:"  real  
x(no,ni),y(no),w(no),vp(ni),ulam(nlam)   378"
updatevars: could not crack entity declaration "ulam(nlam)378".  
Ignoring.
Line #290 in GLMnet.f90:"  real  
ca(nx,nlam),a0(nlam),rsq(nlam),alm(nlam) 379"
updatevars: could not crack entity declaration "alm(nlam)379".  
Ignoring.
Line #291 in GLMnet.f90:"  integer  
jd(*),ia(nx),nin(nlam)380"
updatevars: could not crack entity declaration "nin(nlam)380".  
Ignoring.
Line #306 in GLMnet.f90:"  call  
chkvars(no,ni,x,ju)  392"
analyzeline: No name/args pattern found for li

Is it the numbers that it is objecting to (I'm assuming these are some  
sort of punchcard thing)? Do I need to modify the code in some way to  
make it f2py-friendly?

Thanks,

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

Re: [Numpy-discussion] f2py: "could not crack entity declaration"

[Pearu Peterson]

Try renaming GLMnet.f90 to GLMnet.f.
HTH,
Pearu

David Warde-Farley wrote:
> I decided to give wrapping this code a try:
> 
>   http://morrislab.med.utoronto.ca/~dwf/GLMnet.f90
> 
> I'm afraid my Fortran skills are fairly limited, but I do know that  
> gfortran compiles it fine. f2py run on this file produces lots of  
> errors of the form,
> 
> Reading fortran codes...
>   Reading file 'GLMnet.f90' (format:fix)
> Line #263 in GLMnet.f90:"  real  
> x(no,ni),y(no),w(no),vp(ni),ca(nx,nlam)  353"
>   updatevars: could not crack entity declaration "ca(nx,nlam)353".  
> Ignoring.
> Line #264 in GLMnet.f90:"  real  
> ulam(nlam),a0(nlam),rsq(nlam),alm(nlam)  354"
>   updatevars: could not crack entity declaration "alm(nlam)354".  
> Ignoring.
> Line #265 in GLMnet.f90:"  integer  
> jd(*),ia(nx),nin(nlam)355"
>   updatevars: could not crack entity declaration "nin(nlam)355".  
> Ignoring.
> Line #289 in GLMnet.f90:"  real  
> x(no,ni),y(no),w(no),vp(ni),ulam(nlam)   378"
>   updatevars: could not crack entity declaration "ulam(nlam)378".  
> Ignoring.
> Line #290 in GLMnet.f90:"  real  
> ca(nx,nlam),a0(nlam),rsq(nlam),alm(nlam) 379"
>   updatevars: could not crack entity declaration "alm(nlam)379".  
> Ignoring.
> Line #291 in GLMnet.f90:"  integer  
> jd(*),ia(nx),nin(nlam)380"
>   updatevars: could not crack entity declaration "nin(nlam)380".  
> Ignoring.
> Line #306 in GLMnet.f90:"  call  
> chkvars(no,ni,x,ju)  392"
>   analyzeline: No name/args pattern found for li
> 
> Is it the numbers that it is objecting to (I'm assuming these are some  
> sort of punchcard thing)? Do I need to modify the code in some way to  
> make it f2py-friendly?
> 
> Thanks,
> 
> David
> ___
> 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] numpy.array(arr.flat) mutates arr if arr.flags.fortran: bug?

[Travis Oliphant]

On Mar 24, 2010, at 2:13 PM, Zachary Pincus wrote:

> Hello,
>
> I assume it is a bug that calling numpy.array() on a flatiter of a
> fortran-strided array that owns its own data causes that array to be
> rearranged somehow?
>
> Not sure what happens with a fancier-strided array that also owns its
> own data (because I'm not sure how to create one of those in python).
>
> This is from the latest svn version (2.0.0.dev8302) but was also
> present in a previous version too.

Hmm..   Yeah, this doesn't seem right.

I'm not really sure what

array(a.flat) should return since a.flat is an iterator...

but what it's doing is not right.

-Travis


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