On 16 Jul 2014 10:26, "Tony Yu" wrote:
>
> Is there any reason why the defaults for `allclose` and `assert_allclose`
differ? This makes debugging a broken test much more difficult. More
importantly, using an absolute tolerance of 0 causes failures for some
common cases. For example, if two values
On Wed, Jul 16, 2014 at 6:37 AM, Tony Yu wrote:
> Is there any reason why the defaults for `allclose` and `assert_allclose`
> differ? This makes debugging a broken test much more difficult. More
> importantly, using an absolute tolerance of 0 causes failures for some
> common cases. For example,
Dear all,
I have two arrays with both float type, let's say X and Y. I want to round
the X to integers (intX) according to some decimal threshold, at the same
time I want to limit the following difference as small:
diff = np.sum(X*Y) - np.sum(intX*Y)
I don't have to necessarily minimize the "dif
Sorry, there is one error in this part of code, it should be:
def convert_integer(x,threshold=0):
"""
This fucntion converts the float number x to integer according to the
threshold.
"""
if abs(x-0) < 1e-5:
return 0
else:
pdec,pint = math.modf(x)
if pde
Dear all,
A bit sorry, this is not difficult. scipy.optimize.minimize_scalar seems to
solve my problem. Thanks anyway, for this great tool.
Cheers,
Chao
On Wed, Jul 16, 2014 at 3:18 PM, Chao YUE wrote:
> Dear all,
>
> I have two arrays with both float type, let's say X and Y. I want to round
> But HDF5
> additionally has a fixed-storage-width UTF8 type, so we could map to a
> NumPy fixed-storage-width type trivially.
Sure -- this is why *nix uses utf-8 for filenames -- it can just be a
char*. But that just punts the problem to client code.
I think a UTF-8 string type does not match t
hi,
I have been playing around a bit with gccs link time optimization
feature and found that using it actually speeds up a from scratch build
of numpy due to its ability to perform parallel optimization and linking.
As a bonus you also should get faster binaries due to the better
optimizations lto
On Wed, Jul 16, 2014 at 10:07 AM, Nathaniel Smith wrote:
> Weirdly, I never received Chuck's original email in this thread. Should
> some list admin be informed?
>
Also weirdly, my reply didn't show up on gmane. Not sure if it got through,
so re-sending:
It's already in, so do you mean not using
Perhaps a bit of context might be useful? How is numpy_ufunc different from
the ufuncs that we know and love? What are the known implications? What are
the known shortcomings? Are there ABI and/or API concerns between 1.9 and
1.10?
Ben Root
On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris wrot
On Tue, Jul 15, 2014 at 9:15 AM, Charles R Harris wrote:
>
>
>
> On Tue, Jul 15, 2014 at 5:26 AM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
>
>> On Sa, 2014-07-12 at 12:17 -0500, Charles R Harris wrote:
>> > As previous posts have pointed out, Numpy's `S` type is currently
>> > treate
in 0.15.0 pandas will have full fledged support for categoricals which in
effect allow u 2 map a smaller number of strings to integers
this is now in pandas master
http://pandas-docs.github.io/pandas-docs-travis/categorical.html
feedback welcome!
> On Jul 14, 2014, at 1:00 PM, Olivier Grisel
On Mon, Jul 14, 2014 at 10:39 AM, Andrew Collette wrote:
> For storing data in HDF5 (PyTables or h5py), it would be somewhat
> cleaner if either ASCII or UTF-8 are used, as these are the only two
> charsets officially supported by the library.
good argument for ASCII, but utf-8 is a bad idea,
Is there any reason why the defaults for `allclose` and `assert_allclose`
differ? This makes debugging a broken test much more difficult. More
importantly, using an absolute tolerance of 0 causes failures for some
common cases. For example, if two values are very close to zero, a test
will fail:
On Mon, Jul 14, 2014 at 8:22 PM, Charles R Harris wrote:
> Hi All,
>
> Julian has raised the question of including numpy_ufunc in numpy 1.9. I
> don't feel strongly one way or the other, but it doesn't seem to be
> finished yet and 1.10 might be a better place to work out the remaining
> problems
On Sat, Jul 12, 2014 at 8:02 PM, Nathaniel Smith wrote:
> On 12 Jul 2014 23:06, "Charles R Harris"
> wrote:
> >
> > As previous posts have pointed out, Numpy's `S` type is currently
> treated as a byte string, which leads to more complicated code in python3.
> OTOH, the unicode type is stored as
On Tue, Jul 15, 2014 at 2:22 AM, Neil Hodgson
wrote:
> Hi,
>
> We came across this bug while using np.cross on 3D arrays of 2D vectors.
>
What version of numpy are you using? This should already be solved in numpy
master, and be part of the 1.9 release. Here's the relevant commit,
although the c
Weirdly, I never received Chuck's original email in this thread. Should
some list admin be informed?
I also am not sure what/where Julian's comments were, so I second the call
for context :-). Putting it off until 1.10 doesn't seem like an obviously
bad idea to me, but specifics would help...
(__
17 matches
Mail list logo
