Thanks for the feedback,
As far as I understand it, the proposition is to keep histogram as it is for
1.5, then in 2.0, deprecate normed=True but keep the buggy behavior, while
adding a density keyword that fixes the bug. In a later release, we could
then get rid of normed. While the bug won't be
On Mon, Aug 30, 2010 at 8:29 AM, David Huard david.hu...@gmail.com wrote:
Thanks for the feedback,
As far as I understand it, the proposition is to keep histogram as it is
for 1.5, then in 2.0, deprecate normed=True but keep the buggy behavior,
while adding a density keyword that fixes the
Hello,
I am new to Python (coming from R and Matlab/Octave). I was preparing
to write my usual compute pdf of a really high dimensional (e.g. 1
dimensions) Gaussian code in Python but I noticed that numpy had a
function for computing the log determinant in these situations.
Is there a
On 08/30/2010 09:19 AM, Benjamin Root wrote:
On Mon, Aug 30, 2010 at 8:29 AM, David Huard david.hu...@gmail.com
mailto:david.hu...@gmail.com wrote:
Thanks for the feedback,
As far as I understand it, the proposition is to keep histogram as
it is for 1.5, then in 2.0, deprecate
On Mon, Aug 30, 2010 at 11:39 AM, Bruce Southey bsout...@gmail.com wrote:
On 08/30/2010 09:19 AM, Benjamin Root wrote:
On Mon, Aug 30, 2010 at 8:29 AM, David Huard david.hu...@gmail.com wrote:
Thanks for the feedback,
As far as I understand it, the proposition is to keep histogram as it is
I tend to agree with Josef here,
To me, bincount and digitize are the low-level functions, and histogram
contains a bit more functionality since its used so often and for many use
cases. My guess is that if we removed the normalization, it could annoy a
lot of people and would quickly appear on
I think (a corrected) density histogram is core functionality for
unequal bin lengths.
The graph with raw count in the case of unequal bin sizes would be
quite misleading when plotted and interpreted on the real line and not
on discrete points (shaded areas instead of vertical lines). And
On Mon, Aug 30, 2010 at 10:50 AM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010 at 11:39 AM, Bruce Southey bsout...@gmail.com
wrote:
On 08/30/2010 09:19 AM, Benjamin Root wrote:
On Mon, Aug 30, 2010 at 8:29 AM, David Huard david.hu...@gmail.com
wrote:
Thanks for the feedback,
As
On 2010-08-30, at 11:28 AM, Daniel Elliott wrote:
Hello,
I am new to Python (coming from R and Matlab/Octave). I was preparing
to write my usual compute pdf of a really high dimensional (e.g. 1
dimensions) Gaussian code in Python but I noticed that numpy had a
function for computing
On Mon, Aug 30, 2010 at 2:43 PM, Benjamin Root ben.r...@ou.edu wrote:
On Mon, Aug 30, 2010 at 10:50 AM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010 at 11:39 AM, Bruce Southey bsout...@gmail.com
wrote:
On 08/30/2010 09:19 AM, Benjamin Root wrote:
On Mon, Aug 30, 2010 at 8:29 AM,
On Mon, Aug 30, 2010 at 3:02 PM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010 at 2:43 PM, Benjamin Root ben.r...@ou.edu wrote:
On Mon, Aug 30, 2010 at 10:50 AM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010 at 11:39 AM, Bruce Southey bsout...@gmail.com
wrote:
On 08/30/2010
On Mon, Aug 30, 2010 at 3:44 PM, David Huard david.hu...@gmail.com wrote:
On Mon, Aug 30, 2010 at 3:02 PM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010 at 2:43 PM, Benjamin Root ben.r...@ou.edu wrote:
On Mon, Aug 30, 2010 at 10:50 AM, josef.p...@gmail.com wrote:
On Mon, Aug 30, 2010
Mon, 23 Aug 2010 21:15:55 +, Pauli Virtanen wrote:
[clip]
in the history to have the wrong content -- so to be sure, we have to do
a brute-force comparison of the tree against SVN for each commit. The
particular bug here was fixed in the conversion tool, but better safe
than sorry.
Also
Hi,
I've been lurking for a while here but never really introduced myself.
I'm a mathematician in Brazil working with optimization and numerical
analysis and I'm looking into scipy/numpy basically because I want to
ditch matlab.
I'm just curious as to why you say scipy.linalg.solve(), NOT
On 2010-08-30, at 5:42 PM, Melissa Mendonça wrote:
I'm just curious as to why you say scipy.linalg.solve(), NOT
numpy.linalg.solve(). Can you explain the reason for this?
Oh, the performance will be similar, provided you've linked against a good
BLAS.
It's just that the NumPy version
On Mon, Aug 30, 2010 at 3:42 PM, Melissa Mendonça meliss...@gmail.comwrote:
Hi,
I've been lurking for a while here but never really introduced myself.
I'm a mathematician in Brazil working with optimization and numerical
analysis and I'm looking into scipy/numpy basically because I want to
Thanks for the reply.
David Warde-Farley dwf at cs.toronto.edu writes:
On 2010-08-30, at 11:28 AM, Daniel Elliott wrote:
Large matrices (e.g. 10K x 10K)
Is there a function for performing the inverse or even the pdf of a
multinomial normal in these situations as well?
There's a
On 08/31/2010 11:19 AM, Dan Elliott wrote:
Thanks for the reply.
David Warde-Farleydwfat cs.toronto.edu writes:
On 2010-08-30, at 11:28 AM, Daniel Elliott wrote:
Large matrices (e.g. 10K x 10K)
Is there a function for performing the inverse or even the pdf of a
multinomial normal in
On Mon, Aug 30, 2010 at 8:19 PM, Dan Elliott danelliotts...@gmail.comwrote:
Thanks for the reply.
David Warde-Farley dwf at cs.toronto.edu writes:
On 2010-08-30, at 11:28 AM, Daniel Elliott wrote:
Large matrices (e.g. 10K x 10K)
Is there a function for performing the inverse or even
19 matches
Mail list logo