Re: [Numpy-discussion] Recognizing a cycle in a vector
Oops, that leakage document is incomplete. Guess I should finish it up. On Thu, Nov 26, 2015 at 7:18 AM, Manolo MartÃnez wrote: > Dear all, > > Suppose that I have a vector with the numerical solution of a > differential equation -- more concretely, I am working with evolutionary > game theory models, and the solutions are frequencies of types in a > population that follows the replicator dynamics; but this is probably > irrelevant. > > Sometimes these solutions are cyclical, yet I sample at points which do > not correspond with the period of the cycle, so that np.allclose() > cannot be directly applied. > > Is there any way to check for cycles in this situation? > > Thanks for any advice, > Manolo > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Daniel Sank ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Change default order to Fortran order
; re-compile" is probably a bad idea. The suggestions about using
> "fortran_zeros = partial(np.zeros(order='F'))" is probably the best way so
> far, in my opinion, and I am going to give it a try.
>
> Again, thank you all for replying.
>
> Kang
>
> On 08/02/15, *Nathaniel Smith * wrote:
>
> On Aug 2, 2015 7:30 AM, "Sturla Molden" wrote:
> >
> > On 02/08/15 15:55, Kang Wang wrote:
> >
> > > Can anyone provide any insight/help?
> >
> > There is no "default order". There was before, but now all operators
> > control the order of their return arrays from the order of their input
> > array.
>
> This is... overoptimistic. I would not rely on this in code that I wrote.
>
> It's true that many numpy operations do preserve the input order. But
> there are also many operations that don't. And which are which often
> changes between releases. (Not on purpose usually, but it's an easy bug to
> introduce. And sometimes it is done intentionally, e.g. to make functions
> faster. It sucks to have to make a function slower for everyone because
> someone somewhere is depending on memory layout default details.) And there
> are operations where it's not even clear what preserving order means
> (indexing a C array with a Fortran array, add(C, fortran), ...), and even
> lots of operations that intrinsically break contiguity/ordering (transpose,
> diagonal, slicing, swapaxes, ...), so you will end up with mixed orderings
> one way or another in any non-trivial program.
>
> Instead, it's better to explicitly specify order= just at the places where
> you care. That way your code is *locally* correct (you can check it will
> work by just reading the one function). The alternative is to try and
> enforce a *global* property on your program ("everyone everywhere is very
> careful to only use contiguity-preserving operations", where "everyone"
> includes third party libraries like numpy and others). In software design,
> local invariants invariants are always better than global invariants -- the
> most well known example is local variables versus global variables, but the
> principle is much broader.
>
> -n
>
> --
> *Kang Wang, Ph.D.*
> Highland Ave., Room 1113
> Madison, WI 53705-2275
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
--
Daniel Sank
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Change default order to Fortran order
Could you please explain why you need 'F' ordering? It's pretty unlikely that you actually care about the internal memory layout, and you'll get better advice if you explain why you think you do care. > My first Python project is to somehow modify NumPy source > code such that everything is Fortran column-major by default. This is the road to pain. You'll have to maintain your own fork and will probably inject bugs when trying to rewrite. Nobody will want to help fix them because everyone else just uses numpy as is. > And to eliminate the order kwarg, use functools.partial to patch the > zeros function (or any others, as needed): Instead of monkey patching, why not just define your own shims: fortran_zeros = partial(np.zeros(order='F')) Seems like this would lead to a lot less confusion (although until you tell us why you care about the in-memory layout I don't know the point of doing this at all). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal
Sturia, > Change the name of keyword arguments? > This would be evil. Yes, I see this now. It is really a shame these were defined as keyword arguments. I've shown the docstring to a few people and so far they all agree that it is unnecessarily convoluted. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Would like to patch docstring for numpy.random.normal
Dear numpy users,
I would like to clarify the docstring for numpy.random.normal. I submitted
a patch but it was rejected because it breaks the tests. Unfortunately, the
development workflow page does not explain how to run the tests (in fact it
doesn't mention them at all). I am therefore writing to discuss my proposed
change and find out how to run the tests so that I can make it compatible
with the existing code.
The current form of the docstring for numpy.random.normal is as follows:
"""
normal(loc=0.0, scale=1.0, size=None)
Parameters
--
loc : float
Mean ("centre") of the distribution.
scale : float
Standard deviation (spread or "width") of the distribution.
size : tuple of ints
Output shape. If the given shape is, e.g., ``(m, n, k)``, then
``m * n * k`` samples are drawn.
Notes
-
The probability density for the Gaussian distribution is
.. math:: p(x) = \frac{1}{\sqrt{ 2 \pi \sigma^2 }}
e^{ - \frac{ (x - \mu)^2 } {2 \sigma^2} },
where :math:`\mu` is the mean and :math:`\sigma` the standard deviation.
The square of the standard deviation, :math:`\sigma^2`, is called the
variance.
"""
It seems unnecessarily convoluted to name the input arguments "loc" and
"scale", then immediately define them as the "mean" and "standard
deviation" in the Parameters section, and then again rename them as "mu"
and "sigma" in the written formula. I propose to simply change the argument
names to "mean" and "sigma" to improve consistency.
I tried fixing this via a pull request [1] but it was closed because my
change broke the tests. Unfortunately, the development workflow section of
the web page doesn't explain how to run the tests (in fact it doesn't even
mention them).
How can I make the proposed change without breaking the tests, or
equivalently how do I find out how to run the tests myself so I can find an
acceptable way of making the change on my own?
[1] https://github.com/numpy/numpy/pull/5607#issuecomment-76114282
--
Daniel Sank
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
