[Numpy-discussion] Are the CPP symbols HAVE_LONGDOUBLE_FUNCS and HAVE_FLOAT_FUNCS public ?
Hi, Those two symbols are mentioned in the numpy C-API book, but with my work on cleaning the math configuration, those are not needed by numpy anymore (I grep into numpy and scipy sources, and they are only used in umathmodule.c.src, where they are obsoleted by my clean-up). Can I remove them, or should I keep them for backward compatibility ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Are the CPP symbols HAVE_LONGDOUBLE_FUNCS and HAVE_FLOAT_FUNCS public ?
Fri, 05 Sep 2008 15:27:56 +0900, David Cournapeau wrote: Those two symbols are mentioned in the numpy C-API book, but with my work on cleaning the math configuration, those are not needed by numpy anymore (I grep into numpy and scipy sources, and they are only used in umathmodule.c.src, where they are obsoleted by my clean-up). Can I remove them, or should I keep them for backward compatibility ? If you remove them, please put a reminder somewhere (eg ticket) to update the documentation accordingly. Pauli ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
The error you are seeing may indicate that it is not possible to build python 2.5 extensions with VS 2008 with distutils (the message says distutils did not detect VS 2008 installation, and that may well be caused by distutils not knowing how to deal with VS 2008). You may be right, I remember that VS2003 is hardcoded in some places in distutils. I think I ran into this issue some months ago as well. Matthieu -- French PhD student Information System Engineer Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
Matthieu Brucher wrote: You may be right, I remember that VS2003 is hardcoded in some places in distutils. I think I ran into this issue some months ago as well. Mmmh, wonder if I could get around that in numscons :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
A Friday 05 September 2008, David Cournapeau escrigué: Matthieu Brucher wrote: You may be right, I remember that VS2003 is hardcoded in some places in distutils. I think I ran into this issue some months ago as well. Mmmh, wonder if I could get around that in numscons :) IIRC, Python 2.4 and 2.5 only supports the VS2003 of the MS series of compilers. With Python 2.6 and 3.0 I think that VS2008 will be the one supported. Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
Francesc Alted wrote: IIRC, Python 2.4 and 2.5 only supports the VS2003 of the MS series of compilers. With Python 2.6 and 3.0 I think that VS2008 will be the one supported. Yes, but that's just stupid when you think about it. I mean, the python code to deal with VS 2008 is there, so if you built your python with VS 2008, everything to build extensions with VS 2008 is there (mismatched VS is another story). The code in numscons to detect and setting up VS 2008 (and 2005) is an improved version of the code in python 2.6 distutils, so if there is a way to prevent distutils from barfing during the configuration, it should be doable, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
On 9/5/08, David Cournapeau [EMAIL PROTECTED] wrote: First, you are trying to build with numpy 1.0.2, which is really old. Update to a more recent version. Yes, 1.0.2 is the version we are using on Linux so I went with that one. I will try newer version. The error you are seeing may indicate that it is not possible to build python 2.5 extensions with VS 2008 with distutils (the message says distutils did not detect VS 2008 installation, and that may well be caused by distutils not knowing how to deal with VS 2008). The same error was when I was building PIL library, so I had to apply small patch to msvccompiler.py file in Python's distutils and export DISTUTILS_USE_SDK and MSSDK env variables to override builtin settings which were always looking for VS 2003 compiler, then the build process went without a problem. I followed the instructions described here http://jeethurao.com/blog/?p=35. How did you build python with VS 2008 ? With VS 2008. I opened Python-2.5.1\PCbuild8\pcbuild.sln file with Visual Studio, included project files for tkinter, ssl, bddsb, etc... and everything was built without problems. I have the full Python 2.5.1 distribution build, identical as the Python-2.5.1.msi installation from python.org. P.S: Not to discourage you, but it will certainly be painful to build numpy with VS 2008 and python 2.5, because 2.5 distutils does not really handle VS 2008, and we use distutils for the build, and also because AFAIK, numpy has never been built with VS 2008 yet (2.6 will support VS 2008, so that's something which will be fixed sooner rather than later, assuming numpy C code cannot be compiler with VS 2008 now). Thanks for the info. It would certanly be bad news for me if numpy really can't be build with VS 2008. I will try with numpy 1.1.1 and see what happens. -- Best regards, Miroslav ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Getting a numpy array from a ctype pointer
x = np.frombuffer(int_asbuffer(C.addressof(x.contents), n*8)) I'll go with your faster solution. Very good. Thank you very much. Paulo ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
Miroslav Sabljic wrote: The build log is in attachment. Now I just have to see about this error message I'm getting, don't know how to compile Fortran code on platform 'nt'. This is not an error per se: fortran compiler is not mandatory. You will not get all the features of numpy, but you will get a working numpy without a fortran compiler. Looking at your build.log, it looks like it built successfully, no ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
On 9/5/08, David Cournapeau [EMAIL PROTECTED] wrote: This is not an error per se: fortran compiler is not mandatory. You will not get all the features of numpy, but you will get a working numpy without a fortran compiler. Looking at your build.log, it looks like it built successfully, no ? Yes it looks so, but as this is first time I'm building numpy I wasn't sure. I will now experiment further and try to build it with MKL. Tnx for your help, I really appreciate it! -- Best regards, Miroslav ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy build on windows
Miroslav Sabljic wrote: Yes it looks so, but as this is first time I'm building numpy I wasn't sure. I will now experiment further and try to build it with MKL. Tnx for your help, I really appreciate it! You should first test the binary (import numpy; numpy.test()), to see whether the built was really sucessful. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] sum of positive values in an array
Hi, probably a basic question, but I'm looking for a neat way to sum all the positive values in an array of floats. I'm currently doing it the hard way, but am hoping there is some cunning and elegant syntax I can use instead ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] argsort in descending order
another newb question I suspect, but is there a way to instruct argsort to sort in descending order or should I just sort and reverse? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] BUG in numpy.loadtxt?
Hi Ryan, I applied your patch in r5788 on the trunk. I noticed there was another bug occurring when both converters and usecols are provided. I've added regression tests for both bugs. Could you confirm that everything is fine on your side ? Thanks, On Thu, Sep 4, 2008 at 4:47 PM, Ryan May [EMAIL PROTECTED] wrote: Travis E. Oliphant wrote: Ryan May wrote: Stefan (or anyone else who can comment), It appears that the usecols argument to loadtxt no longer accepts numpy arrays: Could you enter a ticket so we don't lose track of this. I don't remember anything being intentional. Done: #905 http://scipy.org/scipy/numpy/ticket/905 I've attached a patch that does the obvious and coerces usecols to a list when it's not None, so it will work for any iterable. I don't think it was a conscious decision, just a consequence of the rewrite using different methods. There are two problems: 1) It's an API break, technically speaking 2) It currently doesn't even accept tuples, which are used in the docstring. Can we hurry and get this into 1.2? Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
Hi, probably a basic question, but I'm looking for a neat way to sum all the positive values in an array of floats. I'm currently doing it the hard way, but am hoping there is some cunning and elegant syntax I can use instead Fancy indexing's my favorite cunning and elegant syntax: a = numpy.random.randn(100) a.sum() a 0 # gives a boolean array that's True where the elements of a are 0. a[a 0] # retrieve from a only the elements with True in the boolean array. a[a 0].sum() # your desired result. Note that you can also fancy-index with a list/array of indices, as well as a boolean mask array: a[[1, 40, 55]] # pulls just the values at index 1, 40, and 55 out of a into a shape (3,) array. Zach ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
What are the relative merits of sum(a[where(a0]) to a[a 0].sum() ? Second one is more OO, takes a few keystrokes less to type. Is there any real difference if it came to very large arrays? Or is it 'just' a style question? Ludwig 2008/9/5 Zachary Pincus [EMAIL PROTECTED] Hi, probably a basic question, but I'm looking for a neat way to sum all the positive values in an array of floats. I'm currently doing it the hard way, but am hoping there is some cunning and elegant syntax I can use instead Fancy indexing's my favorite cunning and elegant syntax: a = numpy.random.randn(100) a.sum() a 0 # gives a boolean array that's True where the elements of a are 0. a[a 0] # retrieve from a only the elements with True in the boolean array. a[a 0].sum() # your desired result. Note that you can also fancy-index with a list/array of indices, as well as a boolean mask array: a[[1, 40, 55]] # pulls just the values at index 1, 40, and 55 out of a into a shape (3,) array. Zach ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
Ludwig wrote: What are the relative merits of sum(a[where(a0]) to a[a 0].sum() ? Second one is more OO, takes a few keystrokes less to type. Is there any real difference if it came to very large arrays? Or is it 'just' a style question? In this case, it is style: sum(a) really calls a.sum() internally; in the second case, you are sure to call numpy sum, and not python sum, which is a common mistake of people new to numpy. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
On Fri, Sep 5, 2008 at 7:32 AM, David Cournapeau [EMAIL PROTECTED] wrote: Ludwig wrote: What are the relative merits of sum(a[where(a0]) to a[a 0].sum() ? Second one is more OO, takes a few keystrokes less to type. Is there any real difference if it came to very large arrays? Or is it 'just' a style question? In this case, it is style: sum(a) really calls a.sum() internally; in the second case, you are sure to call numpy sum, and not python sum, which is a common mistake of people new to numpy. Here's another difference: a = np.random.randn(10) timeit np.sum(a[np.where(a0)]) 100 loops, best of 3: 3.44 ms per loop timeit a[a 0].sum() 100 loops, best of 3: 2.21 ms per loop ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
On Fri, Sep 5, 2008 at 11:52 PM, Keith Goodman [EMAIL PROTECTED] wrote: Here's another difference: a = np.random.randn(10) timeit np.sum(a[np.where(a0)]) 100 loops, best of 3: 3.44 ms per loop timeit a[a 0].sum() 100 loops, best of 3: 2.21 ms per loop But you're not comparing the same thing: why calling where in one case and not in the other ? The difference is in the where call, not in the a.sum() vs sum(a) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] sum of positive values in an array
On Fri, Sep 5, 2008 at 9:08 AM, David Cournapeau [EMAIL PROTECTED] wrote: On Fri, Sep 5, 2008 at 11:52 PM, Keith Goodman [EMAIL PROTECTED] wrote: Here's another difference: a = np.random.randn(10) timeit np.sum(a[np.where(a0)]) 100 loops, best of 3: 3.44 ms per loop timeit a[a 0].sum() 100 loops, best of 3: 2.21 ms per loop But you're not comparing the same thing: why calling where in one case and not in the other ? The difference is in the where call, not in the a.sum() vs sum(a) I was comparing the two techniques from this question: Ludwig wrote: What are the relative merits of sum(a[where(a0]) to a[a 0].sum() ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] BUG in numpy.loadtxt?
David Huard wrote: Hi Ryan, I applied your patch in r5788 on the trunk. I noticed there was another bug occurring when both converters and usecols are provided. I've added regression tests for both bugs. Could you confirm that everything is fine on your side ? I can confirm that it works fine for me. Can you or someone else backport this to the 1.2 branch so that this bug is fixed in the next release? Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] argsort in descending order
On Fri, Sep 5, 2008 at 8:02 AM, SimonPalmer [EMAIL PROTECTED] wrote: another newb question I suspect, but is there a way to instruct argsort to sort in descending order or should I just sort and reverse? You'll just have to reverse the indices. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] BUG in numpy.loadtxt?
Done in r5790. On Fri, Sep 5, 2008 at 12:36 PM, Ryan May [EMAIL PROTECTED] wrote: David Huard wrote: Hi Ryan, I applied your patch in r5788 on the trunk. I noticed there was another bug occurring when both converters and usecols are provided. I've added regression tests for both bugs. Could you confirm that everything is fine on your side ? I can confirm that it works fine for me. Can you or someone else backport this to the 1.2 branch so that this bug is fixed in the next release? Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] BUG in numpy.loadtxt?
Thanks a bunch for getting these done. David Huard wrote: Done in r5790. On Fri, Sep 5, 2008 at 12:36 PM, Ryan May [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: David Huard wrote: Hi Ryan, I applied your patch in r5788 on the trunk. I noticed there was another bug occurring when both converters and usecols are provided. I've added regression tests for both bugs. Could you confirm that everything is fine on your side ? I can confirm that it works fine for me. Can you or someone else backport this to the 1.2 branch so that this bug is fixed in the next release? Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org mailto:Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] isnan and co: cleaning up
On Thu, Sep 4, 2008 at 11:06 PM, David Cournapeau
[EMAIL PROTECTED] wrote:
Hi,
While working on my branch to clean the math configuration, I
noticed that the code for isnan and co became quite convoluted. autoconf
info file has a mention of it, and suggests the following for
portability (section 5.5.1 of autoconf):
The C99 standard says that `isinf' and `isnan' are macros. On
some systems just macros are available (e.g., HP-UX and Solaris
10), on some systems both macros and functions (e.g., glibc
2.3.2), and on some systems only functions (e.g., IRIX 6 and
Solaris 9). In some cases these functions are declared in
nonstandard headers like `sunmath.h' and defined in non-default
libraries like `-lm' or `-lsunmath'.
The C99 `isinf' and `isnan' macros work correctly with `long
double' arguments, but pre-C99 systems that use functions
typically assume `double' arguments. On such a system, `isinf'
incorrectly returns true for a finite `long double' argument that
is outside the range of `double'.
To work around this porting mess, you can use code like the
following.
#include math.h
#ifndef isnan
# define isnan(x) \
(sizeof (x) == sizeof (long double) ? isnan_ld (x) \
: sizeof (x) == sizeof (double) ? isnan_d (x) \
: isnan_f (x))
static inline int isnan_f (float x) { return x != x; }
static inline int isnan_d (double x) { return x != x; }
static inline int isnan_ld (long double x) { return x != x; }
#endif
#ifndef isinf
# define isinf(x) \
(sizeof (x) == sizeof (long double) ? isinf_ld (x) \
: sizeof (x) == sizeof (double) ? isinf_d (x) \
: isinf_f (x))
static inline int isinf_f (float x) { return isnan (x -
x); }
static inline int isinf_d (double x) { return isnan (x -
x); }
static inline int isinf_ld (long double x) { return isnan (x -
x); }
#endif
Use `AC_C_INLINE' (*note C Compiler::) so that this code works on
compilers that lack the `inline' keyword. Some optimizing
compilers mishandle these definitions, but systems with that bug
typically have missing or broken `isnan' functions anyway, so it's
probably not worth worrying about.
This is simpler than the current code (I actually understand what the
above case does; the current code in numpy has many cases which I do not
understand), does not need any C code (_isnan and co), and probably more
portable since autoconf has a lot of experience there. Is the code in
_isnan really better than just relying on the nan property x != x ? (Do
we support platforms without a IEE754 FPU ?)
Does anyone has any thought on replacing the current code by the above
(modulo the inline part, which we can drop for now) ?
+1, but (putting on pedant hat) I think the functions should be formatted in
the way revealed to us by KR.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] isnan and co: cleaning up
On Sat, Sep 6, 2008 at 8:38 AM, Charles R Harris [EMAIL PROTECTED] wrote: +1, but (putting on pedant hat) I think the functions should be formatted in the way revealed to us by KR. By KR, you mean the KR style, right , not the KR function declaration style ? :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Are the CPP symbols HAVE_LONGDOUBLE_FUNCS and HAVE_FLOAT_FUNCS public ?
On Fri, Sep 5, 2008 at 4:50 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: If you remove them, please put a reminder somewhere (eg ticket) to update the documentation accordingly. Is there a reason for not updating the documentation in the patch (well, branch) itself ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] isnan and co: cleaning up
On Fri, Sep 5, 2008 at 9:15 PM, David Cournapeau [EMAIL PROTECTED] wrote:
On Sat, Sep 6, 2008 at 8:38 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
+1, but (putting on pedant hat) I think the functions should be formatted
in
the way revealed to us by KR.
By KR, you mean the KR style, right , not the KR function
declaration style ? :)
This one http://en.wikipedia.org/wiki/Indent_style#K.26R_style
int main(int argc, char *argv[])
{
...
while (x == y) {
something();
somethingelse();
if (some_error)
do_correct();
else
continue_as_usual();
}
finalthing();
...
}
I'm a bit of a heretic myself, I always use braces in if statements,
even for one liners. It's just a bit easier on my eyes.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
