[Numpy-discussion] Difference between np.loadtxt depending on whether you supply a file object or a filename
Dear list,
I observe a difference when I try to load a 2D numpy array from a file
object compared to if I supply a filename viz:
np.version.version
'1.5.1'
f=open('fit_theoretical.txt')
a=np.loadtxt(f)
a.shape
(1000,)
a=np.loadtxt('fit_theoretical.txt')
a.shape
(500, 2)
This strikes me as unexpected, it's not a documented behaviour. Any ideas?
cheers,
Andrew.
--
_
Dr. Andrew Nelson
_
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Difference between np.loadtxt depending on whether you supply a file object or a filename
Hello,
On Mo, 2012-08-20 at 20:55 +1000, Andrew Nelson wrote:
Dear list,
I observe a difference when I try to load a 2D numpy array from a file
object compared to if I supply a filename viz:
np.version.version
'1.5.1'
f=open('fit_theoretical.txt')
a=np.loadtxt(f)
a.shape
(1000,)
a=np.loadtxt('fit_theoretical.txt')
a.shape
(500, 2)
There is actually a difference between the two, because np.loadtxt opens
the file with open(..., 'U'), which means that newlines might be
interpreted differently (because of difference between linux/windows/mac
newlines using \n, \r, etc. So the problem is that newlines are
interpreted wrong for you if you open with just the default mode.
Regards,
Sebastian
This strikes me as unexpected, it's not a documented behaviour. Any
ideas?
cheers,
Andrew.
--
_
Dr. Andrew Nelson
_
___
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] Preventing lossy cast for new float dtypes ?
On Sat, Aug 18, 2012 at 9:28 AM, David Cournapeau courn...@gmail.com wrote: Hi, I have started toying with implementing a quad precision dtype for numpy on supported platforms, using the __float128 + quadmath lib from gcc. I have noticed invalid (and unexpected) downcast to long double in some cases, especially for ufuncs (e.g. when I don't define my own ufunc for a given operation). Looking down in numpy ufunc machinery, I can see that the issue is coming from the assumption that long double is the highest precision possible for a float type, and the only way I can 'fix' this is to define kind to a value != 'f' in my dtype definition (in which case I get an expected invalid cast exception). Is there a way to still avoid those casts while keeping the 'f' kind ? I never looked at that code, but why not change the ufunc to remove the current assumption? I suppose if you ask the questions is that this is not trivial to do? Fred ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] view of recarray issue
On Wed, Jul 25, 2012 at 10:29 AM, Jay Bourque jay.bour...@continuum.io wrote: I'm actively looking at this issue since it was my pull request that broke this (https://github.com/numpy/numpy/pull/350). We definitely don't want to break this functionality for 1.7. The problem is that even though indexing with a subset of fields still returns a copy (for now), it now returns a copy of a view of the original array. When you call copy() on a view, it copies the entire original structured array with the view dtype. A short term fix would be to manually create a proper copy to return similar to what _index_fields() did before my change, but since the idea is to eventually return the view instead of a copy, long term we need a way to do a proper copy of a structured array view that doesn't copy the unwanted fields. This should be fixed for 1.7.0. However, I am going to release beta now, and then see what we can do about this. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A step toward merging odeint and ode
On Thu, Aug 16, 2012 at 12:46 PM, Fabrice Silva si...@lma.cnrs-mrs.frwrote: Le mercredi 15 août 2012 à 20:54 +0200, Ralf Gommers a écrit : I was mixing it up a bit, but yes: the _odepack extension and the C source for it. Not necessary to do that at once I guess, but wrapping the same function twice is once too many. And forgot in my first email: nice PR, looks good to me. OK then, you can found two commits : the first one removes the _odepack extension (and the relative multipack.h, __odepack.h and _odepackmodule.c), replacing it by Python counterparts in the odeint function itself. https://github.com/FabricioS/scipy/commit/02e8a4856f29f4ad438fef2c86a41b266d6a9e6c Thanks. the second one suggests reverting callback arguments convention: ydot = f(y,t,..) to ode's one: ydot = f(t,y,..) This ones would raise backward compatibility issues but align ordering to the convention defined in the LLNL when designing the ODEPACK. https://github.com/FabricioS/scipy/commit/f867f2b8133d3f6ea47d449bd760a77a7c90394e This is probably not worth the cost for existing users imho. It is a backwards compatibility break that doesn't really add anything except for some consistency (right?). Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 64bit infrastructure
On Sun, Aug 19, 2012 at 11:39 AM, Ralf Gommers The problem is that, unlike 32-bit builds, they can't be made with open source compilers on Windows. So unless we're okay with that, Why does it have to be built with open-source compilers? we're building against the python.org python, yes? Which is built with the MS compiler -- so why the insistance on open-source? -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] 64bit infrastructure
I'm actually not sure, why. I think the issue is making sure that the release manager can actually build NumPy without having to buy a particular compiler. But, I would rather have official builds of NumPy for all platforms with a compiler paid for by a NumPy-sponsor than not have them. -Travis On Aug 20, 2012, at 5:28 PM, Chris Barker wrote: On Sun, Aug 19, 2012 at 11:39 AM, Ralf Gommers The problem is that, unlike 32-bit builds, they can't be made with open source compilers on Windows. So unless we're okay with that, Why does it have to be built with open-source compilers? we're building against the python.org python, yes? Which is built with the MS compiler -- so why the insistance on open-source? -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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 64bit infrastructure
On Mon, Aug 20, 2012 at 3:51 PM, Travis Oliphant tra...@continuum.io wrote: I'm actually not sure, why. I think the issue is making sure that the release manager can actually build NumPy without having to buy a particular compiler. The MS Express editions, while not open source, are free-to-use, and work fine. Not sure what what do about Fortran, though, but that's a scipy, not a numpy issue, yes? -Chris But, I would rather have official builds of NumPy for all platforms with a compiler paid for by a NumPy-sponsor than not have them. -Travis On Aug 20, 2012, at 5:28 PM, Chris Barker wrote: On Sun, Aug 19, 2012 at 11:39 AM, Ralf Gommers The problem is that, unlike 32-bit builds, they can't be made with open source compilers on Windows. So unless we're okay with that, Why does it have to be built with open-source compilers? we're building against the python.org python, yes? Which is built with the MS compiler -- so why the insistance on open-source? -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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- 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
