On Mon, May 25, 2020 at 11:17 AM Sebastian Berg <sebast...@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 < > > sebast...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
