15.03.2013 22:39, Nathaniel Smith kirjoitti:
[clip]
> - Something else...
How about: scrap the automatic signatures altogether, and directly use
the docstring provided to the ufunc creation function?
I suspect ufuncs are not very widely used in 3rd party code, as it
requires somewhat tricky messi
On 3/15/2013 3:34 PM, Dmitrey wrote:
> the suspected bugs are not documented yet
I'm going to guess that the state of the F_i changes
when you use them as keys (i.e., when you call __le__.
It is very hard to imagine that this is a Python or NumPy bug.
Cheers,
Alan
__
On Fri, Mar 15, 2013 at 6:47 PM, Warren Weckesser
wrote:
> Hi all,
>
> In a recent scipy pull request (https://github.com/scipy/scipy/pull/459), I
> ran into the problem of ufuncs automatically generating a signature in the
> docstring using arguments such as 'x' or 'x1, x2'. scipy.special has a
On Fri, Mar 15, 2013 at 9:52 AM, Ake Sandgren wrote:
> On Fri, 2013-03-15 at 09:44 +, Nathaniel Smith wrote:
>> That does look unlikely yeah... Does this have any consequences that
>> you've found? Is there a test case that fails before the patch but
>> works after?
>
> No, just found it durin
On Fri, Mar 15, 2013 at 7:34 PM, Dmitrey wrote:
> --- Исходное сообщение ---
>
> От кого: "Alan G Isaac"
> Дата: 15 марта 2013, 20:38:38
>
> On 3/15/2013 9:21 AM, Dmitrey wrote:
>> Temporary walkaround for a serious bug in FuncDesigner automatic
>> differentiation kernel due to a bug in some vers
--- Исходное сообщение ---
> От кого: "Alan G Isaac"
Дата: 15 марта 2013, 20:38:38
On 3/15/2013 9:21 AM, Dmitrey wrote:
> Temporary walkaround for a serious bug in FuncDesigner automatic
> differentiation kernel due to a bug in some versions of Python or NumPy,
Are the suspected bugs docum
Hi all,
In a recent scipy pull request (https://github.com/scipy/scipy/pull/459), I
ran into the problem of ufuncs automatically generating a signature in the
docstring using arguments such as 'x' or 'x1, x2'. scipy.special has a lot
of ufuncs, and for most of them, there are much more descriptiv
On 3/15/2013 9:21 AM, Dmitrey wrote:
> Temporary walkaround for a serious bug in FuncDesigner automatic
> differentiation kernel due to a bug in some versions of Python or NumPy,
Are the suspected bugs documented somewhere?
Alan
PS The word 'banausic' is very rare in English.
Perhaps you meant '
In fact, there is already an inner1d implemented in
numpy.core.umath_tests.inner1d
from numpy.core.umath_tests import inner1d
It should do the trick :)
On Thu, Mar 14, 2013 at 12:54 PM, Jaakko Luttinen
wrote:
> Answering to myself, this pull request seems to implement an inner
> product with br
Hi all,
>
I'm glad to inform you about new OpenOpt Suite release 0.45
(2013-March-15):
* Essential improvements for FuncDesigner interval analysis (thus affect
interalg)
* Temporary walkaround for a serious bug in FuncDesigner automatic
differentiation kernel due to a bug in some versions of P
On Fri, 2013-03-15 at 09:44 +, Nathaniel Smith wrote:
> That does look unlikely yeah... Does this have any consequences that
> you've found? Is there a test case that fails before the patch but
> works after?
No, just found it during compilation with the intel compiler. It
complained about use
That does look unlikely yeah... Does this have any consequences that you've
found? Is there a test case that fails before the patch but works after?
-n
On 15 Mar 2013 09:19, "Ake Sandgren" wrote:
> Hi!
>
> Found this thing that looks like a bug in
> core/src/multiarray/dtype_transfer.c
>
> diff
Hi!
Found this thing that looks like a bug in
core/src/multiarray/dtype_transfer.c
diff -ru site/numpy/core/src/multiarray/dtype_transfer.c
amd64_ubuntu1004-intel-acml/numpy/core/src/multiarray/dtype_transfer.c
--- site/numpy/core/src/multiarray/dtype_transfer.c 2011-07-20
20:25:28.0
13 matches
Mail list logo