I think ultimately the copy is unnecessary.
That being said introducing prepend and append functions concentrates the
complexity of the mapping in one place. Trying to avoid the extra copy would
probably lead to a more complex implementation of accumulate.
How would in your view the prepend i
Our Numpy arrays are pickled when they are transported over Pipes between
Processors (using multiprocessing). Just to point out that there uses of
pickling not involving files. Would that affect your analysis?
___
NumPy-Discussion mailing list -- numpy-
If needed I can try to construct a minimal example for testing purposes.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discus
OK. Then we will just weight for 2.x and test then.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Memb
I have one more useCase to consider from our ecosystem.
We dump numpy arrays into a MongoDB using GridFS for subsequent visualization,
some snippets:
'''Python
with BytesIO() as BIO:
np.save(BIO, numpy_array)
serialized_A = BIO.getvalue()
filehandle_id =
My Cython code and my swig wrapped C++ code assumes the C-ordering and
contiguous layout which allows for super fast code. I guess making it agnostic
for the ordering would require implementing everything twice and then switch
between them based on what comes in. That is a lot of work for no gai
I wonder whether you are looking for the solution in the right direction. Is
there theory for the shape of the curve? In that case it might be better to see
the problem as a fitting problem.
Other than that I think option 2 is too ad hoc for scientific work. I would opt
for simply not showing t
I created a solution for ENH: Computing std/var and mean at the same time,
issue #23741. The solution can be found here:
https://github.com/soundappraisal/numpy/tree/stdmean-dev-001
I still need to add tests and the solution does touch the implementation of
var. But before starting a pull req
Steps to make this complete:
- move resize of the mean array out of _mean_var and into the calling
mean_std function (to reduce the impact of the code changes on existing
functions)
- establish whether numpy/core/_add_newdocs.py needs to be updated (What is
the function of this file?)
Mean_var, mean_std and tests are now ready.
(https://github.com/soundappraisal/numpy/tree/stdmean-dev-001)
Some decisions made during implementation:
- the output shape of mean follows the output shape of the variance or the
standard deviation. So it responds in the same way to the keepdims fl
I think I left those aspects of the implementation untouched. But having
someone more experienced look at it is probably a good idea.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@
Aha, the unnecessary copy mentioned in the
https://dbs.ifi.uni-heidelberg.de/files/Team/eschubert/publications/SSDBM18-covariance-authorcopy.pdf.
paper is a copy of the input. Here it is about discarding a valuable output
(the mean) and then calculating that result separately.
Not throwing the
I am agnostic to the order of those changes. Also this is my first attempt to
contribute to numpy, so I am not aware of all the ongoing discussions. I'll try
to read the issue you just mentioned.
But in the code I rewrote replacing _mean_var with a faster version would
benefit var, std, mean_va
I had a closer look at the paper. When I have more brain and time I may check
the mathematics. The focus is however more on streaming data, which is an
application with completely different demands. I think that here we can not
afford to sample the data, which is an option in streaming database
I had a look at C-solution, it delegates the summation over one axis from the
axis tuple to the C-helper. And then the remaining axes are summed from
_methods.py. Worst case: if the axis delegated to helper is very short
compared to the other axes I would expect hardly any speed-up, and savings
I had a look at what it would take to improve the C-solution. However I find
that it is beyond my C-programming skils.
The gufunc defintion seems to be at odds with current working of the axis
keyword for mean, std and var. The latter support computation over multiple
axes, whereas the gufunc
Note: the suggested solution requires no allocation of memory beyond that
needed for storing the result.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.pytho
2nd note: I implicit based this on the reduce function.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
I have a pull request, but I am stuck for a day now on how to handle the masked
arrays.
I made some progress by calling the MaskedArray methods, but in some cases
those methods call back the ndarray methods via their super class. The method
_mean_var for ndarray need to resize the produced me
OK, same two tests fail on main (50984037) aswell.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Membe
Issue #23896 is the cause of these two failing tests.
With CFLAGS="NPY_DISABLE_OPTIMIZATION=1" the tests pass.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://ma
Second attempt after the triage review of last week: ENH: add mean keyword to
std and var #24126 (https://github.com/numpy/numpy/pull/24126)
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion
Ilhan Polat wrote:
> I think all these point to the missing convenient functionality that
> extends arrays. In matlab "[0 arr 10]" nicely extends the array to a new
> one but in NumPy you need to punch quite some code and some courage to
> remember whether it is hstack or vstack or concat or block
I was trying to get a feel for how often the work around occurs. I found three
clear examples in Scipy and one unclear case. One case in holoviews. Two in
numpy. One from soundappraisal's code base.
Next to prepending to the output, I also see prepending to the input as a
workaround.
Some exam
> Whether it's necessary to have other keywords to prepend anything other
> than zero, or append rather than prepend, is a lot less clear. Did you find
> a clear need for those things?
No, I haven't found them. For streaming data there might be usecases for
starting with an initial offset, but I
I don't think there is an automatic method for correct binning.
The methods mentioned in the pull request and related issue are all based on
the assumption that the underlying distribution is Gaussian. There is
absolutely no reason to assume that.
Reasonable expectations for automatic binnin
26 matches
Mail list logo
