Re: [Numpy-discussion] Feedback on new argument positions for ma.dot and MaskedArray.dot
On Mon, Nov 9, 2015 at 4:43 PM, Charles R Harris wrote: > > > On Sun, Nov 8, 2015 at 8:43 PM, Nathaniel Smith wrote: >> >> On Nov 8, 2015 6:00 PM, "Eric Firing" wrote: >> > >> > I also prefer that there be a single convention: either the "out" kwarg >> > is the end of the every signature, or it is the first kwarg in every >> > signature. It's a very special and unusual kwarg, so it should have a >> > standard location. >> >> For all ufuncs, out arguments come first immediately after in arguments, >> so +1 for doing that for consistency. > > > Agree that that is what to shoot for. The particular problem with `ma.dot` > is that it already has the `strict` argument where the new `out` argument > should go. I propose the following steps. > > 1. For backward compatibility, start by adding new arguments to the end > 2. Later raise FutureWarning on positional arguments that are out of place > 3. Then make all but early arguments keyword only > > Once we have keyword only for a while, it would be possible to add some > arguments back as positional arguments, but it might be best to keep them as > keyword only as suggested above. > > For the current PR, this means that the dot method will have positional > arguments in a different order than ma.dot. Alternatively, out could be made > keyword only in both, although that would require fixing up some tests. > There is really no magical solution that avoids all difficulties that I can > see. > > Unless a consensus develops otherwise, I will pursue step 1. and go for a > 1.10.2rc tomorrow. If we're adding it in a funny place to ma.dot now (the end of the arglist) with the plan of changing it later, then why not make it kwarg-only in ma.dot now to start with? If this turns out to be annoying somehow then go ahead with whatever as far I'm concerned -- I don't want to hold up 1.10.2 by trying to micro-optimize the transition path for an obscure corner of np.ma :-). -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Feedback on new argument positions for ma.dot and MaskedArray.dot
On Sun, Nov 8, 2015 at 8:43 PM, Nathaniel Smith wrote: > On Nov 8, 2015 6:00 PM, "Eric Firing" wrote: > > > > I also prefer that there be a single convention: either the "out" kwarg > is the end of the every signature, or it is the first kwarg in every > signature. It's a very special and unusual kwarg, so it should have a > standard location. > > For all ufuncs, out arguments come first immediately after in arguments, > so +1 for doing that for consistency. > Agree that that is what to shoot for. The particular problem with `ma.dot` is that it already has the `strict` argument where the new `out` argument should go. I propose the following steps. 1. For backward compatibility, start by adding new arguments to the end 2. Later raise FutureWarning on positional arguments that are out of place 3. Then make all but early arguments keyword only Once we have keyword only for a while, it would be possible to add some arguments back as positional arguments, but it might be best to keep them as keyword only as suggested above. For the current PR, this means that the dot method will have positional arguments in a different order than ma.dot. Alternatively, out could be made keyword only in both, although that would require fixing up some tests. There is really no magical solution that avoids all difficulties that I can see. Unless a consensus develops otherwise, I will pursue step 1. and go for a 1.10.2rc tomorrow. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question about structure arrays
On Sat, Nov 7, 2015 at 1:18 PM, aerojockey wrote: > Inside a > low-level loop, I create a structure array, populate it Python, then turn > it > over to some handwritten C code for processing. can you do that inside bit of the low-level loop in C (or cython?) you often want to put the guts of your loop in C anyway... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(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 https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt and usecols
On Mon, Nov 9, 2015 at 7:42 PM, Benjamin Root wrote:
> My personal rule for flexible inputs like that is that it should be
> encouraged so long as it does not introduce ambiguity. Furthermore,
> Allowing a scalar as an input doesn't add a congitive disconnect on the
> user on how to specify multiple columns. Therefore, I'd give this a +1.
>
> On Mon, Nov 9, 2015 at 4:15 AM, Irvin Probst <
> irvin.pro...@ensta-bretagne.fr> wrote:
>
>> Hi,
>> I've recently seen many students, coming from Matlab, struggling against
>> the usecols argument of loadtxt. Most of them tried something like:
>> loadtxt("foo.bar", usecols=2) or the ones with better documentation
>> reading skills tried loadtxt("foo.bar", usecols=(2)) but none of them
>> understood they had to write usecols=[2] or usecols=(2,).
>>
>> Is there a policy in numpy stating that this kind of arguments must be
>> sequences ?
>
>
There isn't. In many/most cases it's array_like, which means scalar,
sequence or array.
> I think that being able to an int or a sequence when a single column is
>> needed would make this function a bit more user friendly for beginners. I
>> would gladly submit a PR if noone disagrees.
>>
>
+1
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt and usecols
My personal rule for flexible inputs like that is that it should be
encouraged so long as it does not introduce ambiguity. Furthermore,
Allowing a scalar as an input doesn't add a congitive disconnect on the
user on how to specify multiple columns. Therefore, I'd give this a +1.
On Mon, Nov 9, 2015 at 4:15 AM, Irvin Probst wrote:
> Hi,
> I've recently seen many students, coming from Matlab, struggling against
> the usecols argument of loadtxt. Most of them tried something like:
> loadtxt("foo.bar", usecols=2) or the ones with better documentation
> reading skills tried loadtxt("foo.bar", usecols=(2)) but none of them
> understood they had to write usecols=[2] or usecols=(2,).
>
> Is there a policy in numpy stating that this kind of arguments must be
> sequences ? I think that being able to an int or a sequence when a single
> column is needed would make this function a bit more user friendly for
> beginners. I would gladly submit a PR if noone disagrees.
>
> Regards.
>
> --
> Irvin
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Question about structure arrays
On Nov 7, 2015 2:58 PM, "aerojockey" wrote: > > Hello, > > Recently I made some changes to a program I'm working on, and found that the > changes made it four times slower than before. After some digging, I found > out that one of the new costs was that I added structure arrays. Inside a > low-level loop, I create a structure array, populate it Python, then turn it > over to some handwritten C code for processing. It turned out that, when > passed a structure array as a dtype, numpy has to parse the dtype, which > included calls to re.match and eval. > > Now, this is not a big deal for me to work around by using ordinary slicing > and such, and also I can improve things by reusing arrays. Since this is > inner loop stuff, sacrificing readability for speed is an appropriate > tradeoff. > > Nevertheless, I was curious if there was a way (or any plans for there to be > a way) to compile a struture array dtype. I realize it's not the > bread-and-butter of numpy, but it turned out to be a very convenient feature > for my use case (populating an array of structures to pass off to C). I was just looking into structured arrays. In case it is relevant: Are you using certain 1.10? They are apparently a LOT slower than 1.9.3, an issue which will be fixed in a future version. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Failed numpy.test() with numpy-1.10.1 on RHEL 6
This fails because numpy uses the function `cacosh` from the libm and on RHEL6 this function has a bug. As long as you don't care about getting the sign right at the branch cut in this function, then it's harmless. If you do care, the easiest solution will be to install something like anaconda that does not link against the relatively old libm that RHEL6 ships. On Mon, Nov 9, 2015 at 1:11 AM, Lintula wrote: > Hello, > > I'm setting up numpy 1.10.1 on RHEL6 (python 2.6.6, atlas-3.8.4, > lapack-3.2.1, gcc-4.4.7), and this test fails for me. I notice that > someone else has had the same at > https://github.com/numpy/numpy/issues/6063 in July. > > Is this harmless or is it of concern? > > > == > FAIL: test_umath.TestComplexFunctions.test_branch_cuts( 'arccosh'>, [-1, 0.5], [1j, 1j], 1, -1, True) > -- > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/nose/case.py", line 182, in > runTest > self.test(*self.arg) > File > "/usr/lib64/python2.6/site-packages/numpy/core/tests/test_umath.py", > line 1748, in _check_branch_cut > assert_(np.all(np.absolute(y0.imag - yp.imag) < atol), (y0, yp)) > File "/usr/lib64/python2.6/site-packages/numpy/testing/utils.py", line > 53, in assert_ > raise AssertionError(smsg) > AssertionError: (array([ 0.e+00+3.14159265j, > 1.11022302e-16-1.04719755j]), array([ 4.71216091e-07+3.14159218j, > 1.28119737e-13+1.04719755j])) > > -- > Ran 5955 tests in 64.284s > > FAILED (KNOWNFAIL=3, SKIP=2, failures=1) > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] loadtxt and usecols
Hi,
I've recently seen many students, coming from Matlab, struggling against
the usecols argument of loadtxt. Most of them tried something like:
loadtxt("foo.bar", usecols=2) or the ones with better documentation
reading skills tried loadtxt("foo.bar", usecols=(2)) but none of them
understood they had to write usecols=[2] or usecols=(2,).
Is there a policy in numpy stating that this kind of arguments must be
sequences ? I think that being able to an int or a sequence when a
single column is needed would make this function a bit more user
friendly for beginners. I would gladly submit a PR if noone disagrees.
Regards.
--
Irvin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
