[Numpy-discussion] nditer when using operands with mixed C and F order

[Matti Picus]

  
  
 I am trying to
  understand how nditer(ops, order='K') handles C and F order. In
  the documentation it states
  "‘K’ means as close to the order the array elements appear in
  memory as possible"
  but I seem to be getting inconsistent results (numpy 1.9):
  
      >>> a = np.array([[1, 2], [3, 4]], order="C")
      >>> b = np.array([[1, 2], [3, 4]], order="F")
      >>> [v for v in np.nditer([a], order='K')]
  
      [array(1), array(2), array(3), array(4)]
  
      >>> [v for v in np.nditer([b], order='K')]
      [array(1), array(3), array(2), array(4)]
      >>> [v for v in np.nditer([a,b], order='K')]
      [(array(1), array(1)), (array(2), array(2)), (array(3),
  array(3)), (array(4), array(4))]
  
  The result for np.nditer([b], order='K') seems to be wrong. Could
  someone confirm this is an issue or explain what is going on?
  
  Matti

  

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] nditer when using operands with mixed C and F order

[Mark Wiebe]

On Wed, Oct 7, 2015 at 12:59 PM, Matti Picus  wrote:

> I am trying to understand how nditer(ops, order='K') handles C and F
> order. In the documentation it states
> "‘K’ means as close to the order the array elements appear in memory as
> possible"
> but I seem to be getting inconsistent results (numpy 1.9):
>
> >>> a = np.array([[1, 2], [3, 4]], order="C")
> >>> b = np.array([[1, 2], [3, 4]], order="F")
> >>> [v for v in np.nditer([a], order='K')]
>
> [array(1), array(2), array(3), array(4)]
>
> >>> [v for v in np.nditer([b], order='K')]
> [array(1), array(3), array(2), array(4)]
> >>> [v for v in np.nditer([a,b], order='K')]
> [(array(1), array(1)), (array(2), array(2)), (array(3), array(3)),
> (array(4), array(4))]
>
> The result for np.nditer([b], order='K') seems to be wrong. Could someone
> confirm this is an issue or explain what is going on?
>

In this example, elements of a and b are being matched up according to
their array indices, and then the iteration order is chosen according to
the 'K' rule. The array a suggests to go in 'C' order, while the array b
suggests to go in 'F' order. When there's a conflict/ambiguity such as
this, it's resolved in the direction of 'C' order. If it were to go through
a and b in each individual 'K' order, the elements wouldn't be paired
up/broadcast together, which is the whole point of iterating over multiple
arrays via the nditer.

-Mark

>
>
> Matti
>
> ___
> 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] NumFOCUS fiscal sponsorship agreement

[Nathaniel Smith]

Hi all,

Now that the governance document is in place, we need to get our legal
ducks in a row by signing a fiscal sponsorship agreement with
NumFOCUS.

The basic idea here is that there are times when you really need some
kind of corporation to represent the project -- the legal system for
better or worse does not understand "a bunch of folks on a mailing
list" as a legal entity capable of accepting donations, or holding
funds or other assets like domain names. The obvious solution is to
incorporate a company to represent the project -- but incorporating a
company involves lots of super-annoying paperwork. (Like, *super*
annoying.) So a standard trick is that a single non-profit corporation
acts as an umbrella organization providing these services to multiple
projects at once, and this is called "fiscal sponsorship". You can
read more about it here:
https://en.wikipedia.org/wiki/Fiscal_sponsorship

NumFOCUS's standard comprehensive FSA agreement can be seen here:


https://docs.google.com/document/d/11YqMX9UrgfCSgiQEUzmOFyg6Ku-vED6gMxhO6J9lCgg/edit?usp=sharing

and we have the option of negotiating changes if there's anything we don't like.

They also have a FAQ:

https://docs.google.com/document/d/1zdXp07dLvkbqBrDsw96P6mkqxnWzKJuM-1f4408I6Qs/edit?usp=sharing

I've read through the document and didn't see anything that bothered
me, except that I'm not quite sure how to make the split between the
steering council and numfocus subcommittee that we have in our
governance model sync up with their language about the "leadership
body", and in particular the language in section 10 about simple
majority votes. So I've queried them about that already.

In the mean time, I'd encourage anyone with an interest to look it
over and speak up if you see anything that you think should be changed
before we sign.

Cheers,
-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] Numpy 1.10.0 release

[Julian Taylor]

On 10/06/2015 01:45 PM, Neal Becker wrote:

Are extra_compile_args actually used in all compile steps?


extra_compile_args is not used by numpy, its to support some third party 
use case I never understood.
As the typical site.cfg used by numpy only contains binaries that are 
never compiled by numpy itself it should have no effect on anything.



CFLAGS='-march=native -O3' python setup.py build

Does seem to use my CFLAGS, as it always did on previous numpy versions.



still seems to work for me, though the preferred variable is OPT= as 
CFLAGS will contain a bunch of other stuff related to building python 
extensions themselves (e.g. -fno-strict-aliasing)


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.10.0 release

[Julian Taylor]

On 10/06/2015 02:08 PM, Daπid wrote:

I don't get any failures on Fedora 22. I have installed it with pip,
setting my CFLAGS to "-march=core-avx-i -O2 -pipe -mtune=native" and
linking against openblas.

With the new Numpy, Scipy full suite shows two errors, I am sorry I
didn't think of running that in the RC phase:

> ==
> FAIL: test_weighting (test_stats.TestHistogram)

this is a known issue see scipy/scipy/#5148
It can most likely be ignored as the scipy test is too sensitive to 
floating point rounding.



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion