[Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

Neil Girdhar mistersheik at gmail.com
Thu Apr 16 18:19:50 EDT 2015


Actually, looking at the docs, numpy.outer is *only* defined for 1-d
vectors.  Should anyone who used it with multi-dimensional arrays have an
expectation that it will keep working in the same way?

On Thu, Apr 16, 2015 at 10:53 AM, Neil Girdhar <mistersheik at gmail.com>
wrote:

> Would it be possible to deprecate np.outer's usage on non one-dimensional
> vectors for a few versions, and then reintroduce it with definition
> np.outer == np.multiply.outer?
>
> On Wed, Apr 15, 2015 at 8:02 PM, <josef.pktd at gmail.com> wrote:
>
>> On Wed, Apr 15, 2015 at 6:40 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> > On Wed, Apr 15, 2015 at 6:08 PM,  <josef.pktd at gmail.com> wrote:
>> >> On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar <mistersheik at gmail.com>
>> wrote:
>> >>> Does it work for you to set
>> >>>
>> >>> outer = np.multiply.outer
>> >>>
>> >>> ?
>> >>>
>> >>> It's actually faster on my machine.
>> >>
>> >> I assume it does because np.corrcoeff uses it, and it's the same type
>> >> of use cases.
>> >> However, I'm not using it very often (I prefer broadcasting), but I've
>> >> seen it often enough when reviewing code.
>> >>
>> >> This is mainly to point out that it could be a popular function (that
>> >> maybe shouldn't be deprecated)
>> >>
>> >> https://github.com/search?utf8=%E2%9C%93&q=np.outer
>> >> 416914
>> >
>> > For future reference, that's not the number -- you have to click
>> > through to "Code" and then look at a single-language result to get
>> > anything remotely meaningful. In this case b/c they're different by an
>> > order of magnitude, and in general because sometimes the "top line"
>> > number is completely made up (like it has no relation to the
>> > per-language numbers on the left and then changes around randomly if
>> > you simply reload the page).
>> >
>> > (So 29,397 is what you want in this case.)
>> >
>> > Also that count then tends to have tons of duplicates (e.g. b/c there
>> > are hundreds of copies of numpy itself on github), so you need a big
>> > grain of salt when looking at the absolute number, but it can be
>> > useful, esp. for relative comparisons.
>>
>> My mistake, rushing too much.
>> github show only 25 code references in numpy itself.
>>
>> in quotes, python only  (namespace conscious packages on github)
>> (I think github counts modules not instances)
>>
>> "np.cumsum" 11,022
>> "np.cumprod" 1,290
>> "np.outer" 6,838
>>
>> statsmodels
>> "np.cumsum" 21
>> "np.cumprod"  2
>> "np.outer" 15
>>
>> Josef
>>
>> >
>> > -n
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150416/157a67e5/attachment.html>


More information about the NumPy-Discussion mailing list