[Numpy-discussion] somewhat less stupid problem with 0-d arrays
It would be convenient if in arithmetic 0-d arrays were just ignored - it would seem to me to be convenient in generic code where a degenerate array is treated as "nothing" np.zeros ((0,0)) + np.ones ((2,2)) --- ValueErrorTraceback (most recent call last) in () > 1 np.zeros ((0,0)) + np.ones ((2,2)) ValueError: operands could not be broadcast together with shapes (0,0) (2,2) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0-dim arrays inconsistency
Neal Becker wrote: > np.array ((0,0)) > Out[10]: array([0, 0]) <<< ok, it's 2 dimensional > > In [11]: np.array ((0,0)).shape > Out[11]: (2,) <<< except, it isn't Sorry for the stupid question - please ignore ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0-dim arrays inconsistency
Hi Neal, On Fri, May 10, 2013 at 7:36 PM, Neal Becker wrote: > np.array ((0,0)) > Out[10]: array([0, 0]) <<< ok, it's 2 dimensional Think you may have confused yourself :-). It's 1 dimensional with 2 elements... > In [11]: np.array ((0,0)).shape > Out[11]: (2,) <<< except, it isn't ...as per above. (Not sure where the 0-dim part comes in.) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 0-dim arrays inconsistency
np.array ((0,0)) Out[10]: array([0, 0]) <<< ok, it's 2 dimensional In [11]: np.array ((0,0)).shape Out[11]: (2,) <<< except, it isn't ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] tests not running
On Fri, May 10, 2013 at 9:41 PM, KACVINSKY Tom wrote: > Here is my set up: > > Mac OS 10.7.5 > Xcode 4.5.1 > Intel Fortran 12.1 > Python 2.7.3 built from source > Numpy 1.6.2 built from source, using MKL 11.0 > nose 0.11.4 installed > > I run the numpy tests as documented (python -c 'import numpy; > numpy.test()'), but get this output: > > tkacvins@macomsim> python -c 'import numpy; numpy.test()' > Running unit tests for numpy > NumPy version 1.6.2 > NumPy is installed in > /rd/gen/tky/do_not_delete/Python/macpython27/lib/python2.7/site-packages/numpy > Python version 2.7.3 (default, Oct 10 2012, 14:47:52) [GCC 4.2.1 (Based on > Apple Inc. build 5658) (LLVM build 2336.9.00)] > nose version 0.11.4 > > -- > Ran 0 tests in 0.025s > > OK > > Any diagnostics or options I can pass to the tests to see what is going > on? This is rather odd, I thought the tests would run and possibly fail. > I didn't expect 0 tests to run. > That's usually due to the executable bit being set on all files during install (setuptools does this, nose disapproves). Try `` np.test(extra_argv='--exe')``. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array_priority__ don't work for gt, lt, ... operator
thanks, I'll look at it. I made a PR: https://github.com/numpy/numpy/pull/3324 Where should I put the tests about this? thanks Fred On Fri, May 10, 2013 at 4:03 PM, Sebastian Berg wrote: > On Fri, 2013-05-10 at 15:35 -0400, Frédéric Bastien wrote: > > I'm trying to do it, but each time I want to test something, it takes > > a long time to rebuild numpy to test it. Is there a way to don't > > recompile everything for each test? > > > Are you using current master? It defaults to use > ENABLE_SEPARATE_COMPILATION enviroment variable, which, together with > ccache, makes most changes in numpy compile fast for me. > > - Sebastian > > > > thanks > > > > Fred > > > > > > > > On Fri, May 10, 2013 at 1:34 PM, Charles R Harris > > wrote: > > > > > > On Fri, May 10, 2013 at 10:08 AM, Frédéric Bastien > > wrote: > > Hi, > > > > > > it popped again on the Theano mailing list that this > > don't work: > > > > > > np.arange(10) <= a_theano_vector. > > > > > > The reason is that __array_priority__ isn't respected > > for that class of operation. > > > > > > > > This page explain the problem and give a work around: > > > > > > > http://stackoverflow.com/questions/14619449/how-can-i-override-comparisons-between-numpys-ndarray-and-my-type > > > > > > The work around is to make a python function that will > > decide witch version of the comparator to call and do > > the call. Then we tell NumPy to use that function > > instead of its current function with: > > np.set_numeric_ops(...) > > > > But if we do that, when we import theano, we will slow > > down all normal numpy comparison for the user, as when > > <= is execute, first there will be numpy c code > > executed, that will call the python function to decide > > witch version to do, then if it is 2 numpy ndarray, it > > will call again numpy c code. > > > > > > That isn't a good solution. We could do the same > > override in C, but then theano work the same when > > there isn't a c++ compiler. That isn't nice. > > > > > > What do you think of changing them to check for > > __array_priority__ before doing the comparison? > > > > This looks like an oversight and should be fixed. > > > > Chuck > > > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array_priority__ don't work for gt, lt, ... operator
On Fri, 2013-05-10 at 15:35 -0400, Frédéric Bastien wrote: > I'm trying to do it, but each time I want to test something, it takes > a long time to rebuild numpy to test it. Is there a way to don't > recompile everything for each test? > Are you using current master? It defaults to use ENABLE_SEPARATE_COMPILATION enviroment variable, which, together with ccache, makes most changes in numpy compile fast for me. - Sebastian > thanks > > Fred > > > > On Fri, May 10, 2013 at 1:34 PM, Charles R Harris > wrote: > > > On Fri, May 10, 2013 at 10:08 AM, Frédéric Bastien > wrote: > Hi, > > > it popped again on the Theano mailing list that this > don't work: > > > np.arange(10) <= a_theano_vector. > > > The reason is that __array_priority__ isn't respected > for that class of operation. > > > > This page explain the problem and give a work around: > > > > http://stackoverflow.com/questions/14619449/how-can-i-override-comparisons-between-numpys-ndarray-and-my-type > > > The work around is to make a python function that will > decide witch version of the comparator to call and do > the call. Then we tell NumPy to use that function > instead of its current function with: > np.set_numeric_ops(...) > > But if we do that, when we import theano, we will slow > down all normal numpy comparison for the user, as when > <= is execute, first there will be numpy c code > executed, that will call the python function to decide > witch version to do, then if it is 2 numpy ndarray, it > will call again numpy c code. > > > That isn't a good solution. We could do the same > override in C, but then theano work the same when > there isn't a c++ compiler. That isn't nice. > > > What do you think of changing them to check for > __array_priority__ before doing the comparison? > > This looks like an oversight and should be fixed. > > Chuck > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] tests not running
Here is my set up: Mac OS 10.7.5 Xcode 4.5.1 Intel Fortran 12.1 Python 2.7.3 built from source Numpy 1.6.2 built from source, using MKL 11.0 nose 0.11.4 installed I run the numpy tests as documented (python -c 'import numpy; numpy.test()'), but get this output: tkacvins@macomsim> python -c 'import numpy; numpy.test()' Running unit tests for numpy NumPy version 1.6.2 NumPy is installed in /rd/gen/tky/do_not_delete/Python/macpython27/lib/python2.7/site-packages/numpy Python version 2.7.3 (default, Oct 10 2012, 14:47:52) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)] nose version 0.11.4 -- Ran 0 tests in 0.025s OK Any diagnostics or options I can pass to the tests to see what is going on? This is rather odd, I thought the tests would run and possibly fail. I didn't expect 0 tests to run. Thanks, Tom This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email. For other languages, go to http://www.3ds.com/terms/email-disclaimer ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array_priority__ don't work for gt, lt, ... operator
I'm trying to do it, but each time I want to test something, it takes a long time to rebuild numpy to test it. Is there a way to don't recompile everything for each test? thanks Fred On Fri, May 10, 2013 at 1:34 PM, Charles R Harris wrote: > > > On Fri, May 10, 2013 at 10:08 AM, Frédéric Bastien wrote: > >> Hi, >> >> it popped again on the Theano mailing list that this don't work: >> >> np.arange(10) <= a_theano_vector. >> >> The reason is that __array_priority__ isn't respected for that class of >> operation. >> >> This page explain the problem and give a work around: >> >> >> http://stackoverflow.com/questions/14619449/how-can-i-override-comparisons-between-numpys-ndarray-and-my-type >> >> The work around is to make a python function that will decide witch >> version of the comparator to call and do the call. Then we tell NumPy to >> use that function instead of its current function with: >> np.set_numeric_ops(...) >> >> But if we do that, when we import theano, we will slow down all normal >> numpy comparison for the user, as when <= is execute, first there will be >> numpy c code executed, that will call the python function to decide witch >> version to do, then if it is 2 numpy ndarray, it will call again numpy c >> code. >> >> That isn't a good solution. We could do the same override in C, but then >> theano work the same when there isn't a c++ compiler. That isn't nice. >> >> What do you think of changing them to check for __array_priority__ before >> doing the comparison? >> > > This looks like an oversight and should be fixed. > > Chuck > > ___ > 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] __array_priority__ don't work for gt, lt, ... operator
On Fri, May 10, 2013 at 10:08 AM, Frédéric Bastien wrote: > Hi, > > it popped again on the Theano mailing list that this don't work: > > np.arange(10) <= a_theano_vector. > > The reason is that __array_priority__ isn't respected for that class of > operation. > > This page explain the problem and give a work around: > > > http://stackoverflow.com/questions/14619449/how-can-i-override-comparisons-between-numpys-ndarray-and-my-type > > The work around is to make a python function that will decide witch > version of the comparator to call and do the call. Then we tell NumPy to > use that function instead of its current function with: > np.set_numeric_ops(...) > > But if we do that, when we import theano, we will slow down all normal > numpy comparison for the user, as when <= is execute, first there will be > numpy c code executed, that will call the python function to decide witch > version to do, then if it is 2 numpy ndarray, it will call again numpy c > code. > > That isn't a good solution. We could do the same override in C, but then > theano work the same when there isn't a c++ compiler. That isn't nice. > > What do you think of changing them to check for __array_priority__ before > doing the comparison? > This looks like an oversight and should be fixed. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] pyhdf packaging
Hi Andreas, This packaging would be much useful! How can I help with this? pyhdf is very important because HDF4-EOS does not open with another packages, only with pyhdf and gdal. best, Arnaldo --- *Arnaldo D'Amaral Pereira Granja Russo* Lab. de Estudos dos Oceanos e Clima Instituto de Oceanografia - FURG 2012/11/6 Andreas Hilboll > Hi, > > I would like to package pyhdf for Ubuntu and make the package publicly > available. Since the license is not totally clear to me (I cannot find any > information in the sources, and the cheeseshop says "public", which > doesn't mean anything to me), I tried to contact the maintainer, Andre > Gosselin, however the email bounces, so I guess he's gone. > > Can anyone point me to how to proceed from here? > > Cheers, Andreas. > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] __array_priority__ don't work for gt, lt, ... operator
Hi, it popped again on the Theano mailing list that this don't work: np.arange(10) <= a_theano_vector. The reason is that __array_priority__ isn't respected for that class of operation. This page explain the problem and give a work around: http://stackoverflow.com/questions/14619449/how-can-i-override-comparisons-between-numpys-ndarray-and-my-type The work around is to make a python function that will decide witch version of the comparator to call and do the call. Then we tell NumPy to use that function instead of its current function with: np.set_numeric_ops(...) But if we do that, when we import theano, we will slow down all normal numpy comparison for the user, as when <= is execute, first there will be numpy c code executed, that will call the python function to decide witch version to do, then if it is 2 numpy ndarray, it will call again numpy c code. That isn't a good solution. We could do the same override in C, but then theano work the same when there isn't a c++ compiler. That isn't nice. What do you think of changing them to check for __array_priority__ before doing the comparison? Frédéric ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
On May 10, 2013 3:18 PM, "Robert Kern" wrote: > Sure, it's probably more readable I am not sure of it. I would have to check the docs to see what it means. The mathematical term is range, but it already has a meaning in Python, so it is not a good way to go, being perhaps valuerange the compromise, but not really clear by itself. In some areas, nevertheless, ptp is the standard notation, as it is in electronics - and maybe that is why it made its way into Numeric. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
On Fri, May 10, 2013 at 2:27 PM, Ralf Gommers wrote: > > > > On Fri, May 10, 2013 at 3:17 PM, Robert Kern wrote: >> >> On Fri, May 10, 2013 at 2:04 PM, Eli Bressert wrote: >> > That's a good point regarding the range function names. But, I think >> > the issue still stands on the readability of the ptp function. >> > Regarding PEP20 it's stated that "readability counts." >> > >> > If you regard what ptp is supposed to replace, array.max() - >> > array.min(), the aforementioned follows the PEP20 better as it is more >> > readable. If valuerange() is not an acceptable name, maybe span()? >> >> Sure, it's probably more readable, and that would be the controlling >> factor if this were a new function. But that's not really the >> operative question here. Are the gains in readability worth the >> nontrivial costs of deprecating and removing the old name? I, for one, >> am generally not in favor of such deprecations. > > > That's not the only option though. I'm -1 on deprecation, but +0 on renaming > and keeping ptp as an alias. The function name is really quite poor. I think it is a matter of context. I don't know the history of that function, but coming from a signal processing background, its meaning was obvious to me. It is a peak to peak is a very common operations when dealing with audio file, for example (that's how most wave display work AFAIK). I am certainly -1 on the deprecation as well, and -0 on alias. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
On 10.05.2013, at 2:51PM, Daniele Nicolodi wrote:
> If you wish to format numpy arrays preceding them with a variable name,
> the following is a possible solution that gives the same formatting as
> in your example:
>
> import numpy as np
> import sys
>
> def format(out, v, name):
>header = "{} = ".format(name)
>out.write(header)
>np.savetxt(out, v, fmt="%d", delimiter=", ",
> newline="\n" + " " * len(header))
>out.write("\n")
>
> IL = np.array([range(5), ] * 5)
> format(sys.stdout, IL, "IL")
That is a quite ingenuous way to use savetxt functionality to write that extra
column!
Only two comments:
Don't call that function "format", as it would mask the 'format' builtin!
In the present version it will only work with a file handle; to print it a to
file you would need
to pass it as fformat(open(fname, 'a'), … or check for that case inside the
function.
Cheers,
Derek
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
On Fri, May 10, 2013 at 3:17 PM, Robert Kern wrote: > On Fri, May 10, 2013 at 2:04 PM, Eli Bressert wrote: > > That's a good point regarding the range function names. But, I think > > the issue still stands on the readability of the ptp function. > > Regarding PEP20 it's stated that "readability counts." > > > > If you regard what ptp is supposed to replace, array.max() - > > array.min(), the aforementioned follows the PEP20 better as it is more > > readable. If valuerange() is not an acceptable name, maybe span()? > > Sure, it's probably more readable, and that would be the controlling > factor if this were a new function. But that's not really the > operative question here. Are the gains in readability worth the > nontrivial costs of deprecating and removing the old name? I, for one, > am generally not in favor of such deprecations. > That's not the only option though. I'm -1 on deprecation, but +0 on renaming and keeping ptp as an alias. The function name is really quite poor. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
On Fri, May 10, 2013 at 2:04 PM, Eli Bressert wrote: > That's a good point regarding the range function names. But, I think > the issue still stands on the readability of the ptp function. > Regarding PEP20 it's stated that "readability counts." > > If you regard what ptp is supposed to replace, array.max() - > array.min(), the aforementioned follows the PEP20 better as it is more > readable. If valuerange() is not an acceptable name, maybe span()? Sure, it's probably more readable, and that would be the controlling factor if this were a new function. But that's not really the operative question here. Are the gains in readability worth the nontrivial costs of deprecating and removing the old name? I, for one, am generally not in favor of such deprecations. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
10.05.2013 16:04, Eli Bressert kirjoitti: > That's a good point regarding the range function names. But, I think > the issue still stands on the readability of the ptp function. > Regarding PEP20 it's stated that "readability counts." I think here it has to be kept in mind that this function has been called ptp() already in Numeric, i.e., for the last 10+ years. This is the first proposal to change it that I know of, so I think keeping the API the same weighs against changing it due to aesthetic reasons. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
That's a good point regarding the range function names. But, I think the issue still stands on the readability of the ptp function. Regarding PEP20 it's stated that "readability counts." If you regard what ptp is supposed to replace, array.max() - array.min(), the aforementioned follows the PEP20 better as it is more readable. If valuerange() is not an acceptable name, maybe span()? -Eli On Fri, May 10, 2013 at 10:44 PM, Pauli Virtanen wrote: > 10.05.2013 08:47, Eli Bressert kirjoitti: > [clip: renaming ptp] >> valuerange() appears to the best most favored one. > > range(), arange(), valuerange() > > I'm not really a big fan of changing the name of this function at this > stage, as it seems to me that whether it's a gain or not is somewhat a > matter of taste. > > -- > Pauli Virtanen > > ___ > 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] printing array in tabular form
On 10/05/2013 13:20, Sudheer Joseph wrote:
> Hi,
> I am trying to learn Python after feeling its utility in coding and
> also reading a bit aboutits potential only, please do not put words
> in to my mouth like below.
I didn't put words in your mouth, I simply quoted emails you sent to the
list and gave my interpretation of what you wrote.
>>> Before denigrating a programming language
>
> If some one has a quick way I would like to learn from them or get a
> referecence
> where the formatting part is described which was
> my intention while posting here. As I have been using fortran I just tried
> to use it to explain my requirement
For references about string formatting in Python:
http://docs.python.org/2/library/string.html#formatstrings
http://docs.python.org/2/library/stdtypes.html#string-formatting
for the numpy array to text formatting:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.savetxt.html
writing a function to do what you ask is trivial. Unfortunately there is
no "format the thing as I wish" function.
If you wish to format numpy arrays preceding them with a variable name,
the following is a possible solution that gives the same formatting as
in your example:
import numpy as np
import sys
def format(out, v, name):
header = "{} = ".format(name)
out.write(header)
np.savetxt(out, v, fmt="%d", delimiter=", ",
newline="\n" + " " * len(header))
out.write("\n")
IL = np.array([range(5), ] * 5)
format(sys.stdout, IL, "IL")
Cheers,
Daniele
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
Sudheer,
This is not really numpy specific. There are many options for output
formatting in python. For the specific question you have, you could do:
print '{0}{1:8.3f}{2:8.3f}{3:8.3f}{4:8.3f}{5:8.3f}'.format(s,x1,x2,x3,x4,x5)
format is a built-in python string method (see python docs). The one
thing that I will agree with you on is that, as far as I know, there is
no repeat count mechanism. There are tricky ways around that, e.g.
fmt = '{0}' + ''.join(['{'+str(i)+':8.3f}' for i in range(1,6)])
print fmt.format(s,x1,x2,x3,x4,x5)
though not as simple as the fortran output statement.
Jon
On Fri, 2013-05-10 at 17:14 +0800, Sudheer Joseph wrote:
> Thank you,
> But I was looking for a format statement likw
> write(*,"(A,5F8.3)")
> with best regards,
> Sudheer
>
> ***
> Sudheer Joseph
> Indian National Centre for Ocean Information Services
> Ministry of Earth Sciences, Govt. of India
> POST BOX NO: 21, IDA Jeedeemetla P.O.
> Via Pragathi Nagar,Kukatpally, Hyderabad; Pin:5000 55
> Tel:+91-40-23886047(O),Fax:+91-40-23895011(O),
> Tel:+91-40-23044600(R),Tel:+91-40-9440832534(Mobile)
> E-mail:sjo.in...@gmail.com;sudheer.jos...@yahoo.com
> Web- http://oppamthadathil.tripod.com
> ***
>
> __
> From: Daπid
> To: Discussion of Numerical Python
>
> Sent: Thursday, 9 May 2013 2:29 PM
> Subject: Re: [Numpy-discussion] printing array in tabular form
>
>
> On 9 May 2013 10:06, Sudheer Joseph
> wrote:
> > However writing a formatted out put looks to be bit tricky
> with python
> > relative to other programing languages.
>
> If performance is not an issue, you could do it by hand, as
> you can
> always do in any programming language:
>
>
> savefile = open('data.txt', 'w')
> N = len(IL)
>
> for start in xrange(N/5):
> if start+5 > N:
> end = N
> else:
> end = start+5
> print >> savefile, IL[start : end]
>
>
> But this is actually more verbose, and once you get into NumPy
> workflow, it is actually simple.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
--
__
Jonathan D. Slavin Harvard-Smithsonian CfA
jsla...@cfa.harvard.edu 60 Garden Street, MS 83
phone: (617) 496-7981 Cambridge, MA 02138-1516
cell: (781) 363-0035 USA
__
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Name change of the ptp() function
10.05.2013 08:47, Eli Bressert kirjoitti: [clip: renaming ptp] > valuerange() appears to the best most favored one. range(), arange(), valuerange() I'm not really a big fan of changing the name of this function at this stage, as it seems to me that whether it's a gain or not is somewhat a matter of taste. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
On 10.05.2013, at 1:20PM, Sudheer Joseph wrote:
> If some one has a quick way I would like to learn from them or get a
> referecence
> where the formatting part is described which was
> my intention while posting here. As I have been using fortran I just tried
> to use it to explain my requirement
>
Admittedly the formatting options in Python can be confusing to beginners,
precisely
since they are much more powerful than for many other languages. As already
pointed
out, formats of the type '(5i5)' are very common to Fortran programs and thus
readily
supported by the language. np.savetxt is just a convenience function to support
a number
of similarly common output types, and it can create csv, tab-separated, or
plenty of other
outputs from a numpy array just out of the box.
But you added to the confusion as you did not make it clear that you were not
just requiring
a plain csv file as your Fortran example would create (and the first version
did not even
have the commas); since this is a rather non-standard form you will just have
to write a
short loop yourself, wether you are using Fortran or Python.
> Infact the program which should read this file
> requires it in specified format which should look like
> IL = 1,2,3,4,5
> 1,2,3,4,5
> 1,2,3,4,5
>
The formats are all documented
http://docs.python.org/2/library/string.html#format-specification-mini-language
one important thing to know is that you can pretty much add (i.e. concatenate)
them like strings:
print(("%6s"+4*"%d,"+"%d\n") % (("IL = ",)+tuple(IL[:5])))
or, perhaps a bit clearer:
fmt = "%6s"+4*"%d,"+"%d\n"
print_t = ("IL = ",)+tuple(IL[:5])
print(fmt % print_t)
The other important bit to keep in mind is that all arguments have to be passed
as tuples.
This should allow you to write a loop to print with a "header" or an empty
header column
for the subsequent lines as you see fit.
Except for the string field which is explicitly formatted "%s" here, this is
mostly equivalent
to the example Henry just posted.
HTH,
Derek
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
On Fri, 2013-05-10 at 17:14 +0800, Sudheer Joseph wrote:
> Thank you,
> But I was looking for a format statement likw
> write(*,"(A,5F8.3)")
> with best regards,
> Sudheer
How about the following:
print('IL = ' + (('%d,' * 5)[:-1] + '\n ') * 5 % tuple(IL))
If instead of a list IL you had some arbitrary 2D array, a, you could do
(with 2 lines for clarity):
print_string = 'a = ' + (('%d,' * a.shape[1])[:-1] + '\n ') *
a.shape[0] % tuple(a.T.ravel())
print(print_string)
I'll leave it as an exercise for you to put that into a file.
hen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
Hi, I am trying to learn Python after feeling its utility in coding and also reading a bit about its potential only, please do not put words in to my mouth like below. >> Before denigrating a programming language If some one has a quick way I would like to learn from them or get a referecence where the formatting part is described which was my intention while posting here. As I have been using fortran I just tried to use it to explain my requirement with best regards, Sduheer From: Daniele Nicolodi To: numpy-discussion@scipy.org >Sent: Friday, 10 May 2013 3:12 PM >Subject: Re: [Numpy-discussion] printing array in tabular form > > >On 10/05/2013 11:14, Sudheer Joseph wrote: > >> However writing a formatted out put looks to be bit tricky with >> python relative to other programing languages. > >... > >> I was looking for a format statement likw write(*,"(A,5F8.3)") > >Before denigrating a programming language I would make sure to have a >basic understanding of it. Every language is going to be tricky if you >approach it with the mindset of Fortran programming. > >The output format you are trying to obtain is easy in forrtran because >it is how the default text output formatting is designed. Of course >obtaining it with a different programming language / numerical library >takes some more effort. But is not tricky at all. > > >Cheers, >Daniele > >___ >NumPy-Discussion mailing list >NumPy-Discussion@scipy.org >http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Scalar output from sub-classed Numpy array
Hi everyone, I am currently trying to write a sub-class of Numpy ndarray, but am running into issues for functions that return scalar results rather than array results. For example, in the following case: import numpy as np class TestClass(np.ndarray): def __new__(cls, input_array, unit=None): return np.asarray(input_array).view(cls) def __array_finalize__(self, obj): if obj is None: return def __array_wrap__(self, out_arr, context=None): return np.ndarray.__array_wrap__(self, out_arr, context) I get: In [4]: a = TestClass([1,2,3]) In [5]: print type(np.dot(a,a)) In [6]: a = TestClass([[1,2],[1,2]]) In [7]: print type(np.dot(a,a)) that is, in the case where the output is a scalar, it doesn't get wrapped, while in the case where the output is an array, it does. Could anyone explain this behavior to me, and most importantly, is there a way around this and have the above example return a wrapped 0-d TestClass array instead of a Numpy int64? Thanks, Tom ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
On 10/05/2013 11:14, Sudheer Joseph wrote: > However writing a formatted out put looks to be bit tricky with > python relative to other programing languages. ... > I was looking for a format statement likw write(*,"(A,5F8.3)") Before denigrating a programming language I would make sure to have a basic understanding of it. Every language is going to be tricky if you approach it with the mindset of Fortran programming. The output format you are trying to obtain is easy in forrtran because it is how the default text output formatting is designed. Of course obtaining it with a different programming language / numerical library takes some more effort. But is not tricky at all. Cheers, Daniele ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing array in tabular form
Thank you,
But I was looking for a format statement likw
write(*,"(A,5F8.3)")
with best regards,
Sudheer
***
Sudheer Joseph
Indian National Centre for Ocean Information Services
Ministry of Earth Sciences, Govt. of India
POST BOX NO: 21, IDA Jeedeemetla P.O.
Via Pragathi Nagar,Kukatpally, Hyderabad; Pin:5000 55
Tel:+91-40-23886047(O),Fax:+91-40-23895011(O),
Tel:+91-40-23044600(R),Tel:+91-40-9440832534(Mobile)
E-mail:sjo.in...@gmail.com;sudheer.jos...@yahoo.com
Web- http://oppamthadathil.tripod.com
***
>
> From: Daπid
>To: Discussion of Numerical Python
>Sent: Thursday, 9 May 2013 2:29 PM
>Subject: Re: [Numpy-discussion] printing array in tabular form
>
>
>On 9 May 2013 10:06, Sudheer Joseph wrote:
>> However writing a formatted out put looks to be bit tricky with python
>> relative to other programing languages.
>
>If performance is not an issue, you could do it by hand, as you can
>always do in any programming language:
>
>
>savefile = open('data.txt', 'w')
>N = len(IL)
>
>for start in xrange(N/5):
> if start+5 > N:
> end = N
> else:
> end = start+5
> print >> savefile, IL[start : end]
>
>
>But this is actually more verbose, and once you get into NumPy
>workflow, it is actually simple.
>___
>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] printing array in tabular form
Thank you for the response, Infact the program which should read this file requires it in specified format which should look like IL = 1,2,3,4,5 1,2,3,4,5 1,2,3,4,5 JL = 1,2,3,4,5 1,2,3,4,5 1,2,3,4,5 so, what I followed from the mail was that np.savetxt can save it in a file and there is no option like write a string and then leave space and then write the array in above fashion. I searched for a while but could not get any solution. with best regards, Sudheer *** Sudheer Joseph Indian National Centre for Ocean Information Services Ministry of Earth Sciences, Govt. of India POST BOX NO: 21, IDA Jeedeemetla P.O. Via Pragathi Nagar,Kukatpally, Hyderabad; Pin:5000 55 Tel:+91-40-23886047(O),Fax:+91-40-23895011(O), Tel:+91-40-23044600(R),Tel:+91-40-9440832534(Mobile) E-mail:sjo.in...@gmail.com;sudheer.jos...@yahoo.com Web- http://oppamthadathil.tripod.com *** > > From: Henry Gomersall >To: Discussion of Numerical Python >Sent: Thursday, 9 May 2013 2:51 PM >Subject: Re: [Numpy-discussion] printing array in tabular form > > >On Thu, 2013-05-09 at 16:06 +0800, Sudheer Joseph wrote: >> If I wanted to print below text in a file (for reading by another >> program), it looks to be not an easy jobHope new developments will >> come and a userfriendly formatted out put method for pyton will >> evolve. > >I don't understand what the problem is - this seems to be trivial to >solve. You gave an example in Fortran; Is the transliteration to Python >not acceptable? > >Is the output format specified by the receiving program? If not, there >are loads of options for creating interoperable text files. > >Henry > >___ >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
