. On the other hand,
I don't see obvious missing names -- the policy has been to give
commit access for people with sustained code contributions, see also
git shortlog -a -c -s --since=now-2year | sort -n
--
Pauli Virtanen
___
NumPy-Discussion mailing
],
[3, 1]] ])
np.linalg.det(a)
array([-2., -3., -8.])
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
it a shot and see how it works.
protocol=2 so it doesn't needlessly ascii-quote the data.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
seem to remember that also the quantities package had some
issues with operations involving ndarrays, to which being able to
override this could be a solution.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
in a
different order than previously. Both results are IMHO correct, so I'm
not sure there is anything to fix here. Third-party code relying on a
certain outcome of rounding error is likely incorrect anyway.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
:
http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
for that. I don't think there is any
other solution to the spam with the Moin wiki at present.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
pages? They seem to be hurting the
site's performance quite a lot --- for instance,
http://scipy.org/Cookbook doesn't load currently.
A good assumption is probably that new pages created in the past couple
of weeks are all spam...
--
Pauli Virtanen
05.05.2013 15:42, Robert Kern kirjoitti:
[clip: spam]
Manually. I have a whitelist of known-good pages that helps narrow it
down. I'll take care of it in a few hours.
Thanks a lot!
Cheers,
Pauli
___
NumPy-Discussion mailing list
/linux.html#generic-instructions
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
if the integer is too big to
fit into int64 (or maybe into int32 on 32-bit systems). The behavior is
the same as in Numpy 1.2.0, so it has perhaps been like this forever.
So most likely, the code in Scipy was correct only for 32-bit systems.
--
Pauli Virtanen
of taste.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
called ptp() already in Numeric, i.e., for the last 10+ years. This is
the first proposal to change it that I know of, so I think keeping the
API the same weighs against changing it due to aesthetic reasons.
--
Pauli Virtanen
___
NumPy-Discussion
consistent on these platforms.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
08.06.2013 02:48, Nathaniel Smith kirjoitti:
[clip]
...yeah weird. My gut reaction is that it's a bug. Addition on bools
should either be an error, undefined but doable via an implicit upcast
to int (analogous to calling np.sin on an int array triggering an upcast
to float), or xor (i.e.,
also break 3rd party code.
As far as I see, the options are:
1. Add -ff2c (or whatever is the correct flag for Accelerate)
to the Fortran flags on OSX.
2. Drop support for Veclib/Accelerate.
I think Accelerate was also incompatible with multiprocessing,
which would weigh for option 2.
--
Pauli
LDFLAGS=-ldotwrp -lblas
works? This makes things a bit more complicated to the builder, an
issue that can be solved with documentation, and keeping that up to
date is easier than hardcoding stuff into numpy.distutils.
--
Pauli Virtanen
___
NumPy
12.06.2013 00:29, Ralf Gommers kirjoitti:
[clip]
AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS,
so doing something like
export FOPT=-ff2c
[clip]
Sounds like a good idea. Would still make sense to move Accelerate down
in the list of preferred libs, so
Dave Hirschfeld dave.hirschfeld at gmail.com writes:
The example below demonstrates the fact that the datetime64
constructor ignores the dtype argument if passed in. Is this
conscious design decision or a bug/oversight?
Bug. There's probably no dtype argument, but the constructor
just ignores
the appropriate t-value if we
give number of samples ?
The scipy-user mailing list is more appropriate for this question.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
this:
https://github.com/pv/numpy/tree/fortran-abicheck
Interested parties on OSX should check whether they manage to build this
version of Numpy with Accelerate when this is enabled, and whether
Scipy's ARPACK tests still fail when building against this version of Numpy.
--
Pauli Virtanen
13.07.2013 20:46, Nathaniel Smith kirjoitti:
[clip]
Why not just write
def H(a):
return a.conj().T
In long expressions, this puts H to the wrong side.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
in the
source code has been changed.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
20.07.2013 01:38, Nathaniel Smith kirjoitti:
The biggest ~recent change in master's linalg was the switch to gufunc
back ends - you might want to check for that event in your commit log.
That was in mid-April, which doesn't match with the location of the
uptick in the graph.
Pauli
in a way
that leaves leeway for changing the implementation to a view later on.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
is needed.
It is much more rarely used than `ravel()` and `flatten()`, as can be
verified by grepping e.g. the matplotlib source code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
which would be confusing.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the `__array__`
attribute of the flatiter object. If it's faster than .ravel(), that is
surprising.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
How about splitting doc/sphinxext out from the main Numpy repository to
a separate `numpydoc` repo under Numpy project?
It's a separate Python package, after all. Moreover, this would make it
easier to use it as a git submodule (e.g. in Scipy). Moreover, its
release cycle is not in any
24.07.2013 18:33, Pauli Virtanen kirjoitti:
How about splitting doc/sphinxext out from the main Numpy repository to
a separate `numpydoc` repo under Numpy project?
Done:
https://github.com/numpy/numpydoc
https://github.com/numpy/numpy/pull/3547
https://github.com/scipy/scipy/pull/2657
installed), etc.
Or:
python runtests.py
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
working on (e.g. 1.7.1 rather
than 1.8dev).
No, runtests builds the code and sets PYTHONPATH accordingly.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
? Is there a 'numpy' directory below the reported directory after
running runtests.py?
(ii)
Start a fresh Python interpreter and run
import sys
print sys.modules.get('numpy')
(Note: no import numpy above). Does it print `None` or something else?
--
Pauli Virtanen
= get_python_lib(prefix=dst_dir, plat_specific=True)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
that they could cause any breakage.
Getting it in now would have the advantage that we could also manage
to squeeze in the corresponding user-side part inside scipy.sparse for
Scipy 0.13.0.
- --
Pauli Virtanen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux
schedule to get this in 0.13.0, as Ralf is planning to branch that on
next Tuesday.
The Numpy interactions may reveal some surprises, so I'd prefer this
to cook for a while in the dev version.
The best route is probably to postpone until 1.9 and 0.14.0, I think.
- --
Pauli Virtanen
-BEGIN PGP
24.08.2013 21:25, Warren Weckesser kirjoitti:
[clip]
Now the question is: why does `np.dot` mask the overflow warning?
That probably depends on whatever BLAS is used. I wouldn't be
surprised if it's BLAS that swallows the floating point invalid flags.
--
Pauli Virtanen
this is no
longer the case?
I guess you are trying to link with MKL? In that case, I would rather
propose restoring the previous MKL wrappers (with trivial extensions
for the missing w* symbols).
- --
Pauli Virtanen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux
).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
on this behavior (I hope not).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
:
return NotImplemented
Of course, it's written in C so it's a bit more painful to write this.
I think this will have little performance impact, since the check would
be only a NULL check in the inplace op methods + subsequent handling. I
can take a look at some point at this...
--
Pauli
of
maintenance work. 65 people contributed to this release.
Congrats!
Only a tiny little thing: the docs still point to 0.12.0:
http://docs.scipy.org/doc/scipy/reference/
Should be fixed now.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
the documentation has a separate license; also BSD.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
21.10.2013 22:36, Mounir E. Bsaibes kirjoitti:
On Mon, 2013-10-21 at 21:23 +0300, Pauli Virtanen wrote:
21.10.2013 21:00, Charles R Harris kirjoitti:
[clip]
There is no agreement needed, but all numpy is released under the
simplified BSD license and any contributions need to be compatible
.
The links are there: http://www.scipy.org/install.html#custom
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
on Windows and OSX
is a good idea, and needs to be emphasized over needs of advanced users,
who should have enough patience to read the bottom of the page.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
of the scipy
library part from the entry page. This would likely make things much
clearer.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
23.10.2013 21:06, Pauli Virtanen kirjoitti:
23.10.2013 17:51, Chris Barker - NOAA Federal kirjoitti:
[clip]
But it sounds like the real problem is with the surrounding
pages--that's the page you find when you try to figure out how to get
numpy--if that page is about the stack, it should
to an explanation that says that the scipy
exists and what it is. A newcomer may possibly read that.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
23.10.2013 23:24, Pauli Virtanen kirjoitti:
23.10.2013 22:50, Chris Barker kirjoitti:
[clip]
This makes me think: apparently there is an offical scipy stack --
and I even found it with a quick google:
http://www.scipy.org/stackspec.html
If you click More information... on the front page
29.11.2013 22:15, Dan Goodman kirjoitti:
Is it possible to get access to versions of ufuncs like sin and cos but
compiled with the -ffast-math compiler switch?
You can recompile Numpy with -ffast-math in OPT environment variable.
Caveat emptor.
--
Pauli Virtanen
equivalent.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
that the rename 'S' - 'B' was not done in the Python 3 port,
because 'B' already denotes uint8,
np.array([1], dtype='B')
array([1], dtype=uint8)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
. use on Py2.
Adding new data types in Numpy codebase takes some work, but it's
possible to do.
There's also an issue (as noted in the Github ticket) that
array([u'foo'], dtype=bytes) encodes silently via the ASCII codec.
This is probably not how it should be.
--
Pauli Virtanen
OpenBLAS with Numpy source releases ---
arguments against:
OpenBLAS is big, and still rapidly moving. Moreover, bundling it with
Numpy does not really make it any easier to build.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
not.
With some hyberbole added, one could say that from the developer point
of view, np.matrix is doing and has already done evil just by existing,
by messing up the unstated rules of ndarray semantics in Python.
--
Pauli Virtanen
___
NumPy-Discussion
10.02.2014 23:13, Alan G Isaac kirjoitti:
On 2/10/2014 4:03 PM, Pauli Virtanen wrote:
What sparked this discussion (on Github) is that it is not
possible to write duck-typed code that works correctly for:
Do you mean one must start out with an 'asarray'? Or more than
that?
Starting
10.02.2014 23:40, Alan G Isaac kirjoitti:
On 2/10/2014 4:28 PM, Pauli Virtanen wrote:
Starting with asarray won't work: sparse matrices are not
subclasses of ndarray.
I was focused on the `matrix` object. For this object, an initial
asarray is all it takes to use array code
new users
to use the interface with the ndarray convention.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
11.02.2014 00:31, Alan G Isaac kirjoitti:
On 2/10/2014 5:11 PM, Pauli Virtanen wrote:
The existence of np.matrix messes up the general agreement on ndarray
semantics in Python. The meaning of very basic code such as
A * B
A.sum(0)
A[0]
where A and B are NxN matrices of some
np.matrix would point the way.
(I also suspect that this argument has been raised before, but as long
as there's no canonical write-up...)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
as your suggestion is to add
a coercion function in the vein of scipy.sparse.aslinearoperator.
It could deal with known-failure cases (np.matrix, scipy.sparse matrices)
and for the rest just assume the object satisfies the ndarray API
and pass them through.
--
Pauli Virtanen
Sturla Molden sturla.molden at gmail.com writes:
Pauli Virtanen pav at iki.fi wrote:
It is not a good thing that there is no well defined
domain specific language for matrix algebra in Python.
Perhaps Python should get some new operators?
It might still be possible to advocate
interface, for example
as in
https://github.com/cvxgrp/cvxpy/tree/master/cvxpy/interface/numpy_interface.
Here's some more data:
http://nullege.com/codes/search?cq=numpy.matrix
http://nullege.com/codes/search?cq=numpy.array
--
Pauli Virtanen
___
NumPy
evaluate them in most parameter regimes, but AFAIK
both require arbitrary-precision methods for this.)
So I think there would be a large number of possible things to do
here, and help would be appreciated.
- --
Pauli Virtanen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux
Hi,
08.02.2014 06:16, Stéfan van der Walt kirjoitti:
On 8 Feb 2014 04:51, Ralf Gommers ralf.gomm...@gmail.com wrote:
Members of the dipy team would also be interested.
That's specifically for the spherical harmonics topic right?
Right. Spherical harmonics are used as bases in many of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
13.02.2014 20:59, josef.p...@gmail.com kirjoitti:
[clip]
I assume numpy/scipy will participate under the PSF umbrella. So
this deadline is for the PSF. However, Terri, the organizer for the
PSF, asked for links to Ideas pages to be able to show
in scipy.special could bring better evaluation
performance even if the algorithm is the same.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.
This would also solve the issue of how to add attachments
to bug reports in one way.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
be maintained by normal PR
processes just fine.
Yes. However, using a separate repository might make this more
easy to deal with. This also does not have the running arbitrary
code problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
that should definitely be discussed.
But I think this is a problem mainly interesting for Numpy devs, and not
for CPython devs.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
23.02.2014 11:30, Ralf Gommers kirjoitti:
[clip]
1. fix up ideas page with scipy/numpy descriptions, idea difficulty levels
and preferably some more ideas.
Here's a start:
https://github.com/scipy/scipy/wiki/GSoC-project-ideas
___
NumPy-Discussion
. OSX
is somewhat saner in this respect.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
statements of the form `if a b: ...`
with floating point numbers, so that the execution path can be sensitive
to rounding error if you're unlucky, and the chances go up as the
iteration count increases.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
Hi,
25.04.2014 00:56, Matthew Brett kirjoitti: Thanks to Cark Kleffner's
toolchain and some help from Clint Whaley
(main author of ATLAS), I've built 64-bit windows numpy and scipy
wheels for testing.
Where can I get your
numpy.patch
scipy.patch
and what's in them?
Cheers,
. Preferably, the name should be quite short to type.
On the other hand, unlike r_ and c_, I haven't seen or used mat() in
real code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
Hi,
15.07.2014 21:06, Julian Taylor kirjoitti:
[clip: __numpy_ufunc__]
So I'm wondering if we should delay the introduction of this
feature to 1.10 or is it important enough to wait until there is a
consensus on the remaining issues?
My 10c:
The feature is not so much in hurry that it alone
18.07.2014 19:33, Chris Barker kirjoitti:
On Fri, Jul 18, 2014 at 9:07 AM, Pauli Virtanen p...@iki.fi
wrote:
Another approach would be to add a new 1-byte unicode
you can't do unicode in 1-byte -- so what does this mean, exactly?
The first 256 unicode code points, which happen to coincide
18.07.2014 19:35, Julian Taylor kirjoitti:
On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith n...@pobox.com
wrote:
On 18 Jul 2014 15:36, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
git rebase --onto $(git merge-base master maintenance/1.9.x)
HEAD^
As a potential refinement, this
authors who relied on that the default was
atol=0 is not so big.
(In other news, we should discourage use of assert_almost_equal, by
telling people to use assert_allclose instead in the docstring at the
least. It has only atol= and it specifies it in a very cumbersome log10
basis...)
--
Pauli
18.07.2014 22:13, Chris Barker kirjoitti:
[clip]
but an appropriate rtol would work there too. If only zero testing is
needed, then atol=0 makes sense as a default. (or maybe atol=eps)
There's plenty of room below eps, but finfo(float).tiny ~ 3e-308 (or
some big multiple) is also reasonable in
18.07.2014 23:53, Julian Taylor kirjoitti:
On 18.07.2014 19:47, Pauli Virtanen wrote:
[clip]
The other well-known alternative to bugfixes is to first commit it in
the earliest maintenance branch where you want to have it, and then
merge that branch forward to the newer maintenance branches
19.07.2014 01:49, Nathaniel Smith kirjoitti:
On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote:
18.07.2014 23:53, Julian Taylor kirjoitti:
On 18.07.2014 19:47, Pauli Virtanen wrote:
[clip]
The other well-known alternative to bugfixes is to first commit it in
the earliest
19.07.2014 02:10, Pauli Virtanen kirjoitti:
19.07.2014 01:49, Nathaniel Smith kirjoitti:
On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote:
[clip]
Presumably all the commits that we miss on the first pass and end up
backporting the hard way later :-)
If those are just
commits, so test failures
can be caught (although after the fact). This is also the case for
directly pushed cherry-picked commits.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
Scipy
only rules out the option that ndarray.__mul__(other) should
unconditionally call `np.add(self, other)`.
We have some freedom how to solve the binop vs. subclass issues. It's
possible to e.g. retain the __array_priority__ stuff as a backward
compatibility measure as we do currently.
--
Pauli
this trick.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 30 Sep 2010 15:13:04 -0400, Michael Droettboom wrote:
Is the solution as simple as the attached diff? It works for me, but I
don't understand all the implications.
More or less so, applied.
Pauli
___
NumPy-Discussion mailing list
Hi,
Should we set a date for a bugfix 1.5.1 release? There are some bugs that
would be nice to sort out in the 1.5.x series:
Any Python versions:
- #1605 (Cython vs. PEP-3118 issue: raising exceptions with active
cython buffers caused undefined behavior. Breaks Sage.)
- #1617 (Ensure
Thu, 07 Oct 2010 16:34:46 +0800, Ralf Gommers wrote:
[clip]
A 1.5.1 release soon would be good. All the issues above are already
committed, is there anything else that needs to go in? If not, I think
an RC by the end of next week (10/17) and release by the end of the
month should be possible.
Thu, 07 Oct 2010 07:09:37 -0600, Charles R Harris wrote:
[clip]
No, I just wanted to include the Laguerre and Hermite polynomials and
add a domain keyword to the linspace method of the polynomial template.
But I don't think these are pressing needs.
It's a minor release, so I think we need to
storage of re/im conflicts with its memory model. I
believe this will simply not be done, since there seems to be little
need for such a feature.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
Thu, 07 Oct 2010 18:02:43 -0400, Andrew P. Mullhaupt wrote:
On 10/7/2010 3:45 PM, josef.p...@gmail.com wrote:
what's your namespace?from scipy import log
log(int(-2))
(0.69314718055994529+3.1415926535897931j)
This should explain:
R = ones(2)
R[0] = R[0] * 1j
R
array([ 0., 1.])
the
naming issue and open a ticket so we can start rationalizing this for
2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and
pareto2, and deprecating plain old pareto may be the way to go.
The documentation bit can be done, however, if there's a plan how to deal
with it.
--
Pauli
Fri, 08 Oct 2010 13:28:01 -0400, josef.pktd wrote:
[clip]
I think I clarified the doc string enough that user that read the
docstring don't get confused anymore.
http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/
At least the first part is explicit about it, the notes
Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
Would any of you mind giving me commit rights on github? My handle is
pierregm. Thanks a million in advance.
Granted.
Cheers,
Pauli
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
the result of
a merge against the wrong parent (but of course there is no way to know
which is the right one).
The problems with the commit, as far as I see:
- adds unrelated Eclipse .project and .pydev* files
- introduces a merge commit for a small change
--
Pauli Virtanen
? Who would decide?
I think it is best to discuss this now, and make sure all core devs have
similar ideas on what is ideal.
One change at a time (i.e. give 'em the little finger approach).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
101 - 200 of 995 matches
Mail list logo
