Menu
▾
▴
numpy-discussion
|
From: Tim L. <tim...@gm...> - 2006-06-30 02:26:35
|
On 6/30/06, Keith Goodman <kwg...@gm...> wrote: > On 6/29/06, Alan G Isaac <ai...@am...> wrote: > > A rather minor issue, but I would just like to make sure > > that a policy decision was made not to move to a float > > default for identity(), ones(), zeros(), and empty(). > > (I leave aside arange().) > > > > I see the argument for a change to be 3-fold: > > 1. It is easier to introduce people to numpy if > > default data types are all float. (I teach, > > and I want my students to use numpy.) > > 2. It is a better match to languages from which > > users are likely to migrate (e.g., GAUSS or > > Matlab). > > 3. In the uses I am most familiar with, float is > > the most frequently desired data type. (I guess > > this may be field specific, especially for empty().) > > I vote float. +1 float Tim > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > |
|
From: Bill B. <wb...@gm...> - 2006-06-30 02:40:21
|
I also find the int behavior of these functions strange. +1 float default (or double) --bb On 6/30/06, Tim Leslie <tim...@gm...> wrote: > > On 6/30/06, Keith Goodman <kwg...@gm...> wrote: > > On 6/29/06, Alan G Isaac <ai...@am...> wrote: > > > A rather minor issue, but I would just like to make sure > > > that a policy decision was made not to move to a float > > > default for identity(), ones(), zeros(), and empty(). > > > (I leave aside arange().) > > > > > > I see the argument for a change to be 3-fold: > > > 1. It is easier to introduce people to numpy if > > > default data types are all float. (I teach, > > > and I want my students to use numpy.) > > > 2. It is a better match to languages from which > > > users are likely to migrate (e.g., GAUSS or > > > Matlab). > > > 3. In the uses I am most familiar with, float is > > > the most frequently desired data type. (I guess > > > this may be field specific, especially for empty().) > > > > I vote float. > > +1 float > > Tim > > |
|
From: Keith G. <kwg...@gm...> - 2006-06-30 03:10:01
|
On 6/29/06, Bill Baxter <wb...@gm...> wrote: > I also find the int behavior of these functions strange. > > +1 float default (or double) Oh, wait. Which do I want, float or double? What does rand, eigh, lstsq, etc return? |
|
From: Bill B. <wb...@gm...> - 2006-06-30 04:03:23
|
Rand at least returns doubles: >>> num.rand(3,3).dtype.name 'float64' --bb On 6/30/06, Keith Goodman <kwg...@gm...> wrote: > > On 6/29/06, Bill Baxter <wb...@gm...> wrote: > > I also find the int behavior of these functions strange. > > > > +1 float default (or double) > > Oh, wait. Which do I want, float or double? What does rand, eigh, > lstsq, etc return? > |
|
From: Keith G. <kwg...@gm...> - 2006-06-30 04:22:48
|
On 6/29/06, Bill Baxter <wb...@gm...> wrote: > Rand at least returns doubles: > > >>> num.rand(3,3).dtype.name > 'float64' Then I vote float64. >> linalg.eigh(asmatrix(1))[0].dtype.name 'float64' >> linalg.cholesky(asmatrix(1)).dtype.name 'float64' |
|
From: Simon B. <si...@ar...> - 2006-06-30 13:49:02
|
On Fri, 30 Jun 2006 03:33:56 -0600 Travis Oliphant <oli...@ie...> wrote: > > One thing I've learned about Open Source development is that it can be > hard to figure out exactly what is bothering people and get good > critical feedback: people are more likely to just walk away with their > complaints than to try and verbalize and/or post them. So, looking at > adoption patterns can be a reasonable way to pick up on attitudes. General confusion in the community. The whole numeric->numarray->numpy story is a little strange for people to believe. Or at least the source for many jokes. Also, there is no mention of numpy on the numarray page. The whole thing smells a little fishy :) Mose of the (more casual) users of python for science that i talk to are quite confused about what is going on. It also "looks" like numpy is only a few months old. Personally, I am ready to evangelise numpy wherever i can. (eg. Europython in 4 days time:) ) Simon. |
|
From: Erin S. <eri...@gm...> - 2006-06-30 14:29:14
|
On 6/30/06, Simon Burton <si...@ar...> wrote: > > General confusion in the community. The whole numeric->numarray->numpy story > is a little strange for people to believe. Or at least the source for > many jokes. > Also, there is no mention of numpy on the numarray page. The whole > thing smells a little fishy :) I can say that coming to numpy early this year I was confused by this, and in fact I began by using numarray because the documentation was available and clearly written. I now support Travis on his book, since none of this would be happening so rapidly without him, but as I was looking for relief from my IDL license woes this turned me off a bit. >From Googling, It just wasn't clear which was the future, especially since as I dug deeper I saw old references to numpy that were not referring to the current project. I do think that this is more clear now, but the pages http://numeric.scipy.org/ -- Looks antiquated http://www.numpy.org/ -- is empty are not helping. numeric.scipy.org needs to be converted to the wiki look and feel of the rest of scipy.org, or at least made to look modern. numpy.org should point to the new page perhaps. And the numarray page should at least discuss the move to numpy and have links. Erin |
|
From: Erin S. <eri...@gm...> - 2006-06-30 14:33:44
|
On 6/30/06, Erin Sheldon <eri...@gm...> wrote: > http://www.numpy.org/ -- is empty I see this is now pointing to the sourceforge site. Must have been a glitch there earlier as it was returning an empty page. |
|
From: Joris De R. <jo...@st...> - 2006-06-30 15:21:30
|
On Friday 30 June 2006 16:29, Erin Sheldon wrote: [ES]: <snip> the pages [ES]: [ES]: http://numeric.scipy.org/ -- Looks antiquated [ES]: [ES]: are not helping. My opinion too. If that page is the first page you learn about NumPy, you won't have a good impression. Travis, would you accept concrete suggestions or 'help' to improve that page? Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm |
|
From: Travis N. V. <tr...@en...> - 2006-06-30 16:39:06
|
Joris De Ridder wrote: > On Friday 30 June 2006 16:29, Erin Sheldon wrote: > [ES]: <snip> the pages > [ES]: > [ES]: http://numeric.scipy.org/ -- Looks antiquated > [ES]: > [ES]: are not helping. > > My opinion too. If that page is the first page you learn about NumPy, > you won't have a good impression. > > Travis, would you accept concrete suggestions or 'help' to improve > that page? > > Cheers, > Joris > Speaking for the other Travis...I think he's open to suggestions (he hasn't yelled at me yet for suggesting the same sort of things). There was an earlier conversation on this list about the numpy page, in which we proposed redirecting all numeric/numpy links to numpy.scipy.org. I'll ask Jeff to do these redirects if: - everyone agrees that address is a good one - we have the content shaped up on that page. For now, I've copied the content with some basic cleanup (and adding a style sheet) here: http://numpy.scipy.org If anyone with a modicum of web design experience wants access to edit this site...please (please) speak up and it will be so. Other suggestions are welcome. Travis (Vaught) |
|
From: Darren D. <dd...@co...> - 2006-06-30 14:29:37
|
+1 for float64 |
|
From: Scott R. <sr...@nr...> - 2006-06-30 14:40:51
|
+1 for float64 for me as well. Scott On Fri, Jun 30, 2006 at 10:29:42AM -0400, Darren Dale wrote: > +1 for float64 > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sr...@nr... Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 |
|
From: Fernando P. <fpe...@gm...> - 2006-06-30 15:25:32
|
On 6/30/06, Scott Ransom <sr...@nr...> wrote: > +1 for float64 for me as well. +1 for float64 I have lots of code overriding the int defaults by hand which were giving me grief with hand-written extensions (which were written double-only for speed reasons). I'll be happy to clean this up. I completely understand Travis' concerns about backwards compatibility, but frankly, I think that right now the quality and community momentum of numpy is already enough that it will carry things forward. People will suffer a little during the porting days, but they'll be better off in the long run. I don't think we should undrestimate the value of eternal happiness :) Besides, decent unit tests will catch these problems. We all know that every scientific code in existence is unit tested to the smallest routine, so this shouldn't be a problem for anyone. Cheers, f |
|
From: Sasha <nd...@ma...> - 2006-06-30 16:35:39
|
On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > ... > Besides, decent unit tests will catch these problems. We all know > that every scientific code in existence is unit tested to the smallest > routine, so this shouldn't be a problem for anyone. Is this a joke? Did anyone ever measured the coverage of numpy unittests? I would be surprized if it was more than 10%. |
|
From: Travis N. V. <tr...@en...> - 2006-06-30 16:40:22
|
Sasha wrote: > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > >> ... >> Besides, decent unit tests will catch these problems. We all know >> that every scientific code in existence is unit tested to the smallest >> routine, so this shouldn't be a problem for anyone. >> > > Is this a joke? Did anyone ever measured the coverage of numpy > unittests? I would be surprized if it was more than 10%. > Very obviously a joke...uh...with the exception of enthought-written scientific code, of course ;-) |
|
From: Keith G. <kwg...@gm...> - 2006-06-30 16:43:57
|
On 6/30/06, Sasha <nd...@ma...> wrote: > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > > ... > > Besides, decent unit tests will catch these problems. We all know > > that every scientific code in existence is unit tested to the smallest > > routine, so this shouldn't be a problem for anyone. > > Is this a joke? Did anyone ever measured the coverage of numpy > unittests? I would be surprized if it was more than 10%. That's a conundrum. A joke is no longer a joke once you point out, yes it is a joke. |
|
From: Alan G I. <ai...@am...> - 2006-06-30 17:15:16
|
> On 6/30/06, Fernando Perez <fpe...@gm...> wrote: >> Besides, decent unit tests will catch these problems. We >> all know that every scientific code in existence is unit >> tested to the smallest routine, so this shouldn't be >> a problem for anyone. On Fri, 30 Jun 2006, Sasha apparently wrote: > Is this a joke? It had me chuckling. ;-) The dangers of email ... Cheers, Alan Isaac |
|
From: David M. C. <co...@ph...> - 2006-06-30 20:38:48
|
On Fri, 30 Jun 2006 12:35:35 -0400 Sasha <nd...@ma...> wrote: > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > > ... > > Besides, decent unit tests will catch these problems. We all know > > that every scientific code in existence is unit tested to the smallest > > routine, so this shouldn't be a problem for anyone. > > Is this a joke? Did anyone ever measured the coverage of numpy > unittests? I would be surprized if it was more than 10%. A very quick application of the coverage module, available at http://www.garethrees.org/2001/12/04/python-coverage/ gives me 41%: Name Stmts Exec Cover --------------------------------------------------- numpy 25 20 80% numpy._import_tools 235 175 74% numpy.add_newdocs 2 2 100% numpy.core 28 26 92% numpy.core.__svn_version__ 1 1 100% numpy.core._internal 99 48 48% numpy.core.arrayprint 251 92 36% numpy.core.defchararray 221 58 26% numpy.core.defmatrix 259 186 71% numpy.core.fromnumeric 319 153 47% numpy.core.info 3 3 100% numpy.core.ma 1612 1145 71% numpy.core.memmap 64 14 21% numpy.core.numeric 323 138 42% numpy.core.numerictypes 236 204 86% numpy.core.records 272 32 11% numpy.dft 6 4 66% numpy.dft.fftpack 128 31 24% numpy.dft.helper 35 32 91% numpy.dft.info 3 3 100% numpy.distutils 13 9 69% numpy.distutils.__version__ 4 4 100% numpy.distutils.ccompiler 296 49 16% numpy.distutils.exec_command 409 27 6% numpy.distutils.info 2 2 100% numpy.distutils.log 37 18 48% numpy.distutils.misc_util 945 174 18% numpy.distutils.unixccompiler 34 11 32% numpy.dual 41 27 65% numpy.f2py.info 2 2 100% numpy.lib 30 28 93% numpy.lib.arraysetops 121 59 48% numpy.lib.function_base 501 70 13% numpy.lib.getlimits 76 61 80% numpy.lib.index_tricks 223 56 25% numpy.lib.info 4 4 100% numpy.lib.machar 174 154 88% numpy.lib.polynomial 357 52 14% numpy.lib.scimath 51 19 37% numpy.lib.shape_base 220 24 10% numpy.lib.twodim_base 77 51 66% numpy.lib.type_check 110 75 68% numpy.lib.ufunclike 37 24 64% numpy.lib.utils 42 23 54% numpy.linalg 5 3 60% numpy.linalg.info 2 2 100% numpy.linalg.linalg 440 71 16% numpy.random 10 6 60% numpy.random.info 4 4 100% numpy.testing 3 3 100% numpy.testing.info 2 2 100% numpy.testing.numpytest 430 214 49% numpy.testing.utils 151 62 41% numpy.version 7 7 100% --------------------------------------------------- TOTAL 8982 3764 41% (I filtered out all the *.tests.* modules). Note that you have to import numpy after starting the coverage, because we use a lot of module-level code that wouldn't be caught otherwise. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Sasha <nd...@ma...> - 2006-06-30 20:49:56
|
As soon as I sent out my 10% estimate, I realized that someone will challenge it with a python level coverage statistics. My main concern is not what fraction of numpy functions is called by unit tests, but what fraction of special cases in the C code is exercised. I am not sure that David's statistics even answers the first question - I would guess it only counts statements in the pure python methods and ignores methods implemented in C. Can someone post C-level statistics from gcov <http://gcc.gnu.org/onlinedocs/gcc/Gcov.html> or a similar tool? On 6/30/06, David M. Cooke <co...@ph...> wrote: > On Fri, 30 Jun 2006 12:35:35 -0400 > Sasha <nd...@ma...> wrote: > > > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > > > ... > > > Besides, decent unit tests will catch these problems. We all know > > > that every scientific code in existence is unit tested to the smallest > > > routine, so this shouldn't be a problem for anyone. > > > > Is this a joke? Did anyone ever measured the coverage of numpy > > unittests? I would be surprized if it was more than 10%. > > A very quick application of the coverage module, available at > http://www.garethrees.org/2001/12/04/python-coverage/ > gives me 41%: > > Name Stmts Exec Cover > --------------------------------------------------- > numpy 25 20 80% > numpy._import_tools 235 175 74% > numpy.add_newdocs 2 2 100% > numpy.core 28 26 92% > numpy.core.__svn_version__ 1 1 100% > numpy.core._internal 99 48 48% > numpy.core.arrayprint 251 92 36% > numpy.core.defchararray 221 58 26% > numpy.core.defmatrix 259 186 71% > numpy.core.fromnumeric 319 153 47% > numpy.core.info 3 3 100% > numpy.core.ma 1612 1145 71% > numpy.core.memmap 64 14 21% > numpy.core.numeric 323 138 42% > numpy.core.numerictypes 236 204 86% > numpy.core.records 272 32 11% > numpy.dft 6 4 66% > numpy.dft.fftpack 128 31 24% > numpy.dft.helper 35 32 91% > numpy.dft.info 3 3 100% > numpy.distutils 13 9 69% > numpy.distutils.__version__ 4 4 100% > numpy.distutils.ccompiler 296 49 16% > numpy.distutils.exec_command 409 27 6% > numpy.distutils.info 2 2 100% > numpy.distutils.log 37 18 48% > numpy.distutils.misc_util 945 174 18% > numpy.distutils.unixccompiler 34 11 32% > numpy.dual 41 27 65% > numpy.f2py.info 2 2 100% > numpy.lib 30 28 93% > numpy.lib.arraysetops 121 59 48% > numpy.lib.function_base 501 70 13% > numpy.lib.getlimits 76 61 80% > numpy.lib.index_tricks 223 56 25% > numpy.lib.info 4 4 100% > numpy.lib.machar 174 154 88% > numpy.lib.polynomial 357 52 14% > numpy.lib.scimath 51 19 37% > numpy.lib.shape_base 220 24 10% > numpy.lib.twodim_base 77 51 66% > numpy.lib.type_check 110 75 68% > numpy.lib.ufunclike 37 24 64% > numpy.lib.utils 42 23 54% > numpy.linalg 5 3 60% > numpy.linalg.info 2 2 100% > numpy.linalg.linalg 440 71 16% > numpy.random 10 6 60% > numpy.random.info 4 4 100% > numpy.testing 3 3 100% > numpy.testing.info 2 2 100% > numpy.testing.numpytest 430 214 49% > numpy.testing.utils 151 62 41% > numpy.version 7 7 100% > --------------------------------------------------- > TOTAL 8982 3764 41% > > (I filtered out all the *.tests.* modules). Note that you have to import > numpy after starting the coverage, because we use a lot of module-level code > that wouldn't be caught otherwise. > > -- > |>|\/|< > /--------------------------------------------------------------------------\ > |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ > |co...@ph... > |
|
From: Sasha <nd...@ma...> - 2006-06-30 22:10:12
|
It is not as bad as I thought, but there is certainly room for improvement. File `numpy/core/src/multiarraymodule.c' Lines executed:63.56% of 3290 File `numpy/core/src/arrayobject.c' Lines executed:59.70% of 5280 File `numpy/core/src/scalartypes.inc.src' Lines executed:31.67% of 963 File `numpy/core/src/arraytypes.inc.src' Lines executed:47.35% of 868 File `numpy/core/src/arraymethods.c' Lines executed:57.65% of 739 On 6/30/06, Sasha <nd...@ma...> wrote: > As soon as I sent out my 10% estimate, I realized that someone will > challenge it with a python level coverage statistics. My main concern > is not what fraction of numpy functions is called by unit tests, but > what fraction of special cases in the C code is exercised. I am not > sure that David's statistics even answers the first question - I would > guess it only counts statements in the pure python methods and > ignores methods implemented in C. > > Can someone post C-level statistics from gcov > <http://gcc.gnu.org/onlinedocs/gcc/Gcov.html> or a similar tool? > > On 6/30/06, David M. Cooke <co...@ph...> wrote: > > On Fri, 30 Jun 2006 12:35:35 -0400 > > Sasha <nd...@ma...> wrote: > > > > > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > > > > ... > > > > Besides, decent unit tests will catch these problems. We all know > > > > that every scientific code in existence is unit tested to the smallest > > > > routine, so this shouldn't be a problem for anyone. > > > > > > Is this a joke? Did anyone ever measured the coverage of numpy > > > unittests? I would be surprized if it was more than 10%. > > > > A very quick application of the coverage module, available at > > http://www.garethrees.org/2001/12/04/python-coverage/ > > gives me 41%: > > > > Name Stmts Exec Cover > > --------------------------------------------------- > > numpy 25 20 80% > > numpy._import_tools 235 175 74% > > numpy.add_newdocs 2 2 100% > > numpy.core 28 26 92% > > numpy.core.__svn_version__ 1 1 100% > > numpy.core._internal 99 48 48% > > numpy.core.arrayprint 251 92 36% > > numpy.core.defchararray 221 58 26% > > numpy.core.defmatrix 259 186 71% > > numpy.core.fromnumeric 319 153 47% > > numpy.core.info 3 3 100% > > numpy.core.ma 1612 1145 71% > > numpy.core.memmap 64 14 21% > > numpy.core.numeric 323 138 42% > > numpy.core.numerictypes 236 204 86% > > numpy.core.records 272 32 11% > > numpy.dft 6 4 66% > > numpy.dft.fftpack 128 31 24% > > numpy.dft.helper 35 32 91% > > numpy.dft.info 3 3 100% > > numpy.distutils 13 9 69% > > numpy.distutils.__version__ 4 4 100% > > numpy.distutils.ccompiler 296 49 16% > > numpy.distutils.exec_command 409 27 6% > > numpy.distutils.info 2 2 100% > > numpy.distutils.log 37 18 48% > > numpy.distutils.misc_util 945 174 18% > > numpy.distutils.unixccompiler 34 11 32% > > numpy.dual 41 27 65% > > numpy.f2py.info 2 2 100% > > numpy.lib 30 28 93% > > numpy.lib.arraysetops 121 59 48% > > numpy.lib.function_base 501 70 13% > > numpy.lib.getlimits 76 61 80% > > numpy.lib.index_tricks 223 56 25% > > numpy.lib.info 4 4 100% > > numpy.lib.machar 174 154 88% > > numpy.lib.polynomial 357 52 14% > > numpy.lib.scimath 51 19 37% > > numpy.lib.shape_base 220 24 10% > > numpy.lib.twodim_base 77 51 66% > > numpy.lib.type_check 110 75 68% > > numpy.lib.ufunclike 37 24 64% > > numpy.lib.utils 42 23 54% > > numpy.linalg 5 3 60% > > numpy.linalg.info 2 2 100% > > numpy.linalg.linalg 440 71 16% > > numpy.random 10 6 60% > > numpy.random.info 4 4 100% > > numpy.testing 3 3 100% > > numpy.testing.info 2 2 100% > > numpy.testing.numpytest 430 214 49% > > numpy.testing.utils 151 62 41% > > numpy.version 7 7 100% > > --------------------------------------------------- > > TOTAL 8982 3764 41% > > > > (I filtered out all the *.tests.* modules). Note that you have to import > > numpy after starting the coverage, because we use a lot of module-level code > > that wouldn't be caught otherwise. > > > > -- > > |>|\/|< > > /--------------------------------------------------------------------------\ > > |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ > > |co...@ph... > > > |
|
From: Sasha <nd...@ma...> - 2006-06-30 22:21:25
|
"Software developers also use coverage testing in concert with testsuites, to make sure software is actually good enough for a release. " -- Gcov Manual I think if we can improve the test coverage, it will speak volumes about the quality of numpy. Does anyone know if it is possible to instrument numpy libraries without having to instrument python itself? It would be nice to make the coverage reports easily available either by including a generating script with the source distribution or by publishing the reports for the releases. On 6/30/06, Sasha <nd...@ma...> wrote: > It is not as bad as I thought, but there is certainly room for improvement. > > File `numpy/core/src/multiarraymodule.c' > Lines executed:63.56% of 3290 > > File `numpy/core/src/arrayobject.c' > Lines executed:59.70% of 5280 > > File `numpy/core/src/scalartypes.inc.src' > Lines executed:31.67% of 963 > > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 > > File `numpy/core/src/arraymethods.c' > Lines executed:57.65% of 739 > > > > On 6/30/06, Sasha <nd...@ma...> wrote: > > As soon as I sent out my 10% estimate, I realized that someone will > > challenge it with a python level coverage statistics. My main concern > > is not what fraction of numpy functions is called by unit tests, but > > what fraction of special cases in the C code is exercised. I am not > > sure that David's statistics even answers the first question - I would > > guess it only counts statements in the pure python methods and > > ignores methods implemented in C. > > > > Can someone post C-level statistics from gcov > > <http://gcc.gnu.org/onlinedocs/gcc/Gcov.html> or a similar tool? > > > > On 6/30/06, David M. Cooke <co...@ph...> wrote: > > > On Fri, 30 Jun 2006 12:35:35 -0400 > > > Sasha <nd...@ma...> wrote: > > > > > > > On 6/30/06, Fernando Perez <fpe...@gm...> wrote: > > > > > ... > > > > > Besides, decent unit tests will catch these problems. We all know > > > > > that every scientific code in existence is unit tested to the smallest > > > > > routine, so this shouldn't be a problem for anyone. > > > > > > > > Is this a joke? Did anyone ever measured the coverage of numpy > > > > unittests? I would be surprized if it was more than 10%. > > > > > > A very quick application of the coverage module, available at > > > http://www.garethrees.org/2001/12/04/python-coverage/ > > > gives me 41%: > > > > > > Name Stmts Exec Cover > > > --------------------------------------------------- > > > numpy 25 20 80% > > > numpy._import_tools 235 175 74% > > > numpy.add_newdocs 2 2 100% > > > numpy.core 28 26 92% > > > numpy.core.__svn_version__ 1 1 100% > > > numpy.core._internal 99 48 48% > > > numpy.core.arrayprint 251 92 36% > > > numpy.core.defchararray 221 58 26% > > > numpy.core.defmatrix 259 186 71% > > > numpy.core.fromnumeric 319 153 47% > > > numpy.core.info 3 3 100% > > > numpy.core.ma 1612 1145 71% > > > numpy.core.memmap 64 14 21% > > > numpy.core.numeric 323 138 42% > > > numpy.core.numerictypes 236 204 86% > > > numpy.core.records 272 32 11% > > > numpy.dft 6 4 66% > > > numpy.dft.fftpack 128 31 24% > > > numpy.dft.helper 35 32 91% > > > numpy.dft.info 3 3 100% > > > numpy.distutils 13 9 69% > > > numpy.distutils.__version__ 4 4 100% > > > numpy.distutils.ccompiler 296 49 16% > > > numpy.distutils.exec_command 409 27 6% > > > numpy.distutils.info 2 2 100% > > > numpy.distutils.log 37 18 48% > > > numpy.distutils.misc_util 945 174 18% > > > numpy.distutils.unixccompiler 34 11 32% > > > numpy.dual 41 27 65% > > > numpy.f2py.info 2 2 100% > > > numpy.lib 30 28 93% > > > numpy.lib.arraysetops 121 59 48% > > > numpy.lib.function_base 501 70 13% > > > numpy.lib.getlimits 76 61 80% > > > numpy.lib.index_tricks 223 56 25% > > > numpy.lib.info 4 4 100% > > > numpy.lib.machar 174 154 88% > > > numpy.lib.polynomial 357 52 14% > > > numpy.lib.scimath 51 19 37% > > > numpy.lib.shape_base 220 24 10% > > > numpy.lib.twodim_base 77 51 66% > > > numpy.lib.type_check 110 75 68% > > > numpy.lib.ufunclike 37 24 64% > > > numpy.lib.utils 42 23 54% > > > numpy.linalg 5 3 60% > > > numpy.linalg.info 2 2 100% > > > numpy.linalg.linalg 440 71 16% > > > numpy.random 10 6 60% > > > numpy.random.info 4 4 100% > > > numpy.testing 3 3 100% > > > numpy.testing.info 2 2 100% > > > numpy.testing.numpytest 430 214 49% > > > numpy.testing.utils 151 62 41% > > > numpy.version 7 7 100% > > > --------------------------------------------------- > > > TOTAL 8982 3764 41% > > > > > > (I filtered out all the *.tests.* modules). Note that you have to import > > > numpy after starting the coverage, because we use a lot of module-level code > > > that wouldn't be caught otherwise. > > > > > > -- > > > |>|\/|< > > > /--------------------------------------------------------------------------\ > > > |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ > > > |co...@ph... > > > > > > |
|
From: Alexander B. <ale...@gm...> - 2006-06-30 23:01:55
|
On 6/30/06, Sasha <nd...@ma...> wrote: > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 This is was an overly optimistic number. More relevant is the following obtained by disabling the #line directives: File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' Lines executed:26.71% of 5010 |
|
From: Sasha <nd...@ma...> - 2006-06-30 23:02:21
|
---------- Forwarded message ---------- From: Alexander Belopolsky <ale...@gm...> Date: Jun 30, 2006 7:01 PM Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0 To: "David M. Cooke" <co...@ph...> Cc: Fernando Perez <fpe...@gm...>, num...@li... On 6/30/06, Sasha <nd...@ma...> wrote: > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 This is was an overly optimistic number. More relevant is the following obtained by disabling the #line directives: File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' Lines executed:26.71% of 5010 |
|
From: Travis O. <oli...@ee...> - 2006-06-30 23:04:54
|
Alexander Belopolsky wrote: >On 6/30/06, Sasha <nd...@ma...> wrote: > > > >>File `numpy/core/src/arraytypes.inc.src' >>Lines executed:47.35% of 868 >> >> > >This is was an overly optimistic number. More relevant is the >following obtained by disabling the #line directives: > >File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' >Lines executed:26.71% of 5010 > > Yes, this is true, but the auto-generation means that success for one instantiation increases the likelihood for success in the others. So, the 26.7% is probably too pessimistic. -Travis |
|
From: Sasha <nd...@ma...> - 2006-06-30 23:16:30
|
On 6/30/06, Travis Oliphant <oli...@ee...> wrote: > ... > Yes, this is true, but the auto-generation means that success for one > instantiation increases the likelihood for success in the others. So, > the 26.7% is probably too pessimistic. Agree, but "increases the likelihood" != "guarantees". For example, relying on nan propagation is a fine strategy for the floating point case, but will not work for integer types. Similarly code relying on wrap on overflow will fail when type=float. The best solution would be to autogenerate test cases so that all types are tested where appropriate. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X