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 <man...@austrohungaro.com> 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
Smith * n...@pobox.com wrote: On Aug 2, 2015 7:30 AM, Sturla Molden sturla.mol...@gmail.com 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)
snip
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.
snip
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
