X-Debbugs-Cc: gin...@debian.org, bren...@br.ibm.com
On 11/29/2016 03:18 PM, Fernando Seiti Furusato wrote:
> Also I had to consider a ci failure on appveyor, that is why I also
> included a verification for msvc version on the PR.
By the way, it has been merged upstream.
signature.asc
Descript
Hello.
At first I tried to fix that with round().
Problem is round() returns the same type as the argument so the cast
happens anyway.
I would recommend using the latest version, with llround(), which
returns long long.
Also I had to consider a ci failure on appveyor, that is why I also
included
tags 845082 + pending
thanks
--
Antonio Valentino
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Hello.
It is noticeable that it fails on a 3^3 array operation.
On "scalar" operations, it doesn't show the same behavior.
Like so:
$ python3.5
Python 3.5.2+ (default, Nov 3 2016, 11:10:16)
[GCC 6.2.0 20161027] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> i
On 11/20/2016 07:41 AM, Adrian Bunk wrote:
>
> Lots of failures like:
>
Yes. I just tried it here, and more than 40 tests failed.
It is usually off by 1, and I am wondering if we are being bite by a similar
issue I found on OpenJDK, where there are math inconsistency when using
optimization hig
Source: numexpr
Version: 2.6.1-1
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=numexpr&arch=ppc64el&ver=2.6.1-1&stamp=1479607449
Lots of failures like:
...
==
FAIL: test_scalar0_int_aggressive_OPERATIONS_0309
