Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Thu, Feb 11, 2010 at 18:23, Charles R Harris charlesr.har...@gmail.com wrote: What about python version? Do we want to bump that up from 2.4? Only if it were *really* necessary for the Python 3 port. Otherwise, I would resist the urge. I don't think it's necessary for that. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Fri, Feb 12, 2010 at 9:01 AM, Pauli Virtanen p...@iki.fi wrote: On Thu, Feb 11, 2010 at 18:23, Charles R Harris charlesr.har...@gmail.com wrote: What about python version? Do we want to bump that up from 2.4? Only if it were *really* necessary for the Python 3 port. Otherwise, I would resist the urge. I don't think it's necessary for that. -- I'm trying to follow this discussion as good as I can. Please tell me, is the planned ABI change including the Addition of a dict object to all NumPy objects I was asking about recently. (I'm mostly referring to an old thread of Aug 2008: http://www.mail-archive.com/numpy-discussion@scipy.org/msg11898.html ) Oh, and is there a proposed name for that attribute (on the Python side) ? Regards, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] docstring suggestions
Hi, I was just looking for numpy.ma.compressed, but forgot its name. I suggest to add a pointer/see also to numpy.ma.filled at least: http://docs.scipy.org/numpy/docs/numpy.ma.core.filled/ Unfortunately, I forgot the PW of my account (hans_meine), otherwise I'd have given it a shot. Ciao, Hans ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Friday 12 February 2010 13:43:56 Hans Meine wrote:
I was just looking for numpy.ma.compressed, but forgot its name.
Another strange thing is the docstring of numpy.ma.compress, which appears in
ipython like this:
Type: instance
Base Class: numpy.ma.core._frommethod
[...]
Docstring:
compress(self, condition, axis=None, out=None)
Return `a` where condition is ``True``.
[...]
Parameters
--
condition : var
[...]
axis : {None, int}, optional
[...]
out : {None, ndarray}, optional
[...]
Call def: numpy.ma.compress(self, a, *args, **params)
Note the `self` vs. `a` problem, as well as the call def which has both, but
no condition anymore. And `a`/self does not appear under parameters.
All these problems are probably related to numpy.ma.core._frommethod, but
anyhow this looks wrong from a user's POV.
HTH,
Hans
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Fri, Feb 12, 2010 at 12:16 AM, David Cournapeau da...@silveregg.co.jp wrote: Charles R Harris wrote: I don't see any struct definitions there, it looks clean. Any struct defined outside numpy/core/include is fine to change at will as far as ABI is concerned anyway, so no need to check anything :) Thanks for the clarification. I just double checked the svn diff (r7308), and I did not touch anything in numpy/core/include. Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Mon, Feb 8, 2010 at 7:25 PM, Robert Kern robert.k...@gmail.com wrote: Here's the problem that I don't think many people appreciate: logical arguments suck just as much as personal experience in answering these questions. You can make perfectly structured arguments until you are blue in the face, but without real data to premise them on, they are no better than the gut feelings. They can often be significantly worse if the strength of the logic gets confused with the strength of the premise. I need to frame this (or make a sig to put it in, the internet equivalent of a wooden frame :). Thank you, Robert. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Re ading scientific notation using D instead of E
I am trying to read a large amount of data that is output in scientific
notation using D instead of E. After searching around I found a thread that
implied numpy already has the capability to do this:
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
However, this does not work for me. I get:
numpy.float('1.23D+04')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for float(): 1.23D+04
Was this capability lost in more recent versions of numpy?
I would rather not have to do a search and replace every time I read in
data.
Thanks.
--
View this message in context:
http://old.nabble.com/Reading-scientific-notation-using-D-instead-of-E-tp27565041p27565041.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Re ading scientific notation using D instead of E
On Fri, Feb 12, 2010 at 10:46 AM, Robert C. ricit...@mac.com wrote:
I am trying to read a large amount of data that is output in scientific
notation using D instead of E. After searching around I found a thread that
implied numpy already has the capability to do this:
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
However, this does not work for me. I get:
numpy.float('1.23D+04')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for float(): 1.23D+04
Was this capability lost in more recent versions of numpy?
I would rather not have to do a search and replace every time I read in
data.
np.float('1.5698D+03')
1569.8
np.float('1.23D+04')
12300.0
it's still working with numpy 1.4.0
Josef
Thanks.
--
View this message in context:
http://old.nabble.com/Reading-scientific-notation-using-D-instead-of-E-tp27565041p27565041.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.
___
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] Re ading scientific notation using D instead of E
On Fri, Feb 12, 2010 at 11:03 AM, josef.p...@gmail.com wrote:
On Fri, Feb 12, 2010 at 10:46 AM, Robert C. ricit...@mac.com wrote:
I am trying to read a large amount of data that is output in scientific
notation using D instead of E. After searching around I found a thread that
implied numpy already has the capability to do this:
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
However, this does not work for me. I get:
numpy.float('1.23D+04')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for float(): 1.23D+04
Was this capability lost in more recent versions of numpy?
I would rather not have to do a search and replace every time I read in
data.
np.float('1.5698D+03')
1569.8
np.float('1.23D+04')
12300.0
it's still working with numpy 1.4.0
maybe this is a python feature with python builtin float:
float('1.5698D+03')
1569.8
float('123D+04')
123.0
with python 2.5
Josef
Josef
Thanks.
--
View this message in context:
http://old.nabble.com/Reading-scientific-notation-using-D-instead-of-E-tp27565041p27565041.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.
___
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] Re ading scientific notation using D instead of E
josef.p...@gmail.com wrote:
On Fri, Feb 12, 2010 at 11:03 AM, josef.p...@gmail.com wrote:
On Fri, Feb 12, 2010 at 10:46 AM, Robert C. ricit...@mac.com wrote:
I am trying to read a large amount of data that is output in scientific
notation using D instead of E. After searching around I found a thread that
implied numpy already has the capability to do this:
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
http://stackoverflow.com/questions/1959210/python-scientific-notation-using-d-instead-of-e
However, this does not work for me. I get:
numpy.float('1.23D+04')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for float(): 1.23D+04
Was this capability lost in more recent versions of numpy?
I would rather not have to do a search and replace every time I read in
data.
np.float('1.5698D+03')
1569.8
np.float('1.23D+04')
12300.0
it's still working with numpy 1.4.0
maybe this is a python feature with python builtin float:
float('1.5698D+03')
1569.8
float('123D+04')
123.0
with python 2.5
With Python 2.6, I get Invalid literal for float.
Dag Sverre
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Re ading scientific notation using D instead of E
On Fri, Feb 12, 2010 at 10:05, josef.p...@gmail.com wrote:
On Fri, Feb 12, 2010 at 11:03 AM, josef.p...@gmail.com wrote:
np.float('1.5698D+03')
1569.8
np.float('1.23D+04')
12300.0
it's still working with numpy 1.4.0
maybe this is a python feature with python builtin float:
float('1.5698D+03')
1569.8
float('123D+04')
123.0
with python 2.5
numpy.float is indeed Python's builtin float type (for obscure
historical reasons that I won't go into). However, in Python 2.5, at
least, the parsing of the string is offloaded to the standard C
function strtod(). On your platform, strtod() will parse the D
correctly. On OS X, for example, it doesn't. It has nothing to do with
Python versions but rather the platform that you are on.
--
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] Re ading scientific notation using D instead of E
Thank you for the replies. It must be because I am using python on OSX. Is
there no work around for it then?
Robert Kern-2 wrote:
On Fri, Feb 12, 2010 at 10:05, josef.p...@gmail.com wrote:
On Fri, Feb 12, 2010 at 11:03 AM, josef.p...@gmail.com wrote:
np.float('1.5698D+03')
1569.8
np.float('1.23D+04')
12300.0
it's still working with numpy 1.4.0
maybe this is a python feature with python builtin float:
float('1.5698D+03')
1569.8
float('123D+04')
123.0
with python 2.5
numpy.float is indeed Python's builtin float type (for obscure
historical reasons that I won't go into). However, in Python 2.5, at
least, the parsing of the string is offloaded to the standard C
function strtod(). On your platform, strtod() will parse the D
correctly. On OS X, for example, it doesn't. It has nothing to do with
Python versions but rather the platform that you are on.
--
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
--
View this message in context:
http://old.nabble.com/Reading-scientific-notation-using-D-instead-of-E-tp27565041p27566555.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Re ading scientific notation using D instead of E
Robert Kern wrote: numpy.float is indeed Python's builtin float type (for obscure historical reasons that I won't go into). However, in Python 2.5, at least, the parsing of the string is offloaded to the standard C function strtod(). well, sort of -- it's pre-processed first, to add some numpy features, including parsing of NaN's. So it wouldn't be all that hard to add this too (well not that hard in the context of messing around in ugly C code, anyway). See my messages about fromfile() a few weeks ago for details. By the way, I got as far as identifying bugs/issues in that code, but not fixing them -- I'll try to do that before the upcoming 1.5/2.0/whatever release. If anyone wants to work in this issue, it might make sense to collaborate. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Re ading scientific notation using D instead of E
On Fri, Feb 12, 2010 at 11:27, Christopher Barker chris.bar...@noaa.gov wrote: Robert Kern wrote: numpy.float is indeed Python's builtin float type (for obscure historical reasons that I won't go into). However, in Python 2.5, at least, the parsing of the string is offloaded to the standard C function strtod(). well, sort of -- it's pre-processed first, to add some numpy features, including parsing of NaN's. So it wouldn't be all that hard to add this too (well not that hard in the context of messing around in ugly C code, anyway). Eh, what? numpy.float is Python's float. No numpy features at all. There is some preprocessing, specifically to handle edge conditions like .1, and Python 2.6 handles 'nan', but the important point is that we don't control that code. You will have to submit a bug report to Python in order to change that behavior. That said, numpy.float64() is under our control, and you may submit a patch to convert [dD] to [eE]. -- 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] docstring suggestions
2010/2/12 Hans Meine me...@informatik.uni-hamburg.de
On Friday 12 February 2010 13:43:56 Hans Meine wrote:
I was just looking for numpy.ma.compressed, but forgot its name.
Fixed this one in the Wiki.
Another strange thing is the docstring of numpy.ma.compress, which appears
in
ipython like this:
Type: instance
Base Class: numpy.ma.core._frommethod
[...]
Docstring:
compress(self, condition, axis=None, out=None)
Return `a` where condition is ``True``.
[...]
Parameters
--
condition : var
[...]
axis : {None, int}, optional
[...]
out : {None, ndarray}, optional
[...]
Call def: numpy.ma.compress(self, a, *args, **params)
Note the `self` vs. `a` problem, as well as the call def which has both,
but
no condition anymore. And `a`/self does not appear under parameters.
Uncertain how to fix this one - is it a bug in how the docstring is
interpreted somewhere along the line?
DG
PS: please, if you don't mind, in the future post docstring complaints at
scipy-dev (numpy-discussion has many more subscribers, many of whom probably
don't immediately care about any particular docstring problem, whereas
anyone who is working on the docstrings is - hopefully - subscribed to
scipy-dev); thanks.
All these problems are probably related to numpy.ma.core._frommethod, but
anyhow this looks wrong from a user's POV.
HTH,
Hans
___
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] docstring suggestions
On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. -- 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
[Numpy-discussion] Fwd: [atlas-devel] ATLAS support letters
Hi, I don't know if y'all are subscribed to the ATLAS mailing list, but, it would be good if we could find a way of supporting Clint as strongly as we can. Best, Matthew -- Forwarded message -- From: Clint Whaley wha...@cs.utsa.edu Date: Fri, Feb 12, 2010 at 9:15 AM Subject: [atlas-devel] ATLAS support letters To: math-atlas-de...@lists.sourceforge.net Guys, I go up for tenure this year. The tenure committee has asked me to get letters of support from ATLAS users so that they can assess the service impact of my support of ATLAS (I *tell* them it is widely used, but can I show it other than downloads?). The letter would discuss a little of what you do, and how you use ATLAS, and the importance of having ATLAS in furthering your project goals. So, if you are part of an organization/business/open source project/research project that uses ATLAS, please contact me if you or a colleague is willing to help with such a letter. If you know someone at such a place that uses ATLAS, forward this on. I will be contacting some groups that I know use ATLAS, but I don't know about the majority of people/groups who do, and I often don't have records and so forget even the ones I knew used it . . . With Goto taking a position at MS, it is all the more important that I can show my colleagues that ATLAS support and development is a service to the community, and having it at UTSA helps the university and department . . . Thanks, Clint ** ** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley ** ** -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Math-atlas-devel mailing list math-atlas-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/math-atlas-devel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Hi, On Fri, Feb 12, 2010 at 7:02 AM, Fernando Perez fperez@gmail.com wrote: On Mon, Feb 8, 2010 at 7:25 PM, Robert Kern robert.k...@gmail.com wrote: Here's the problem that I don't think many people appreciate: logical arguments suck just as much as personal experience in answering these questions. You can make perfectly structured arguments until you are blue in the face, but without real data to premise them on, they are no better than the gut feelings. They can often be significantly worse if the strength of the logic gets confused with the strength of the premise. I need to frame this (or make a sig to put it in, the internet equivalent of a wooden frame :). Thank you, Robert. Yes, except that, at its most extreme, it renders reasonable argument pointless, and leads to resolving disputes by authority rather than discussion. Of course we don't work or think in realm that can be cleared of bias or error, but it would be difficult be a scientist and fail to notice that - agreeing - things that really should be true, aren't true and - disagreeing - despite all the threatening brackets, reasoned argument, and careful return to data, do work in increasing our understanding. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? DG -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. -- 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] docstring suggestions
On Fri, Feb 12, 2010 at 3:29 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. doceditor not moin Wiki, that was the policy that Ralf and David followed since last summer to have all docediting questions in one place. Josef -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 14:42, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:29 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. doceditor not moin Wiki, that was the policy that Ralf and David followed since last summer to have all docediting questions in one place. Is the volume of questions really so large to justify the inconvenience to the questioners? It's one thing to direct someone to, say, the matplotlib list when asking matplotlib questions, but no one is going to guess that they need to go to scipy-dev to ask a question about the doceditor when they run into a problem editing a numpy docstring. -- 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] docstring suggestions
On Fri, Feb 12, 2010 at 3:47 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:42, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:29 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. doceditor not moin Wiki, that was the policy that Ralf and David followed since last summer to have all docediting questions in one place. Is the volume of questions really so large to justify the inconvenience to the questioners? It's one thing to direct someone to, say, the matplotlib list when asking matplotlib questions, but no one is going to guess that they need to go to scipy-dev to ask a question about the doceditor when they run into a problem editing a numpy docstring. No, I agree with you, short questions can be answered wherever they happen, especially if they are on topic. But, if it turns into a discussion about the internal structure of how doc strings are generated, then maybe David can redirect the traffic. Josef -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 14:58, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:47 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:42, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:29 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. doceditor not moin Wiki, that was the policy that Ralf and David followed since last summer to have all docediting questions in one place. Is the volume of questions really so large to justify the inconvenience to the questioners? It's one thing to direct someone to, say, the matplotlib list when asking matplotlib questions, but no one is going to guess that they need to go to scipy-dev to ask a question about the doceditor when they run into a problem editing a numpy docstring. No, I agree with you, short questions can be answered wherever they happen, especially if they are on topic. But, if it turns into a discussion about the internal structure of how doc strings are generated, then maybe David can redirect the traffic. I just don't see the reason for all that hassle, and it is a substantial hassle. You redirect people in order to get their question in front of the audience that can help them best or for truly off-topic discussions. As far as I'm concerned, questions about the doceditor, which drives the documentation for both numpy and scipy, are on-topic for any of either of the projects' lists. You don't redirect people just to keep things tidy. Mailing lists are messy things no matter what you do. -- 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] docstring suggestions
OK, OK, Ok, it's not worth getting into a flame war over. We ask people who are going to be working on the docstrings to subscribe to scipy-dev; this is not the same thing as being an innocent bystander asking a question or making a comment - I retract the request. Now, does anyone have anything useful to say about OP's original second problem? DG On Fri, Feb 12, 2010 at 1:05 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:58, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:47 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:42, josef.p...@gmail.com wrote: On Fri, Feb 12, 2010 at 3:29 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 14:26, David Goldsmith d.l.goldsm...@gmail.com wrote: On Fri, Feb 12, 2010 at 10:57 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 12, 2010 at 12:19, David Goldsmith d.l.goldsm...@gmail.com wrote: PS: please, if you don't mind, in the future post docstring complaints at scipy-dev (numpy-discussion has many more subscribers, many of whom probably don't immediately care about any particular docstring problem, whereas anyone who is working on the docstrings is - hopefully - subscribed to scipy-dev); thanks. numpy docstrings get discussed on numpy-discussion. Then is it just the Wiki and related issues that we ask people to discuss @ scipy-dev? I don't see a reason to do that, either. doceditor not moin Wiki, that was the policy that Ralf and David followed since last summer to have all docediting questions in one place. Is the volume of questions really so large to justify the inconvenience to the questioners? It's one thing to direct someone to, say, the matplotlib list when asking matplotlib questions, but no one is going to guess that they need to go to scipy-dev to ask a question about the doceditor when they run into a problem editing a numpy docstring. No, I agree with you, short questions can be answered wherever they happen, especially if they are on topic. But, if it turns into a discussion about the internal structure of how doc strings are generated, then maybe David can redirect the traffic. I just don't see the reason for all that hassle, and it is a substantial hassle. You redirect people in order to get their question in front of the audience that can help them best or for truly off-topic discussions. As far as I'm concerned, questions about the doceditor, which drives the documentation for both numpy and scipy, are on-topic for any of either of the projects' lists. You don't redirect people just to keep things tidy. Mailing lists are messy things no matter what you do. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Re ading scientific notation using D instead of E
Robert Kern wrote:
Eh, what? numpy.float is Python's float. No numpy features at all.
my mistake -- I guess I assumed that numpy.float was an alias for
numpy.float64.
anyway, the (all?) the numpy dtypes have their own implementation of
conversion from strings (which are a bit buggy, unfortunately).
They don't seem to be accessible in the same way, though:
In [44]: np.float64('1.23F+04')
---
ValueErrorTraceback (most recent call last)
/Users/cbarker/HAZMAT/SmallTools/WxTool/trunk/tests/ipython console in
module()
ValueError: setting an array element with a sequence.
is the only way to do this:
In [49]: np.fromstring('1.23', dtype=np.float64, sep=' ')
Out[49]: array([ 1.23])
which is indeed, buggy (I wasn't aware of this bug yet):
In [51]: np.fromstring('1.23F+04', dtype=np.float64, sep=',')
Out[51]: array([ 1.23])
This make me think that the string conversion code is only being used by
fromstring/fromfile, and that it isn't used much there!
Which makes me wonder -- should we fix it or deprecate it?
If fix_it:
I wonder about the choice of strtod() and friends for the string
conversion -- is seems that fscans would be easier and more robust (or
easier to make robust, anyway)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Feb 12, 2010, at 4:24 PM, David Goldsmith wrote: OK, OK, Ok, it's not worth getting into a flame war over. We ask people who are going to be working on the docstrings to subscribe to scipy-dev; this is not the same thing as being an innocent bystander asking a question or making a comment - I retract the request. Now, does anyone have anything useful to say about OP's original second problem? Yes: write a proper docstring, or find me a better way to automatically create the docstring of a function from the docstring of the corresponding method (or vice-versa) than we have now for numpy.ma. I agree that the current method is not ideal, but at least you get some kind of info. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 2:30 PM, Pierre GM pgmdevl...@gmail.com wrote: On Feb 12, 2010, at 4:24 PM, David Goldsmith wrote: OK, OK, Ok, it's not worth getting into a flame war over. We ask people who are going to be working on the docstrings to subscribe to scipy-dev; this is not the same thing as being an innocent bystander asking a question or making a comment - I retract the request. Now, does anyone have anything useful to say about OP's original second problem? Yes: write a proper docstring, or find me a better way to automatically create the docstring of a function from the docstring of the corresponding method (or vice-versa) than we have now for numpy.ma. I agree that the current method is not ideal, but at least you get some kind of info. Ah, now I understand. We've been here before: http://docs.scipy.org/numpy/Questions+Answers/#documenting-equivalent-functions-and-methods No canonical answer has been recorded, but Scott Sinclair commented: In the the masked array module we should doc the methods. The functions automatically have the same docstring. Is the present issue an instance where Scott's second statement is invalid, an instance where its validity is resulting in a poor docstring for the function, or an instance in which Scott's recommendation was not followed? In any event, Ralf Gommers agreed w/ Scott's first statement, I'm neutral, and no one else appears to have voted... DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Feb 12, 2010, at 8:14 PM, David Goldsmith wrote Is the present issue an instance where Scott's second statement is invalid, an instance where its validity is resulting in a poor docstring for the function, or an instance in which Scott's recommendation was not followed? The methods' docstring are fine, but we could improve the way the corresponding function docstrings are created. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] docstring suggestions
On Fri, Feb 12, 2010 at 7:09 PM, Pierre GM pgmdevl...@gmail.com wrote: On Feb 12, 2010, at 8:14 PM, David Goldsmith wrote Is the present issue an instance where Scott's second statement is invalid, an instance where its validity is resulting in a poor docstring for the function, or an instance in which Scott's recommendation was not followed? The methods' docstring are fine, but we could improve the way the corresponding function docstrings are created. Does anyone have an idea of how universal of a problem this is (i.e., is it just confined to ma)? Scott's statement appears to imply that he thought there was no problem at all. DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
