[Numpy-discussion] log of negative real numbers -> RuntimeWarning: invalid value encountered in log

[Robert Kern]

On Mon, May 25, 2020 at 11:17 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> > On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> > sebastian at sipsolutions.net>
> > wrote:
> >
> > > On Mon, 2020-05-25 at 10:09 -0400, Brian Racey wrote:
> > > > Would a "complex default" mode ever make it into numpy, to behave
> > > > more like
> > > > Matlab and other packages with respect to complex number
> > > > handling?
> > > > Sure it
> > > > would make it marginally slower if enabled, but it might open the
> > > > door to
> > > > better compatibility when porting code to Python.
> > > >
> > >
> > > I think the SciPy versions may have such a default, or there is
> > > such a
> > > functionality hidden somewhere (maybe even the switching
> > > behaviour).
> > > I am not sure anyone actually uses those, so it may not be a good
> > > idea
> > > to use them to be honest.
> > >
> >
> > The versions in `np.lib.scimath` behave like this. Of course, people
> > do use
> > them when they want to deal with real numbers as subsets of the
> > complex
> > numbers.
> >
>
> True, I guess I just used complex numbers too rarely in programs (i.e.
> never central to any programming project).
>
> It seems this is actually also exposed as `np.emath`, which is maybe a
> better entry point? And I guess the scipy namespace uses them.
>

Ah, yes, that's the preferred alias, though the documentation page for it
seems to be a little buggy (using `np.lib.scimath` instead `np.emath`;
telling you to look at the docstrings for the individual functions, but
they don't exist in the documentation).

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200525/939e6798/attachment.html>