From charlesr.harris at gmail.com Fri Oct 2 11:39:56 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 2 Oct 2020 09:39:56 -0600 Subject: [Numpy-discussion] Updating swig.i to python3 only. Message-ID: Hi All, Motivated by the replacement of compatibility macros in NumPy core, see issue , I was wondering if we should extend that to swig.i. That would make swig incompatible with Python2.7, but one can't use recent numpy with Python 2.7 either. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.rogozhnikov at yandex.ru Sat Oct 3 05:50:11 2020 From: alex.rogozhnikov at yandex.ru (Alex Rogozhnikov) Date: Sat, 03 Oct 2020 12:50:11 +0300 Subject: [Numpy-discussion] Einops cross-linking from einsum In-Reply-To: References: <3191601184364@mail.yandex.ru> Message-ID: <298641601718502@mail.yandex.ru> An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Mon Oct 5 19:25:06 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 5 Oct 2020 17:25:06 -0600 Subject: [Numpy-discussion] Python 3.9 is out. Message-ID: Hi All, The subject says it all. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.w.augspurger at gmail.com Mon Oct 5 21:59:07 2020 From: tom.w.augspurger at gmail.com (Tom Augspurger) Date: Mon, 5 Oct 2020 20:59:07 -0500 Subject: [Numpy-discussion] Python 3.9 is out. In-Reply-To: References: Message-ID: I believe that the latest version of NumPy (1.19.2) is source-compatible with Python 3.9. Does NumPy plan to upload wheels to PyPI for Python 3.9, or will you wait for the next release? Pandas is planning to upload wheels for 3.9 with our latest released version (1.1.3) but are planning to build against a version of NumPy with a wheel that's uploaded to PyPI. Thanks, Tom On Mon, Oct 5, 2020 at 6:26 PM Charles R Harris wrote: > Hi All, > > The subject says it all. > > Chuck > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Oct 6 00:43:37 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 5 Oct 2020 22:43:37 -0600 Subject: [Numpy-discussion] Python 3.9 is out. In-Reply-To: References: Message-ID: On Mon, Oct 5, 2020 at 7:58 PM Tom Augspurger wrote: > I believe that the latest version of NumPy (1.19.2) is source-compatible > with Python 3.9. Does NumPy plan to upload wheels to PyPI for Python 3.9, > or will you wait for the next release? > > Pandas is planning to upload wheels for 3.9 with our latest released > version (1.1.3) but are planning to build against a version of NumPy with a > wheel that's uploaded to PyPI. > I'll put out a 19.3 release with Python 3.9 wheels as soon as we are able to build the wheels on azure. We may need to do the Python install ourselves. I'd also like to fix the Windows 2004 problem, but that may have to wait for 1.19.4 if Microsoft doesn't fix it first. I'm also thinking of only providing manylinux2014 wheels for 3.9 as it comes with a recent pip version. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Oct 6 18:50:37 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 6 Oct 2020 16:50:37 -0600 Subject: [Numpy-discussion] Python 3.9 is out. In-Reply-To: References: Message-ID: On Mon, Oct 5, 2020 at 10:43 PM Charles R Harris wrote: > > > On Mon, Oct 5, 2020 at 7:58 PM Tom Augspurger > wrote: > >> I believe that the latest version of NumPy (1.19.2) is source-compatible >> with Python 3.9. Does NumPy plan to upload wheels to PyPI for Python 3.9, >> or will you wait for the next release? >> >> Pandas is planning to upload wheels for 3.9 with our latest released >> version (1.1.3) but are planning to build against a version of NumPy with a >> wheel that's uploaded to PyPI. >> > > I'll put out a 19.3 release with Python 3.9 wheels as soon as we are able > to build the wheels on azure. We may need to do the Python install > ourselves. I'd also like to fix the Windows 2004 problem, but that may have > to wait for 1.19.4 if Microsoft doesn't fix it first. I'm also thinking of > only providing manylinux2014 wheels for 3.9 as it comes with a recent pip > version. > > Looks like 3.9 should be available on azure next week: https://github.com/actions/virtual-environments/issues/1740. It is already available through GitHub Actions, but I think we can wait a week. I think it still needs to be added/built for the manylinux docker images. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Wed Oct 7 11:00:26 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Wed, 07 Oct 2020 10:00:26 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Wednesday - Triage Focus Message-ID: Hi all, Our bi-weekly triage-focused NumPy development meeting is today (Wednesday, October 7th) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized, discussed, or reviewed. Best regards Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sebastian at sipsolutions.net Thu Oct 8 08:51:16 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 08 Oct 2020 07:51:16 -0500 Subject: [Numpy-discussion] =?utf-8?q?Accepting_NEP_42_=E2=80=94_New_and_?= =?utf-8?q?extensible_DTypes?= Message-ID: Hi all, after another thorough revision of NEP 42 (much thanks to Ben!), I propose accepting the NEP, with the note that details are expected change. I am always happy to clarify and review the document based on feedback, but I feel the important technical points should be very clear and settled. Exposing all of the proposed API may need additional detailed API discussion. My focus is still a bit on the big picture design choices that the NEP makes need to move forward and settle the implementation internal to NumPy, although I am happy to discuss the details! The title of the NEP is: NEP 42 ? New and extensible DTypes And available at: https://numpy.org/neps/nep-0042-new-dtypes.html While enabling new user-defined DTypes is the main goal, the main work is the internal restructure of NumPy's own DTypes necessary to allow that. I have pasted the "Abstract" and "Motivation and scope" section below, which give a good overview of the issues and we are trying to address. It is followed by the "Usage and impact" section which gives a big- picture overview of the design. I will refer to the full NEP for more detailed technical decisions and explanations. Cheers, Sebastian PS: In some places NEP 42 references NEP 43, for which I hope to merge the draft soon, the current status is here: https://github.com/numpy/numpy/pull/16723 However, this should be mainly interested for those wishing to go into more technical details. *********************************************************************** ******* Abstract *********************************************************************** ******* NumPy's dtype architecture is monolithic -- each dtype is an instance of a single class. There's no principled way to expand it for new dtypes, and the code is difficult to read and maintain. As :ref:`NEP 41 ` explains, we are proposing a new architecture that is modular and open to user additions. dtypes will derive from a new ``DType`` class serving as the extension point for new types. ``np.dtype("float64")`` will return an instance of a ``Float64`` class, a subclass of root class ``np.dtype``. This NEP is one of two that lay out the design and API of this new architecture. This NEP addresses dtype implementation; NEP 43 addresses universal functions. .. note:: Details of the private and external APIs may change to reflect user comments and implementation constraints. The underlying principles and choices should not change significantly. *********************************************************************** ******* Motivation and scope *********************************************************************** ******* Our goal is to allow user code to create fully featured dtypes for a broad variety of uses, from physical units (such as meters) to domain- specific representations of geometric objects. :ref:`NEP 41 ` describes a number of these new dtypes and their benefits. Any design supporting dtypes must consider: - How shape and dtype are determined when an array is created - How array elements are stored and accessed - The rules for casting dtypes to other dtypes In addition: - We want dtypes to comprise a class hierarchy open to new types and to subhierarchies, as motivated in :ref:`NEP 41 `. And to provide this, - We need to define a user API. All these are the subjects of this NEP. - The class hierarchy, its relation to the Python scalar types, and its important attributes are described in `nep42_DType class`_. - The functionality that will support dtype casting is described in `Casting`_. - The implementation of item access and storage, and the way shape and dtype are determined when creating an array, are described in :ref:`nep42_array_coercion`. - The functionality for users to define their own DTypes is described in `Public C-API`_. The API here and in NEP 43 is entirely on the C side. A Python-side version will be proposed in a future NEP. A future Python API is expected to be similar, but provide a more convenient API to reuse the functionality of existing DTypes. It could also provide shorthands to create structured DTypes similar to Python's `dataclasses `_. *********************************************************************** ******* Usage and impact *********************************************************************** ******* We believe the few structures in this section are sufficient to consolidate NumPy's present functionality and also to support complex user-defined DTypes. The rest of the NEP fills in details and provides support for the claim. Again, though Python is used for illustration, the implementation is a C API only; a future NEP will tackle the Python API. After implementing this NEP, creating a DType will be possible by implementing the following outlined DType base class, that is further described in `nep42_DType class`_: class DType(np.dtype): type : type # Python scalar type parametric : bool # (may be indicated by superclass) @property def canonical(self) -> bool: raise NotImplementedError def ensure_canonical(self : DType) -> DType: raise NotImplementedError For casting, a large part of the functionality is provided by the "methods" stored in ``_castingimpl`` @classmethod def common_dtype(cls : DTypeMeta, other : DTypeMeta) -> DTypeMeta: raise NotImplementedError def common_instance(self : DType, other : DType) -> DType: raise NotImplementedError # A mapping of "methods" each detailing how to cast to another DType # (further specified at the end of the section) _castingimpl = {} For array-coercion, also part of casting: def __dtype_setitem__(self, item_pointer, value): raise NotImplementedError def __dtype_getitem__(self, item_pointer, base_obj) -> object: raise NotImplementedError @classmethod def __discover_descr_from_pyobject__(cls, obj : object) -> DType: raise NotImplementedError # initially private: @classmethod def _known_scalar_type(cls, obj : object) -> bool: raise NotImplementedError Other elements of the casting implementation is the ``CastingImpl``: casting = Union["safe", "same_kind", "unsafe"] class CastingImpl: # Object describing and performing the cast casting : casting def resolve_descriptors(self, Tuple[DType] : input) -> (casting, Tuple[DType]): raise NotImplementedError # initially private: def _get_loop(...) -> lowlevel_C_loop: raise NotImplementedError which describes the casting from one DType to another. In NEP 43 this ``CastingImpl`` object is used unchanged to support universal functions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From lee.johnston.100 at gmail.com Fri Oct 9 08:48:17 2020 From: lee.johnston.100 at gmail.com (Lee Johnston) Date: Fri, 9 Oct 2020 07:48:17 -0500 Subject: [Numpy-discussion] NEP 42 and physical unit DType Message-ID: NEP 42 mentions physical units as a possible use case for the new DType. Having worked on `unyt`, which is an ndarray subclass, and other unit system implementations based on the dispatch mechanism, I am quite familiar with the challenges. One challenge is integration with Matplotlib that has a unit conversion interface. This interface is invoked by a registry mapping from unit array type, such as `unyt_array`, and its conversion class. A custom DType will still result in an ndarray type - correct? If so, Matplotlib will attempt to perform its internal calculations eventually leading to an invalid operation when adding a physical quantity to a pure number. This happens today with `unyt_array` and some of the plotting functions that allow the subclass to leak through into the internals. Has this been discussed? I can imagine other libraries will have the same challenge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Fri Oct 9 13:08:07 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Fri, 09 Oct 2020 12:08:07 -0500 Subject: [Numpy-discussion] NEP 42 and physical unit DType In-Reply-To: References: Message-ID: On Fri, 2020-10-09 at 07:48 -0500, Lee Johnston wrote: > NEP 42 mentions physical units as a possible use case for the new > DType. > Having worked on `unyt`, which is an ndarray subclass, and other unit > system implementations based on the dispatch mechanism, I am quite > familiar > with the challenges. One challenge is integration with Matplotlib > that has > a unit conversion interface. This interface is invoked by a registry > mapping from unit array type, such as `unyt_array`, and its > conversion > class. A custom DType will still result in an ndarray type - correct? A custom DType will be attached to a normal NumPy array (or, hopefully a pandas dataframe, etc.). I am not sure if that is what you meant, but a custom DType will mean there is no array subclass involved (this is different from how pandas approaches extension dtypes). But, I am not sure that this makes much of a difference with respect to the problem. > If > so, Matplotlib will attempt to perform its internal calculations > eventually > leading to an invalid operation when adding a physical quantity to a > pure > number. This happens today with `unyt_array` and some of the plotting It sounds unlikely that this would solve the issue immediately. Rather, we probably need to think about creating some kind of "protocol" to drop units, such as: arr.astype(Unitless) which would be a no-op for the NumPy numerical types. Or baking in something similar to make working with units easier. I would have hoped a bit that it is possible to avoid such issues e.g. by dividing by a step/difference, but I do not know the details. The most important question for me would be more whether there is something in the basic infrastructure to consider that cannot be done as an extension/protocol later (like the `arr.astype(Unitless)` cast, which should be a straight forward extension). Although, it would be interesting to figure out how a future Unit DType would best look in this regard! Cheers, Sebastian > functions that allow the subclass to leak through into the internals. > Has > this been discussed? I can imagine other libraries will have the same > challenge. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From tcaswell at gmail.com Fri Oct 9 14:05:28 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 9 Oct 2020 14:05:28 -0400 Subject: [Numpy-discussion] NEP 42 and physical unit DType In-Reply-To: References: Message-ID: >From the Matplotlib side we can definitely do dispatch based on the dtype of the ndarray (not just that it is an array) which is how we handle arrays of datetimes. Matplotlib should (internally) never try to do operations on user data before we do the unit conversion and my default position is that where we let that leak is a bug in mpl. I don't think bugs in Matplotlib should feed back to the dtype design. Tom On Fri, Oct 9, 2020 at 1:08 PM Sebastian Berg wrote: > On Fri, 2020-10-09 at 07:48 -0500, Lee Johnston wrote: > > NEP 42 mentions physical units as a possible use case for the new > > DType. > > Having worked on `unyt`, which is an ndarray subclass, and other unit > > system implementations based on the dispatch mechanism, I am quite > > familiar > > with the challenges. One challenge is integration with Matplotlib > > that has > > a unit conversion interface. This interface is invoked by a registry > > mapping from unit array type, such as `unyt_array`, and its > > conversion > > class. A custom DType will still result in an ndarray type - correct? > > A custom DType will be attached to a normal NumPy array (or, hopefully > a pandas dataframe, etc.). I am not sure if that is what you meant, but > a custom DType will mean there is no array subclass involved (this is > different from how pandas approaches extension dtypes). > But, I am not sure that this makes much of a difference with respect to > the problem. > > > If > > so, Matplotlib will attempt to perform its internal calculations > > eventually > > leading to an invalid operation when adding a physical quantity to a > > pure > > number. This happens today with `unyt_array` and some of the plotting > > It sounds unlikely that this would solve the issue immediately. Rather, > we probably need to think about creating some kind of "protocol" to > drop units, such as: > > arr.astype(Unitless) > > which would be a no-op for the NumPy numerical types. Or baking in > something similar to make working with units easier. > > I would have hoped a bit that it is possible to avoid such issues e.g. > by dividing by a step/difference, but I do not know the details. > > The most important question for me would be more whether there is > something in the basic infrastructure to consider that cannot be done > as an extension/protocol later (like the `arr.astype(Unitless)` cast, > which should be a straight forward extension). > > Although, it would be interesting to figure out how a future Unit DType > would best look in this regard! > > Cheers, > > Sebastian > > > > functions that allow the subclass to leak through into the internals. > > Has > > this been discussed? I can imagine other libraries will have the same > > challenge. > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Fri Oct 9 18:34:00 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Fri, 9 Oct 2020 19:34:00 -0300 Subject: [Numpy-discussion] Documentation Team meeting - Monday October 12 In-Reply-To: References: Message-ID: Hi all! This is a reminder that our next Documentation Team meeting will be on *Monday, October 12* at 3PM UTC**. If you wish to join on Zoom, **you need to use this NEW link** https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09 Here's the permanent hackmd document with the meeting notes (still being updated in the next few days!): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20201012T15&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Sat Oct 10 08:22:24 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sat, 10 Oct 2020 20:22:24 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. Message-ID: Hi, My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I try to run the script , but it will keep running and never end. When I use 'Ctrl + c' to terminate it, it will give the following output: $ python mu.py [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] I have to terminate it and obtained the following information: ^CTraceback (most recent call last): File "mu.py", line 38, in integrand=DOS*fermi_array(energy,mu,kT) File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", line 2108, in __call__ return self._vectorize_call(func=func, args=vargs) File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", line 2192, in _vectorize_call outputs = ufunc(*inputs) File "mu.py", line 8, in fermi return 1./(exp((E-mu)/kT)+1) KeyboardInterrupt Any helps and hints for this problem will be highly appreciated? Regards, -- Hongyi Zhao From robert.kern at gmail.com Sat Oct 10 13:48:12 2020 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 10 Oct 2020 13:48:12 -0400 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: > Hi, > > My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > try to run the script > < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > but it will keep running and never end. When I use 'Ctrl + c' to > terminate it, it will give the following output: > > $ python mu.py > [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > I have to terminate it and obtained the following information: > > ^CTraceback (most recent call last): > File "mu.py", line 38, in > integrand=DOS*fermi_array(energy,mu,kT) > File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > line 2108, in __call__ > return self._vectorize_call(func=func, args=vargs) > File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > line 2192, in _vectorize_call > outputs = ufunc(*inputs) > File "mu.py", line 8, in fermi > return 1./(exp((E-mu)/kT)+1) > KeyboardInterrupt > > > Any helps and hints for this problem will be highly appreciated? > > Regards, > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Sat Oct 10 18:26:21 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sun, 11 Oct 2020 06:26:21 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: > > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. Yes, it really does the trick. See the following for the benchmark based on your suggestion: $ time python mu.py [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] real 0m41.056s user 0m43.970s sys 0m3.813s But are there any ways to further improve/increase efficiency? Regards, HY > > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> >> Hi, >> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> try to run the script >> , >> but it will keep running and never end. When I use 'Ctrl + c' to >> terminate it, it will give the following output: >> >> $ python mu.py >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> I have to terminate it and obtained the following information: >> >> ^CTraceback (most recent call last): >> File "mu.py", line 38, in >> integrand=DOS*fermi_array(energy,mu,kT) >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> line 2108, in __call__ >> return self._vectorize_call(func=func, args=vargs) >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> line 2192, in _vectorize_call >> outputs = ufunc(*inputs) >> File "mu.py", line 8, in fermi >> return 1./(exp((E-mu)/kT)+1) >> KeyboardInterrupt >> >> >> Any helps and hints for this problem will be highly appreciated? >> >> Regards, >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From andrea.gavana at gmail.com Sun Oct 11 01:14:44 2020 From: andrea.gavana at gmail.com (Andrea Gavana) Date: Sun, 11 Oct 2020 07:14:44 +0200 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: Hi, On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: > On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: > > > > You don't need to use vectorize() on fermi(). fermi() will work just > fine on arrays and should be much faster. > > Yes, it really does the trick. See the following for the benchmark > based on your suggestion: > > $ time python mu.py > [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > real 0m41.056s > user 0m43.970s > sys 0m3.813s > > > But are there any ways to further improve/increase efficiency? I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? Andrea. > > Regards, > HY > > > > > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: > >> > >> Hi, > >> > >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > >> try to run the script > >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > >> but it will keep running and never end. When I use 'Ctrl + c' to > >> terminate it, it will give the following output: > >> > >> $ python mu.py > >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> > >> I have to terminate it and obtained the following information: > >> > >> ^CTraceback (most recent call last): > >> File "mu.py", line 38, in > >> integrand=DOS*fermi_array(energy,mu,kT) > >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> line 2108, in __call__ > >> return self._vectorize_call(func=func, args=vargs) > >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> line 2192, in _vectorize_call > >> outputs = ufunc(*inputs) > >> File "mu.py", line 8, in fermi > >> return 1./(exp((E-mu)/kT)+1) > >> KeyboardInterrupt > >> > >> > >> Any helps and hints for this problem will be highly appreciated? > >> > >> Regards, > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.gavana at gmail.com Sun Oct 11 01:32:29 2020 From: andrea.gavana at gmail.com (Andrea Gavana) Date: Sun, 11 Oct 2020 07:32:29 +0200 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: > Hi, > > On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: > >> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern >> wrote: >> > >> > You don't need to use vectorize() on fermi(). fermi() will work just >> fine on arrays and should be much faster. >> >> Yes, it really does the trick. See the following for the benchmark >> based on your suggestion: >> >> $ time python mu.py >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> real 0m41.056s >> user 0m43.970s >> sys 0m3.813s >> >> >> But are there any ways to further improve/increase efficiency? > > > > I believe it will get a bit better if you don?t column_stack an array 6000 > times - maybe pre-allocate your output first? > > Andrea. > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. > > >> >> Regards, >> HY >> >> > >> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao >> wrote: >> >> >> >> Hi, >> >> >> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> >> try to run the script >> >> < >> https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py >> >, >> >> but it will keep running and never end. When I use 'Ctrl + c' to >> >> terminate it, it will give the following output: >> >> >> >> $ python mu.py >> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >> >> I have to terminate it and obtained the following information: >> >> >> >> ^CTraceback (most recent call last): >> >> File "mu.py", line 38, in >> >> integrand=DOS*fermi_array(energy,mu,kT) >> >> File >> "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> line 2108, in __call__ >> >> return self._vectorize_call(func=func, args=vargs) >> >> File >> "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> line 2192, in _vectorize_call >> >> outputs = ufunc(*inputs) >> >> File "mu.py", line 8, in fermi >> >> return 1./(exp((E-mu)/kT)+1) >> >> KeyboardInterrupt >> >> >> >> >> >> Any helps and hints for this problem will be highly appreciated? >> >> >> >> Regards, >> >> -- >> >> Hongyi Zhao >> >> _______________________________________________ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion at python.org >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Sun Oct 11 01:51:12 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sun, 11 Oct 2020 13:51:12 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: > > > > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> >> Hi, >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >>> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >>> > >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >>> >>> Yes, it really does the trick. See the following for the benchmark >>> based on your suggestion: >>> >>> $ time python mu.py >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >>> >>> real 0m41.056s >>> user 0m43.970s >>> sys 0m3.813s >>> >>> >>> But are there any ways to further improve/increase efficiency? >> >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> >> Andrea. > > > > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. Still not so clear on your solutions for this problem. Could you please post here the corresponding snippet of your enhancement? Regards, HY > >> >> >>> >>> >>> Regards, >>> HY >>> >>> > >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >>> >> >>> >> Hi, >>> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >>> >> try to run the script >>> >> , >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >>> >> terminate it, it will give the following output: >>> >> >>> >> $ python mu.py >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >>> >> >>> >> I have to terminate it and obtained the following information: >>> >> >>> >> ^CTraceback (most recent call last): >>> >> File "mu.py", line 38, in >>> >> integrand=DOS*fermi_array(energy,mu,kT) >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >>> >> line 2108, in __call__ >>> >> return self._vectorize_call(func=func, args=vargs) >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >>> >> line 2192, in _vectorize_call >>> >> outputs = ufunc(*inputs) >>> >> File "mu.py", line 8, in fermi >>> >> return 1./(exp((E-mu)/kT)+1) >>> >> KeyboardInterrupt >>> >> >>> >> >>> >> Any helps and hints for this problem will be highly appreciated? >>> >> >>> >> Regards, >>> >> -- >>> >> Hongyi Zhao >>> >> _______________________________________________ >>> >> NumPy-Discussion mailing list >>> >> NumPy-Discussion at python.org >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >>> > >>> > _______________________________________________ >>> > NumPy-Discussion mailing list >>> > NumPy-Discussion at python.org >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >>> >>> >>> >>> -- >>> Hongyi Zhao >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From andrea.gavana at gmail.com Sun Oct 11 02:01:46 2020 From: andrea.gavana at gmail.com (Andrea Gavana) Date: Sun, 11 Oct 2020 08:01:46 +0200 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: > On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana > wrote: > > > > > > > > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana > wrote: > >> > >> Hi, > >> > >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao > wrote: > >>> > >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern > wrote: > >>> > > >>> > You don't need to use vectorize() on fermi(). fermi() will work just > fine on arrays and should be much faster. > >>> > >>> Yes, it really does the trick. See the following for the benchmark > >>> based on your suggestion: > >>> > >>> $ time python mu.py > >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >>> > >>> real 0m41.056s > >>> user 0m43.970s > >>> sys 0m3.813s > >>> > >>> > >>> But are there any ways to further improve/increase efficiency? > >> > >> > >> > >> I believe it will get a bit better if you don?t column_stack an array > 6000 times - maybe pre-allocate your output first? > >> > >> Andrea. > > > > > > > > I?m sorry, scratch that: I?ve seen a ghost white space in front of your > column_stack call and made me think you were stacking your results very > many times, which is not the case. > > Still not so clear on your solutions for this problem. Could you > please post here the corresponding snippet of your enhancement? I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - not to mention calling trapz 6000 times in a loop. Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... > > Regards, > HY > > > >> > >> > >>> > >>> > >>> Regards, > >>> HY > >>> > >>> > > >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao > wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > >>> >> try to run the script > >>> >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > >>> >> but it will keep running and never end. When I use 'Ctrl + c' to > >>> >> terminate it, it will give the following output: > >>> >> > >>> >> $ python mu.py > >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >>> >> > >>> >> I have to terminate it and obtained the following information: > >>> >> > >>> >> ^CTraceback (most recent call last): > >>> >> File "mu.py", line 38, in > >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >>> >> line 2108, in __call__ > >>> >> return self._vectorize_call(func=func, args=vargs) > >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >>> >> line 2192, in _vectorize_call > >>> >> outputs = ufunc(*inputs) > >>> >> File "mu.py", line 8, in fermi > >>> >> return 1./(exp((E-mu)/kT)+1) > >>> >> KeyboardInterrupt > >>> >> > >>> >> > >>> >> Any helps and hints for this problem will be highly appreciated? > >>> >> > >>> >> Regards, > >>> >> -- > >>> >> Hongyi Zhao > >>> >> _______________________________________________ > >>> >> NumPy-Discussion mailing list > >>> >> NumPy-Discussion at python.org > >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >>> > > >>> > _______________________________________________ > >>> > NumPy-Discussion mailing list > >>> > NumPy-Discussion at python.org > >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >>> > >>> > >>> > >>> -- > >>> Hongyi Zhao > >>> _______________________________________________ > >>> NumPy-Discussion mailing list > >>> NumPy-Discussion at python.org > >>> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Sun Oct 11 02:32:19 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sun, 11 Oct 2020 14:32:19 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: > > > > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: >> > >> > >> > >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> >> >> >> Hi, >> >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >> >>> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >> >>> > >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >> >>> >> >>> Yes, it really does the trick. See the following for the benchmark >> >>> based on your suggestion: >> >>> >> >>> $ time python mu.py >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >>> >> >>> real 0m41.056s >> >>> user 0m43.970s >> >>> sys 0m3.813s >> >>> >> >>> >> >>> But are there any ways to further improve/increase efficiency? >> >> >> >> >> >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> >> >> >> Andrea. >> > >> > >> > >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. >> >> Still not so clear on your solutions for this problem. Could you >> please post here the corresponding snippet of your enhancement? > > > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. > > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - The size of the ?energy? and ?DOS? array is Problem-related and shouldn't be reduced arbitrarily. > not to mention calling trapz 6000 times in a loop. I'm currently thinking on parallelization the execution of the for loop, say, with joblib , but I still haven't figured out the corresponding codes. If you have some experience on this type of solution, could you please give me some more hints? > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... > >> >> >> Regards, >> HY >> > >> >> >> >> >> >>> >> >>> >> >>> Regards, >> >>> HY >> >>> >> >>> > >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> >>> >> >> >>> >> Hi, >> >>> >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> >>> >> try to run the script >> >>> >> , >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >> >>> >> terminate it, it will give the following output: >> >>> >> >> >>> >> $ python mu.py >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >>> >> >> >>> >> I have to terminate it and obtained the following information: >> >>> >> >> >>> >> ^CTraceback (most recent call last): >> >>> >> File "mu.py", line 38, in >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >>> >> line 2108, in __call__ >> >>> >> return self._vectorize_call(func=func, args=vargs) >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >>> >> line 2192, in _vectorize_call >> >>> >> outputs = ufunc(*inputs) >> >>> >> File "mu.py", line 8, in fermi >> >>> >> return 1./(exp((E-mu)/kT)+1) >> >>> >> KeyboardInterrupt >> >>> >> >> >>> >> >> >>> >> Any helps and hints for this problem will be highly appreciated? >> >>> >> >> >>> >> Regards, >> >>> >> -- >> >>> >> Hongyi Zhao >> >>> >> _______________________________________________ >> >>> >> NumPy-Discussion mailing list >> >>> >> NumPy-Discussion at python.org >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >>> > >> >>> > _______________________________________________ >> >>> > NumPy-Discussion mailing list >> >>> > NumPy-Discussion at python.org >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >>> >> >>> >> >>> >> >>> -- >> >>> Hongyi Zhao >> >>> _______________________________________________ >> >>> NumPy-Discussion mailing list >> >>> NumPy-Discussion at python.org >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From evgeny.burovskiy at gmail.com Sun Oct 11 02:55:26 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 11 Oct 2020 09:55:26 +0300 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: The script seems to be computing the particle numbers for an array of chemical potentials. Two ways of speeding it up, both are likely simpler then using dask: First: use numpy 1. Move constructing mu_all out of the loop (np.linspace) 2. Arrange the integrands into a 2d array 3. np.trapz along an axis which corresponds to a single integrand array (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) Second: Move the loop into cython. ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana > wrote: > > > > > > > > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: > >> > >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana > wrote: > >> > > >> > > >> > > >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana > wrote: > >> >> > >> >> Hi, > >> >> > >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao > wrote: > >> >>> > >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern > wrote: > >> >>> > > >> >>> > You don't need to use vectorize() on fermi(). fermi() will work > just fine on arrays and should be much faster. > >> >>> > >> >>> Yes, it really does the trick. See the following for the benchmark > >> >>> based on your suggestion: > >> >>> > >> >>> $ time python mu.py > >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >>> > >> >>> real 0m41.056s > >> >>> user 0m43.970s > >> >>> sys 0m3.813s > >> >>> > >> >>> > >> >>> But are there any ways to further improve/increase efficiency? > >> >> > >> >> > >> >> > >> >> I believe it will get a bit better if you don?t column_stack an > array 6000 times - maybe pre-allocate your output first? > >> >> > >> >> Andrea. > >> > > >> > > >> > > >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of > your column_stack call and made me think you were stacking your results > very many times, which is not the case. > >> > >> Still not so clear on your solutions for this problem. Could you > >> please post here the corresponding snippet of your enhancement? > > > > > > I have no solution, I originally thought you were calling ?column_stack? > 6000 times in the loop, but that is not the case, I was mistaken. My > apologies for that. > > > > The timings of your approach is highly dependent on the size of your > ?energy? and ?DOS? array - > > The size of the ?energy? and ?DOS? array is Problem-related and > shouldn't be reduced arbitrarily. > > > not to mention calling trapz 6000 times in a loop. > > I'm currently thinking on parallelization the execution of the for > loop, say, with joblib , but I still > haven't figured out the corresponding codes. If you have some > experience on this type of solution, could you please give me some > more hints? > > > Maybe there?s a better way to do it with another approach, but at the > moment I can?t think of one... > > > >> > >> > >> Regards, > >> HY > >> > > >> >> > >> >> > >> >>> > >> >>> > >> >>> Regards, > >> >>> HY > >> >>> > >> >>> > > >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao > wrote: > >> >>> >> > >> >>> >> Hi, > >> >>> >> > >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by > pyenv. I > >> >>> >> try to run the script > >> >>> >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to > >> >>> >> terminate it, it will give the following output: > >> >>> >> > >> >>> >> $ python mu.py > >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >>> >> > >> >>> >> I have to terminate it and obtained the following information: > >> >>> >> > >> >>> >> ^CTraceback (most recent call last): > >> >>> >> File "mu.py", line 38, in > >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >>> >> line 2108, in __call__ > >> >>> >> return self._vectorize_call(func=func, args=vargs) > >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >>> >> line 2192, in _vectorize_call > >> >>> >> outputs = ufunc(*inputs) > >> >>> >> File "mu.py", line 8, in fermi > >> >>> >> return 1./(exp((E-mu)/kT)+1) > >> >>> >> KeyboardInterrupt > >> >>> >> > >> >>> >> > >> >>> >> Any helps and hints for this problem will be highly appreciated? > >> >>> >> > >> >>> >> Regards, > >> >>> >> -- > >> >>> >> Hongyi Zhao > >> >>> >> _______________________________________________ > >> >>> >> NumPy-Discussion mailing list > >> >>> >> NumPy-Discussion at python.org > >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >>> > > >> >>> > _______________________________________________ > >> >>> > NumPy-Discussion mailing list > >> >>> > NumPy-Discussion at python.org > >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Hongyi Zhao > >> >>> _______________________________________________ > >> >>> NumPy-Discussion mailing list > >> >>> NumPy-Discussion at python.org > >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > > >> > _______________________________________________ > >> > NumPy-Discussion mailing list > >> > NumPy-Discussion at python.org > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Sun Oct 11 03:41:35 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 11 Oct 2020 10:41:35 +0300 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski wrote: > > The script seems to be computing the particle numbers for an array of chemical potentials. > > Two ways of speeding it up, both are likely simpler then using dask: > > First: use numpy > > 1. Move constructing mu_all out of the loop (np.linspace) > 2. Arrange the integrands into a 2d array > 3. np.trapz along an axis which corresponds to a single integrand array > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) Roughly like this: https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 > Second: > > Move the loop into cython. > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : >> >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: >> > >> > >> > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: >> >> >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: >> >> > >> >> > >> >> > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >> >> >>> >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >> >> >>> > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >> >> >>> >> >> >>> Yes, it really does the trick. See the following for the benchmark >> >> >>> based on your suggestion: >> >> >>> >> >> >>> $ time python mu.py >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >>> real 0m41.056s >> >> >>> user 0m43.970s >> >> >>> sys 0m3.813s >> >> >>> >> >> >>> >> >> >>> But are there any ways to further improve/increase efficiency? >> >> >> >> >> >> >> >> >> >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> >> >> >> >> >> Andrea. >> >> > >> >> > >> >> > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. >> >> >> >> Still not so clear on your solutions for this problem. Could you >> >> please post here the corresponding snippet of your enhancement? >> > >> > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. >> > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - >> >> The size of the ?energy? and ?DOS? array is Problem-related and >> shouldn't be reduced arbitrarily. >> >> > not to mention calling trapz 6000 times in a loop. >> >> I'm currently thinking on parallelization the execution of the for >> loop, say, with joblib , but I still >> haven't figured out the corresponding codes. If you have some >> experience on this type of solution, could you please give me some >> more hints? >> >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... >> > >> >> >> >> >> >> Regards, >> >> HY >> >> > >> >> >> >> >> >> >> >> >>> >> >> >>> >> >> >>> Regards, >> >> >>> HY >> >> >>> >> >> >>> > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> >> >>> >> >> >> >>> >> Hi, >> >> >>> >> >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> >> >>> >> try to run the script >> >> >>> >> , >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >> >> >>> >> terminate it, it will give the following output: >> >> >>> >> >> >> >>> >> $ python mu.py >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >> >>> >> I have to terminate it and obtained the following information: >> >> >>> >> >> >> >>> >> ^CTraceback (most recent call last): >> >> >>> >> File "mu.py", line 38, in >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2108, in __call__ >> >> >>> >> return self._vectorize_call(func=func, args=vargs) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2192, in _vectorize_call >> >> >>> >> outputs = ufunc(*inputs) >> >> >>> >> File "mu.py", line 8, in fermi >> >> >>> >> return 1./(exp((E-mu)/kT)+1) >> >> >>> >> KeyboardInterrupt >> >> >>> >> >> >> >>> >> >> >> >>> >> Any helps and hints for this problem will be highly appreciated? >> >> >>> >> >> >> >>> >> Regards, >> >> >>> >> -- >> >> >>> >> Hongyi Zhao >> >> >>> >> _______________________________________________ >> >> >>> >> NumPy-Discussion mailing list >> >> >>> >> NumPy-Discussion at python.org >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > NumPy-Discussion mailing list >> >> >>> > NumPy-Discussion at python.org >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Hongyi Zhao >> >> >>> _______________________________________________ >> >> >>> NumPy-Discussion mailing list >> >> >>> NumPy-Discussion at python.org >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > >> >> > _______________________________________________ >> >> > NumPy-Discussion mailing list >> >> > NumPy-Discussion at python.org >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> >> >> >> >> -- >> >> Hongyi Zhao >> >> _______________________________________________ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion at python.org >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion From hongyi.zhao at gmail.com Sun Oct 11 06:27:51 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sun, 11 Oct 2020 18:27:51 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 2:56 PM Evgeni Burovski wrote: > > The script seems to be computing the particle numbers for an array of chemical potentials. > > Two ways of speeding it up, both are likely simpler then using dask: What do you mean by saying *dask*? > > First: use numpy > > 1. Move constructing mu_all out of the loop (np.linspace) > 2. Arrange the integrands into a 2d array > 3. np.trapz along an axis which corresponds to a single integrand array > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) > > Second: > > Move the loop into cython. Will this be more efficient than the schema like parallelization based on python modules, say, joblib? > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : >> >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: >> > >> > >> > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: >> >> >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: >> >> > >> >> > >> >> > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >> >> >>> >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >> >> >>> > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >> >> >>> >> >> >>> Yes, it really does the trick. See the following for the benchmark >> >> >>> based on your suggestion: >> >> >>> >> >> >>> $ time python mu.py >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >>> real 0m41.056s >> >> >>> user 0m43.970s >> >> >>> sys 0m3.813s >> >> >>> >> >> >>> >> >> >>> But are there any ways to further improve/increase efficiency? >> >> >> >> >> >> >> >> >> >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> >> >> >> >> >> Andrea. >> >> > >> >> > >> >> > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. >> >> >> >> Still not so clear on your solutions for this problem. Could you >> >> please post here the corresponding snippet of your enhancement? >> > >> > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. >> > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - >> >> The size of the ?energy? and ?DOS? array is Problem-related and >> shouldn't be reduced arbitrarily. >> >> > not to mention calling trapz 6000 times in a loop. >> >> I'm currently thinking on parallelization the execution of the for >> loop, say, with joblib , but I still >> haven't figured out the corresponding codes. If you have some >> experience on this type of solution, could you please give me some >> more hints? >> >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... >> > >> >> >> >> >> >> Regards, >> >> HY >> >> > >> >> >> >> >> >> >> >> >>> >> >> >>> >> >> >>> Regards, >> >> >>> HY >> >> >>> >> >> >>> > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> >> >>> >> >> >> >>> >> Hi, >> >> >>> >> >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> >> >>> >> try to run the script >> >> >>> >> , >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >> >> >>> >> terminate it, it will give the following output: >> >> >>> >> >> >> >>> >> $ python mu.py >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >> >>> >> I have to terminate it and obtained the following information: >> >> >>> >> >> >> >>> >> ^CTraceback (most recent call last): >> >> >>> >> File "mu.py", line 38, in >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2108, in __call__ >> >> >>> >> return self._vectorize_call(func=func, args=vargs) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2192, in _vectorize_call >> >> >>> >> outputs = ufunc(*inputs) >> >> >>> >> File "mu.py", line 8, in fermi >> >> >>> >> return 1./(exp((E-mu)/kT)+1) >> >> >>> >> KeyboardInterrupt >> >> >>> >> >> >> >>> >> >> >> >>> >> Any helps and hints for this problem will be highly appreciated? >> >> >>> >> >> >> >>> >> Regards, >> >> >>> >> -- >> >> >>> >> Hongyi Zhao >> >> >>> >> _______________________________________________ >> >> >>> >> NumPy-Discussion mailing list >> >> >>> >> NumPy-Discussion at python.org >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > NumPy-Discussion mailing list >> >> >>> > NumPy-Discussion at python.org >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Hongyi Zhao >> >> >>> _______________________________________________ >> >> >>> NumPy-Discussion mailing list >> >> >>> NumPy-Discussion at python.org >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > >> >> > _______________________________________________ >> >> > NumPy-Discussion mailing list >> >> > NumPy-Discussion at python.org >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> >> >> >> >> -- >> >> Hongyi Zhao >> >> _______________________________________________ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion at python.org >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From hongyi.zhao at gmail.com Sun Oct 11 06:31:20 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sun, 11 Oct 2020 18:31:20 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski wrote: > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > wrote: > > > > The script seems to be computing the particle numbers for an array of chemical potentials. > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > First: use numpy > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > 2. Arrange the integrands into a 2d array > > 3. np.trapz along an axis which corresponds to a single integrand array > > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) > > > Roughly like this: > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 I can't find the cython part suggested by you, i.e., move the loop into cython. Furthermore, I also learned that the numpy array is optimized and has the performance close to C/C++. > > > > > Second: > > > > Move the loop into cython. > > > > > > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > >> > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: > >> > > >> > > >> > > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: > >> >> > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: > >> >> >>> > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: > >> >> >>> > > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. > >> >> >>> > >> >> >>> Yes, it really does the trick. See the following for the benchmark > >> >> >>> based on your suggestion: > >> >> >>> > >> >> >>> $ time python mu.py > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> > >> >> >>> real 0m41.056s > >> >> >>> user 0m43.970s > >> >> >>> sys 0m3.813s > >> >> >>> > >> >> >>> > >> >> >>> But are there any ways to further improve/increase efficiency? > >> >> >> > >> >> >> > >> >> >> > >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? > >> >> >> > >> >> >> Andrea. > >> >> > > >> >> > > >> >> > > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. > >> >> > >> >> Still not so clear on your solutions for this problem. Could you > >> >> please post here the corresponding snippet of your enhancement? > >> > > >> > > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. > >> > > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - > >> > >> The size of the ?energy? and ?DOS? array is Problem-related and > >> shouldn't be reduced arbitrarily. > >> > >> > not to mention calling trapz 6000 times in a loop. > >> > >> I'm currently thinking on parallelization the execution of the for > >> loop, say, with joblib , but I still > >> haven't figured out the corresponding codes. If you have some > >> experience on this type of solution, could you please give me some > >> more hints? > >> > >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... > >> > > >> >> > >> >> > >> >> Regards, > >> >> HY > >> >> > > >> >> >> > >> >> >> > >> >> >>> > >> >> >>> > >> >> >>> Regards, > >> >> >>> HY > >> >> >>> > >> >> >>> > > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: > >> >> >>> >> > >> >> >>> >> Hi, > >> >> >>> >> > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > >> >> >>> >> try to run the script > >> >> >>> >> , > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to > >> >> >>> >> terminate it, it will give the following output: > >> >> >>> >> > >> >> >>> >> $ python mu.py > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> >> > >> >> >>> >> I have to terminate it and obtained the following information: > >> >> >>> >> > >> >> >>> >> ^CTraceback (most recent call last): > >> >> >>> >> File "mu.py", line 38, in > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2108, in __call__ > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2192, in _vectorize_call > >> >> >>> >> outputs = ufunc(*inputs) > >> >> >>> >> File "mu.py", line 8, in fermi > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > >> >> >>> >> KeyboardInterrupt > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> Any helps and hints for this problem will be highly appreciated? > >> >> >>> >> > >> >> >>> >> Regards, > >> >> >>> >> -- > >> >> >>> >> Hongyi Zhao > >> >> >>> >> _______________________________________________ > >> >> >>> >> NumPy-Discussion mailing list > >> >> >>> >> NumPy-Discussion at python.org > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > > >> >> >>> > _______________________________________________ > >> >> >>> > NumPy-Discussion mailing list > >> >> >>> > NumPy-Discussion at python.org > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Hongyi Zhao > >> >> >>> _______________________________________________ > >> >> >>> NumPy-Discussion mailing list > >> >> >>> NumPy-Discussion at python.org > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > > >> >> > _______________________________________________ > >> >> > NumPy-Discussion mailing list > >> >> > NumPy-Discussion at python.org > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > >> >> > >> >> > >> >> -- > >> >> Hongyi Zhao > >> >> _______________________________________________ > >> >> NumPy-Discussion mailing list > >> >> NumPy-Discussion at python.org > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > > >> > _______________________________________________ > >> > NumPy-Discussion mailing list > >> > NumPy-Discussion at python.org > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From evgeny.burovskiy at gmail.com Sun Oct 11 08:42:03 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 11 Oct 2020 15:42:03 +0300 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: ??, 11 ???. 2020 ?., 13:31 Hongyi Zhao : > On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski > wrote: > > > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > > wrote: > > > > > > The script seems to be computing the particle numbers for an array of > chemical potentials. > > > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > > > First: use numpy > > > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > > 2. Arrange the integrands into a 2d array > > > 3. np.trapz along an axis which corresponds to a single integrand array > > > (Or avoid the overhead of trapz by just implementing the trapezoid > formula manually) > > > > > > Roughly like this: > > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 > > I can't find the cython part suggested by you, i.e., move the loop > into cython. Furthermore, I also learned that the numpy array is > optimized and has the performance close to C/C++. > > > Basically, it seems pure numpy is OK here and nothing more sophisticated > is needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Sun Oct 11 22:55:29 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Mon, 12 Oct 2020 10:55:29 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski wrote: > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > wrote: > > > > The script seems to be computing the particle numbers for an array of chemical potentials. > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > First: use numpy > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > 2. Arrange the integrands into a 2d array > > 3. np.trapz along an axis which corresponds to a single integrand array > > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) > > > Roughly like this: > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 I try to run this notebook, but find that all of the function/variable/method can't be found at all, if invoke them in separate cells. See here for more details: https://github.com/hongyi-zhao/test/blob/master/fermi_integrate_np.ipynb Any hints for this problem? Regards, HY > > > > > Second: > > > > Move the loop into cython. > > > > > > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > >> > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: > >> > > >> > > >> > > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: > >> >> > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: > >> >> >>> > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: > >> >> >>> > > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. > >> >> >>> > >> >> >>> Yes, it really does the trick. See the following for the benchmark > >> >> >>> based on your suggestion: > >> >> >>> > >> >> >>> $ time python mu.py > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> > >> >> >>> real 0m41.056s > >> >> >>> user 0m43.970s > >> >> >>> sys 0m3.813s > >> >> >>> > >> >> >>> > >> >> >>> But are there any ways to further improve/increase efficiency? > >> >> >> > >> >> >> > >> >> >> > >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? > >> >> >> > >> >> >> Andrea. > >> >> > > >> >> > > >> >> > > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. > >> >> > >> >> Still not so clear on your solutions for this problem. Could you > >> >> please post here the corresponding snippet of your enhancement? > >> > > >> > > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. > >> > > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - > >> > >> The size of the ?energy? and ?DOS? array is Problem-related and > >> shouldn't be reduced arbitrarily. > >> > >> > not to mention calling trapz 6000 times in a loop. > >> > >> I'm currently thinking on parallelization the execution of the for > >> loop, say, with joblib , but I still > >> haven't figured out the corresponding codes. If you have some > >> experience on this type of solution, could you please give me some > >> more hints? > >> > >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... > >> > > >> >> > >> >> > >> >> Regards, > >> >> HY > >> >> > > >> >> >> > >> >> >> > >> >> >>> > >> >> >>> > >> >> >>> Regards, > >> >> >>> HY > >> >> >>> > >> >> >>> > > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: > >> >> >>> >> > >> >> >>> >> Hi, > >> >> >>> >> > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > >> >> >>> >> try to run the script > >> >> >>> >> , > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to > >> >> >>> >> terminate it, it will give the following output: > >> >> >>> >> > >> >> >>> >> $ python mu.py > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> >> > >> >> >>> >> I have to terminate it and obtained the following information: > >> >> >>> >> > >> >> >>> >> ^CTraceback (most recent call last): > >> >> >>> >> File "mu.py", line 38, in > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2108, in __call__ > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2192, in _vectorize_call > >> >> >>> >> outputs = ufunc(*inputs) > >> >> >>> >> File "mu.py", line 8, in fermi > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > >> >> >>> >> KeyboardInterrupt > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> Any helps and hints for this problem will be highly appreciated? > >> >> >>> >> > >> >> >>> >> Regards, > >> >> >>> >> -- > >> >> >>> >> Hongyi Zhao > >> >> >>> >> _______________________________________________ > >> >> >>> >> NumPy-Discussion mailing list > >> >> >>> >> NumPy-Discussion at python.org > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > > >> >> >>> > _______________________________________________ > >> >> >>> > NumPy-Discussion mailing list > >> >> >>> > NumPy-Discussion at python.org > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Hongyi Zhao > >> >> >>> _______________________________________________ > >> >> >>> NumPy-Discussion mailing list > >> >> >>> NumPy-Discussion at python.org > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > > >> >> > _______________________________________________ > >> >> > NumPy-Discussion mailing list > >> >> > NumPy-Discussion at python.org > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > >> >> > >> >> > >> >> -- > >> >> Hongyi Zhao > >> >> _______________________________________________ > >> >> NumPy-Discussion mailing list > >> >> NumPy-Discussion at python.org > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > > >> > _______________________________________________ > >> > NumPy-Discussion mailing list > >> > NumPy-Discussion at python.org > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From evgeny.burovskiy at gmail.com Mon Oct 12 01:31:10 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 12 Oct 2020 08:31:10 +0300 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: Just remove %%timeit ??, 12 ???. 2020 ?., 5:56 Hongyi Zhao : > On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski > wrote: > > > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > > wrote: > > > > > > The script seems to be computing the particle numbers for an array of > chemical potentials. > > > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > > > First: use numpy > > > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > > 2. Arrange the integrands into a 2d array > > > 3. np.trapz along an axis which corresponds to a single integrand array > > > (Or avoid the overhead of trapz by just implementing the trapezoid > formula manually) > > > > > > Roughly like this: > > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 > > I try to run this notebook, but find that all of the > function/variable/method can't be found at all, if invoke them in > separate cells. See here for more details: > > https://github.com/hongyi-zhao/test/blob/master/fermi_integrate_np.ipynb > > Any hints for this problem? > > Regards, > HY > > > > > > > > > > Second: > > > > > > Move the loop into cython. > > > > > > > > > > > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > > >> > > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> > > > >> > > > >> > > > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao > wrote: > > >> >> > > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> >> > > > >> >> > > > >> >> > > > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> >> >> > > >> >> >> Hi, > > >> >> >> > > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > > >> >> >>> > > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern < > robert.kern at gmail.com> wrote: > > >> >> >>> > > > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will > work just fine on arrays and should be much faster. > > >> >> >>> > > >> >> >>> Yes, it really does the trick. See the following for the > benchmark > > >> >> >>> based on your suggestion: > > >> >> >>> > > >> >> >>> $ time python mu.py > > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > >> >> >>> > > >> >> >>> real 0m41.056s > > >> >> >>> user 0m43.970s > > >> >> >>> sys 0m3.813s > > >> >> >>> > > >> >> >>> > > >> >> >>> But are there any ways to further improve/increase efficiency? > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> I believe it will get a bit better if you don?t column_stack an > array 6000 times - maybe pre-allocate your output first? > > >> >> >> > > >> >> >> Andrea. > > >> >> > > > >> >> > > > >> >> > > > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front > of your column_stack call and made me think you were stacking your results > very many times, which is not the case. > > >> >> > > >> >> Still not so clear on your solutions for this problem. Could you > > >> >> please post here the corresponding snippet of your enhancement? > > >> > > > >> > > > >> > I have no solution, I originally thought you were calling > ?column_stack? 6000 times in the loop, but that is not the case, I was > mistaken. My apologies for that. > > >> > > > >> > The timings of your approach is highly dependent on the size of > your ?energy? and ?DOS? array - > > >> > > >> The size of the ?energy? and ?DOS? array is Problem-related and > > >> shouldn't be reduced arbitrarily. > > >> > > >> > not to mention calling trapz 6000 times in a loop. > > >> > > >> I'm currently thinking on parallelization the execution of the for > > >> loop, say, with joblib , but I > still > > >> haven't figured out the corresponding codes. If you have some > > >> experience on this type of solution, could you please give me some > > >> more hints? > > >> > > >> > Maybe there?s a better way to do it with another approach, but at > the moment I can?t think of one... > > >> > > > >> >> > > >> >> > > >> >> Regards, > > >> >> HY > > >> >> > > > >> >> >> > > >> >> >> > > >> >> >>> > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> HY > > >> >> >>> > > >> >> >>> > > > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > > >> >> >>> >> > > >> >> >>> >> Hi, > > >> >> >>> >> > > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by > pyenv. I > > >> >> >>> >> try to run the script > > >> >> >>> >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + > c' to > > >> >> >>> >> terminate it, it will give the following output: > > >> >> >>> >> > > >> >> >>> >> $ python mu.py > > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > >> >> >>> >> > > >> >> >>> >> I have to terminate it and obtained the following > information: > > >> >> >>> >> > > >> >> >>> >> ^CTraceback (most recent call last): > > >> >> >>> >> File "mu.py", line 38, in > > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > > >> >> >>> >> line 2108, in __call__ > > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > > >> >> >>> >> line 2192, in _vectorize_call > > >> >> >>> >> outputs = ufunc(*inputs) > > >> >> >>> >> File "mu.py", line 8, in fermi > > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > > >> >> >>> >> KeyboardInterrupt > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> Any helps and hints for this problem will be highly > appreciated? > > >> >> >>> >> > > >> >> >>> >> Regards, > > >> >> >>> >> -- > > >> >> >>> >> Hongyi Zhao > > >> >> >>> >> _______________________________________________ > > >> >> >>> >> NumPy-Discussion mailing list > > >> >> >>> >> NumPy-Discussion at python.org > > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> >>> > > > >> >> >>> > _______________________________________________ > > >> >> >>> > NumPy-Discussion mailing list > > >> >> >>> > NumPy-Discussion at python.org > > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> -- > > >> >> >>> Hongyi Zhao > > >> >> >>> _______________________________________________ > > >> >> >>> NumPy-Discussion mailing list > > >> >> >>> NumPy-Discussion at python.org > > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> > > > >> >> > _______________________________________________ > > >> >> > NumPy-Discussion mailing list > > >> >> > NumPy-Discussion at python.org > > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> > > >> >> > > >> >> > > >> >> -- > > >> >> Hongyi Zhao > > >> >> _______________________________________________ > > >> >> NumPy-Discussion mailing list > > >> >> NumPy-Discussion at python.org > > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> > > > >> > _______________________________________________ > > >> > NumPy-Discussion mailing list > > >> > NumPy-Discussion at python.org > > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> > > >> > > >> > > >> -- > > >> Hongyi Zhao > > >> _______________________________________________ > > >> NumPy-Discussion mailing list > > >> NumPy-Discussion at python.org > > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Mon Oct 12 01:47:22 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Mon, 12 Oct 2020 13:47:22 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 2:56 PM Evgeni Burovski wrote: > > The script seems to be computing the particle numbers for an array of chemical potentials. > > Two ways of speeding it up, both are likely simpler then using dask: > > First: use numpy > > 1. Move constructing mu_all out of the loop (np.linspace) > 2. Arrange the integrands into a 2d array > 3. np.trapz along an axis which corresponds to a single integrand array > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) Could you please give me some more explanations on the reasons why doing so can improve performance? > > Second: > > Move the loop into cython. > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : >> >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: >> > >> > >> > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: >> >> >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: >> >> > >> >> > >> >> > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >> >> >>> >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >> >> >>> > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >> >> >>> >> >> >>> Yes, it really does the trick. See the following for the benchmark >> >> >>> based on your suggestion: >> >> >>> >> >> >>> $ time python mu.py >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >>> real 0m41.056s >> >> >>> user 0m43.970s >> >> >>> sys 0m3.813s >> >> >>> >> >> >>> >> >> >>> But are there any ways to further improve/increase efficiency? >> >> >> >> >> >> >> >> >> >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> >> >> >> >> >> Andrea. >> >> > >> >> > >> >> > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. >> >> >> >> Still not so clear on your solutions for this problem. Could you >> >> please post here the corresponding snippet of your enhancement? >> > >> > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. >> > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - >> >> The size of the ?energy? and ?DOS? array is Problem-related and >> shouldn't be reduced arbitrarily. >> >> > not to mention calling trapz 6000 times in a loop. >> >> I'm currently thinking on parallelization the execution of the for >> loop, say, with joblib , but I still >> haven't figured out the corresponding codes. If you have some >> experience on this type of solution, could you please give me some >> more hints? >> >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... >> > >> >> >> >> >> >> Regards, >> >> HY >> >> > >> >> >> >> >> >> >> >> >>> >> >> >>> >> >> >>> Regards, >> >> >>> HY >> >> >>> >> >> >>> > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> >> >>> >> >> >> >>> >> Hi, >> >> >>> >> >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> >> >>> >> try to run the script >> >> >>> >> , >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >> >> >>> >> terminate it, it will give the following output: >> >> >>> >> >> >> >>> >> $ python mu.py >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> >> >>> >> >> >> >>> >> I have to terminate it and obtained the following information: >> >> >>> >> >> >> >>> >> ^CTraceback (most recent call last): >> >> >>> >> File "mu.py", line 38, in >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2108, in __call__ >> >> >>> >> return self._vectorize_call(func=func, args=vargs) >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> >> >>> >> line 2192, in _vectorize_call >> >> >>> >> outputs = ufunc(*inputs) >> >> >>> >> File "mu.py", line 8, in fermi >> >> >>> >> return 1./(exp((E-mu)/kT)+1) >> >> >>> >> KeyboardInterrupt >> >> >>> >> >> >> >>> >> >> >> >>> >> Any helps and hints for this problem will be highly appreciated? >> >> >>> >> >> >> >>> >> Regards, >> >> >>> >> -- >> >> >>> >> Hongyi Zhao >> >> >>> >> _______________________________________________ >> >> >>> >> NumPy-Discussion mailing list >> >> >>> >> NumPy-Discussion at python.org >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > NumPy-Discussion mailing list >> >> >>> > NumPy-Discussion at python.org >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Hongyi Zhao >> >> >>> _______________________________________________ >> >> >>> NumPy-Discussion mailing list >> >> >>> NumPy-Discussion at python.org >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > >> >> > _______________________________________________ >> >> > NumPy-Discussion mailing list >> >> > NumPy-Discussion at python.org >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> >> >> >> >> -- >> >> Hongyi Zhao >> >> _______________________________________________ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion at python.org >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From klaus.zimmermann at smhi.se Mon Oct 12 04:39:03 2020 From: klaus.zimmermann at smhi.se (Zimmermann Klaus) Date: Mon, 12 Oct 2020 08:39:03 +0000 Subject: [Numpy-discussion] Add sliding_window_view method to numpy Message-ID: Hello, I would like to draw the attention of this list to PR #17394 [1] that adds the implementation of a sliding window view to numpy. Having a sliding window view in numpy is a longstanding open issue (cf #7753 [2] from 2016). A brief summary of the discussions surrounding it can be found in the description of the PR. This PR implements a sliding window view based on stride tricks. Following the discussion in issue #7753, a first implementation was provided by Fanjin Zeng in PR #10771. After some discussion, that PR stalled and I picked up the issue in the present PR #17394. It is based on the first implementation, but follows the changed API as suggested by Eric Wieser. Code reviews have been provided by Bas van Beek, Stephen Hoyer, and Eric Wieser. Sebastian Berg added the "62 - Python API" label. Do you think this is suitable for inclusion in numpy? Do you consider the PR ready? Do you have suggestions or requests? Thanks for your time and consideration! Klaus [1] https://github.com/numpy/numpy/pull/17394 [2] https://github.com/numpy/numpy/issues/7753 From hongyi.zhao at gmail.com Mon Oct 12 08:37:28 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Mon, 12 Oct 2020 20:37:28 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski wrote: > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > wrote: > > > > The script seems to be computing the particle numbers for an array of chemical potentials. > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > First: use numpy > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > 2. Arrange the integrands into a 2d array > > 3. np.trapz along an axis which corresponds to a single integrand array > > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) > > > Roughly like this: > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 I've done the comparison of the real execution time for your version I've compared the execution efficiency of your above method and the original method of the python script by directly using fermi() without executing vectorize() on it. Very surprisingly, the latter is more efficient than the former, see following for more info: $ time python fermi_integrate_np.py [[1.03000000e+01 4.55561775e+17] [1.03001000e+01 4.55561780e+17] [1.03002000e+01 4.55561786e+17] ... [1.08997000e+01 1.33654085e+21] [1.08998000e+01 1.33818034e+21] [1.08999000e+01 1.33982054e+21]] real 1m8.797s user 0m47.204s sys 0m27.105s $ time python mu.py [[1.03000000e+01 4.55561775e+17] [1.03001000e+01 4.55561780e+17] [1.03002000e+01 4.55561786e+17] ... [1.08997000e+01 1.33654085e+21] [1.08998000e+01 1.33818034e+21] [1.08999000e+01 1.33982054e+21]] real 0m38.829s user 0m41.541s sys 0m3.399s So, I think that the benchmark dataset used by you for testing code efficiency is not so appropriate. What's your point of view on this testing results? Regards, HY > > > > > Second: > > > > Move the loop into cython. > > > > > > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > >> > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: > >> > > >> > > >> > > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: > >> >> > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: > >> >> >>> > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: > >> >> >>> > > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. > >> >> >>> > >> >> >>> Yes, it really does the trick. See the following for the benchmark > >> >> >>> based on your suggestion: > >> >> >>> > >> >> >>> $ time python mu.py > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> > >> >> >>> real 0m41.056s > >> >> >>> user 0m43.970s > >> >> >>> sys 0m3.813s > >> >> >>> > >> >> >>> > >> >> >>> But are there any ways to further improve/increase efficiency? > >> >> >> > >> >> >> > >> >> >> > >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? > >> >> >> > >> >> >> Andrea. > >> >> > > >> >> > > >> >> > > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. > >> >> > >> >> Still not so clear on your solutions for this problem. Could you > >> >> please post here the corresponding snippet of your enhancement? > >> > > >> > > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. > >> > > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - > >> > >> The size of the ?energy? and ?DOS? array is Problem-related and > >> shouldn't be reduced arbitrarily. > >> > >> > not to mention calling trapz 6000 times in a loop. > >> > >> I'm currently thinking on parallelization the execution of the for > >> loop, say, with joblib , but I still > >> haven't figured out the corresponding codes. If you have some > >> experience on this type of solution, could you please give me some > >> more hints? > >> > >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... > >> > > >> >> > >> >> > >> >> Regards, > >> >> HY > >> >> > > >> >> >> > >> >> >> > >> >> >>> > >> >> >>> > >> >> >>> Regards, > >> >> >>> HY > >> >> >>> > >> >> >>> > > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: > >> >> >>> >> > >> >> >>> >> Hi, > >> >> >>> >> > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I > >> >> >>> >> try to run the script > >> >> >>> >> , > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to > >> >> >>> >> terminate it, it will give the following output: > >> >> >>> >> > >> >> >>> >> $ python mu.py > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> >> >>> >> > >> >> >>> >> I have to terminate it and obtained the following information: > >> >> >>> >> > >> >> >>> >> ^CTraceback (most recent call last): > >> >> >>> >> File "mu.py", line 38, in > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2108, in __call__ > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> >> >>> >> line 2192, in _vectorize_call > >> >> >>> >> outputs = ufunc(*inputs) > >> >> >>> >> File "mu.py", line 8, in fermi > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > >> >> >>> >> KeyboardInterrupt > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> Any helps and hints for this problem will be highly appreciated? > >> >> >>> >> > >> >> >>> >> Regards, > >> >> >>> >> -- > >> >> >>> >> Hongyi Zhao > >> >> >>> >> _______________________________________________ > >> >> >>> >> NumPy-Discussion mailing list > >> >> >>> >> NumPy-Discussion at python.org > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > > >> >> >>> > _______________________________________________ > >> >> >>> > NumPy-Discussion mailing list > >> >> >>> > NumPy-Discussion at python.org > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Hongyi Zhao > >> >> >>> _______________________________________________ > >> >> >>> NumPy-Discussion mailing list > >> >> >>> NumPy-Discussion at python.org > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > > >> >> > _______________________________________________ > >> >> > NumPy-Discussion mailing list > >> >> > NumPy-Discussion at python.org > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> >> > >> >> > >> >> > >> >> -- > >> >> Hongyi Zhao > >> >> _______________________________________________ > >> >> NumPy-Discussion mailing list > >> >> NumPy-Discussion at python.org > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > > >> > _______________________________________________ > >> > NumPy-Discussion mailing list > >> > NumPy-Discussion at python.org > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From andrea.gavana at gmail.com Mon Oct 12 09:33:06 2020 From: andrea.gavana at gmail.com (Andrea Gavana) Date: Mon, 12 Oct 2020 15:33:06 +0200 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: Hi, On Mon, 12 Oct 2020 at 14:38, Hongyi Zhao wrote: > On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski > wrote: > > > > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > > wrote: > > > > > > The script seems to be computing the particle numbers for an array of > chemical potentials. > > > > > > Two ways of speeding it up, both are likely simpler then using dask: > > > > > > First: use numpy > > > > > > 1. Move constructing mu_all out of the loop (np.linspace) > > > 2. Arrange the integrands into a 2d array > > > 3. np.trapz along an axis which corresponds to a single integrand array > > > (Or avoid the overhead of trapz by just implementing the trapezoid > formula manually) > > > > > > Roughly like this: > > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 > > I've done the comparison of the real execution time for your version > I've compared the execution efficiency of your above method and the > original method of the python script by directly using fermi() without > executing vectorize() on it. Very surprisingly, the latter is more > efficient than the former, see following for more info: > > $ time python fermi_integrate_np.py > [[1.03000000e+01 4.55561775e+17] > [1.03001000e+01 4.55561780e+17] > [1.03002000e+01 4.55561786e+17] > ... > [1.08997000e+01 1.33654085e+21] > [1.08998000e+01 1.33818034e+21] > [1.08999000e+01 1.33982054e+21]] > > real 1m8.797s > user 0m47.204s > sys 0m27.105s > $ time python mu.py > [[1.03000000e+01 4.55561775e+17] > [1.03001000e+01 4.55561780e+17] > [1.03002000e+01 4.55561786e+17] > ... > [1.08997000e+01 1.33654085e+21] > [1.08998000e+01 1.33818034e+21] > [1.08999000e+01 1.33982054e+21]] > > real 0m38.829s > user 0m41.541s > sys 0m3.399s > > So, I think that the benchmark dataset used by you for testing code > efficiency is not so appropriate. What's your point of view on this > testing results? > Evgeni has provided an interesting example on how to speed up your code - granted, he used toy data but the improvement is real. As far as I can see, you haven't specified how big are your DOS etc... vectors, so it's not that obvious how to draw any conclusions. I find it highly puzzling that his implementation appears to be slower than your original code. In any case, if performance is so paramount for you, then I would suggest you to move in the direction Evgeni was proposing, i.e. shifting your implementation to C/Cython or Fortran/f2py. I had much better results myself using Fortran/f2py than pure NumPy or C/Cython, but this is mostly because my knowledge of Cython is quite limited. That said, your problem should be fairly easy to implement in a compiled language. Andrea. > > Regards, > HY > > > > > > > > > > Second: > > > > > > Move the loop into cython. > > > > > > > > > > > > > > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > > >> > > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> > > > >> > > > >> > > > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao > wrote: > > >> >> > > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> >> > > > >> >> > > > >> >> > > > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana < > andrea.gavana at gmail.com> wrote: > > >> >> >> > > >> >> >> Hi, > > >> >> >> > > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > > >> >> >>> > > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern < > robert.kern at gmail.com> wrote: > > >> >> >>> > > > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will > work just fine on arrays and should be much faster. > > >> >> >>> > > >> >> >>> Yes, it really does the trick. See the following for the > benchmark > > >> >> >>> based on your suggestion: > > >> >> >>> > > >> >> >>> $ time python mu.py > > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > >> >> >>> > > >> >> >>> real 0m41.056s > > >> >> >>> user 0m43.970s > > >> >> >>> sys 0m3.813s > > >> >> >>> > > >> >> >>> > > >> >> >>> But are there any ways to further improve/increase efficiency? > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> I believe it will get a bit better if you don?t column_stack an > array 6000 times - maybe pre-allocate your output first? > > >> >> >> > > >> >> >> Andrea. > > >> >> > > > >> >> > > > >> >> > > > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front > of your column_stack call and made me think you were stacking your results > very many times, which is not the case. > > >> >> > > >> >> Still not so clear on your solutions for this problem. Could you > > >> >> please post here the corresponding snippet of your enhancement? > > >> > > > >> > > > >> > I have no solution, I originally thought you were calling > ?column_stack? 6000 times in the loop, but that is not the case, I was > mistaken. My apologies for that. > > >> > > > >> > The timings of your approach is highly dependent on the size of > your ?energy? and ?DOS? array - > > >> > > >> The size of the ?energy? and ?DOS? array is Problem-related and > > >> shouldn't be reduced arbitrarily. > > >> > > >> > not to mention calling trapz 6000 times in a loop. > > >> > > >> I'm currently thinking on parallelization the execution of the for > > >> loop, say, with joblib , but I > still > > >> haven't figured out the corresponding codes. If you have some > > >> experience on this type of solution, could you please give me some > > >> more hints? > > >> > > >> > Maybe there?s a better way to do it with another approach, but at > the moment I can?t think of one... > > >> > > > >> >> > > >> >> > > >> >> Regards, > > >> >> HY > > >> >> > > > >> >> >> > > >> >> >> > > >> >> >>> > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> HY > > >> >> >>> > > >> >> >>> > > > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > > >> >> >>> >> > > >> >> >>> >> Hi, > > >> >> >>> >> > > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by > pyenv. I > > >> >> >>> >> try to run the script > > >> >> >>> >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + > c' to > > >> >> >>> >> terminate it, it will give the following output: > > >> >> >>> >> > > >> >> >>> >> $ python mu.py > > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > > >> >> >>> >> > > >> >> >>> >> I have to terminate it and obtained the following > information: > > >> >> >>> >> > > >> >> >>> >> ^CTraceback (most recent call last): > > >> >> >>> >> File "mu.py", line 38, in > > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > > >> >> >>> >> line 2108, in __call__ > > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > > >> >> >>> >> line 2192, in _vectorize_call > > >> >> >>> >> outputs = ufunc(*inputs) > > >> >> >>> >> File "mu.py", line 8, in fermi > > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > > >> >> >>> >> KeyboardInterrupt > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> Any helps and hints for this problem will be highly > appreciated? > > >> >> >>> >> > > >> >> >>> >> Regards, > > >> >> >>> >> -- > > >> >> >>> >> Hongyi Zhao > > >> >> >>> >> _______________________________________________ > > >> >> >>> >> NumPy-Discussion mailing list > > >> >> >>> >> NumPy-Discussion at python.org > > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> >>> > > > >> >> >>> > _______________________________________________ > > >> >> >>> > NumPy-Discussion mailing list > > >> >> >>> > NumPy-Discussion at python.org > > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> -- > > >> >> >>> Hongyi Zhao > > >> >> >>> _______________________________________________ > > >> >> >>> NumPy-Discussion mailing list > > >> >> >>> NumPy-Discussion at python.org > > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> > > > >> >> > _______________________________________________ > > >> >> > NumPy-Discussion mailing list > > >> >> > NumPy-Discussion at python.org > > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> >> > > >> >> > > >> >> > > >> >> -- > > >> >> Hongyi Zhao > > >> >> _______________________________________________ > > >> >> NumPy-Discussion mailing list > > >> >> NumPy-Discussion at python.org > > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > > >> > > > >> > _______________________________________________ > > >> > NumPy-Discussion mailing list > > >> > NumPy-Discussion at python.org > > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > > >> > > >> > > >> > > >> -- > > >> Hongyi Zhao > > >> _______________________________________________ > > >> NumPy-Discussion mailing list > > >> NumPy-Discussion at python.org > > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Mon Oct 12 10:20:49 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Mon, 12 Oct 2020 22:20:49 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Mon, Oct 12, 2020 at 9:33 PM Andrea Gavana wrote: > > Hi, > > On Mon, 12 Oct 2020 at 14:38, Hongyi Zhao wrote: >> >> On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski >> wrote: >> > >> > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski >> > wrote: >> > > >> > > The script seems to be computing the particle numbers for an array of chemical potentials. >> > > >> > > Two ways of speeding it up, both are likely simpler then using dask: >> > > >> > > First: use numpy >> > > >> > > 1. Move constructing mu_all out of the loop (np.linspace) >> > > 2. Arrange the integrands into a 2d array >> > > 3. np.trapz along an axis which corresponds to a single integrand array >> > > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) >> > >> > >> > Roughly like this: >> > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 >> >> I've done the comparison of the real execution time for your version >> I've compared the execution efficiency of your above method and the >> original method of the python script by directly using fermi() without >> executing vectorize() on it. Very surprisingly, the latter is more >> efficient than the former, see following for more info: >> >> $ time python fermi_integrate_np.py >> [[1.03000000e+01 4.55561775e+17] >> [1.03001000e+01 4.55561780e+17] >> [1.03002000e+01 4.55561786e+17] >> ... >> [1.08997000e+01 1.33654085e+21] >> [1.08998000e+01 1.33818034e+21] >> [1.08999000e+01 1.33982054e+21]] >> >> real 1m8.797s >> user 0m47.204s >> sys 0m27.105s >> $ time python mu.py >> [[1.03000000e+01 4.55561775e+17] >> [1.03001000e+01 4.55561780e+17] >> [1.03002000e+01 4.55561786e+17] >> ... >> [1.08997000e+01 1.33654085e+21] >> [1.08998000e+01 1.33818034e+21] >> [1.08999000e+01 1.33982054e+21]] >> >> real 0m38.829s >> user 0m41.541s >> sys 0m3.399s >> >> So, I think that the benchmark dataset used by you for testing code >> efficiency is not so appropriate. What's your point of view on this >> testing results? > > > > Evgeni has provided an interesting example on how to speed up your code - granted, he used toy data but the improvement is real. As far as I can see, you haven't specified how big are your DOS etc... vectors, so it's not that obvious how to draw any conclusions. I find it highly puzzling that his implementation appears to be slower than your original code. > > In any case, if performance is so paramount for you, then I would suggest you to move in the direction Evgeni was proposing, i.e. shifting your implementation to C/Cython or Fortran/f2py. If so, I think that the C/Fortran based implementations should be more efficient than the ones using Cython/f2py. > I had much better results myself using Fortran/f2py than pure NumPy or C/Cython, but this is mostly because my knowledge of Cython is quite limited. That said, your problem should be fairly easy to implement in a compiled language. > > Andrea. > > >> >> >> Regards, >> HY >> >> > >> > >> > >> > > Second: >> > > >> > > Move the loop into cython. >> > > >> > > >> > > >> > > >> > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : >> > >> >> > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao wrote: >> > >> >> >> > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana wrote: >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana wrote: >> > >> >> >> >> > >> >> >> Hi, >> > >> >> >> >> > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao wrote: >> > >> >> >>> >> > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern wrote: >> > >> >> >>> > >> > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() will work just fine on arrays and should be much faster. >> > >> >> >>> >> > >> >> >>> Yes, it really does the trick. See the following for the benchmark >> > >> >> >>> based on your suggestion: >> > >> >> >>> >> > >> >> >>> $ time python mu.py >> > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> > >> >> >>> >> > >> >> >>> real 0m41.056s >> > >> >> >>> user 0m43.970s >> > >> >> >>> sys 0m3.813s >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> But are there any ways to further improve/increase efficiency? >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> I believe it will get a bit better if you don?t column_stack an array 6000 times - maybe pre-allocate your output first? >> > >> >> >> >> > >> >> >> Andrea. >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in front of your column_stack call and made me think you were stacking your results very many times, which is not the case. >> > >> >> >> > >> >> Still not so clear on your solutions for this problem. Could you >> > >> >> please post here the corresponding snippet of your enhancement? >> > >> > >> > >> > >> > >> > I have no solution, I originally thought you were calling ?column_stack? 6000 times in the loop, but that is not the case, I was mistaken. My apologies for that. >> > >> > >> > >> > The timings of your approach is highly dependent on the size of your ?energy? and ?DOS? array - >> > >> >> > >> The size of the ?energy? and ?DOS? array is Problem-related and >> > >> shouldn't be reduced arbitrarily. >> > >> >> > >> > not to mention calling trapz 6000 times in a loop. >> > >> >> > >> I'm currently thinking on parallelization the execution of the for >> > >> loop, say, with joblib , but I still >> > >> haven't figured out the corresponding codes. If you have some >> > >> experience on this type of solution, could you please give me some >> > >> more hints? >> > >> >> > >> > Maybe there?s a better way to do it with another approach, but at the moment I can?t think of one... >> > >> > >> > >> >> >> > >> >> >> > >> >> Regards, >> > >> >> HY >> > >> >> > >> > >> >> >> >> > >> >> >> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> Regards, >> > >> >> >>> HY >> > >> >> >>> >> > >> >> >>> > >> > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao wrote: >> > >> >> >>> >> >> > >> >> >>> >> Hi, >> > >> >> >>> >> >> > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed by pyenv. I >> > >> >> >>> >> try to run the script >> > >> >> >>> >> , >> > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl + c' to >> > >> >> >>> >> terminate it, it will give the following output: >> > >> >> >>> >> >> > >> >> >>> >> $ python mu.py >> > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] [4.973e-84 >> > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] >> > >> >> >>> >> >> > >> >> >>> >> I have to terminate it and obtained the following information: >> > >> >> >>> >> >> > >> >> >>> >> ^CTraceback (most recent call last): >> > >> >> >>> >> File "mu.py", line 38, in >> > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) >> > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> > >> >> >>> >> line 2108, in __call__ >> > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) >> > >> >> >>> >> File "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", >> > >> >> >>> >> line 2192, in _vectorize_call >> > >> >> >>> >> outputs = ufunc(*inputs) >> > >> >> >>> >> File "mu.py", line 8, in fermi >> > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) >> > >> >> >>> >> KeyboardInterrupt >> > >> >> >>> >> >> > >> >> >>> >> >> > >> >> >>> >> Any helps and hints for this problem will be highly appreciated? >> > >> >> >>> >> >> > >> >> >>> >> Regards, >> > >> >> >>> >> -- >> > >> >> >>> >> Hongyi Zhao >> > >> >> >>> >> _______________________________________________ >> > >> >> >>> >> NumPy-Discussion mailing list >> > >> >> >>> >> NumPy-Discussion at python.org >> > >> >> >>> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> >>> > >> > >> >> >>> > _______________________________________________ >> > >> >> >>> > NumPy-Discussion mailing list >> > >> >> >>> > NumPy-Discussion at python.org >> > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> -- >> > >> >> >>> Hongyi Zhao >> > >> >> >>> _______________________________________________ >> > >> >> >>> NumPy-Discussion mailing list >> > >> >> >>> NumPy-Discussion at python.org >> > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> > >> > >> >> > _______________________________________________ >> > >> >> > NumPy-Discussion mailing list >> > >> >> > NumPy-Discussion at python.org >> > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> >> > >> >> >> > >> >> >> > >> >> -- >> > >> >> Hongyi Zhao >> > >> >> _______________________________________________ >> > >> >> NumPy-Discussion mailing list >> > >> >> NumPy-Discussion at python.org >> > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > >> > >> > _______________________________________________ >> > >> > NumPy-Discussion mailing list >> > >> > NumPy-Discussion at python.org >> > >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> > >> >> > >> >> > >> -- >> > >> Hongyi Zhao >> > >> _______________________________________________ >> > >> NumPy-Discussion mailing list >> > >> NumPy-Discussion at python.org >> > >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Hongyi Zhao >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Hongyi Zhao From andrea.gavana at gmail.com Mon Oct 12 10:41:08 2020 From: andrea.gavana at gmail.com (Andrea Gavana) Date: Mon, 12 Oct 2020 16:41:08 +0200 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: Hi, On Mon, 12 Oct 2020 at 16.22, Hongyi Zhao wrote: > On Mon, Oct 12, 2020 at 9:33 PM Andrea Gavana > wrote: > > > > Hi, > > > > On Mon, 12 Oct 2020 at 14:38, Hongyi Zhao wrote: > >> > >> On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski > >> wrote: > >> > > >> > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski > >> > wrote: > >> > > > >> > > The script seems to be computing the particle numbers for an array > of chemical potentials. > >> > > > >> > > Two ways of speeding it up, both are likely simpler then using dask: > >> > > > >> > > First: use numpy > >> > > > >> > > 1. Move constructing mu_all out of the loop (np.linspace) > >> > > 2. Arrange the integrands into a 2d array > >> > > 3. np.trapz along an axis which corresponds to a single integrand > array > >> > > (Or avoid the overhead of trapz by just implementing the trapezoid > formula manually) > >> > > >> > > >> > Roughly like this: > >> > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 > >> > >> I've done the comparison of the real execution time for your version > >> I've compared the execution efficiency of your above method and the > >> original method of the python script by directly using fermi() without > >> executing vectorize() on it. Very surprisingly, the latter is more > >> efficient than the former, see following for more info: > >> > >> $ time python fermi_integrate_np.py > >> [[1.03000000e+01 4.55561775e+17] > >> [1.03001000e+01 4.55561780e+17] > >> [1.03002000e+01 4.55561786e+17] > >> ... > >> [1.08997000e+01 1.33654085e+21] > >> [1.08998000e+01 1.33818034e+21] > >> [1.08999000e+01 1.33982054e+21]] > >> > >> real 1m8.797s > >> user 0m47.204s > >> sys 0m27.105s > >> $ time python mu.py > >> [[1.03000000e+01 4.55561775e+17] > >> [1.03001000e+01 4.55561780e+17] > >> [1.03002000e+01 4.55561786e+17] > >> ... > >> [1.08997000e+01 1.33654085e+21] > >> [1.08998000e+01 1.33818034e+21] > >> [1.08999000e+01 1.33982054e+21]] > >> > >> real 0m38.829s > >> user 0m41.541s > >> sys 0m3.399s > >> > >> So, I think that the benchmark dataset used by you for testing code > >> efficiency is not so appropriate. What's your point of view on this > >> testing results? > > > > > > > > Evgeni has provided an interesting example on how to speed up your > code - granted, he used toy data but the improvement is real. As far as I > can see, you haven't specified how big are your DOS etc... vectors, so it's > not that obvious how to draw any conclusions. I find it highly puzzling > that his implementation appears to be slower than your original code. > > > > In any case, if performance is so paramount for you, then I would > suggest you to move in the direction Evgeni was proposing, i.e. shifting > your implementation to C/Cython or Fortran/f2py. > > If so, I think that the C/Fortran based implementations should be more > efficient than the ones using Cython/f2py. That is not what I meant: what I meant is: write the time consuming part of your code in C or Fortran and then bridge it to Python using Cython or f2py. Andrea. > > > > I had much better results myself using Fortran/f2py than pure NumPy or > C/Cython, but this is mostly because my knowledge of Cython is quite > limited. That said, your problem should be fairly easy to implement in a > compiled language. > > > > Andrea. > > > > > >> > >> > >> Regards, > >> HY > >> > >> > > >> > > >> > > >> > > Second: > >> > > > >> > > Move the loop into cython. > >> > > > >> > > > >> > > > >> > > > >> > > ??, 11 ???. 2020 ?., 9:32 Hongyi Zhao : > >> > >> > >> > >> On Sun, Oct 11, 2020 at 2:02 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Sun, 11 Oct 2020 at 07.52, Hongyi Zhao > wrote: > >> > >> >> > >> > >> >> On Sun, Oct 11, 2020 at 1:33 PM Andrea Gavana < > andrea.gavana at gmail.com> wrote: > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On Sun, 11 Oct 2020 at 07.14, Andrea Gavana < > andrea.gavana at gmail.com> wrote: > >> > >> >> >> > >> > >> >> >> Hi, > >> > >> >> >> > >> > >> >> >> On Sun, 11 Oct 2020 at 00.27, Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > >> > >> >> >>> > >> > >> >> >>> On Sun, Oct 11, 2020 at 1:48 AM Robert Kern < > robert.kern at gmail.com> wrote: > >> > >> >> >>> > > >> > >> >> >>> > You don't need to use vectorize() on fermi(). fermi() > will work just fine on arrays and should be much faster. > >> > >> >> >>> > >> > >> >> >>> Yes, it really does the trick. See the following for the > benchmark > >> > >> >> >>> based on your suggestion: > >> > >> >> >>> > >> > >> >> >>> $ time python mu.py > >> > >> >> >>> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > >> > >> >> >>> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> > >> >> >>> > >> > >> >> >>> real 0m41.056s > >> > >> >> >>> user 0m43.970s > >> > >> >> >>> sys 0m3.813s > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> But are there any ways to further improve/increase > efficiency? > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> I believe it will get a bit better if you don?t column_stack > an array 6000 times - maybe pre-allocate your output first? > >> > >> >> >> > >> > >> >> >> Andrea. > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > I?m sorry, scratch that: I?ve seen a ghost white space in > front of your column_stack call and made me think you were stacking your > results very many times, which is not the case. > >> > >> >> > >> > >> >> Still not so clear on your solutions for this problem. Could you > >> > >> >> please post here the corresponding snippet of your enhancement? > >> > >> > > >> > >> > > >> > >> > I have no solution, I originally thought you were calling > ?column_stack? 6000 times in the loop, but that is not the case, I was > mistaken. My apologies for that. > >> > >> > > >> > >> > The timings of your approach is highly dependent on the size of > your ?energy? and ?DOS? array - > >> > >> > >> > >> The size of the ?energy? and ?DOS? array is Problem-related and > >> > >> shouldn't be reduced arbitrarily. > >> > >> > >> > >> > not to mention calling trapz 6000 times in a loop. > >> > >> > >> > >> I'm currently thinking on parallelization the execution of the for > >> > >> loop, say, with joblib , but I > still > >> > >> haven't figured out the corresponding codes. If you have some > >> > >> experience on this type of solution, could you please give me some > >> > >> more hints? > >> > >> > >> > >> > Maybe there?s a better way to do it with another approach, but > at the moment I can?t think of one... > >> > >> > > >> > >> >> > >> > >> >> > >> > >> >> Regards, > >> > >> >> HY > >> > >> >> > > >> > >> >> >> > >> > >> >> >> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> Regards, > >> > >> >> >>> HY > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > On Sat, Oct 10, 2020, 8:23 AM Hongyi Zhao < > hongyi.zhao at gmail.com> wrote: > >> > >> >> >>> >> > >> > >> >> >>> >> Hi, > >> > >> >> >>> >> > >> > >> >> >>> >> My environment is Ubuntu 20.04 and python 3.8.3 managed > by pyenv. I > >> > >> >> >>> >> try to run the script > >> > >> >> >>> >> < > https://notebook.rcc.uchicago.edu/files/acs.chemmater.9b05047/Data/bulk/dft/mu.py > >, > >> > >> >> >>> >> but it will keep running and never end. When I use 'Ctrl > + c' to > >> > >> >> >>> >> terminate it, it will give the following output: > >> > >> >> >>> >> > >> > >> >> >>> >> $ python mu.py > >> > >> >> >>> >> [-10.999 -10.999 -10.999 ... 20. 20. 20. ] > [4.973e-84 > >> > >> >> >>> >> 4.973e-84 4.973e-84 ... 4.973e-84 4.973e-84 4.973e-84] > >> > >> >> >>> >> > >> > >> >> >>> >> I have to terminate it and obtained the following > information: > >> > >> >> >>> >> > >> > >> >> >>> >> ^CTraceback (most recent call last): > >> > >> >> >>> >> File "mu.py", line 38, in > >> > >> >> >>> >> integrand=DOS*fermi_array(energy,mu,kT) > >> > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> > >> >> >>> >> line 2108, in __call__ > >> > >> >> >>> >> return self._vectorize_call(func=func, args=vargs) > >> > >> >> >>> >> File > "/home/werner/.pyenv/versions/datasci/lib/python3.8/site-packages/numpy/lib/function_base.py", > >> > >> >> >>> >> line 2192, in _vectorize_call > >> > >> >> >>> >> outputs = ufunc(*inputs) > >> > >> >> >>> >> File "mu.py", line 8, in fermi > >> > >> >> >>> >> return 1./(exp((E-mu)/kT)+1) > >> > >> >> >>> >> KeyboardInterrupt > >> > >> >> >>> >> > >> > >> >> >>> >> > >> > >> >> >>> >> Any helps and hints for this problem will be highly > appreciated? > >> > >> >> >>> >> > >> > >> >> >>> >> Regards, > >> > >> >> >>> >> -- > >> > >> >> >>> >> Hongyi Zhao > >> > >> >> >>> >> _______________________________________________ > >> > >> >> >>> >> NumPy-Discussion mailing list > >> > >> >> >>> >> NumPy-Discussion at python.org > >> > >> >> >>> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> >> >>> > > >> > >> >> >>> > _______________________________________________ > >> > >> >> >>> > NumPy-Discussion mailing list > >> > >> >> >>> > NumPy-Discussion at python.org > >> > >> >> >>> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> -- > >> > >> >> >>> Hongyi Zhao > >> > >> >> >>> _______________________________________________ > >> > >> >> >>> NumPy-Discussion mailing list > >> > >> >> >>> NumPy-Discussion at python.org > >> > >> >> >>> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> >> > > >> > >> >> > _______________________________________________ > >> > >> >> > NumPy-Discussion mailing list > >> > >> >> > NumPy-Discussion at python.org > >> > >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> -- > >> > >> >> Hongyi Zhao > >> > >> >> _______________________________________________ > >> > >> >> NumPy-Discussion mailing list > >> > >> >> NumPy-Discussion at python.org > >> > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > > >> > >> > _______________________________________________ > >> > >> > NumPy-Discussion mailing list > >> > >> > NumPy-Discussion at python.org > >> > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Hongyi Zhao > >> > >> _______________________________________________ > >> > >> NumPy-Discussion mailing list > >> > >> NumPy-Discussion at python.org > >> > >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> > _______________________________________________ > >> > NumPy-Discussion mailing list > >> > NumPy-Discussion at python.org > >> > https://mail.python.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Hongyi Zhao > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > -- > Hongyi Zhao > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Mon Oct 12 10:49:25 2020 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Mon, 12 Oct 2020 22:49:25 +0800 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Mon, Oct 12, 2020 at 10:41 PM Andrea Gavana wrote: > > Hi, > > On Mon, 12 Oct 2020 at 16.22, Hongyi Zhao wrote: >> >> On Mon, Oct 12, 2020 at 9:33 PM Andrea Gavana wrote: >> > >> > Hi, >> > >> > On Mon, 12 Oct 2020 at 14:38, Hongyi Zhao wrote: >> >> >> >> On Sun, Oct 11, 2020 at 3:42 PM Evgeni Burovski >> >> wrote: >> >> > >> >> > On Sun, Oct 11, 2020 at 9:55 AM Evgeni Burovski >> >> > wrote: >> >> > > >> >> > > The script seems to be computing the particle numbers for an array of chemical potentials. >> >> > > >> >> > > Two ways of speeding it up, both are likely simpler then using dask: >> >> > > >> >> > > First: use numpy >> >> > > >> >> > > 1. Move constructing mu_all out of the loop (np.linspace) >> >> > > 2. Arrange the integrands into a 2d array >> >> > > 3. np.trapz along an axis which corresponds to a single integrand array >> >> > > (Or avoid the overhead of trapz by just implementing the trapezoid formula manually) >> >> > >> >> > >> >> > Roughly like this: >> >> > https://gist.github.com/ev-br/0250e4eee461670cf489515ee427eb99 >> >> >> >> I've done the comparison of the real execution time for your version >> >> I've compared the execution efficiency of your above method and the >> >> original method of the python script by directly using fermi() without >> >> executing vectorize() on it. Very surprisingly, the latter is more >> >> efficient than the former, see following for more info: >> >> >> >> $ time python fermi_integrate_np.py >> >> [[1.03000000e+01 4.55561775e+17] >> >> [1.03001000e+01 4.55561780e+17] >> >> [1.03002000e+01 4.55561786e+17] >> >> ... >> >> [1.08997000e+01 1.33654085e+21] >> >> [1.08998000e+01 1.33818034e+21] >> >> [1.08999000e+01 1.33982054e+21]] >> >> >> >> real 1m8.797s >> >> user 0m47.204s >> >> sys 0m27.105s >> >> $ time python mu.py >> >> [[1.03000000e+01 4.55561775e+17] >> >> [1.03001000e+01 4.55561780e+17] >> >> [1.03002000e+01 4.55561786e+17] >> >> ... >> >> [1.08997000e+01 1.33654085e+21] >> >> [1.08998000e+01 1.33818034e+21] >> >> [1.08999000e+01 1.33982054e+21]] >> >> >> >> real 0m38.829s >> >> user 0m41.541s >> >> sys 0m3.399s >> >> >> >> So, I think that the benchmark dataset used by you for testing code >> >> efficiency is not so appropriate. What's your point of view on this >> >> testing results? >> > >> > >> > >> > Evgeni has provided an interesting example on how to speed up your code - granted, he used toy data but the improvement is real. As far as I can see, you haven't specified how big are your DOS etc... vectors, so it's not that obvious how to draw any conclusions. I find it highly puzzling that his implementation appears to be slower than your original code. >> > >> > In any case, if performance is so paramount for you, then I would suggest you to move in the direction Evgeni was proposing, i.e. shifting your implementation to C/Cython or Fortran/f2py. >> >> If so, I think that the C/Fortran based implementations should be more >> efficient than the ones using Cython/f2py. > > > That is not what I meant: what I meant is: write the time consuming part of your code in C or Fortran and then bridge it to Python using Cython or f2py. I understand your meaning, but I think that for such small job, why not do them with pure C/Fortran if we must bother them? All the best, -- Hongyi Zhao From robert.kern at gmail.com Mon Oct 12 10:54:55 2020 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 12 Oct 2020 10:54:55 -0400 Subject: [Numpy-discussion] The mu.py script will keep running and never end. In-Reply-To: References: Message-ID: On Mon, Oct 12, 2020 at 10:50 AM Hongyi Zhao wrote: > On Mon, Oct 12, 2020 at 10:41 PM Andrea Gavana > wrote: > > > That is not what I meant: what I meant is: write the time consuming part > of your code in C or Fortran and then bridge it to Python using Cython or > f2py. > > I understand your meaning, but I think that for such small job, why > not do them with pure C/Fortran if we must bother them? > If it's a small job, don't bother optimizing it further at all. We don't know how important this is for you. We can only make conditional recommendations ("if it's worth spending development effort to gain speed, here are some ways to do that"). Balancing the development effort with the utility of further performance gains is entirely up to you. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Mon Oct 12 11:25:35 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Mon, 12 Oct 2020 10:25:35 -0500 Subject: [Numpy-discussion] Add sliding_window_view method to numpy In-Reply-To: References: Message-ID: On Mon, 2020-10-12 at 08:39 +0000, Zimmermann Klaus wrote: > Hello, > > I would like to draw the attention of this list to PR #17394 [1] that > adds the implementation of a sliding window view to numpy. > Hi, thanks for working on this and driving going forward. I like the choice of a minimal API. I have pasted the doc-string (html, hope that works fine) below to allow a quicker idea of what is being proposed. To me it looks good! (I wonder if we need `subok`, but I guess we probably do.) Cheers, Sebastian numpy.sliding_window_viewnumpy.sliding_window_view(x, window_shape, axi s=None, *, subok=False, writeable=False)Create a sliding window view into the array with the given window shape. Creates a sliding window view of the N dimensional array with the given window shape. Window slides across each dimension of the array and extract a subsets of the array at any window position. Parametersx : array_likeArray to create the sliding window view from.window_shape : int or tuple of intSize of window over each axis that takes part in the sliding window. If axis is not present, must have same length as the number of input array dimensions. Single integers i are treated as if they were the tuple (i,).axis : int or tuple of int, optionalAxis or axes along which the sliding window is applied. By default, the sliding window is applied to all axes and window_shape[i] will refer to axis i of x. If axis is given as a tuple of int, window_shape[i] will refer to the axis axis[i] of x. Single integers i are treated as if they were the tuple (i,).subok : bool, optionalIf True, sub-classes will be passed- through, otherwise the returned array will be forced to be a base-class array (default).writeable : bool, optionalWhen true, allow writing to the returned view. The default is false, as this should be used with caution: the returned view contains the same memory location multiple times, so writing to one location will cause others to change.Returnsview : ndarraySliding window view of the array. The sliding window dimensions are inserted at the end, and the original dimensions are trimmed as required by the size of the sliding window. That is, view.shape = x_shape_trimmed + window_shape, where x_shape_trimmed is x.shape with every entry reduced by one less than the corresponding window size.See also lib.stride_tricks.as_stridedCreate a view into the array with the given shape and strides.broadcast_tobroadcast an array to a given shape. Notes For some cases there may be more efficient approaches to calculate transformations across multi-dimensional arrays, for instance scipy.signal.fftconvolve, where combining the iterating step with the calculation itself while storing partial results can result in significant speedups. Examples >>> x = np.arange(6) >>> x.shape (6,) >>> v = np.sliding_window_view(x, 3) >>> v.shape (4, 3) >>> v array([[0, 1, 2], [1, 2, 3], [2, 3, 4], [3, 4, 5]]) This also works in more dimensions, e.g. >>> i, j = np.ogrid[:3, :4] >>> x = 10*i + j >>> x.shape (3, 4) >>> x array([[ 0, 1, 2, 3], [10, 11, 12, 13], [20, 21, 22, 23]]) >>> shape = (2,2) >>> v = np.sliding_window_view(x, shape) >>> v.shape (2, 3, 2, 2) >>> v array([[[[ 0, 1], [10, 11]], [[ 1, 2], [11, 12]], [[ 2, 3], [12, 13]]], [[[10, 11], [20, 21]], [[11, 12], [21, 22]], [[12, 13], [22, 23]]]]) The axis can be specified explicitly: >>> v = np.sliding_window_view(x, 3, 0) >>> v.shape (1, 4, 3) >>> v array([[[ 0, 10, 20], [ 1, 11, 21], [ 2, 12, 22], [ 3, 13, 23]]]) The same axis can be used several times. In that case, every use reduces the corresponding original dimension: >>> v = np.sliding_window_view(x, (2, 3), (1, 1)) >>> v.shape (3, 1, 2, 3) >>> v array([[[[ 0, 1, 2], [ 1, 2, 3]]], [[[10, 11, 12], [11, 12, 13]]], [[[20, 21, 22], [21, 22, 23]]]]) Combining with stepped slicing (::step), this can be used to take sliding views which skip elements: >>> x = np.arange(7) >>> np.sliding_window_view(x, 5)[:, ::2] array([[0, 2, 4], [1, 3, 5], [2, 4, 6]]) or views which move by multiple elements >>> x = np.arange(7) >>> np.sliding_window_view(x, 3)[::2, :] array([[0, 1, 2], [2, 3, 4], [4, 5, 6]]) > Having a sliding window view in numpy is a longstanding open issue > (cf > #7753 [2] from 2016). A brief summary of the discussions surrounding > it > can be found in the description of the PR. > > This PR implements a sliding window view based on stride tricks. > Following the discussion in issue #7753, a first implementation was > provided by Fanjin Zeng in PR #10771. After some discussion, that PR > stalled and I picked up the issue in the present PR #17394. It is > based > on the first implementation, but follows the changed API as suggested > by > Eric Wieser. > > Code reviews have been provided by Bas van Beek, Stephen Hoyer, and > Eric > Wieser. Sebastian Berg added the "62 - Python API" label. > > > Do you think this is suitable for inclusion in numpy? > > Do you consider the PR ready? > > Do you have suggestions or requests? > > > Thanks for your time and consideration! > Klaus > > > [1] https://github.com/numpy/numpy/pull/17394 > [2] https://github.com/numpy/numpy/issues/7753 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From jni at fastmail.com Mon Oct 12 19:18:52 2020 From: jni at fastmail.com (Juan Nunez-Iglesias) Date: Tue, 13 Oct 2020 10:18:52 +1100 Subject: [Numpy-discussion] Add sliding_window_view method to numpy In-Reply-To: References: Message-ID: <672D2E29-C531-4F5B-A193-23A8B0E0D65C@fastmail.com> Looks gorgeous, thank you to all who worked on the implementation, API, and review, and thank you Sebastian for saving me a click! ? > On 13 Oct 2020, at 2:25 am, Sebastian Berg wrote: > > On Mon, 2020-10-12 at 08:39 +0000, Zimmermann Klaus wrote: >> Hello, >> >> I would like to draw the attention of this list to PR #17394 [1] that >> adds the implementation of a sliding window view to numpy. >> > > Hi, > > thanks for working on this and driving going forward. I like the choice of a minimal API. I have pasted the doc-string (html, hope that works fine) below to allow a quicker idea of what is being proposed. To me it looks good! (I wonder if we need `subok`, but I guess we probably do.) > > Cheers, > > Sebastian > > > numpy.sliding_window_view > numpy.sliding_window_view(x, window_shape, axis=None, *, subok=False, writeable=False) > Create a sliding window view into the array with the given window shape. > > Creates a sliding window view of the N dimensional array with the given window shape. Window slides across each dimension of the array and extract a subsets of the array at any window position. > > Parameters > x : array_like > Array to create the sliding window view from. > window_shape : int or tuple of int > Size of window over each axis that takes part in the sliding window. If axis is not present, must have same length as the number of input array dimensions. Single integers i are treated as if they were the tuple (i,). > axis : int or tuple of int, optional > Axis or axes along which the sliding window is applied. By default, the sliding window is applied to all axes and window_shape[i] will refer to axis i of x. If axis is given as a tuple of int, window_shape[i] will refer to the axis axis[i] of x. Single integers i are treated as if they were the tuple (i,). > subok : bool, optional > If True, sub-classes will be passed-through, otherwise the returned array will be forced to be a base-class array (default). > writeable : bool, optional > When true, allow writing to the returned view. The default is false, as this should be used with caution: the returned view contains the same memory location multiple times, so writing to one location will cause others to change. > Returns > view : ndarray > Sliding window view of the array. The sliding window dimensions are inserted at the end, and the original dimensions are trimmed as required by the size of the sliding window. > That is, view.shape = x_shape_trimmed + window_shape, where x_shape_trimmed is x.shape with every entry reduced by one less than the corresponding window size. > See also > lib.stride_tricks.as_strided > Create a view into the array with the given shape and strides. > broadcast_to > broadcast an array to a given shape. > Notes > > For some cases there may be more efficient approaches to calculate transformations across multi-dimensional arrays, for instance scipy.signal.fftconvolve , where combining the iterating step with the calculation itself while storing partial results can result in significant speedups. > > Examples > > >>> x = np.arange(6) > >>> x.shape > (6,) > >>> v = np.sliding_window_view(x, 3) > >>> v.shape > (4, 3) > >>> v > array([[0, 1, 2], > [1, 2, 3], > [2, 3, 4], > [3, 4, 5]]) > This also works in more dimensions, e.g. > > >>> i, j = np.ogrid[:3, :4] > >>> x = 10*i + j > >>> x.shape > (3, 4) > >>> x > array([[ 0, 1, 2, 3], > [10, 11, 12, 13], > [20, 21, 22, 23]]) > >>> shape = (2,2) > >>> v = np.sliding_window_view(x, shape) > >>> v.shape > (2, 3, 2, 2) > >>> v > array([[[[ 0, 1], > [10, 11]], > [[ 1, 2], > [11, 12]], > [[ 2, 3], > [12, 13]]], > [[[10, 11], > [20, 21]], > [[11, 12], > [21, 22]], > [[12, 13], > [22, 23]]]]) > The axis can be specified explicitly: > > >>> v = np.sliding_window_view(x, 3, 0) > >>> v.shape > (1, 4, 3) > >>> v > array([[[ 0, 10, 20], > [ 1, 11, 21], > [ 2, 12, 22], > [ 3, 13, 23]]]) > The same axis can be used several times. In that case, every use reduces the corresponding original dimension: > > >>> v = np.sliding_window_view(x, (2, 3), (1, 1)) > >>> v.shape > (3, 1, 2, 3) > >>> v > array([[[[ 0, 1, 2], > [ 1, 2, 3]]], > [[[10, 11, 12], > [11, 12, 13]]], > [[[20, 21, 22], > [21, 22, 23]]]]) > Combining with stepped slicing (::step), this can be used to take sliding views which skip elements: > > >>> x = np.arange(7) > >>> np.sliding_window_view(x, 5)[:, ::2] > array([[0, 2, 4], > [1, 3, 5], > [2, 4, 6]]) > or views which move by multiple elements > > >>> x = np.arange(7) > >>> np.sliding_window_view(x, 3)[::2, :] > array([[0, 1, 2], > [2, 3, 4], > [4, 5, 6]]) > > > > > >> Having a sliding window view in numpy is a longstanding open issue (cf >> #7753 [2] from 2016). A brief summary of the discussions surrounding it >> can be found in the description of the PR. >> >> This PR implements a sliding window view based on stride tricks. >> Following the discussion in issue #7753, a first implementation was >> provided by Fanjin Zeng in PR #10771. After some discussion, that PR >> stalled and I picked up the issue in the present PR #17394. It is based >> on the first implementation, but follows the changed API as suggested by >> Eric Wieser. >> >> Code reviews have been provided by Bas van Beek, Stephen Hoyer, and Eric >> Wieser. Sebastian Berg added the "62 - Python API" label. >> >> >> Do you think this is suitable for inclusion in numpy? >> >> Do you consider the PR ready? >> >> Do you have suggestions or requests? >> >> >> Thanks for your time and consideration! >> Klaus >> >> >> [1] https://github.com/numpy/numpy/pull/17394 >> [2] https://github.com/numpy/numpy/issues/7753 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.zimmermann at smhi.se Tue Oct 13 05:18:32 2020 From: klaus.zimmermann at smhi.se (Zimmermann Klaus) Date: Tue, 13 Oct 2020 09:18:32 +0000 Subject: [Numpy-discussion] Add sliding_window_view method to numpy In-Reply-To: References: Message-ID: <6d23ec38-6ec9-680a-7c6f-7dafe587f83d@smhi.se> Hi, thanks, Sebastian! Since `sliding_window_view` is essentially a small function determining the parameters with which to call `as_strided`, it makes sense to me to keep the essential `as_strided` parameters, `subok` among them. But if somebody with a deeper insight into numpy is convinced this should go, I have no problem with it. Cheers Klaus On 12/10/2020 17:25, Sebastian Berg wrote: > On Mon, 2020-10-12 at 08:39 +0000, Zimmermann Klaus wrote: >> Hello, >> >> I would like to draw the attention of this list to PR #17394 [1] that >> adds the implementation of a sliding window view to numpy. >> > > Hi, > > thanks for working on this and driving going forward. I like the choice > of a minimal API. ?I have pasted the doc-string (html, hope that works > fine) below to allow a quicker idea of what is being proposed. ?To me it > looks good! (I wonder if we need `subok`, but I guess we probably do.) > > Cheers, > > Sebastian > > > numpy.sliding_window_view > > > |numpy.||sliding_window_view|(/x/,?/window_shape/,?/axis=None/,?/*/,?/subok=False/,?/writeable=False/) > > Create a sliding window view into the array with the given window > shape. > > Creates a sliding window view of the N dimensional array with the > given window shape. Window slides across each dimension of the > array and extract a subsets of the array at any window position. > > Parameters > > x :?array_like > > Array to create the sliding window view from. > > window_shape?:?int or tuple of int > > Size of window over each axis that takes part in the > sliding window. If?/axis/?is not present, must have same > length as the number of input array dimensions. Single > integers?/i/?are treated as if they were the tuple?/(i,)/. > > axis?:?int or tuple of int, optional > > Axis or axes along which the sliding window is applied. By > default, the sliding window is applied to all axes > and?/window_shape[i]/?will refer to axis?/i/?of?/x/. > If?/axis/?is given as a?/tuple of > int/,?/window_shape[i]/?will refer to the > axis?/axis[i]/?of?/x/. Single integers?/i/?are treated as > if they were the tuple?/(i,)/. > > subok?:?bool, optional > > If True, sub-classes will be passed-through, otherwise the > returned array will be forced to be a base-class array > (default). > > writeable?:?bool, optional > > When true, allow writing to the returned view. The default > is false, as this should be used with caution: the > returned view contains the same memory location multiple > times, so writing to one location will cause others to change. > > Returns > > view?:?ndarray > > Sliding window view of the array. The sliding window > dimensions are inserted at the end, and the original > dimensions are trimmed as required by the size of the > sliding window. > > That is,?|view.shape?=?x_shape_trimmed?+?window_shape|, > where?|x_shape_trimmed|?is?|x.shape|?with every entry > reduced by one less than the corresponding window size. > > See also > > |lib.stride_tricks.as_strided| > > > Create a view into the array with the given shape and strides. > > |broadcast_to| > > > broadcast an array to a given shape. > > Notes > > For some cases there may be more efficient approaches to calculate > transformations across multi-dimensional arrays, for > instance?|scipy.signal.fftconvolve| > , > where combining the iterating step with the calculation itself > while storing partial results can result in significant speedups. > > Examples > > >>> x = np.arange(6) > >>> x.shape > (6,) > >>> v = np.sliding_window_view(x, 3) > >>> v.shape > (4, 3) > >>> v > array([[0, 1, 2], > [1, 2, 3], > [2, 3, 4], > [3, 4, 5]]) > > This also works in more dimensions, e.g. > > >>> i, j = np.ogrid[:3, :4] > >>> x = 10*i + j > >>> x.shape > (3, 4) > >>> x > array([[ 0, 1, 2, 3], > [10, 11, 12, 13], > [20, 21, 22, 23]]) > >>> shape = (2,2) > >>> v = np.sliding_window_view(x, shape) > >>> v.shape > (2, 3, 2, 2) > >>> v > array([[[[ 0, 1], > [10, 11]], > [[ 1, 2], > [11, 12]], > [[ 2, 3], > [12, 13]]], > [[[10, 11], > [20, 21]], > [[11, 12], > [21, 22]], > [[12, 13], > [22, 23]]]]) > > The axis can be specified explicitly: > > >>> v = np.sliding_window_view(x, 3, 0) > >>> v.shape > (1, 4, 3) > >>> v > array([[[ 0, 10, 20], > [ 1, 11, 21], > [ 2, 12, 22], > [ 3, 13, 23]]]) > > The same axis can be used several times. In that case, every use > reduces the corresponding original dimension: > > >>> v = np.sliding_window_view(x, (2, 3), (1, 1)) > >>> v.shape > (3, 1, 2, 3) > >>> v > array([[[[ 0, 1, 2], > [ 1, 2, 3]]], > [[[10, 11, 12], > [11, 12, 13]]], > [[[20, 21, 22], > [21, 22, 23]]]]) > > Combining with stepped slicing (/::step/), this can be used to > take sliding views which skip elements: > > >>> x = np.arange(7) > >>> np.sliding_window_view(x, 5)[:, ::2] > array([[0, 2, 4], > [1, 3, 5], > [2, 4, 6]]) > > or views which move by multiple elements > > >>> x = np.arange(7) > >>> np.sliding_window_view(x, 3)[::2, :] > array([[0, 1, 2], > [2, 3, 4], > [4, 5, 6]]) > > > > > >> Having a sliding window view in numpy is a longstanding open issue (cf >> #7753 [2] from 2016). A brief summary of the discussions surrounding it >> can be found in the description of the PR. >> >> This PR implements a sliding window view based on stride tricks. >> Following the discussion in issue #7753, a first implementation was >> provided by Fanjin Zeng in PR #10771. After some discussion, that PR >> stalled and I picked up the issue in the present PR #17394. It is based >> on the first implementation, but follows the changed API as suggested by >> Eric Wieser. >> >> Code reviews have been provided by Bas van Beek, Stephen Hoyer, and Eric >> Wieser. Sebastian Berg added the "62 - Python API" label. >> >> >> Do you think this is suitable for inclusion in numpy? >> >> Do you consider the PR ready? >> >> Do you have suggestions or requests? >> >> >> Thanks for your time and consideration! >> Klaus >> >> >> [1] https://github.com/numpy/numpy/pull/17394 >> >> [2] https://github.com/numpy/numpy/issues/7753 >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > From klaus.zimmermann at smhi.se Tue Oct 13 05:19:06 2020 From: klaus.zimmermann at smhi.se (Zimmermann Klaus) Date: Tue, 13 Oct 2020 09:19:06 +0000 Subject: [Numpy-discussion] Add sliding_window_view method to numpy In-Reply-To: <672D2E29-C531-4F5B-A193-23A8B0E0D65C@fastmail.com> References: <672D2E29-C531-4F5B-A193-23A8B0E0D65C@fastmail.com> Message-ID: Hi, thanks, Juan, you are very kind! Let's hope we can get this in soon :) Cheers Klaus On 13/10/2020 01:18, Juan Nunez-Iglesias wrote: > Looks gorgeous, thank you to all who worked on the implementation, API, > and review, and thank you Sebastian for saving me a click! ? > >> On 13 Oct 2020, at 2:25 am, Sebastian Berg > > wrote: >> >> On Mon, 2020-10-12 at 08:39 +0000, Zimmermann Klaus wrote: >>> Hello, >>> >>> I would like to draw the attention of this list to PR #17394 [1] that >>> adds the implementation of a sliding window view to numpy. >>> >> >> Hi, >> >> thanks for working on this and driving going forward. I like the >> choice of a minimal API. ?I have pasted the doc-string (html, hope >> that works fine) below to allow a quicker idea of what is being >> proposed. ?To me it looks good! (I wonder if we need `subok`, but I >> guess we probably do.) >> >> Cheers, >> >> Sebastian >> >> >> numpy.sliding_window_view >> >> >> |numpy.||sliding_window_view|(/x/,?/window_shape/,?/axis=None/,?/*/,?/subok=False/,?/writeable=False/) >> >> Create a sliding window view into the array with the given >> window shape. >> >> Creates a sliding window view of the N dimensional array with >> the given window shape. Window slides across each dimension of >> the array and extract a subsets of the array at any window position. >> >> Parameters >> >> x :?array_like >> Array to create the sliding window view from. >> window_shape?:?int or tuple of int >> Size of window over each axis that takes part in the >> sliding window. If?/axis/?is not present, must have same >> length as the number of input array dimensions. Single >> integers?/i/?are treated as if they were the tuple?/(i,)/. >> axis?:?int or tuple of int, optional >> Axis or axes along which the sliding window is applied. >> By default, the sliding window is applied to all axes >> and?/window_shape[i]/?will refer to axis?/i/?of?/x/. >> If?/axis/?is given as a?/tuple of >> int/,?/window_shape[i]/?will refer to the >> axis?/axis[i]/?of?/x/. Single integers?/i/?are treated >> as if they were the tuple?/(i,)/. >> subok?:?bool, optional >> If True, sub-classes will be passed-through, otherwise >> the returned array will be forced to be a base-class >> array (default). >> writeable?:?bool, optional >> When true, allow writing to the returned view. The >> default is false, as this should be used with caution: >> the returned view contains the same memory location >> multiple times, so writing to one location will cause >> others to change. >> >> Returns >> >> view?:?ndarray >> Sliding window view of the array. The sliding window >> dimensions are inserted at the end, and the original >> dimensions are trimmed as required by the size of the >> sliding window. >> That is,?|view.shape?=?x_shape_trimmed?+?window_shape|, >> where?|x_shape_trimmed|?is?|x.shape|?with every entry >> reduced by one less than the corresponding window size. >> >> See also >> >> |lib.stride_tricks.as_strided| >> >> Create a view into the array with the given shape and strides. >> |broadcast_to| >> >> broadcast an array to a given shape. >> >> Notes >> >> For some cases there may be more efficient approaches to >> calculate transformations across multi-dimensional arrays, for >> instance?|scipy.signal.fftconvolve| >> , >> where combining the iterating step with the calculation itself >> while storing partial results can result in significant speedups. >> >> Examples >> >> >>> x = np.arange(6) >> >>> x.shape >> (6,) >> >>> v = np.sliding_window_view(x, 3) >> >>> v.shape >> (4, 3) >> >>> v >> array([[0, 1, 2], >> [1, 2, 3], >> [2, 3, 4], >> [3, 4, 5]]) >> >> This also works in more dimensions, e.g. >> >> >>> i, j = np.ogrid[:3, :4] >> >>> x = 10*i + j >> >>> x.shape >> (3, 4) >> >>> x >> array([[ 0, 1, 2, 3], >> [10, 11, 12, 13], >> [20, 21, 22, 23]]) >> >>> shape = (2,2) >> >>> v = np.sliding_window_view(x, shape) >> >>> v.shape >> (2, 3, 2, 2) >> >>> v >> array([[[[ 0, 1], >> [10, 11]], >> [[ 1, 2], >> [11, 12]], >> [[ 2, 3], >> [12, 13]]], >> [[[10, 11], >> [20, 21]], >> [[11, 12], >> [21, 22]], >> [[12, 13], >> [22, 23]]]]) >> >> The axis can be specified explicitly: >> >> >>> v = np.sliding_window_view(x, 3, 0) >> >>> v.shape >> (1, 4, 3) >> >>> v >> array([[[ 0, 10, 20], >> [ 1, 11, 21], >> [ 2, 12, 22], >> [ 3, 13, 23]]]) >> >> The same axis can be used several times. In that case, every use >> reduces the corresponding original dimension: >> >> >>> v = np.sliding_window_view(x, (2, 3), (1, 1)) >> >>> v.shape >> (3, 1, 2, 3) >> >>> v >> array([[[[ 0, 1, 2], >> [ 1, 2, 3]]], >> [[[10, 11, 12], >> [11, 12, 13]]], >> [[[20, 21, 22], >> [21, 22, 23]]]]) >> >> Combining with stepped slicing (/::step/), this can be used to >> take sliding views which skip elements: >> >> >>> x = np.arange(7) >> >>> np.sliding_window_view(x, 5)[:, ::2] >> array([[0, 2, 4], >> [1, 3, 5], >> [2, 4, 6]]) >> >> or views which move by multiple elements >> >> >>> x = np.arange(7) >> >>> np.sliding_window_view(x, 3)[::2, :] >> array([[0, 1, 2], >> [2, 3, 4], >> [4, 5, 6]]) >> >> >> >> >> >>> Having a sliding window view in numpy is a longstanding open issue (cf >>> #7753 [2] from 2016). A brief summary of the discussions surrounding it >>> can be found in the description of the PR. >>> >>> This PR implements a sliding window view based on stride tricks. >>> Following the discussion in issue #7753, a first implementation was >>> provided by Fanjin Zeng in PR #10771. After some discussion, that PR >>> stalled and I picked up the issue in the present PR #17394. It is based >>> on the first implementation, but follows the changed API as suggested by >>> Eric Wieser. >>> >>> Code reviews have been provided by Bas van Beek, Stephen Hoyer, and Eric >>> Wieser. Sebastian Berg added the "62 - Python API" label. >>> >>> >>> Do you think this is suitable for inclusion in numpy? >>> >>> Do you consider the PR ready? >>> >>> Do you have suggestions or requests? >>> >>> >>> Thanks for your time and consideration! >>> Klaus >>> >>> >>> [1]?https://github.com/numpy/numpy/pull/17394 >>> >>> [2]?https://github.com/numpy/numpy/issues/7753 >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >>> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > From ralf.gommers at gmail.com Tue Oct 13 16:02:55 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 13 Oct 2020 21:02:55 +0100 Subject: [Numpy-discussion] NumPy community town hall on Oct 14th Message-ID: Hi all, Tomorrow there will be no regular community meeting. Instead, we will be holding a town hall meeting at 1pm PDT (20:00 UTC), focused on community building, our diversity, equity & inclusion (DEI) efforts, ways for new contributors to plug in, and related topics. For details see https://numpy.discourse.group/t/community-town-hall-details/24 A few comments and requests: 1. We promised to hold this town hall after the controversy on Twitter following the criticism of the lack of diversity in the NumPy paper author list. The town hall was announced on Twitter too ( https://twitter.com/numpy_team/status/1315742564859949059) and we also invited a number of organizations focused on DEI issues in STEM and open source, like PyLadies. 2. The event is focused on outreach, not on project-internal discussion. 3. Everyone is welcome and encouraged to attend. Please do keep in mind that we're focused on a sensitive topic here - the focus is on our community building, mentorship, DEI, etc. efforts, so please only weigh in on those as a member/representative of the NumPy project if you're (a) familiar with our efforts and recent history in this area, and (b) comfortable commenting on this topic in public. 4. This Discourse is new. We set it up because we needed a friendly forum with much better moderation tools than either the mailing list or Twitter provides. We may aim to keep it if it goes well and we like what Discourse has to offer, that's for later to propose and decide. For now this Discourse instance is just for this event. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdupree at speakeasy.net Wed Oct 14 02:43:46 2020 From: sdupree at speakeasy.net (Samuel Dupree) Date: Wed, 14 Oct 2020 02:43:46 -0400 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error Message-ID: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> I'm attempting to wrap a Fortran-77 source member using f2py. I'm running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm running is 1.18.3. I've attached a copy of the Fortran source code to this note (see rkfn78.for). The command I'm using to wrap this code is f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" -m rkfn78 The output I get is captured in the file rkfn78_build_output.txt. I don't understand the cause behind the error message I get, so any advice would be welcomed. Sam Dupree. -------------- next part -------------- SUBROUTINE rkfn78( N, FCN, X, Y, YP, XEND, EPS, HMAX, H ) C ---------------------------------------------------------------------- C C RKFN78 ( N, FCN, X, Y, YP, XEND, EPS, HMAX, H ) C C Numerical solution of a system of second order C ordinary differential equations y"=f(x,y,dy) C This is an embedded nystroem method of order 7(8) C due to Fehlberg with stepsize control C C input parameters C ---------------- C N dimension of the system (N.LE.51) C FCN name (external) of subroutine computing the C second derivative F(X,Y,DY): C SUBROUTINE FCN(X,Y,DY,F) C REAL*8 X,Y(N),DY(N),F(N) C F(1)=... ETC. C X initial x-value C XEND final x-value (XEND.GT.X) C Y(N) initial values for y C YP(N) initial values for y' C EPS local tolerance C HMAX maximal stepsize C H initial stepsize guess C C output parameters C ----------------- C Y(N) solution at xend C YP(N) derivative of solution at xend C C COMMON STAT can be used for statistics C NFCN number of function evaluations C NSTEP number of computed steps C NACCPT number of accepted steps C NREJCT number of rejected steps C C Ref.: Erwin Fehlberg, Computing 14, p.371, 1975 C ---------------------------------------------------------------------- C23456789012345678901234567890123456789012345678901234567890123456789012 implicit none ! I/O list INTEGER*4 N REAL*8 X, Y(N), YP(N), XEND, EPS, HMAX, H ! method related constants INTEGER*4 N_STAGE, P PARAMETER ( N_STAGE=13, P=7 ) ! implementation dependant constants INTEGER*4 N_MAX, MAX_STEPS REAL*8 UROUND PARAMETER ( N_MAX=180, MAX_STEPS=2147483647, UROUND=1.1D-16 ) ! auxiliary variables REAL*8 K ( 1:N_MAX, 0:N_STAGE ) REAL*8 Y1 ( 1:N_MAX ), YP1 ( 1:N_MAX ), TE ( 1:N_MAX ) REAL*8 POSNEG, HNEW, DENOM, ERR, FAC, H2, SUM, SUMP INTEGER I_STAGE, I, J, L LOGICAL REJECT ! coefficients REAL*8 ALPHA_(1:13), BETA_(1:13,0:12), GAMMA_(1:13,0:12) COMMON /CRKFN78/ ALPHA_, BETA_, GAMMA_ ! statistics INTEGER*4 NFCN,NSTEP,NACCPT,NREJCT COMMON /STAT/ NFCN,NSTEP,NACCPT,NREJCT Cf2py intent(in) N, FCN, X, XEND Cf2py intent(inout) Y, YP, HMAX, H, EPS Cf2py depend(in) Y, YP ! initial preparations IF (ALPHA_(13).NE.1.0D0) THEN CALL FN78INI END IF POSNEG = SIGN ( 1.0D0, XEND-X) HMAX = ABS(HMAX) H = MIN ( MAX(1.0D-8,ABS(H)) , HMAX ) H = SIGN ( H, POSNEG ) EPS = MAX ( EPS, 9.0*UROUND ) REJECT = .FALSE. NFCN = NFCN + 1 CALL FCN ( X, Y, YP, K(1,0) ) ! basic integration step DO WHILE ( POSNEG*(X-XEND)+UROUND .LE. 0.0 ) ! failure exit IF ( NSTEP.GT.MAX_STEPS .OR. X+0.05*H.EQ.X ) THEN WRITE (*,*) 'Exit of RKNF78 at x = ', X WRITE (*,*) 'NSTEP = ', NSTEP WRITE (*,*) 'MAX_STEPS = ', MAX_STEPS WRITE (*,*) 'H = ', H WRITE (*,*) 'X+0.05*H = ', X+0.05*H STOP END IF ! limit step size IF ( (X+H-XEND)*POSNEG .GT. 0.0 ) THEN H = XEND-X END IF H2 = H**2 NSTEP = NSTEP+1 ! calculate K(*,1) .. K(*,N_STAGE) DO I_STAGE = 1,N_STAGE DO L=1,N SUM = 0.0 SUMP = 0.0 DO J=0,(I_STAGE-1) SUM = SUM + GAMMA_(I_STAGE,J)*K(L,J) SUMP = SUMP + BETA_ (I_STAGE,J)*K(L,J) END DO Y1(L) = Y(L) + ALPHA_(I_STAGE)*H*YP(L) + H2*SUM YP1(L) = YP(L) + H*SUMP END DO CALL FCN( X + ALPHA_(I_STAGE)*H, Y1, YP1, K(1,I_STAGE) ) END DO ! end of loop over stages NFCN = NFCN+N_STAGE ! error term and relative error estimation DO L=1,N TE(L) = GAMMA_(N_STAGE,N_STAGE-1) * H2 . * ( K(L,N_STAGE-1) - K(L,N_STAGE) ) END DO ERR = 0.0 DO L=1,N DENOM = MAX ( 1.0D-6, ABS(Y(L)), ABS(Y1(L)), 2.0*UROUND/EPS ) ERR = ERR + ( TE(L) / DENOM )**2 END DO ERR = SQRT ( ERR / N ) ! new step size 0.1 /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 Reading fortran codes... Reading file 'rkfn78.for' (format:fix,strict) Post-processing... Block: rkfn78 Block: rkfn78 Block: fcn Block: fn78ini Post-processing (stage 2)... Building modules... Constructing call-back function "cb_fcn_in_rkfn78__user__routines" def fcn(x,y,yp,e_k_1_0_err): return Building module "rkfn78"... Constructing wrapper function "rkfn78"... rkfn78(fcn,x,y,yp,xend,eps,hmax,h,[n,fcn_extra_args]) Constructing wrapper function "fn78ini"... fn78ini() Constructing COMMON block support for "crkfn78"... alpha_,beta_,gamma_ Constructing COMMON block support for "stat"... nfcn,nstep,naccpt,nrejct Wrote C/API module "rkfn78" to file "/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c" Fortran 77 wrappers are saved to "/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78-f2pywrappers.f" adding '/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/fortranobject.c' to sources. adding '/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7' to include_dirs. copying /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/src/fortranobject.c -> /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 copying /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/src/fortranobject.h -> /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 adding '/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78-f2pywrappers.f' to sources. build_src: building npy-pkg config files running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext customize Gnu95FCompiler Found executable /opt/local/bin/gfortran customize Gnu95FCompiler using build_ext building 'rkfn78' extension compiling C sources C compiler: gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/user/opt/anaconda3/include -arch x86_64 -I/Users/user/opt/anaconda3/include -arch x86_64 creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 compile options: '-I/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 -I/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include -I/Users/user/opt/anaconda3/include/python3.7m -c' gcc: /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c gcc: /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/fortranobject.c In file included from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1832, from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:12, from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4, from /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/fortranobject.h:13, from /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/fortranobject.c:2: /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp] 17 | #warning "Using deprecated NumPy API, disable it with " \ | ^~~~~~~ In file included from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1832, from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:12, from /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4, from /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/fortranobject.h:13, from /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c:16: /Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp] 17 | #warning "Using deprecated NumPy API, disable it with " \ | ^~~~~~~ /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c: In function 'cb_fcn_in_rkfn78__user__routines': /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c:441:13: error: 'n' undeclared (first use in this function) 441 | y_Dims[0]=n; | ^ /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c:441:13: note: each undeclared identifier is reported only once for each function it appears in /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c:396:7: warning: variable 'capi_j' set but not used [-Wunused-but-set-variable] 396 | int capi_j,capi_i = 0; | ^~~~~~ At top level: /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c:156:12: warning: 'f2py_size' defined but not used [-Wunused-function] 156 | static int f2py_size(PyArrayObject* var, ...) | ^~~~~~~~~ error: Command "gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/user/opt/anaconda3/include -arch x86_64 -I/Users/user/opt/anaconda3/include -arch x86_64 -I/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7 -I/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/core/include -I/Users/user/opt/anaconda3/include/python3.7m -c /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.c -o /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.o -MMD -MF /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp92spbywz/src.macosx-10.9-x86_64-3.7/rkfn78module.o.d" failed with exit status 1 done. (base) user at Samuels-Mac-Pro RKFN78_folder % From madhulikajain at gmail.com Thu Oct 15 12:30:41 2020 From: madhulikajain at gmail.com (Madhulika Jain Chambers) Date: Thu, 15 Oct 2020 09:30:41 -0700 Subject: [Numpy-discussion] new function: broadcast_shapes Message-ID: Hello all, I opened a PR to add a function which returns the broadcasted shape from a given set of shapes: https://github.com/numpy/numpy/pull/17535 As this is a proposed change to the API, I wanted to see if there was any feedback from the list. Thanks so much, Madhulika -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Thu Oct 15 14:46:40 2020 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Thu, 15 Oct 2020 14:46:40 -0400 Subject: [Numpy-discussion] new function: broadcast_shapes In-Reply-To: References: Message-ID: On 10/15/20, Madhulika Jain Chambers wrote: > Hello all, > > I opened a PR to add a function which returns the broadcasted shape from a > given set of shapes: > https://github.com/numpy/numpy/pull/17535 > > As this is a proposed change to the API, I wanted to see if there was any > feedback from the list. Thanks, this is useful! I've implemented something similar many times over the years, and could have used it in some SciPy code, where we currently have a private implementation in one of the `stats` modules. Warren > > Thanks so much, > > Madhulika > From shoyer at gmail.com Thu Oct 15 15:51:47 2020 From: shoyer at gmail.com (Stephan Hoyer) Date: Thu, 15 Oct 2020 12:51:47 -0700 Subject: [Numpy-discussion] new function: broadcast_shapes In-Reply-To: References: Message-ID: On Thu, Oct 15, 2020 at 11:46 AM Warren Weckesser < warren.weckesser at gmail.com> wrote: > On 10/15/20, Madhulika Jain Chambers wrote: > > Hello all, > > > > I opened a PR to add a function which returns the broadcasted shape from > a > > given set of shapes: > > https://github.com/numpy/numpy/pull/17535 > > > > As this is a proposed change to the API, I wanted to see if there was any > > feedback from the list. > > > Thanks, this is useful! I've implemented something similar many times > over the years, and could have used it in some SciPy code, where we > currently have a private implementation in one of the `stats` modules. > > Warren +1 for adding this. There's a version of this helper function -- coincidentally with the exactly same API and name -- in JAX, too: https://github.com/google/jax/blob/22c3684d3bac3ad0f40aca69cdbc76842fa9dfc0/jax/lax/lax.py#L73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.k.sheppard at gmail.com Fri Oct 16 05:59:18 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Fri, 16 Oct 2020 10:59:18 +0100 Subject: [Numpy-discussion] new function: broadcast_shapes In-Reply-To: References: Message-ID: There is at least one custom implementation in `Generator` IIRC, so a formal API addition sounds like a good idea. Kevin On Thu, Oct 15, 2020 at 8:52 PM Stephan Hoyer wrote: > On Thu, Oct 15, 2020 at 11:46 AM Warren Weckesser < > warren.weckesser at gmail.com> wrote: > >> On 10/15/20, Madhulika Jain Chambers wrote: >> > Hello all, >> > >> > I opened a PR to add a function which returns the broadcasted shape >> from a >> > given set of shapes: >> > https://github.com/numpy/numpy/pull/17535 >> > >> > As this is a proposed change to the API, I wanted to see if there was >> any >> > feedback from the list. >> >> >> Thanks, this is useful! I've implemented something similar many times >> over the years, and could have used it in some SciPy code, where we >> currently have a private implementation in one of the `stats` modules. >> >> Warren > > > +1 for adding this. > > There's a version of this helper function -- coincidentally with the > exactly same API and name -- in JAX, too: > > https://github.com/google/jax/blob/22c3684d3bac3ad0f40aca69cdbc76842fa9dfc0/jax/lax/lax.py#L73 > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Sat Oct 17 18:22:36 2020 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sat, 17 Oct 2020 16:22:36 -0600 Subject: [Numpy-discussion] ANN: SciPy 1.5.3 Message-ID: Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.3, which is a bug fix release that includes Linux ARM64 wheels for the first time. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.3 One of a few ways to install this release with pip: pip install scipy==1.5.3 ========================== SciPy 1.5.3 Release Notes ========================== SciPy 1.5.3 is a bug-fix release with no new features compared to 1.5.2. In particular, Linux ARM64 wheels are now available and a compatibility issue with XCode 12 has been fixed. Authors ====== * Peter Bell * CJ Carey * Thomas Duvernay + * Gregory Lee * Eric Moore * odidev * Dima Pasechnik * Tyler Reddy * Simon Segerblom Rex + * Daniel B. Smith * Will Tirone + * Warren Weckesser A total of 12 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.5.3 ------------------------------ * `#9611 `__: Overflow error with new way of p-value calculation in kendall... * `#10069 `__: scipy.ndimage.watershed_ift regression in 1.0.0 * `#11260 `__: BUG: DOP853 with complex data computes complex error norm, causing... * `#11479 `__: RuntimeError: dictionary changed size during iteration on loading... * `#11972 `__: BUG (solved): Error estimation in DOP853 ODE solver fails for... * `#12543 `__: BUG: Picture rotated 180 degrees and rotated -180 degrees should... * `#12613 `__: Travis X.4 and X.7 failures in master * `#12654 `__: scipy.stats.combine_pvalues produces wrong results with method='mudholkar_george' * `#12819 `__: BUG: Scipy Sparse slice indexing assignment Bug with zeros * `#12834 `__: BUG: ValueError upon calling Scipy Interpolator objects * `#12836 `__: ndimage.median can return incorrect values for integer inputs * `#12860 `__: Build failure with Xcode 12 Pull requests for 1.5.3 ----------------------------- * `#12611 `__: MAINT: prepare for SciPy 1.5.3 * `#12614 `__: MAINT: prevent reverse broadcasting * `#12617 `__: MAINT: optimize: Handle nonscalar size 1 arrays in fmin_slsqp... * `#12623 `__: MAINT: stats: Loosen some test tolerances. * `#12638 `__: CI, MAINT: pin pytest for Azure win * `#12668 `__: BUG: Ensure factorial is not too large in mstats.kendalltau * `#12705 `__: MAINT: \`openblas_support\` added sha256 hash * `#12706 `__: BUG: fix incorrect 1d case of the fourier_ellipsoid filter * `#12721 `__: BUG: use special.sindg in ndimage.rotate * `#12724 `__: BUG: per #12654 adjusted mudholkar_george method to combine p... * `#12726 `__: BUG: Fix DOP853 error norm for complex problems * `#12730 `__: CI: pin xdist for Azure windows * `#12786 `__: BUG: stats: Fix formula in the \`stats\` method of the ARGUS... * `#12795 `__: CI: Pin setuptools on windows CI * `#12830 `__: [BUG] sparse: Avoid using size attribute in LIL __setitem__ * `#12833 `__: BUG: change list of globals items to list of a copy * `#12842 `__: BUG: Use uint16 for cost in NI_WatershedElement * `#12845 `__: BUG: avoid boolean or integer addition error in ndimage.measurements.median * `#12864 `__: BLD: replace the #include of libqull_r.h with with this of qhull_ra.h... * `#12867 `__: BUG: Fixes a ValueError yielded upon calling Scipy Interpolator... * `#12902 `__: CI: Remove 'env' from pytest.ini * `#12913 `__: MAINT: Ignore pytest's PytestConfigWarning Checksums ========= MD5 ~~~ fd75941594b22a322f63a27d53c1bdda scipy-1.5.3-cp36-cp36m-macosx_10_9_x86_64.whl 85d547117ae6d9fd447120c1768ff2d0 scipy-1.5.3-cp36-cp36m-manylinux1_i686.whl 8e8ca0d9123c4f4bf59f74ec474fc936 scipy-1.5.3-cp36-cp36m-manylinux1_x86_64.whl 855db93424cf97e5b4685c4cf74be346 scipy-1.5.3-cp36-cp36m-manylinux2014_aarch64.whl 20405ee4157858d33e38c62b873b6420 scipy-1.5.3-cp36-cp36m-win32.whl be3f3ba1018e7b1f3a30738aa502a4b5 scipy-1.5.3-cp36-cp36m-win_amd64.whl 12be163517b748a025cd399e6e9ce7df scipy-1.5.3-cp37-cp37m-macosx_10_9_x86_64.whl b2d761876d1f1d27e289b08f44034ede scipy-1.5.3-cp37-cp37m-manylinux1_i686.whl 1cd15a513ad76c64a4353a63eee6b3a8 scipy-1.5.3-cp37-cp37m-manylinux1_x86_64.whl 00bb4f63f4ee40869193c8e639da3274 scipy-1.5.3-cp37-cp37m-manylinux2014_aarch64.whl f783a76397dfe2a73752ac86f32fa474 scipy-1.5.3-cp37-cp37m-win32.whl 3c2927e6adf9b522f7f1745308b4d1f2 scipy-1.5.3-cp37-cp37m-win_amd64.whl faaa0cab95b6f352508120b8f628aaae scipy-1.5.3-cp38-cp38-macosx_10_9_x86_64.whl 77e8cb222c1868f01f048a444ef49260 scipy-1.5.3-cp38-cp38-manylinux1_i686.whl a2a035b15f78106090b9550f1383b40f scipy-1.5.3-cp38-cp38-manylinux1_x86_64.whl 86d52a963596a4cf6e1930ac5cf79a03 scipy-1.5.3-cp38-cp38-manylinux2014_aarch64.whl 8dd29aceb8dae5b5cc4f8100d8b35423 scipy-1.5.3-cp38-cp38-win32.whl 14f617e43a37827a29e8ee9ad97eda4b scipy-1.5.3-cp38-cp38-win_amd64.whl ecf5c58e4df1d257abf1634d51cb9205 scipy-1.5.3.tar.gz 61bcc473115587a66acfb42d3021479b scipy-1.5.3.tar.xz a9c549f19c661ab1b44e5b2cc707d4c1 scipy-1.5.3.zip SHA256 ~~~~~~ f574558f1b774864516f3c3fe072ebc90a29186f49b720f60ed339294b7f32ac scipy-1.5.3-cp36-cp36m-macosx_10_9_x86_64.whl e527c9221b6494bcd06a17f9f16874406b32121385f9ab353b8a9545be458f0b scipy-1.5.3-cp36-cp36m-manylinux1_i686.whl b9751b39c52a3fa59312bd2e1f40144ee26b51404db5d2f0d5259c511ff6f614 scipy-1.5.3-cp36-cp36m-manylinux1_x86_64.whl d5e3cc60868f396b78fc881d2c76460febccfe90f6d2f082b9952265c79a8788 scipy-1.5.3-cp36-cp36m-manylinux2014_aarch64.whl 1fee28b6641ecbff6e80fe7788e50f50c5576157d278fa40f36c851940eb0aff scipy-1.5.3-cp36-cp36m-win32.whl ffcbd331f1ffa82e22f1d408e93c37463c9a83088243158635baec61983aaacf scipy-1.5.3-cp36-cp36m-win_amd64.whl 07b083128beae040f1129bd8a82b01804f5e716a7fd2962c1053fa683433e4ab scipy-1.5.3-cp37-cp37m-macosx_10_9_x86_64.whl e2602f79c85924e4486f684aa9bbab74afff90606100db88d0785a0088be7edb scipy-1.5.3-cp37-cp37m-manylinux1_i686.whl aebb69bcdec209d874fc4b0c7ac36f509d50418a431c1422465fa34c2c0143ea scipy-1.5.3-cp37-cp37m-manylinux1_x86_64.whl bc0e63daf43bf052aefbbd6c5424bc03f629d115ece828e87303a0bcc04a37e4 scipy-1.5.3-cp37-cp37m-manylinux2014_aarch64.whl 8cc5c39ed287a8b52a5509cd6680af078a40b0e010e2657eca01ffbfec929468 scipy-1.5.3-cp37-cp37m-win32.whl 0edd67e8a00903aaf7a29c968555a2e27c5a69fea9d1dcfffda80614281a884f scipy-1.5.3-cp37-cp37m-win_amd64.whl 66ec29348444ed6e8a14c9adc2de65e74a8fc526dc2c770741725464488ede1f scipy-1.5.3-cp38-cp38-macosx_10_9_x86_64.whl 12fdcbfa56cac926a0a9364a30cbf4ad03c2c7b59f75b14234656a5e4fd52bf3 scipy-1.5.3-cp38-cp38-manylinux1_i686.whl a1a13858b10d41beb0413c4378462b43eafef88a1948d286cb357eadc0aec024 scipy-1.5.3-cp38-cp38-manylinux1_x86_64.whl 5163200ab14fd2b83aba8f0c4ddcc1fa982a43192867264ab0f4c8065fd10d17 scipy-1.5.3-cp38-cp38-manylinux2014_aarch64.whl 33e6a7439f43f37d4c1135bc95bcd490ffeac6ef4b374892c7005ce2c729cf4a scipy-1.5.3-cp38-cp38-win32.whl a3db1fe7c6cb29ca02b14c9141151ebafd11e06ffb6da8ecd330eee5c8283a8a scipy-1.5.3-cp38-cp38-win_amd64.whl ddae76784574cc4c172f3d5edd7308be16078dd3b977e8746860c76c195fa707 scipy-1.5.3.tar.gz cab92f8dab54a3be66525ea23e4f6568145abd1e94681cce19258a140f4de416 scipy-1.5.3.tar.xz 32dd070e203363e3a63bc184afb1d8e165c0a36a49b83b097642f78ef4da6077 scipy-1.5.3.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Mon Oct 19 09:16:02 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Mon, 19 Oct 2020 10:16:02 -0300 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> Message-ID: Hello, Sam, sorry for taking so long to answer! The problem seems to be that you are using cf2py depend(in) Y, YP instead of cf2py depend(n) Y, YP <- (note that there was a spurious i in that depend expression) and that the callback FCN needs the dimension n as an argument. I was able to compile your code correctly after making these changes. If you have any further questions let me know, I hope this helps. Cheers, Melissa On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree wrote: > I'm attempting to wrap a Fortran-77 source member using f2py. I'm > running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) > under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm running > is 1.18.3. > > I've attached a copy of the Fortran source code to this note (see > rkfn78.for). The command I'm using to wrap this code is > > f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" -m rkfn78 > > The output I get is captured in the file rkfn78_build_output.txt. > > I don't understand the cause behind the error message I get, so any > advice would be welcomed. > > Sam Dupree. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdupree at speakeasy.net Mon Oct 19 12:03:13 2020 From: sdupree at speakeasy.net (Samuel Dupree) Date: Mon, 19 Oct 2020 12:03:13 -0400 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> Message-ID: Melissa, Thank you for answering my post. I made the changes you recommended and the code compiles successfully. But I do have one question. The arrays being passed in the CALL to FCN were treated as assumed shaped arrays in the called subroutine. Are assumed shaped arrays a problem for f2py? Sam Dupree. On October/19/2020 09:16:02, Melissa Mendon?a wrote: > Hello, Sam, sorry for taking so long to answer! > > The problem seems to be that you are using > > cf2py depend(in) Y, YP > > instead of > > cf2py depend(n) Y, YP <- (note that there was a spurious i in that > depend expression) > > and that the callback FCN needs the dimension n as an argument. I was > able to compile your code correctly after making these changes. > > If you have any further questions let me know, I hope this helps. > > Cheers, > > Melissa > > > On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree > wrote: > > I'm attempting to wrap a Fortran-77 source member using f2py. I'm > running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) > under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm > running > is 1.18.3. > > I've attached a copy of the Fortran source code to this note (see > rkfn78.for). The command I'm using to wrap this code is > > f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" > -m rkfn78 > > The output I get is captured in the file rkfn78_build_output.txt. > > I don't understand the cause behind the error message I get, so any > advice would be welcomed. > > Sam Dupree. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- mail-signature ------------------------------------------------------------------------ ? ?Samuel H. Dupree, Jr.sdupree at speakeasy.net ?? 10501 Rising Ridge Road ?? Apartment 201 http://users.speakeasy.net/~sdupree/ ?? Fredericksburg, VA 22407, USA ??? HOME: 540-693-1240??? ??? ??? iPhone: 215-530-8753 ??? ??? FAX: 866-514-9629 /????????? "The Greatest Show on Earth" is not on Earth. It's in Space!/ ------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IYA-2009.jpg Type: image/jpeg Size: 10005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mmb_emblem-2.gif Type: image/gif Size: 3793 bytes Desc: not available URL: From melissawm at gmail.com Mon Oct 19 13:01:13 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Mon, 19 Oct 2020 14:01:13 -0300 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> Message-ID: Sure, you can use assume-shape arrays, but if you generate a signature file using $ f2py rkfn78.for -m rkfn78 -h rkfn78.pyf you can see that f2py correctly determines n to be the length of the array Y, but since YP also depends on n, that's what generated the error you saw the first time. If you change the .pyf signature file to the one attached to this message, delete your original cf2py lines in the .for file and compile it all using $ f2py -c rkfn78.pyf rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" -m rkfn78 then you'll have no trouble with assumed-shape arrays. Cheers, Melissa On Mon, Oct 19, 2020 at 1:03 PM Samuel Dupree wrote: > > Melissa, > > Thank you for answering my post. I made the changes you recommended and the code compiles successfully. But I do have one question. The arrays being passed in the CALL to FCN were treated as assumed shaped arrays in the called subroutine. Are assumed shaped arrays a problem for f2py? > > Sam Dupree. > > > On October/19/2020 09:16:02, Melissa Mendon?a wrote: > > Hello, Sam, sorry for taking so long to answer! > > The problem seems to be that you are using > > cf2py depend(in) Y, YP > > instead of > > cf2py depend(n) Y, YP <- (note that there was a spurious i in that depend expression) > > and that the callback FCN needs the dimension n as an argument. I was able to compile your code correctly after making these changes. > > If you have any further questions let me know, I hope this helps. > > Cheers, > > Melissa > > > On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree wrote: >> >> I'm attempting to wrap a Fortran-77 source member using f2py. I'm >> running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) >> under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm running >> is 1.18.3. >> >> I've attached a copy of the Fortran source code to this note (see >> rkfn78.for). The command I'm using to wrap this code is >> >> f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" -m rkfn78 >> >> The output I get is captured in the file rkfn78_build_output.txt. >> >> I don't understand the cause behind the error message I get, so any >> advice would be welcomed. >> >> Sam Dupree. >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > -- > ________________________________ > > > Samuel H. Dupree, Jr. sdupree at speakeasy.net > 10501 Rising Ridge Road > Apartment 201 http://users.speakeasy.net/~sdupree/ > Fredericksburg, VA 22407, USA > > HOME: 540-693-1240 iPhone: 215-530-8753 FAX: 866-514-9629 > > "The Greatest Show on Earth" is not on Earth. It's in Space! > > ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rkfn78.pyf Type: application/octet-stream Size: 1778 bytes Desc: not available URL: From sdupree at speakeasy.net Mon Oct 19 13:35:04 2020 From: sdupree at speakeasy.net (Samuel Dupree) Date: Mon, 19 Oct 2020 13:35:04 -0400 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> Message-ID: <6a3e68d1-cf05-936b-5dda-17acc2ff091b@speakeasy.net> One more question. Where can I find a documentation on f2py that covers issues like assumed shaped arrays, and issues such as the one discussed in this post? Sam Dupree. On October/19/2020 13:01:13, Melissa Mendon?a wrote: > Sure, you can use assume-shape arrays, but if you generate a signature > file using > > $ f2py rkfn78.for -m rkfn78 -h rkfn78.pyf > > you can see that f2py correctly determines n to be the length of the > array Y, but since YP also depends on n, that's what generated the > error you saw the first time. > > If you change the .pyf signature file to the one attached to this > message, delete your original cf2py lines in the .for file and compile > it all using > > $ f2py -c rkfn78.pyf rkfn78.for --fcompiler=gfortran --f77flags="-c -O > -Wall" -m rkfn78 > > then you'll have no trouble with assumed-shape arrays. > > Cheers, > > Melissa > > On Mon, Oct 19, 2020 at 1:03 PM Samuel Dupree > wrote: > > > > Melissa, > > > > Thank you for answering my post. I made the changes you recommended > and the code compiles successfully. But I do have one question. The > arrays being passed in the CALL to FCN were treated as assumed shaped > arrays in the called subroutine. Are assumed shaped arrays a problem > for f2py? > > > > Sam Dupree. > > > > > > On October/19/2020 09:16:02, Melissa Mendon?a wrote: > > > > Hello, Sam, sorry for taking so long to answer! > > > > The problem seems to be that you are using > > > > cf2py depend(in) Y, YP > > > > instead of > > > > cf2py depend(n) Y, YP <- (note that there was a spurious i in that > depend expression) > > > > and that the callback FCN needs the dimension n as an argument. I > was able to compile your code correctly after making these changes. > > > > If you have any further questions let me know, I hope this helps. > > > > Cheers, > > > > Melissa > > > > > > On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree > wrote: > >> > >> I'm attempting to wrap a Fortran-77 source member using f2py. I'm > >> running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) > >> under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm > running > >> is 1.18.3. > >> > >> I've attached a copy of the Fortran source code to this note (see > >> rkfn78.for). The command I'm using to wrap this code is > >> > >> f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" > -m rkfn78 > >> > >> The output I get is captured in the file rkfn78_build_output.txt. > >> > >> I don't understand the cause behind the error message I get, so any > >> advice would be welcomed. > >> > >> Sam Dupree. > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Mon Oct 19 13:53:03 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Mon, 19 Oct 2020 14:53:03 -0300 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: <6a3e68d1-cf05-936b-5dda-17acc2ff091b@speakeasy.net> References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> <6a3e68d1-cf05-936b-5dda-17acc2ff091b@speakeasy.net> Message-ID: The documentation for f2py is not very complete, I'm afraid. I'll try to work on that front in the next few months. For now, you can find it here: https://numpy.org/doc/stable/f2py Cheers, Melissa On Mon, Oct 19, 2020 at 2:35 PM Samuel Dupree wrote: > One more question. Where can I find a documentation on f2py that covers > issues like assumed shaped arrays, and issues such as the one discussed in > this post? > > Sam Dupree. > > > On October/19/2020 13:01:13, Melissa Mendon?a wrote: > > Sure, you can use assume-shape arrays, but if you generate a signature > file using > > $ f2py rkfn78.for -m rkfn78 -h rkfn78.pyf > > you can see that f2py correctly determines n to be the length of the array > Y, but since YP also depends on n, that's what generated the error you saw > the first time. > > If you change the .pyf signature file to the one attached to this message, > delete your original cf2py lines in the .for file and compile it all using > > $ f2py -c rkfn78.pyf rkfn78.for --fcompiler=gfortran --f77flags="-c -O > -Wall" -m rkfn78 > > then you'll have no trouble with assumed-shape arrays. > > Cheers, > > Melissa > > On Mon, Oct 19, 2020 at 1:03 PM Samuel Dupree > wrote: > > > > Melissa, > > > > Thank you for answering my post. I made the changes you recommended and > the code compiles successfully. But I do have one question. The arrays > being passed in the CALL to FCN were treated as assumed shaped arrays in > the called subroutine. Are assumed shaped arrays a problem for f2py? > > > > Sam Dupree. > > > > > > On October/19/2020 09:16:02, Melissa Mendon?a wrote: > > > > Hello, Sam, sorry for taking so long to answer! > > > > The problem seems to be that you are using > > > > cf2py depend(in) Y, YP > > > > instead of > > > > cf2py depend(n) Y, YP <- (note that there was a spurious i in that > depend expression) > > > > and that the callback FCN needs the dimension n as an argument. I was > able to compile your code correctly after making these changes. > > > > If you have any further questions let me know, I hope this helps. > > > > Cheers, > > > > Melissa > > > > > > On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree > wrote: > >> > >> I'm attempting to wrap a Fortran-77 source member using f2py. I'm > >> running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) > >> under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm running > >> is 1.18.3. > >> > >> I've attached a copy of the Fortran source code to this note (see > >> rkfn78.for). The command I'm using to wrap this code is > >> > >> f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O -Wall" -m > rkfn78 > >> > >> The output I get is captured in the file rkfn78_build_output.txt. > >> > >> I don't understand the cause behind the error message I get, so any > >> advice would be welcomed. > >> > >> Sam Dupree. > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdupree at speakeasy.net Mon Oct 19 14:03:40 2020 From: sdupree at speakeasy.net (Samuel Dupree) Date: Mon, 19 Oct 2020 14:03:40 -0400 Subject: [Numpy-discussion] Attempting to wrap a Fortran-77 subroutine using f2py but I haven't been able to understand what is causing the error In-Reply-To: References: <9cb71de5-11c7-1bdc-e47d-c595e0afc81c@speakeasy.net> <6a3e68d1-cf05-936b-5dda-17acc2ff091b@speakeasy.net> Message-ID: Melissa, I've tried working with the documentation hosted at https://numpy.org/doc/stable/f2py/ and you're right, it is not very complete ;-). So on that front I wish you the best. Once again, thank you very much for answering my post. All the best. Sam Dupree. On October/19/2020 13:53:03, Melissa Mendon?a wrote: > The documentation for f2py is not very complete, I'm afraid. I'll try > to work on that front in the next few months. For now, you can find it > here: https://numpy.org/doc/stable/f2py > > > Cheers, > > Melissa > > On Mon, Oct 19, 2020 at 2:35 PM Samuel Dupree > wrote: > > One more question. Where can I find a documentation on f2py that > covers issues like assumed shaped arrays, and issues such as the > one discussed in this post? > > Sam Dupree. > > > On October/19/2020 13:01:13, Melissa Mendon?a wrote: >> Sure, you can use assume-shape arrays, but if you generate a >> signature file using >> >> $ f2py rkfn78.for -m rkfn78 -h rkfn78.pyf >> >> you can see that f2py correctly determines n to be the length of >> the array Y, but since YP also depends on n, that's what >> generated the error you saw the first time. >> >> If you change the .pyf signature file to the one attached to this >> message, delete your original cf2py lines in the .for file and >> compile it all using >> >> $ f2py -c rkfn78.pyf rkfn78.for --fcompiler=gfortran >> --f77flags="-c -O -Wall" -m rkfn78 >> >> then you'll have no trouble with assumed-shape arrays. >> >> Cheers, >> >> Melissa >> >> On Mon, Oct 19, 2020 at 1:03 PM Samuel Dupree >> > wrote: >> > >> > Melissa, >> > >> > Thank you for answering my post. I made the changes you >> recommended and the code compiles successfully. But I do have one >> question. The arrays being passed in the CALL to FCN were treated >> as assumed shaped arrays in the called subroutine. Are assumed >> shaped arrays a problem for f2py? >> > >> > Sam Dupree. >> > >> > >> > On October/19/2020 09:16:02, Melissa Mendon?a wrote: >> > >> > Hello, Sam, sorry for taking so long to answer! >> > >> > The problem seems to be that you are using >> > >> > cf2py depend(in) Y, YP >> > >> > instead of >> > >> > cf2py depend(n) Y, YP <- (note that there was a spurious i in >> that depend expression) >> > >> > and that the callback FCN needs the dimension n as an argument. >> I was able to compile your code correctly after making these changes. >> > >> > If you have any further questions let me know, I hope this helps. >> > >> > Cheers, >> > >> > Melissa >> > >> > >> > On Wed, Oct 14, 2020 at 4:03 AM Samuel Dupree >> > wrote: >> >> >> >> I'm attempting to wrap a Fortran-77 source member using f2py. I'm >> >> running he Anaconda distribution for Python 3.7.6 on a Mac Pro >> (2019) >> >> under Mac OS X Catalina (ver. 10.15.6). The version of NumPy >> I'm running >> >> is 1.18.3. >> >> >> >> I've attached a copy of the Fortran source code to this note (see >> >> rkfn78.for). The command I'm using to wrap this code is >> >> >> >> f2py3 -c rkfn78.for --fcompiler=gfortran --f77flags="-c -O >> -Wall" -m rkfn78 >> >> >> >> The output I get is captured in the file rkfn78_build_output.txt. >> >> >> >> I don't understand the cause behind the error message I get, >> so any >> >> advice would be welcomed. >> >> >> >> Sam Dupree. >> >> _______________________________________________ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion at python.org >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Mon Oct 19 19:50:38 2020 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 19 Oct 2020 19:50:38 -0400 Subject: [Numpy-discussion] [SciPy-Dev] ANN: SciPy 1.5.3 In-Reply-To: References: Message-ID: On 10/17/20, Tyler Reddy wrote: > Hi all, > > On behalf of the SciPy development team I'm pleased to announce > the release of SciPy 1.5.3, which is a bug fix release that includes > Linux ARM64 wheels for the first time. Thanks Tyler! A lot of work goes into a SciPy release, so I'm grateful you continue to manage the releases so well. Warren > > Sources and binary wheels can be found at: > https://pypi.org/project/scipy/ > and at: https://github.com/scipy/scipy/releases/tag/v1.5.3 > > One of a few ways to install this release with pip: > > pip install scipy==1.5.3 > > ========================== > SciPy 1.5.3 Release Notes > ========================== > > SciPy 1.5.3 is a bug-fix release with no new features > compared to 1.5.2. In particular, Linux ARM64 wheels are now > available and a compatibility issue with XCode 12 has > been fixed. > > Authors > ====== > > * Peter Bell > * CJ Carey > * Thomas Duvernay + > * Gregory Lee > * Eric Moore > * odidev > * Dima Pasechnik > * Tyler Reddy > * Simon Segerblom Rex + > * Daniel B. Smith > * Will Tirone + > * Warren Weckesser > > A total of 12 people contributed to this release. > People with a "+" by their names contributed a patch for the first time. > This list of names is automatically generated, and may not be fully > complete. > > Issues closed for 1.5.3 > ------------------------------ > > * `#9611 `__: Overflow error > with new way of p-value calculation in kendall... > * `#10069 `__: > scipy.ndimage.watershed_ift regression in 1.0.0 > * `#11260 `__: BUG: DOP853 > with complex data computes complex error norm, causing... > * `#11479 `__: RuntimeError: > dictionary changed size during iteration on loading... > * `#11972 `__: BUG (solved): > Error estimation in DOP853 ODE solver fails for... > * `#12543 `__: BUG: Picture > rotated 180 degrees and rotated -180 degrees should... > * `#12613 `__: Travis X.4 and > X.7 failures in master > * `#12654 `__: > scipy.stats.combine_pvalues produces wrong results with > method='mudholkar_george' > * `#12819 `__: BUG: Scipy > Sparse slice indexing assignment Bug with zeros > * `#12834 `__: BUG: ValueError > upon calling Scipy Interpolator objects > * `#12836 `__: ndimage.median > can return incorrect values for integer inputs > * `#12860 `__: Build failure > with Xcode 12 > > Pull requests for 1.5.3 > ----------------------------- > > * `#12611 `__: MAINT: prepare > for SciPy 1.5.3 > * `#12614 `__: MAINT: prevent > reverse broadcasting > * `#12617 `__: MAINT: optimize: > Handle nonscalar size 1 arrays in fmin_slsqp... > * `#12623 `__: MAINT: stats: > Loosen some test tolerances. > * `#12638 `__: CI, MAINT: pin > pytest for Azure win > * `#12668 `__: BUG: Ensure > factorial is not too large in mstats.kendalltau > * `#12705 `__: MAINT: > \`openblas_support\` added sha256 hash > * `#12706 `__: BUG: fix > incorrect 1d case of the fourier_ellipsoid filter > * `#12721 `__: BUG: use > special.sindg in ndimage.rotate > * `#12724 `__: BUG: per #12654 > adjusted mudholkar_george method to combine p... > * `#12726 `__: BUG: Fix DOP853 > error norm for complex problems > * `#12730 `__: CI: pin xdist for > Azure windows > * `#12786 `__: BUG: stats: Fix > formula in the \`stats\` method of the ARGUS... > * `#12795 `__: CI: Pin > setuptools on windows CI > * `#12830 `__: [BUG] sparse: > Avoid using size attribute in LIL __setitem__ > * `#12833 `__: BUG: change list > of globals items to list of a copy > * `#12842 `__: BUG: Use uint16 > for cost in NI_WatershedElement > * `#12845 `__: BUG: avoid > boolean or integer addition error in ndimage.measurements.median > * `#12864 `__: BLD: replace the > #include of libqull_r.h with with this of qhull_ra.h... > * `#12867 `__: BUG: Fixes a > ValueError yielded upon calling Scipy Interpolator... > * `#12902 `__: CI: Remove 'env' > from pytest.ini > * `#12913 `__: MAINT: Ignore > pytest's PytestConfigWarning > > > Checksums > ========= > > MD5 > ~~~ > > fd75941594b22a322f63a27d53c1bdda > scipy-1.5.3-cp36-cp36m-macosx_10_9_x86_64.whl > 85d547117ae6d9fd447120c1768ff2d0 > scipy-1.5.3-cp36-cp36m-manylinux1_i686.whl > 8e8ca0d9123c4f4bf59f74ec474fc936 > scipy-1.5.3-cp36-cp36m-manylinux1_x86_64.whl > 855db93424cf97e5b4685c4cf74be346 > scipy-1.5.3-cp36-cp36m-manylinux2014_aarch64.whl > 20405ee4157858d33e38c62b873b6420 scipy-1.5.3-cp36-cp36m-win32.whl > be3f3ba1018e7b1f3a30738aa502a4b5 scipy-1.5.3-cp36-cp36m-win_amd64.whl > 12be163517b748a025cd399e6e9ce7df > scipy-1.5.3-cp37-cp37m-macosx_10_9_x86_64.whl > b2d761876d1f1d27e289b08f44034ede > scipy-1.5.3-cp37-cp37m-manylinux1_i686.whl > 1cd15a513ad76c64a4353a63eee6b3a8 > scipy-1.5.3-cp37-cp37m-manylinux1_x86_64.whl > 00bb4f63f4ee40869193c8e639da3274 > scipy-1.5.3-cp37-cp37m-manylinux2014_aarch64.whl > f783a76397dfe2a73752ac86f32fa474 scipy-1.5.3-cp37-cp37m-win32.whl > 3c2927e6adf9b522f7f1745308b4d1f2 scipy-1.5.3-cp37-cp37m-win_amd64.whl > faaa0cab95b6f352508120b8f628aaae > scipy-1.5.3-cp38-cp38-macosx_10_9_x86_64.whl > 77e8cb222c1868f01f048a444ef49260 scipy-1.5.3-cp38-cp38-manylinux1_i686.whl > a2a035b15f78106090b9550f1383b40f > scipy-1.5.3-cp38-cp38-manylinux1_x86_64.whl > 86d52a963596a4cf6e1930ac5cf79a03 > scipy-1.5.3-cp38-cp38-manylinux2014_aarch64.whl > 8dd29aceb8dae5b5cc4f8100d8b35423 scipy-1.5.3-cp38-cp38-win32.whl > 14f617e43a37827a29e8ee9ad97eda4b scipy-1.5.3-cp38-cp38-win_amd64.whl > ecf5c58e4df1d257abf1634d51cb9205 scipy-1.5.3.tar.gz > 61bcc473115587a66acfb42d3021479b scipy-1.5.3.tar.xz > a9c549f19c661ab1b44e5b2cc707d4c1 scipy-1.5.3.zip > > SHA256 > ~~~~~~ > > f574558f1b774864516f3c3fe072ebc90a29186f49b720f60ed339294b7f32ac > scipy-1.5.3-cp36-cp36m-macosx_10_9_x86_64.whl > e527c9221b6494bcd06a17f9f16874406b32121385f9ab353b8a9545be458f0b > scipy-1.5.3-cp36-cp36m-manylinux1_i686.whl > b9751b39c52a3fa59312bd2e1f40144ee26b51404db5d2f0d5259c511ff6f614 > scipy-1.5.3-cp36-cp36m-manylinux1_x86_64.whl > d5e3cc60868f396b78fc881d2c76460febccfe90f6d2f082b9952265c79a8788 > scipy-1.5.3-cp36-cp36m-manylinux2014_aarch64.whl > 1fee28b6641ecbff6e80fe7788e50f50c5576157d278fa40f36c851940eb0aff > scipy-1.5.3-cp36-cp36m-win32.whl > ffcbd331f1ffa82e22f1d408e93c37463c9a83088243158635baec61983aaacf > scipy-1.5.3-cp36-cp36m-win_amd64.whl > 07b083128beae040f1129bd8a82b01804f5e716a7fd2962c1053fa683433e4ab > scipy-1.5.3-cp37-cp37m-macosx_10_9_x86_64.whl > e2602f79c85924e4486f684aa9bbab74afff90606100db88d0785a0088be7edb > scipy-1.5.3-cp37-cp37m-manylinux1_i686.whl > aebb69bcdec209d874fc4b0c7ac36f509d50418a431c1422465fa34c2c0143ea > scipy-1.5.3-cp37-cp37m-manylinux1_x86_64.whl > bc0e63daf43bf052aefbbd6c5424bc03f629d115ece828e87303a0bcc04a37e4 > scipy-1.5.3-cp37-cp37m-manylinux2014_aarch64.whl > 8cc5c39ed287a8b52a5509cd6680af078a40b0e010e2657eca01ffbfec929468 > scipy-1.5.3-cp37-cp37m-win32.whl > 0edd67e8a00903aaf7a29c968555a2e27c5a69fea9d1dcfffda80614281a884f > scipy-1.5.3-cp37-cp37m-win_amd64.whl > 66ec29348444ed6e8a14c9adc2de65e74a8fc526dc2c770741725464488ede1f > scipy-1.5.3-cp38-cp38-macosx_10_9_x86_64.whl > 12fdcbfa56cac926a0a9364a30cbf4ad03c2c7b59f75b14234656a5e4fd52bf3 > scipy-1.5.3-cp38-cp38-manylinux1_i686.whl > a1a13858b10d41beb0413c4378462b43eafef88a1948d286cb357eadc0aec024 > scipy-1.5.3-cp38-cp38-manylinux1_x86_64.whl > 5163200ab14fd2b83aba8f0c4ddcc1fa982a43192867264ab0f4c8065fd10d17 > scipy-1.5.3-cp38-cp38-manylinux2014_aarch64.whl > 33e6a7439f43f37d4c1135bc95bcd490ffeac6ef4b374892c7005ce2c729cf4a > scipy-1.5.3-cp38-cp38-win32.whl > a3db1fe7c6cb29ca02b14c9141151ebafd11e06ffb6da8ecd330eee5c8283a8a > scipy-1.5.3-cp38-cp38-win_amd64.whl > ddae76784574cc4c172f3d5edd7308be16078dd3b977e8746860c76c195fa707 > scipy-1.5.3.tar.gz > cab92f8dab54a3be66525ea23e4f6568145abd1e94681cce19258a140f4de416 > scipy-1.5.3.tar.xz > 32dd070e203363e3a63bc184afb1d8e165c0a36a49b83b097642f78ef4da6077 > scipy-1.5.3.zip > From sebastian at sipsolutions.net Tue Oct 20 14:04:27 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 20 Oct 2020 13:04:27 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Wednesday - Triage Focus Message-ID: <72e547fe8ac71df099c35dcc217d8d44e5960daa.camel@sipsolutions.net> Hi all, Our bi-weekly triage-focused NumPy development meeting is today (Wednesday, October 21st) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized, discussed, or reviewed. Best regards Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From amardeepjk at gmail.com Fri Oct 23 13:50:47 2020 From: amardeepjk at gmail.com (Amardeep Singh) Date: Sat, 24 Oct 2020 01:50:47 +0800 Subject: [Numpy-discussion] help needed Message-ID: Hi All I am a new joiner.Using macbook. Can someone please guide me how to debug numpy using clion? I am able to build not sure about debugging the c code. ProductName: Mac OS X ProductVersion: 10.15.7 BuildVersion: 19H2 thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Fri Oct 23 14:09:23 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Fri, 23 Oct 2020 13:09:23 -0500 Subject: [Numpy-discussion] help needed In-Reply-To: References: Message-ID: <7af1264fd9aca5b6873d4a9716d4cb527351e316.camel@sipsolutions.net> On Sat, 2020-10-24 at 01:50 +0800, Amardeep Singh wrote: > Hi All > > I am a new joiner.Using macbook. > Can someone please guide me how to debug numpy using clion? > I am able to build not sure about debugging the c code. > > ProductName: Mac OS X > > ProductVersion: 10.15.7 > > BuildVersion: 19H2 Hi, I have set up an bogus `CMakeLists.txt` (actually using `python runtests.py` for compilation and running). That should allow you to use debugging tools in editors relying on cmake normally. My current file is below. This is the opposite of polished or thought out, so happy to learn of a better solution. And for example recently I added `NULL=0` because I had issues without really digging into why and I am sure it lists many files multiple times: cmake_minimum_required(VERSION 3.13) #cmake_policy(SET CMP0074 NEW) project(NumPy-dummy) AUX_SOURCE_DIRECTORY(numpy/core/src/multiarray/ MULTIARRAY) AUX_SOURCE_DIRECTORY(numpy/core/src/umath/ UMATH) AUX_SOURCE_DIRECTORY(numpy/core/src/common/ COMMON) AUX_SOURCE_DIRECTORY(numpy/core/src/npymath/ NPYMATH) AUX_SOURCE_DIRECTORY(numpy/core/src/npysort/ NPYSORT) AUX_SOURCE_DIRECTORY(numpy/core/include/ NPYINCLUDE) AUX_SOURCE_DIRECTORY(numpy/core/include/numpy/ NPYINCLUDEFULL) AUX_SOURCE_DIRECTORY(build/testenv/lib/python3.8/site-packages/numpy/core/include/numpy/ INSTALLED_NUMPY) AUX_SOURCE_DIRECTORY(build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ HELPER_FOR_C_SCR_FILES) set( SOURCE_FILES ${MULTIARRAY} ${UMATH} ${COMMON} ${NPYMATH} ${NPYSORT} numpy/core/src/multiarray/ build/src.linux-x86_64-3.8/numpy/core/include/ build/src.linux-x86_64-3.8/numpy/core/include/numpy/ build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c build/src.linux-x86_64-3.8/numpy/core/src/common/ build/src.linux-x86_64-3.8/numpy/core/src/umath/ build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ build/src.linux-x86_64-3.8/numpy/core/src/npymath/ build/src.linux-x86_64-3.8/numpy/core/src/npysort/ numpy/core/src/common/ numpy/core/include/) set(CMAKE_INCLUDE_PATH SOURCE_FILES) add_compile_definitions(NPY_INTERNAL_BUILD) add_compile_definitions([=[NPY_VISIBILITY_HIDDEN=__attribute__((visibility("hidden")))]=]) # add_compile_definitions(NPY_VISIBILITY_HIDDEN=) add_compile_definitions(NULL=0) #add_compile_definitions(NPY_SIZEOF_SHORT=2) #add_compile_definitions(NPY_SIZEOF_INT=4) #add_compile_definitions(NPY_SIZEOF_LONG=8) #add_compile_definitions(NPY_SIZEOF_LONGLONG=8) #add_compile_definitions(NPY_SIZEOF_PY_INTPTR_T=8) # Find default python libraries and interpreter #find_package(PythonInterp 3 REQUIRED) #find_package(PythonLibs 3 REQUIRED) #include_directories(${SOURCE_FILES} ${PYTHON_INCLUDE_DIRS}) # PYTHON_INCLUDE_DIRS also picks up the wrong numpy files... # The "clean" version below is manually edited with numpy removed... # I manuall deleted sudo rm -rf /usr/include/numpy, but I do not think it should have been there?! #include_directories(${SOURCE_FILES} /home/sebastian/venvs/pydbg-clean/include/python3.8d) include_directories(${SOURCE_FILES} /usr/include/python3.8) add_executable(asdf build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c ${SOURCE_FILES}) > > > thx > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From melissawm at gmail.com Fri Oct 23 16:23:26 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Fri, 23 Oct 2020 17:23:26 -0300 Subject: [Numpy-discussion] Fwd: Documentation Team meeting - Monday October 12 In-Reply-To: References: Message-ID: Hi all! This is a reminder that our next Documentation Team meeting will be on *Monday, October 26* at 3PM UTC**. If you wish to join on Zoom, **you need to use this NEW link** https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09 Here's the permanent hackmd document with the meeting notes (still being updated in the next few days!): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20201026T15&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From amardeepjk at gmail.com Fri Oct 23 17:38:14 2020 From: amardeepjk at gmail.com (Amardeep Singh) Date: Sat, 24 Oct 2020 05:38:14 +0800 Subject: [Numpy-discussion] help needed In-Reply-To: <7af1264fd9aca5b6873d4a9716d4cb527351e316.camel@sipsolutions.net> References: <7af1264fd9aca5b6873d4a9716d4cb527351e316.camel@sipsolutions.net> Message-ID: How do you use the debug enabled cpython on mac.i guess we need it. You build cpython from source? this is mytest.py file import numpy as np x = np.arange(5) np.empty_like(x) i run this command gdb --args python3 runtests.py -g --python3 mytest.py i get this Reading symbols from python3... (No debugging symbols found in python3) (gdb) sh-3.2# which python3 /Library/Frameworks/Python.framework/Versions/3.7/bin/python3 sh-3.2# On Sat, Oct 24, 2020 at 2:09 AM Sebastian Berg wrote: > On Sat, 2020-10-24 at 01:50 +0800, Amardeep Singh wrote: > > Hi All > > > > I am a new joiner.Using macbook. > > Can someone please guide me how to debug numpy using clion? > > I am able to build not sure about debugging the c code. > > > > ProductName: Mac OS X > > > > ProductVersion: 10.15.7 > > > > BuildVersion: 19H2 > > > > Hi, > > I have set up an bogus `CMakeLists.txt` (actually using `python > runtests.py` for compilation and running). That should allow you to > use debugging tools in editors relying on cmake normally. > > My current file is below. This is the opposite of polished or thought > out, so happy to learn of a better solution. And for example recently I > added `NULL=0` because I had issues without really digging into why and > I am sure it lists many files multiple times: > > > > cmake_minimum_required(VERSION 3.13) > > #cmake_policy(SET CMP0074 NEW) > > project(NumPy-dummy) > > > AUX_SOURCE_DIRECTORY(numpy/core/src/multiarray/ MULTIARRAY) > AUX_SOURCE_DIRECTORY(numpy/core/src/umath/ UMATH) > AUX_SOURCE_DIRECTORY(numpy/core/src/common/ COMMON) > AUX_SOURCE_DIRECTORY(numpy/core/src/npymath/ NPYMATH) > AUX_SOURCE_DIRECTORY(numpy/core/src/npysort/ NPYSORT) > > AUX_SOURCE_DIRECTORY(numpy/core/include/ NPYINCLUDE) > AUX_SOURCE_DIRECTORY(numpy/core/include/numpy/ NPYINCLUDEFULL) > > AUX_SOURCE_DIRECTORY(build/testenv/lib/python3.8/site-packages/numpy/core/include/numpy/ > INSTALLED_NUMPY) > AUX_SOURCE_DIRECTORY(build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ > HELPER_FOR_C_SCR_FILES) > > set( > SOURCE_FILES > ${MULTIARRAY} > ${UMATH} > ${COMMON} > ${NPYMATH} > ${NPYSORT} > numpy/core/src/multiarray/ > build/src.linux-x86_64-3.8/numpy/core/include/ > build/src.linux-x86_64-3.8/numpy/core/include/numpy/ > > build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c > build/src.linux-x86_64-3.8/numpy/core/src/common/ > build/src.linux-x86_64-3.8/numpy/core/src/umath/ > build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ > build/src.linux-x86_64-3.8/numpy/core/src/npymath/ > build/src.linux-x86_64-3.8/numpy/core/src/npysort/ > numpy/core/src/common/ > numpy/core/include/) > > set(CMAKE_INCLUDE_PATH SOURCE_FILES) > > add_compile_definitions(NPY_INTERNAL_BUILD) > > add_compile_definitions([=[NPY_VISIBILITY_HIDDEN=__attribute__((visibility("hidden")))]=]) > # add_compile_definitions(NPY_VISIBILITY_HIDDEN=) > > add_compile_definitions(NULL=0) > #add_compile_definitions(NPY_SIZEOF_SHORT=2) > #add_compile_definitions(NPY_SIZEOF_INT=4) > #add_compile_definitions(NPY_SIZEOF_LONG=8) > #add_compile_definitions(NPY_SIZEOF_LONGLONG=8) > #add_compile_definitions(NPY_SIZEOF_PY_INTPTR_T=8) > > > # Find default python libraries and interpreter > #find_package(PythonInterp 3 REQUIRED) > #find_package(PythonLibs 3 REQUIRED) > > #include_directories(${SOURCE_FILES} ${PYTHON_INCLUDE_DIRS}) # > PYTHON_INCLUDE_DIRS also picks up the wrong numpy files... > # The "clean" version below is manually edited with numpy removed... > # I manuall deleted sudo rm -rf /usr/include/numpy, but I do not think it > should have been there?! > #include_directories(${SOURCE_FILES} > /home/sebastian/venvs/pydbg-clean/include/python3.8d) > include_directories(${SOURCE_FILES} /usr/include/python3.8) > > add_executable(asdf > build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c > ${SOURCE_FILES}) > > > > > > > > > > thx > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh3597 at gmail.com Fri Oct 23 20:34:59 2020 From: ganesh3597 at gmail.com (Ganesh Kathiresan) Date: Sat, 24 Oct 2020 06:04:59 +0530 Subject: [Numpy-discussion] ENH: Changed repr of np.bool_ #17592 (requesting confirmation) Message-ID: Hi All, I have raised a PR to change the np.bool_ string representation to avoid confusion with python's True and False as mentioned in this issue . This change makes string representation of np.bool_ into numpy.True_ and numpy.False_ As Eric mentioned, I wanted your feedback on the change and if we can go ahead with this idea. Regards, Ganesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustin at virtualroadside.com Sat Oct 24 03:11:15 2020 From: dustin at virtualroadside.com (Dustin Spicuzza) Date: Sat, 24 Oct 2020 03:11:15 -0400 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package Message-ID: Hey all, [copied from https://github.com/numpy/numpy/issues/17620, as requested by the feature request guidelines] Cross-compiling scipy and other projects that depend on numpy's distutils is a huge pain right now, because to do it [in addition to lots of other details that you have to get right] you have to have both a native and cross-compiled version of numpy installed. It seems pretty unreasonable that I need a native version of numpy installed to compile scipy. One might ask, why is this needed? Well, scipy's setup.py uses numpy's distutils fork for the fortran support (I think). Because numpy.distutils is a subpackage of numpy, if you're working with a cross-compiled version of numpy, it eventually tries to import some .so that wasn't compiled for your host and everything dies -- thus you have to have a native numpy installed to allow numpy.distutils to import correctly. As far as I can tell, numpy's distutils fork is pure python and doesn't actually use anything else in numpy itself, and so is completely separable from numpy. If it were its own top-level package that scipy et al could use, then cross-compiling would be significantly less tricky. The mechanics of this would work like so: * contents of numpy.distutils would be moved to 'numpy_distutils' package * importing numpy.distutils would raise a deprecation warning and redirect to numpy_distutils, probably using import hook magic * scipy and other packages would now utilize numpy_distutils instead of numpy.distutils at build time Initially, I considered proposing creating a separate pypi package for numpy_distutils, but I expect that would be more trouble than it's worth. One could also propose creating a new PEP 517 build backend, or move to cmake, or other huge changes, but those also seem more trouble than they're worth. Thanks for your consideration. Dustin From kevin.k.sheppard at gmail.com Sat Oct 24 03:32:20 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Sat, 24 Oct 2020 08:32:20 +0100 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: Message-ID: Separating it is definitely a good idea. The only thing that I think would be better would be if they key features that are not in setuptools could be added there so that NumPy distutils could eventually be retired. Kevin On Sat, Oct 24, 2020, 08:12 Dustin Spicuzza wrote: > Hey all, > > [copied from https://github.com/numpy/numpy/issues/17620, as requested > by the feature request guidelines] > > Cross-compiling scipy and other projects that depend on numpy's > distutils is a huge pain right now, because to do it [in addition to > lots of other details that you have to get right] you have to have both > a native and cross-compiled version of numpy installed. It seems pretty > unreasonable that I need a native version of numpy installed to compile > scipy. One might ask, why is this needed? > > Well, scipy's setup.py uses numpy's distutils fork for the fortran > support (I think). Because numpy.distutils is a subpackage of numpy, if > you're working with a cross-compiled version of numpy, it eventually > tries to import some .so that wasn't compiled for your host and > everything dies -- thus you have to have a native numpy installed to > allow numpy.distutils to import correctly. > > As far as I can tell, numpy's distutils fork is pure python and doesn't > actually use anything else in numpy itself, and so is completely > separable from numpy. If it were its own top-level package that scipy et > al could use, then cross-compiling would be significantly less tricky. > > The mechanics of this would work like so: > > * contents of numpy.distutils would be moved to 'numpy_distutils' package > * importing numpy.distutils would raise a deprecation warning and > redirect to numpy_distutils, probably using import hook magic > * scipy and other packages would now utilize numpy_distutils instead of > numpy.distutils at build time > > Initially, I considered proposing creating a separate pypi package for > numpy_distutils, but I expect that would be more trouble than it's > worth. One could also propose creating a new PEP 517 build backend, or > move to cmake, or other huge changes, but those also seem more trouble > than they're worth. > > Thanks for your consideration. > > Dustin > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sat Oct 24 08:31:56 2020 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 24 Oct 2020 15:31:56 +0300 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: Message-ID: la, 2020-10-24 kello 03:11 -0400, Dustin Spicuzza kirjoitti: > Cross-compiling scipy and other projects that depend on numpy's > distutils is a huge pain right now, because to do it [in addition to > lots of other details that you have to get right] you have to have > both > a native and cross-compiled version of numpy installed. It seems > pretty > unreasonable that I need a native version of numpy installed to > compile > scipy. One might ask, why is this needed? Factoring out numpy.distutils from numpy alone will not enable compiling scipy without numpy being installed. It probably can help, though, and might make sense also in view of the incoming deprecation of Python distutils (https://www.python.org/dev/peps/pep-0632/). Extension modules, including f2py, need numpy headers and probably also their platform-specific configuration. There are also some assumptions about data type sizes and Numpy versions at build-time being compatible with the ones at runtime, which factoring out distutils won't address. IIUC, cross-compilation is not actually supported, so that it can be made to work is surprising. Pauli From amardeepjk at gmail.com Sat Oct 24 13:22:10 2020 From: amardeepjk at gmail.com (Amardeep Singh) Date: Sun, 25 Oct 2020 01:22:10 +0800 Subject: [Numpy-discussion] help needed In-Reply-To: References: <7af1264fd9aca5b6873d4a9716d4cb527351e316.camel@sipsolutions.net> Message-ID: Hi All, Thx.Debug enabled build worked fine on windows10.Also python for macos does not give option to install debug enabled build . I was able to build and debug via clion on windows not on mac. lldb did not work for me on mac.Not sure why.seems gdb has some version issues with macos even after code signing. thx On Sat, Oct 24, 2020 at 5:38 AM Amardeep Singh wrote: > How do you use the debug enabled cpython on mac.i guess we need it. > You build cpython from source? > > this is mytest.py file > > import numpy as np > x = np.arange(5) > np.empty_like(x) > > i run this command > > gdb --args python3 runtests.py -g --python3 mytest.py > > i get this > > Reading symbols from python3... > (No debugging symbols found in python3) > (gdb) > > sh-3.2# which python3 > /Library/Frameworks/Python.framework/Versions/3.7/bin/python3 > sh-3.2# > > > > > > > > > On Sat, Oct 24, 2020 at 2:09 AM Sebastian Berg > wrote: > >> On Sat, 2020-10-24 at 01:50 +0800, Amardeep Singh wrote: >> > Hi All >> > >> > I am a new joiner.Using macbook. >> > Can someone please guide me how to debug numpy using clion? >> > I am able to build not sure about debugging the c code. >> > >> > ProductName: Mac OS X >> > >> > ProductVersion: 10.15.7 >> > >> > BuildVersion: 19H2 >> >> >> >> Hi, >> >> I have set up an bogus `CMakeLists.txt` (actually using `python >> runtests.py` for compilation and running). That should allow you to >> use debugging tools in editors relying on cmake normally. >> >> My current file is below. This is the opposite of polished or thought >> out, so happy to learn of a better solution. And for example recently I >> added `NULL=0` because I had issues without really digging into why and >> I am sure it lists many files multiple times: >> >> >> >> cmake_minimum_required(VERSION 3.13) >> >> #cmake_policy(SET CMP0074 NEW) >> >> project(NumPy-dummy) >> >> >> AUX_SOURCE_DIRECTORY(numpy/core/src/multiarray/ MULTIARRAY) >> AUX_SOURCE_DIRECTORY(numpy/core/src/umath/ UMATH) >> AUX_SOURCE_DIRECTORY(numpy/core/src/common/ COMMON) >> AUX_SOURCE_DIRECTORY(numpy/core/src/npymath/ NPYMATH) >> AUX_SOURCE_DIRECTORY(numpy/core/src/npysort/ NPYSORT) >> >> AUX_SOURCE_DIRECTORY(numpy/core/include/ NPYINCLUDE) >> AUX_SOURCE_DIRECTORY(numpy/core/include/numpy/ NPYINCLUDEFULL) >> >> AUX_SOURCE_DIRECTORY(build/testenv/lib/python3.8/site-packages/numpy/core/include/numpy/ >> INSTALLED_NUMPY) >> AUX_SOURCE_DIRECTORY(build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ >> HELPER_FOR_C_SCR_FILES) >> >> set( >> SOURCE_FILES >> ${MULTIARRAY} >> ${UMATH} >> ${COMMON} >> ${NPYMATH} >> ${NPYSORT} >> numpy/core/src/multiarray/ >> build/src.linux-x86_64-3.8/numpy/core/include/ >> build/src.linux-x86_64-3.8/numpy/core/include/numpy/ >> >> build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c >> build/src.linux-x86_64-3.8/numpy/core/src/common/ >> build/src.linux-x86_64-3.8/numpy/core/src/umath/ >> build/src.linux-x86_64-3.8/numpy/core/src/multiarray/ >> build/src.linux-x86_64-3.8/numpy/core/src/npymath/ >> build/src.linux-x86_64-3.8/numpy/core/src/npysort/ >> numpy/core/src/common/ >> numpy/core/include/) >> >> set(CMAKE_INCLUDE_PATH SOURCE_FILES) >> >> add_compile_definitions(NPY_INTERNAL_BUILD) >> >> add_compile_definitions([=[NPY_VISIBILITY_HIDDEN=__attribute__((visibility("hidden")))]=]) >> # add_compile_definitions(NPY_VISIBILITY_HIDDEN=) >> >> add_compile_definitions(NULL=0) >> #add_compile_definitions(NPY_SIZEOF_SHORT=2) >> #add_compile_definitions(NPY_SIZEOF_INT=4) >> #add_compile_definitions(NPY_SIZEOF_LONG=8) >> #add_compile_definitions(NPY_SIZEOF_LONGLONG=8) >> #add_compile_definitions(NPY_SIZEOF_PY_INTPTR_T=8) >> >> >> # Find default python libraries and interpreter >> #find_package(PythonInterp 3 REQUIRED) >> #find_package(PythonLibs 3 REQUIRED) >> >> #include_directories(${SOURCE_FILES} ${PYTHON_INCLUDE_DIRS}) # >> PYTHON_INCLUDE_DIRS also picks up the wrong numpy files... >> # The "clean" version below is manually edited with numpy removed... >> # I manuall deleted sudo rm -rf /usr/include/numpy, but I do not think it >> should have been there?! >> #include_directories(${SOURCE_FILES} >> /home/sebastian/venvs/pydbg-clean/include/python3.8d) >> include_directories(${SOURCE_FILES} /usr/include/python3.8) >> >> add_executable(asdf >> build/src.linux-x86_64-3.8/numpy/core/include/numpy/__multiarray_api.c >> ${SOURCE_FILES}) >> >> >> >> >> > >> > >> > thx >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustin at virtualroadside.com Sat Oct 24 14:59:12 2020 From: dustin at virtualroadside.com (Dustin Spicuzza) Date: Sat, 24 Oct 2020 14:59:12 -0400 (EDT) Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: Message-ID: <857851769.190322.1603565952851@email.ionos.com> An HTML attachment was scrubbed... URL: From dustin at virtualroadside.com Sun Oct 25 04:46:52 2020 From: dustin at virtualroadside.com (Dustin Spicuzza) Date: Sun, 25 Oct 2020 04:46:52 -0400 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: <857851769.190322.1603565952851@email.ionos.com> References: <857851769.190322.1603565952851@email.ionos.com> Message-ID: <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> On 10/24/20 2:59 PM, Dustin Spicuzza wrote: > Since this initial feedback seems mostly positive, I'll go ahead and > take a stab at refactoring it and make a PR potentially this weekend. > It should be fairly straightforward. > > Dustin I took a first stab at it, and... surprise, surprise, there were a few more warts than I had originally expected in my initial survey. The biggest unexpected result is that numpy.f2py would need to also be a toplevel package. I did get the refactor cross-compiled and started on scipy, but there's a few more issues that will have to be resolved on the scipy side. I posted a detailed set of notes on the issue (#17620) and made a draft PR with my initial results (#17632) if you want to get a sense for how invasive this is (or isn't depending on your point of view). Dustin From matti.picus at gmail.com Sun Oct 25 05:23:00 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 25 Oct 2020 11:23:00 +0200 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: On 10/25/20 10:46 AM, Dustin Spicuzza wrote: > I took a first stab at it, and... surprise, surprise, there were a few > more warts than I had originally expected in my initial survey. The > biggest unexpected result is that numpy.f2py would need to also be a > toplevel package. I did get the refactor cross-compiled and started on > scipy, but there's a few more issues that will have to be resolved on > the scipy side. > > I posted a detailed set of notes on the issue (#17620) and made a draft > PR with my initial results (#17632) if you want to get a sense for how > invasive this is (or isn't depending on your point of view). > > Dustin > Is there a way to do this without modifying SciPy? That would reassure me that this change will not break other peoples' workflow. It is hard to believe that only SciPy uses numpy.distutils. If the changes break backward compatibility, they need to be done like any other deprecation: warn for 4 releases (two years) before actually breaking workflows. Matti From kevin.k.sheppard at gmail.com Sun Oct 25 09:19:58 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Sun, 25 Oct 2020 13:19:58 +0000 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: NumPy could take an explicit runtime dependency on numpy-distutils so that the code would be technically in a different repo bit would always be available through NumPy. Eventually this could be removed as a runtime dependency. Kevin On Sun, Oct 25, 2020, 09:23 Matti Picus wrote: > > On 10/25/20 10:46 AM, Dustin Spicuzza wrote: > > I took a first stab at it, and... surprise, surprise, there were a few > > more warts than I had originally expected in my initial survey. The > > biggest unexpected result is that numpy.f2py would need to also be a > > toplevel package. I did get the refactor cross-compiled and started on > > scipy, but there's a few more issues that will have to be resolved on > > the scipy side. > > > > I posted a detailed set of notes on the issue (#17620) and made a draft > > PR with my initial results (#17632) if you want to get a sense for how > > invasive this is (or isn't depending on your point of view). > > > > Dustin > > > Is there a way to do this without modifying SciPy? That would reassure > me that this change will not break other peoples' workflow. It is hard > to believe that only SciPy uses numpy.distutils. If the changes break > backward compatibility, they need to be done like any other deprecation: > warn for 4 releases (two years) before actually breaking workflows. > > > Matti > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustin at virtualroadside.com Sun Oct 25 11:39:04 2020 From: dustin at virtualroadside.com (Dustin Spicuzza) Date: Sun, 25 Oct 2020 11:39:04 -0400 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: On 10/25/20 5:23 AM, Matti Picus wrote: > > On 10/25/20 10:46 AM, Dustin Spicuzza wrote: >> I took a first stab at it, and... surprise, surprise, there were a few >> more warts than I had originally expected in my initial survey. The >> biggest unexpected result is that numpy.f2py would need to also be a >> toplevel package. I did get the refactor cross-compiled and started on >> scipy, but there's a few more issues that will have to be resolved on >> the scipy side. >> >> I posted a detailed set of notes on the issue (#17620) and made a draft >> PR with my initial results (#17632) if you want to get a sense for how >> invasive this is (or isn't depending on your point of view). >> >> Dustin >> > Is there a way to do this without modifying SciPy? That would reassure > me that this change will not break other peoples' workflow. It is hard > to believe that only SciPy uses numpy.distutils. If the changes break > backward compatibility, they need to be done like any other > deprecation: warn for 4 releases (two years) before actually breaking > workflows. > > > Matti Sorry for not being clear, when I was discussing modifications to scipy I was referring to the specific use case of cross-compilation. The goal is that existing native builds would not break backwards compatibility. To that end, there's a package redirection stub in my PR for both numpy.distutils and numpy.f2py. Just tried a native build using my current PR branch and at the moment scipy doesn't work. However, it's a size mismatch during compilation as opposed to an ImportError, so I probably just missed a subtlety when I moved things. But I would definitely expect the finalized version of this set of changes should not break existing users. Dustin From dustin at virtualroadside.com Sun Oct 25 15:44:28 2020 From: dustin at virtualroadside.com (Dustin Spicuzza) Date: Sun, 25 Oct 2020 15:44:28 -0400 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: On 10/25/20 11:39 AM, Dustin Spicuzza wrote: > On 10/25/20 5:23 AM, Matti Picus wrote: >> On 10/25/20 10:46 AM, Dustin Spicuzza wrote: >>> I took a first stab at it, and... surprise, surprise, there were a few >>> more warts than I had originally expected in my initial survey. The >>> biggest unexpected result is that numpy.f2py would need to also be a >>> toplevel package. I did get the refactor cross-compiled and started on >>> scipy, but there's a few more issues that will have to be resolved on >>> the scipy side. >>> >>> I posted a detailed set of notes on the issue (#17620) and made a draft >>> PR with my initial results (#17632) if you want to get a sense for how >>> invasive this is (or isn't depending on your point of view). >>> >>> Dustin >>> >> Is there a way to do this without modifying SciPy? That would reassure >> me that this change will not break other peoples' workflow. It is hard >> to believe that only SciPy uses numpy.distutils. If the changes break >> backward compatibility, they need to be done like any other >> deprecation: warn for 4 releases (two years) before actually breaking >> workflows. >> >> >> Matti > > Sorry for not being clear, when I was discussing modifications to scipy > I was referring to the specific use case of cross-compilation. The goal > is that existing native builds would not break backwards compatibility. > To that end, there's a package redirection stub in my PR for both > numpy.distutils and numpy.f2py. > > Just tried a native build using my current PR branch and at the moment > scipy doesn't work. However, it's a size mismatch during compilation as > opposed to an ImportError, so I probably just missed a subtlety when I > moved things. But I would definitely expect the finalized version of > this set of changes should not break existing users. > > Dustin PR now builds unmodified scipy natively. Dustin From matti.picus at gmail.com Sun Oct 25 15:46:31 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 25 Oct 2020 21:46:31 +0200 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: On 10/25/20 5:39 PM, Dustin Spicuzza wrote: > Sorry for not being clear, when I was discussing modifications to scipy > I was referring to the specific use case of cross-compilation. The goal > is that existing native builds would not break backwards compatibility. > To that end, there's a package redirection stub in my PR for both > numpy.distutils and numpy.f2py. > > Dustin Thanks for the clarification. Matti From ralf.gommers at gmail.com Mon Oct 26 13:29:55 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 26 Oct 2020 17:29:55 +0000 Subject: [Numpy-discussion] Proposal: split numpy.distutils into it's own package In-Reply-To: References: <857851769.190322.1603565952851@email.ionos.com> <6bbaf4e0-17df-4910-eb73-c997385cb8a8@virtualroadside.com> Message-ID: On Sun, Oct 25, 2020 at 1:20 PM Kevin Sheppard wrote: > NumPy could take an explicit runtime dependency on numpy-distutils so that > the code would be technically in a different repo bit would always be > available through NumPy. Eventually this could be removed as a runtime > dependency. > I put some more thoughts in https://github.com/numpy/numpy/issues/17620. We cannot remove numpy.distutils, so that separate package may be needed for cross-compilation but we don't need to use it in NumPy itself. >From a high level: being able to cross-compile would be great. However long-term we can hopefully put everything in setuptools, so I'd like the changes now to be as non-invasive as possible. > Kevin > > > On Sun, Oct 25, 2020, 09:23 Matti Picus wrote: > >> >> On 10/25/20 10:46 AM, Dustin Spicuzza wrote: >> > I took a first stab at it, and... surprise, surprise, there were a few >> > more warts than I had originally expected in my initial survey. The >> > biggest unexpected result is that numpy.f2py would need to also be a >> > toplevel package. I did get the refactor cross-compiled and started on >> > scipy, but there's a few more issues that will have to be resolved on >> > the scipy side. >> > >> > I posted a detailed set of notes on the issue (#17620) and made a draft >> > PR with my initial results (#17632) if you want to get a sense for how >> > invasive this is (or isn't depending on your point of view). >> > >> > Dustin >> > >> Is there a way to do this without modifying SciPy? > > The goal is to modify SciPy here, so it can be cross-compiled. That would reassure >> me that this change will not break other peoples' workflow. It is hard >> to believe that only SciPy uses numpy.distutils. > > That is indeed not the case, numpy.distutils is widely used. The `numpy.distutils` namespace must remain accessible imho. Cheers, Ralf If the changes break >> backward compatibility, they need to be done like any other deprecation: >> warn for 4 releases (two years) before actually breaking workflows. >> > >> >> Matti >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Oct 27 13:06:13 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 27 Oct 2020 12:06:13 -0500 Subject: [Numpy-discussion] =?utf-8?q?Accepting_NEP_42_=E2=80=94_New_and_?= =?utf-8?q?extensible_DTypes?= In-Reply-To: References: Message-ID: <9eaa0c4de45eb118ce8e091170015ac5b22b0537.camel@sipsolutions.net> Hi all, On Thu, 2020-10-08 at 07:51 -0500, Sebastian Berg wrote: > Hi all, > > after another thorough revision of NEP 42 (much thanks to Ben!), I > propose accepting the NEP, with the note that details are expected > change. > > I am always happy to clarify and review the document based on > feedback, > but I feel the important technical points should be very clear and > settled. > Exposing all of the proposed API may need additional detailed API > discussion. My focus is still a bit on the big picture design choices > that the NEP makes need to move forward and settle the implementation > internal to NumPy, although I am happy to discuss the details! > > The title of the NEP is: > > NEP 42 ? New and extensible DTypes > This has been a while ago, and a draft for NEP 43 (UFunc redesign) is now available at: https://numpy.org/neps/nep-0043-extensible-ufuncs.html I would appreciate any feedback and am happy to go into more details where necessary. Do we have a consensus about the general big picture API design or are there any concerns? These documents outline (most importantly): 1. How DTypes should be created (NEP 42) 2. How Casting will be implemented (NEP 42) 3. How UFuncs will be redesigned: (NEP 43) * This changes the calling convention * It also unifies casting largely with ufuncs 4. How ufunc promotion will be handled in the future: (NEP 43) * This is what happens when you add mixed types, for example float64 + int32 casts int32 to float64 and uses the float64 + float64 implementation. Point 1. is finished to the extend currently necessary. Right now I am basically finishing with Casting (point 2). And I expect it to move forward very soon at least in part. This does have a big overlap with UFuncs (point 3), though. So if you are interested in that, it is a good time to dive in, even if many details can still be changed easily for a while! Cheers, Sebastian > And available at: > > https://numpy.org/neps/nep-0042-new-dtypes.html > > While enabling new user-defined DTypes is the main goal, the main > work > is the internal restructure of NumPy's own DTypes necessary to allow > that. > > I have pasted the "Abstract" and "Motivation and scope" section > below, > which give a good overview of the issues and we are trying to > address. > It is followed by the "Usage and impact" section which gives a big- > picture overview of the design. > I will refer to the full NEP for more detailed technical decisions > and > explanations. > > Cheers, > > Sebastian > > > PS: In some places NEP 42 references NEP 43, for which I hope to > merge > the draft soon, the current status is here: > > https://github.com/numpy/numpy/pull/16723 > > However, this should be mainly interested for those wishing to go > into > more technical details. > > > > > ********************************************************************* > ** > ******* > Abstract > ********************************************************************* > ** > ******* > > NumPy's dtype architecture is monolithic -- each dtype is an instance > of a > single class. There's no principled way to expand it for new dtypes, > and the > code is difficult to read and maintain. > > As :ref:`NEP 41 ` explains, we are proposing a new > architecture > that is > modular and open to user additions. dtypes will derive from a new > ``DType`` > class serving as the extension point for new types. > ``np.dtype("float64")`` > will return an instance of a ``Float64`` class, a subclass of root > class > ``np.dtype``. > > This NEP is one of two that lay out the design and API of this new > architecture. This NEP addresses dtype implementation; NEP 43 > addresses > universal functions. > > .. note:: > > Details of the private and external APIs may change to reflect > user > comments and implementation constraints. The underlying > principles > and > choices should not change significantly. > > > ********************************************************************* > ** > ******* > Motivation and scope > ********************************************************************* > ** > ******* > > Our goal is to allow user code to create fully featured dtypes for a > broad > variety of uses, from physical units (such as meters) to domain- > specific > representations of geometric objects. :ref:`NEP 41 ` describes > a > number > of these new dtypes and their benefits. > > Any design supporting dtypes must consider: > > - How shape and dtype are determined when an array is created > - How array elements are stored and accessed > - The rules for casting dtypes to other dtypes > > In addition: > > - We want dtypes to comprise a class hierarchy open to new types and > to > subhierarchies, as motivated in :ref:`NEP 41 `. > > And to provide this, > > - We need to define a user API. > > All these are the subjects of this NEP. > > - The class hierarchy, its relation to the Python scalar types, and > its > important attributes are described in `nep42_DType class`_. > > - The functionality that will support dtype casting is described in > `Casting`_. > > - The implementation of item access and storage, and the way shape > and > dtype > are determined when creating an array, are described in > :ref:`nep42_array_coercion`. > > - The functionality for users to define their own DTypes is described > in > `Public C-API`_. > > The API here and in NEP 43 is entirely on the C side. A Python-side > version > will be proposed in a future NEP. A future Python API is expected to > be > similar, but provide a more convenient API to reuse the functionality > of > existing DTypes. It could also provide shorthands to create > structured > DTypes > similar to Python's > `dataclasses `_ > . > > > ********************************************************************* > ** > ******* > Usage and impact > ********************************************************************* > ** > ******* > > We believe the few structures in this section are sufficient to > consolidate > NumPy's present functionality and also to support complex user- > defined > DTypes. > > The rest of the NEP fills in details and provides support for the > claim. > > Again, though Python is used for illustration, the implementation is > a > C API only; a > future NEP will tackle the Python API. > > After implementing this NEP, creating a DType will be possible by > implementing > the following outlined DType base class, > that is further described in `nep42_DType class`_: > > class DType(np.dtype): > type : type # Python scalar type > parametric : bool # (may be indicated by superclass) > > @property > def canonical(self) -> bool: > raise NotImplementedError > > def ensure_canonical(self : DType) -> DType: > raise NotImplementedError > > For casting, a large part of the functionality is provided by the > "methods" stored > in ``_castingimpl`` > > @classmethod > def common_dtype(cls : DTypeMeta, other : DTypeMeta) -> > DTypeMeta: > raise NotImplementedError > > def common_instance(self : DType, other : DType) -> DType: > raise NotImplementedError > > # A mapping of "methods" each detailing how to cast to > another > DType > # (further specified at the end of the section) > _castingimpl = {} > > For array-coercion, also part of casting: > > def __dtype_setitem__(self, item_pointer, value): > raise NotImplementedError > > def __dtype_getitem__(self, item_pointer, base_obj) -> > object: > raise NotImplementedError > > @classmethod > def __discover_descr_from_pyobject__(cls, obj : object) -> > DType: > raise NotImplementedError > > # initially private: > @classmethod > def _known_scalar_type(cls, obj : object) -> bool: > raise NotImplementedError > > > Other elements of the casting implementation is the ``CastingImpl``: > > casting = Union["safe", "same_kind", "unsafe"] > > class CastingImpl: > # Object describing and performing the cast > casting : casting > > def resolve_descriptors(self, Tuple[DType] : input) -> > (casting, Tuple[DType]): > raise NotImplementedError > > # initially private: > def _get_loop(...) -> lowlevel_C_loop: > raise NotImplementedError > > which describes the casting from one DType to another. In > NEP 43 this ``CastingImpl`` object is used unchanged to > support universal functions. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From asmeurer at gmail.com Tue Oct 27 19:15:31 2020 From: asmeurer at gmail.com (Aaron Meurer) Date: Tue, 27 Oct 2020 17:15:31 -0600 Subject: [Numpy-discussion] Allow __getitem__ to support custom objects Message-ID: For ndindex (https://quansight.github.io/ndindex/), the biggest issue with the API is that to use an ndindex object to actually index an array, you have to use a[idx.raw] instead of a[idx]. This is because for NumPy arrays, you cannot allow custom objects to be indices. The exception is objects that define __index__, but this only works for integer indices. If __index__ returns anything other than an integer, you get an IndexError. This is annoying because it's easy to forget to do this when working with the ndindex API, and the error message from NumPy isn't informative about what went wrong unless you know to expect it. I'd like to propose an API that would allow custom objects to define how they should be converted to a standard NumPy index, similar to __index__ but that supports all index types. I think there are two options here: - Allow __index__ to return any index type, not just integers. This is the simplest because it reuses an existing API, and __index__ is the best possible name for this API. However, I'm not sure, but this may actually conflict with the text of PEP 357 (https://www.python.org/dev/peps/pep-0357/). Also, some other APIs use __index__ to check if something is an indexable integer, which wouldn't accept generic index. For example, elements of a slice can be any object that defines __index__. - Add a new __numpy_index__ API that works like def __numpy_index__(self): return In NumPy, __getitem__ and __setitem__ on ndarray would first check if the input index type is one of the known types as it currently does, then it would try __index__, and if neither of those fails, it would call __numpy_index__(index) and use that. Note: there is a more general way that NumPy arrays could allow __getitem__ to be defined on custom objects, which I am NOT proposing. Instead of an API that returns one of the current predefined index types (tuple, integer, slice, newaxis, ellipsis, or integer or boolean array), there could instead be an API that takes the array as input and returns another array (or view) as an output. This would allow an object to define itself as an index in arbitrary ways, even if such an index would not actually be possible via traditional indexing. There are definitely some interesting ideas that could be done with this, but this idea would be much more complicated, and isn't something that I need. Unless the community feels that a more general API like this would be preferred, I would suggest deferring something like it to a later discussion. What would be the best way to go about getting something like this implemented? Is it simple enough that we can just work out the details here and on a pull request, or should I write a NEP? Aaron Meurer From sebastian at sipsolutions.net Wed Oct 28 00:55:10 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 27 Oct 2020 23:55:10 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday (1h difference for Europe due to daylight saving ending) Message-ID: <65c6783168a6767c37c72271c18ad8e2bffcf0fc.camel@sipsolutions.net> Hi all, There will be a NumPy Community meeting Wednesday October 27th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bas.vanbeek at hotmail.com Wed Oct 28 17:43:28 2020 From: bas.vanbeek at hotmail.com (bas van beek) Date: Wed, 28 Oct 2020 21:43:28 +0000 Subject: [Numpy-discussion] Ndarray static typing: Order of generic types Message-ID: Hey all, With the recent merging of numpy/numpy#16759 we're at the point where `ndarray` can be made generic w.r.t. its dtype and shape. An open question which yet remains is to order in which these two parameters should appear (numpy/numpy#16547): * `ndarray[Dtype, Shape]` * `ndarray[Shape, Dtype]` There has been a some discussion about this question in issue 16547, but a consensus has not yet to be reached. Most people seem to slightly preferring one option over the other. Are there any further thoughts on this subject? Regards, Bas van Beek -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Oct 28 22:12:30 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 28 Oct 2020 20:12:30 -0600 Subject: [Numpy-discussion] NumPy 1.19.3 release Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.3 has been released. NumPy 1.19.3 is a small maintenance release with two major improvements: - Python 3.9 binary wheels on all supported platforms, - OpenBLAS fixes for Windows 10 version 2004 fmod bug. This release supports Python 3.6-3.9 and is linked with OpenBLAS 3.12 to avoid some of the fmod problems on Windows 10 version 2004. Microsoft is aware of the problem and users should upgrade when the fix becomes available, the fix here is limited in scope. NumPy Wheels for this release can be downloaded from the PyPI , source archives, release notes, and wheel hashes are available on Github . Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 8 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Chris Brown + - Daniel Vanzo + - E. Madison Bray + - Hugo van Kemenade + - Ralf Gommers - Sebastian Berg - @danbeibei + *Pull requests merged* A total of 10 pull requests were merged for this release. - #17298: BLD: set upper versions for build dependencies - #17336: BUG: Set deprecated fields to null in PyArray_InitArrFuncs - #17446: ENH: Warn on unsupported Python 3.10+ - #17450: MAINT: Update test_requirements.txt. - #17522: ENH: Support for the NVIDIA HPC SDK nvfortran compiler - #17568: BUG: Cygwin Workaround for #14787 on affected platforms - #17647: BUG: Fix memory leak of buffer-info cache due to relaxed strides - #17652: MAINT: Backport openblas_support from master. - #17653: TST: Add Python 3.9 to the CI testing on Windows, Mac. - #17660: TST: Simplify source path names in test_extending. Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Wed Oct 28 23:34:07 2020 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Wed, 28 Oct 2020 23:34:07 -0400 Subject: [Numpy-discussion] [SciPy-Dev] NumPy 1.19.3 release In-Reply-To: References: Message-ID: On 10/28/20, Charles R Harris wrote: > Hi All, > > On behalf of the NumPy team I am pleased to announce that NumPy 1.19.3 has > been released. NumPy 1.19.3 is a small maintenance release with two major > improvements: > > - Python 3.9 binary wheels on all supported platforms, > - OpenBLAS fixes for Windows 10 version 2004 fmod bug. > > This release supports Python 3.6-3.9 and is linked with OpenBLAS 3.12 to > avoid some of the fmod problems on Windows 10 version 2004. Microsoft is > aware of the problem and users should upgrade when the fix becomes > available, the fix here is limited in scope. > > NumPy Wheels for this release can be downloaded from the PyPI > , source archives, release notes, > and wheel hashes are available on Github > . Linux users will > need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 > wheels. > > *Contributors* > > A total of 8 people contributed to this release. People with a "+" by > their > names contributed a patch for the first time. > > > - Charles Harris > - Chris Brown + > - Daniel Vanzo + > - E. Madison Bray + > - Hugo van Kemenade + > - Ralf Gommers > - Sebastian Berg > - @danbeibei + > > > > *Pull requests merged* > A total of 10 pull requests were merged for this release. > > - #17298: BLD: set upper versions for build dependencies > - #17336: BUG: Set deprecated fields to null in PyArray_InitArrFuncs > - #17446: ENH: Warn on unsupported Python 3.10+ > - #17450: MAINT: Update test_requirements.txt. > - #17522: ENH: Support for the NVIDIA HPC SDK nvfortran compiler > - #17568: BUG: Cygwin Workaround for #14787 on affected platforms > - #17647: BUG: Fix memory leak of buffer-info cache due to relaxed > strides > - #17652: MAINT: Backport openblas_support from master. > - #17653: TST: Add Python 3.9 to the CI testing on Windows, Mac. > - #17660: TST: Simplify source path names in test_extending. > > Cheers, > > Charles Harris > Thanks for managing the release, Chuck! Warren From charlesr.harris at gmail.com Wed Oct 28 23:42:59 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 28 Oct 2020 21:42:59 -0600 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? Message-ID: Hi All, Seems that is pretty easy to transfer a github repo to another owner. Should we do this for the numpy-wheels repo? That would put all the management in one place and now might be a good time to do it before the 1.20.x branch. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Oct 29 04:41:04 2020 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 29 Oct 2020 08:41:04 +0000 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: References: Message-ID: Seems like a good idea. It would need Matti or someone to set up the various keys I think? From matti.picus at gmail.com Thu Oct 29 06:00:10 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 29 Oct 2020 12:00:10 +0200 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: References: Message-ID: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> On 10/29/20 5:42 AM, Charles R Harris wrote: > Hi All, > > Seems that is pretty easy to transfer a github repo to another owner. > Should we do this for the numpy-wheels repo? That would put all the > management in one place and now might be a good time to do it before > the 1.20.x branch. > > Chuck > What is the goal? So far it is convenient that all the repos that upload to https://anaconda.org/multibuild-wheels-staging are under one org to coordinate upload token use. From charlesr.harris at gmail.com Thu Oct 29 10:24:59 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 29 Oct 2020 08:24:59 -0600 Subject: [Numpy-discussion] NumPy 1.20.x branch in two weeks Message-ID: Hi All, Time to start planning for the 1.20.x branch. These are my thoughts at the moment: - Keep support for Python 3.6. Python 3.7 came out in June 2018, which seems too recent to be our oldest supported version. - Drop Python 3.6 for 1.21.x, that will make the oldest supported version about three years old. - Drop manylinux1 for 1.21.x. It would be nice to drop earlier, but manylinux2010 is pretty recent. There were 33 wheels in the 1.19.3 release, I think we can live with that for 1.20.x. I'm more worried about our tools aging out. After Python has settled into its yearly release cycle, I think we will end up supporting the latest 4 versions. Thoughts? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Oct 29 10:33:47 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 29 Oct 2020 10:33:47 -0400 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> References: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> Message-ID: I agree with Matti that keeping at least the nightly wheel building / uploading for a bunch of projects all in on place makes sense. Tom On Thu, Oct 29, 2020 at 6:00 AM Matti Picus wrote: > > On 10/29/20 5:42 AM, Charles R Harris wrote: > > Hi All, > > > > Seems that is pretty easy to transfer a github repo to another owner. > > Should we do this for the numpy-wheels repo? That would put all the > > management in one place and now might be a good time to do it before > > the 1.20.x branch. > > > > Chuck > > > > What is the goal? So far it is convenient that all the repos that upload > to https://anaconda.org/multibuild-wheels-staging are under one org to > coordinate upload token use. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Thu Oct 29 10:42:11 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 29 Oct 2020 08:42:11 -0600 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> References: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> Message-ID: On Thu, Oct 29, 2020 at 4:00 AM Matti Picus wrote: > > On 10/29/20 5:42 AM, Charles R Harris wrote: > > Hi All, > > > > Seems that is pretty easy to transfer a github repo to another owner. > > Should we do this for the numpy-wheels repo? That would put all the > > management in one place and now might be a good time to do it before > > the 1.20.x branch. > > > > Chuck > > > > What is the goal? So far it is convenient that all the repos that upload > to https://anaconda.org/multibuild-wheels-staging are under one org to > coordinate upload token use. > > My thought was administration, which was triggered by the need to move to travis-ci.com. Note that the travis app shows up on the MacPython site, and apparently is available for scipy-wheels, but is not visible to numpy-wheels. My guess is that an owner of MacPython needs to add the repo and migrate it. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Thu Oct 29 12:18:53 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 29 Oct 2020 18:18:53 +0200 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: References: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> Message-ID: <46509cce-3c31-db7c-0288-3da1d780c85b@gmail.com> An HTML attachment was scrubbed... URL: From kevin.k.sheppard at gmail.com Thu Oct 29 12:21:24 2020 From: kevin.k.sheppard at gmail.com (Kevin Sheppard) Date: Thu, 29 Oct 2020 16:21:24 +0000 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: <46509cce-3c31-db7c-0288-3da1d780c85b@gmail.com> References: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> , <46509cce-3c31-db7c-0288-3da1d780c85b@gmail.com> Message-ID: <1B4CAF43-DF7A-41D8-B9BF-972C13AD144D@hxcore.ol> An HTML attachment was scrubbed... URL: From grlee77 at gmail.com Thu Oct 29 13:08:44 2020 From: grlee77 at gmail.com (Gregory Lee) Date: Thu, 29 Oct 2020 13:08:44 -0400 Subject: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org? In-Reply-To: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> References: <0aa8b543-90c1-5aad-b02b-8c7ffe369722@gmail.com> Message-ID: On Thu, Oct 29, 2020 at 6:00 AM Matti Picus wrote: > > On 10/29/20 5:42 AM, Charles R Harris wrote: > > Hi All, > > > > Seems that is pretty easy to transfer a github repo to another owner. > > Should we do this for the numpy-wheels repo? That would put all the > > management in one place and now might be a good time to do it before > > the 1.20.x branch. > > > > Chuck > > > > What is the goal? So far it is convenient that all the repos that upload > to https://anaconda.org/multibuild-wheels-staging are under one org to > coordinate upload token use. > > One case using *multibuild-wheels-staging* that is not currently under MacPython is https://github.com/scikit-image/scikit-image-wheels. We have not actually uploaded to *multibuild-wheels-staging* yet, but will be doing so when we build wheels for the upcoming 0.18 release. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shoyer at gmail.com Thu Oct 29 16:35:41 2020 From: shoyer at gmail.com (Stephan Hoyer) Date: Thu, 29 Oct 2020 13:35:41 -0700 Subject: [Numpy-discussion] Ndarray static typing: Order of generic types In-Reply-To: References: Message-ID: On Wed, Oct 28, 2020 at 2:44 PM bas van beek wrote: > Hey all, > > > > With the recent merging of numpy/numpy#16759 > we?re at the point where ` > ndarray` can be made generic w.r.t. its dtype and shape. > > An open question which yet remains is to order in which these two > parameters should appear (numpy/numpy#16547 > ): > > ? `ndarray[Dtype, Shape]` > > ? `ndarray[Shape, Dtype]` > > Hi Bas, Thanks for driving this forward! Just to speak for myself, I don't think the precise choice matters very much. There are arguments for consistency both ways. In the end Dtype and Shape are different enough that I doubt it will be a point of confusion. Also, I would guess many users will define their own type aliases, so can write something more succinct like Float64[shape] rather than ndarray[float64, shape]. We might even consider including some of these in numpy.typing. Cheers, Stephan > > > There has been a some discussion about this question in issue 16547, but a > consensus has not yet to be reached. > > Most people seem to slightly preferring one option over the other. > > > > Are there any further thoughts on this subject? > > > > Regards, > > Bas van Beek > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From currurant at gmail.com Thu Oct 29 17:18:14 2020 From: currurant at gmail.com (Currurant) Date: Thu, 29 Oct 2020 14:18:14 -0700 (MST) Subject: [Numpy-discussion] Multinomial random sampling Message-ID: <1604006294913-0.post@n7.nabble.com> I wonder if there is an efficient way to draw multinomial random samples. For univariate sampling, we can do that for different parameters and desired shape, but neither of rng nor multinomial function in numpy.random is able to achieve that. To be specific, can we draw multinomial samples for different probabilities and different n? I asked the question on Stackoverflow here: https://stackoverflow.com/questions/64529620/is-there-an-efficient-way-to-generate-multinomial-random-variables-in-parallel. Seems like there isn't a function to do that. Thank you and appreciate numpy, Daniel -- Sent from: http://numpy-discussion.10968.n7.nabble.com/ From robert.kern at gmail.com Thu Oct 29 17:49:18 2020 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 29 Oct 2020 17:49:18 -0400 Subject: [Numpy-discussion] Multinomial random sampling In-Reply-To: <1604006294913-0.post@n7.nabble.com> References: <1604006294913-0.post@n7.nabble.com> Message-ID: On Thu, Oct 29, 2020 at 5:19 PM Currurant wrote: > I wonder if there is an efficient way to draw multinomial random samples. > For > univariate sampling, we can do that for different parameters and desired > shape, but neither of rng nor multinomial function in numpy.random is able > to achieve that. To be specific, can we draw multinomial samples for > different probabilities and different n? > > I asked the question on Stackoverflow here: > > https://stackoverflow.com/questions/64529620/is-there-an-efficient-way-to-generate-multinomial-random-variables-in-parallel > . > > Seems like there isn't a function to do that. > We call this feature "broadcasting". This is currently being worked on for multinomial and the other multivariate distributions: https://github.com/numpy/numpy/issues/17669 https://github.com/numpy/numpy/pull/16740 -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Thu Oct 29 20:03:52 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 29 Oct 2020 19:03:52 -0500 Subject: [Numpy-discussion] Allow __getitem__ to support custom objects In-Reply-To: References: Message-ID: <5fcaeba57ae045da6a01e273643415335f91fcda.camel@sipsolutions.net> On Tue, 2020-10-27 at 17:15 -0600, Aaron Meurer wrote: > For ndindex (https://quansight.github.io/ndindex/), the biggest issue > with the API is that to use an ndindex object to actually index an > array, you have to use a[idx.raw] instead of a[idx]. This is because > for NumPy arrays, you cannot allow custom objects to be indices. The > exception is objects that define __index__, but this only works for > integer indices. If __index__ returns anything other than an integer, > you get an IndexError. This is annoying because it's easy to forget > to > do this when working with the ndindex API, and the error message from > NumPy isn't informative about what went wrong unless you know to > expect it. > > I'd like to propose an API that would allow custom objects to define > how they should be converted to a standard NumPy index, similar to > __index__ but that supports all index types. I think there are two > options here: > > - Allow __index__ to return any index type, not just integers. This > is > the simplest because it reuses an existing API, and __index__ is the > best possible name for this API. However, I'm not sure, but this may > actually conflict with the text of PEP 357 > (https://www.python.org/dev/peps/pep-0357/). Also, some other APIs > use > __index__ to check if something is an indexable integer, which > wouldn't accept generic index. For example, elements of a slice can > be > any object that defines __index__. > Index converts to an integer (safely). There is an assumptions that the integer is good for indexing, but I the name shouldn't be taken to mean it is specific to indexing (even if that was the main motivation). > - Add a new __numpy_index__ API that works like > > def __numpy_index__(self): > return boolean array> > > In NumPy, __getitem__ and __setitem__ on ndarray would first check if > the input index type is one of the known types as it currently does, > then it would try __index__, and if neither of those fails, it would > call __numpy_index__(index) and use that. Do you anticipate just: arr[index] or also: arr[index1, index2] Would you expect pandas or array-like objects to support this as well? If we only do `arr[index]` might subclassing tuple be sufficient? Do you have any thought on how this might play out with a potential `arr.oindex[...]`? Adding either to NumPy is probably fairly straight forward, although I prefer either not slow down every single indexing operation for an extremely niche use-case (which is likely possible) or timing that it is insignificant. What might help me is understanding that `ndindex` itself better. Since it seems like asking to add a protocol that may very well be used by only this one project? > > Note: there is a more general way that NumPy arrays could allow > __getitem__ to be defined on custom objects, which I am NOT > proposing. > Instead of an API that returns one of the current predefined index > types (tuple, integer, slice, newaxis, ellipsis, or integer or > boolean > array), there could instead be an API that takes the array as input > and returns another array (or view) as an output. This would allow an > object to define itself as an index in arbitrary ways, even if such > an > index would not actually be possible via traditional indexing. There > are definitely some interesting ideas that could be done with this, > but this idea would be much more complicated, and isn't something > that > I need. Unless the community feels that a more general API like this > would be preferred, I would suggest deferring something like it to a > later discussion. > > What would be the best way to go about getting something like this > implemented? Is it simple enough that we can just work out the > details > here and on a pull request, or should I write a NEP? A short NEP may make sense, at least if this is supposed to be a generic protocol for general array-likes, which I guess it would have to be ready for. Cheers, Sebastian > > Aaron Meurer > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From asmeurer at gmail.com Fri Oct 30 01:58:53 2020 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 29 Oct 2020 23:58:53 -0600 Subject: [Numpy-discussion] Allow __getitem__ to support custom objects In-Reply-To: <5fcaeba57ae045da6a01e273643415335f91fcda.camel@sipsolutions.net> References: <5fcaeba57ae045da6a01e273643415335f91fcda.camel@sipsolutions.net> Message-ID: On Thu, Oct 29, 2020 at 6:09 PM Sebastian Berg wrote: > > On Tue, 2020-10-27 at 17:15 -0600, Aaron Meurer wrote: > > For ndindex (https://quansight.github.io/ndindex/), the biggest issue > > with the API is that to use an ndindex object to actually index an > > array, you have to use a[idx.raw] instead of a[idx]. This is because > > for NumPy arrays, you cannot allow custom objects to be indices. The > > exception is objects that define __index__, but this only works for > > integer indices. If __index__ returns anything other than an integer, > > you get an IndexError. This is annoying because it's easy to forget > > to > > do this when working with the ndindex API, and the error message from > > NumPy isn't informative about what went wrong unless you know to > > expect it. > > > > I'd like to propose an API that would allow custom objects to define > > how they should be converted to a standard NumPy index, similar to > > __index__ but that supports all index types. I think there are two > > options here: > > > > - Allow __index__ to return any index type, not just integers. This > > is > > the simplest because it reuses an existing API, and __index__ is the > > best possible name for this API. However, I'm not sure, but this may > > actually conflict with the text of PEP 357 > > (https://www.python.org/dev/peps/pep-0357/). Also, some other APIs > > use > > __index__ to check if something is an indexable integer, which > > wouldn't accept generic index. For example, elements of a slice can > > be > > any object that defines __index__. > > > > Index converts to an integer (safely). There is an assumptions that > the integer is good for indexing, but I the name shouldn't be taken to > mean it is specific to indexing (even if that was the main motivation). > > > > - Add a new __numpy_index__ API that works like > > > > def __numpy_index__(self): > > return > boolean array> > > > > In NumPy, __getitem__ and __setitem__ on ndarray would first check if > > the input index type is one of the known types as it currently does, > > then it would try __index__, and if neither of those fails, it would > > call __numpy_index__(index) and use that. > > Do you anticipate just: > > arr[index] > > or also: > > arr[index1, index2] I think both should work. If the second one doesn't work it would be surprising. > > Would you expect pandas or array-like objects to support this as well? Yes, it would probably be best for array-like to also work with the same API. I don't know much about Pandas. It seems like it already allows a lot of indexing stuff. Do Series/Dataframe already have such an API? > > If we only do `arr[index]` might subclassing tuple be sufficient? I guess that technically works, except now your objects have to act like a tuple, even if they represent something like a slice (Python does not allow subclassing slice). For ndindex I've tried to make a distinction between objects as representing indices and the built-in objects that happen to be used to represent those indices by default. So an ndindex.Tuple explicitly doesn't work like a Tuple, an ndindex.Integer doesn't work like an int, and so on. That way there is a clear distinction between ndindex operations and operations on the built-in types. > Do > you have any thought on how this might play out with a potential > `arr.oindex[...]`? I think oindex[idx] would call the same API on idx. I'm not sure if it matters that it's oindex, since that's at a higher level. > > Adding either to NumPy is probably fairly straight forward, although I > prefer either not slow down every single indexing operation for an > extremely niche use-case (which is likely possible) or timing that it > is insignificant. I'm not sure it would. The current cases would all be tried first. The only time the new protocol would be used is when the index type isn't one of the currently allowed types, which currently raises IndexError. > > What might help me is understanding that `ndindex` itself better. Since > it seems like asking to add a protocol that may very well be used by > only this one project? That's fair. Maybe the more general API would make more sense then? I think it would need more thinking out, but it would allow a lot more use-cases. Aaron Meurer > > > > > Note: there is a more general way that NumPy arrays could allow > > __getitem__ to be defined on custom objects, which I am NOT > > proposing. > > Instead of an API that returns one of the current predefined index > > types (tuple, integer, slice, newaxis, ellipsis, or integer or > > boolean > > array), there could instead be an API that takes the array as input > > and returns another array (or view) as an output. This would allow an > > object to define itself as an index in arbitrary ways, even if such > > an > > index would not actually be possible via traditional indexing. There > > are definitely some interesting ideas that could be done with this, > > but this idea would be much more complicated, and isn't something > > that > > I need. Unless the community feels that a more general API like this > > would be preferred, I would suggest deferring something like it to a > > later discussion. > > > > What would be the best way to go about getting something like this > > implemented? Is it simple enough that we can just work out the > > details > > here and on a pull request, or should I write a NEP? > > A short NEP may make sense, at least if this is supposed to be a > generic protocol for general array-likes, which I guess it would have > to be ready for. > > Cheers, > > Sebastian > > > > > > Aaron Meurer > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From sebastian at sipsolutions.net Fri Oct 30 11:12:51 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Fri, 30 Oct 2020 10:12:51 -0500 Subject: [Numpy-discussion] Allow __getitem__ to support custom objects In-Reply-To: References: <5fcaeba57ae045da6a01e273643415335f91fcda.camel@sipsolutions.net> Message-ID: On Thu, 2020-10-29 at 23:58 -0600, Aaron Meurer wrote: > On Thu, Oct 29, 2020 at 6:09 PM Sebastian Berg > wrote: > > On Tue, 2020-10-27 at 17:15 -0600, Aaron Meurer wrote: > > > For ndindex (https://quansight.github.io/ndindex/), the biggest > > > issue > > > with the API is that to use an ndindex object to actually index > > > an > > > array, you have to use a[idx.raw] instead of a[idx]. This is > > > because > > > for NumPy arrays, you cannot allow custom objects to be indices. > > > The > > > exception is objects that define __index__, but this only works > > > for > > > integer indices. If __index__ returns anything other than an > > > integer, > > > you get an IndexError. This is annoying because it's easy to > > > forget > > > to > > > do this when working with the ndindex API, and the error message > > > from > > > NumPy isn't informative about what went wrong unless you know to > > > expect it. > > > > > > I'd like to propose an API that would allow custom objects to > > > define > > > how they should be converted to a standard NumPy index, similar > > > to > > > __index__ but that supports all index types. I think there are > > > two > > > options here: > > > > > > - Allow __index__ to return any index type, not just integers. > > > This > > > is > > > the simplest because it reuses an existing API, and __index__ is > > > the > > > best possible name for this API. However, I'm not sure, but this > > > may > > > actually conflict with the text of PEP 357 > > > (https://www.python.org/dev/peps/pep-0357/). Also, some other > > > APIs > > > use > > > __index__ to check if something is an indexable integer, which > > > wouldn't accept generic index. For example, elements of a slice > > > can > > > be > > > any object that defines __index__. > > > > > > > Index converts to an integer (safely). There is an assumptions > > that > > the integer is good for indexing, but I the name shouldn't be taken > > to > > mean it is specific to indexing (even if that was the main > > motivation). > > > > > > > - Add a new __numpy_index__ API that works like > > > > > > def __numpy_index__(self): > > > return > > or > > > boolean array> > > > > > > In NumPy, __getitem__ and __setitem__ on ndarray would first > > > check if > > > the input index type is one of the known types as it currently > > > does, > > > then it would try __index__, and if neither of those fails, it > > > would > > > call __numpy_index__(index) and use that. > > > > Do you anticipate just: > > > > arr[index] > > > > or also: > > > > arr[index1, index2] > > I think both should work. If the second one doesn't work it would be > surprising. > > > Would you expect pandas or array-like objects to support this as > > well? > > Yes, it would probably be best for array-like to also work with the > same API. > > I don't know much about Pandas. It seems like it already allows a lot > of indexing stuff. Do Series/Dataframe already have such an API? I do not think so, but indexing in pandas works differently often. So I was curious whether y > > > If we only do `arr[index]` might subclassing tuple be sufficient? > > I guess that technically works, except now your objects have to act > like a tuple, even if they represent something like a slice (Python > does not allow subclassing slice). For ndindex I've tried to make a > distinction between objects as representing indices and the built-in > objects that happen to be used to represent those indices by default. > So an ndindex.Tuple explicitly doesn't work like a Tuple, an > ndindex.Integer doesn't work like an int, and so on. That way there > is > a clear distinction between ndindex operations and operations on the > built-in types. > > > Do > > you have any thought on how this might play out with a potential > > `arr.oindex[...]`? > > I think oindex[idx] would call the same API on idx. I'm not sure if > it > matters that it's oindex, since that's at a higher level. It is at a higher level, but it seemed to me that `ndindex` largely plays at that level. For example, you have a method to implement index chaining: arr[idx1][idx2] == arr[idx1.as_subindex(idx2)] (or similar). But this will not work: arr.oindex[idx1].oindex[idx2] != arr.idx[idx1.as_subindex(idx2)] Also the "result" shape, or even questions like `.isempty()` will give different answers when used as an `.oindex[...]`. This is why I though that `arr[idx1, idx2]` is possibly very different case from `arr[idx]` at least for current NumPy indexing logic (it would be better with `arr.oindex[]`). The difference doesn't matter in your proposal, but I had the impression that the `arr[idx1, idx2]` form might be rare/unused and that form would not be able to carry information such as whether this is supposed to be an "oindex". Maybe it helps to look back at `.oindex` to explain this. A possible solution to subclass handling if we add `arr.oindex` is to make it so that: myarr.oindex[indx] could call: myarr.__getitem__(indx_object) Where `index_object` knows that this is was an oindex. The main reason is the expectation that many subclasses may implement `__getitem__`, but probably just do: def __getitem__(self, indx): new_data = self.data[indx] # Do something with new_data. Now for `ndindex` it would seem to make a lot of sense to have an OIndex object, etc. for the same reason. Of course how we implement `.oindex` can be pretty separate from this. > > > Adding either to NumPy is probably fairly straight forward, > > although I > > prefer either not slow down every single indexing operation for an > > extremely niche use-case (which is likely possible) or timing that > > it > > is insignificant. > > I'm not sure it would. The current cases would all be tried first. > The > only time the new protocol would be used is when the index type isn't > one of the currently allowed types, which currently raises > IndexError. > > > What might help me is understanding that `ndindex` itself better. > > Since > > it seems like asking to add a protocol that may very well be used > > by > > only this one project? > > That's fair. Maybe the more general API would make more sense then? I > think it would need more thinking out, but it would allow a lot more > use-cases. > A general API might make sense, but I am edgy about reversing the roles of who performs the indexing. For one thing that probably would break subclassing and overriding of `__getitem__`? Cheers, Sebastian > Aaron Meurer > > > > Note: there is a more general way that NumPy arrays could allow > > > __getitem__ to be defined on custom objects, which I am NOT > > > proposing. > > > Instead of an API that returns one of the current predefined > > > index > > > types (tuple, integer, slice, newaxis, ellipsis, or integer or > > > boolean > > > array), there could instead be an API that takes the array as > > > input > > > and returns another array (or view) as an output. This would > > > allow an > > > object to define itself as an index in arbitrary ways, even if > > > such > > > an > > > index would not actually be possible via traditional indexing. > > > There > > > are definitely some interesting ideas that could be done with > > > this, > > > but this idea would be much more complicated, and isn't something > > > that > > > I need. Unless the community feels that a more general API like > > > this > > > would be preferred, I would suggest deferring something like it > > > to a > > > later discussion. > > > > > > What would be the best way to go about getting something like > > > this > > > implemented? Is it simple enough that we can just work out the > > > details > > > here and on a pull request, or should I write a NEP? > > > > A short NEP may make sense, at least if this is supposed to be a > > generic protocol for general array-likes, which I guess it would > > have > > to be ready for. > > > > Cheers, > > > > Sebastian > > > > > > > Aaron Meurer > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion at python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From asmeurer at gmail.com Fri Oct 30 16:27:13 2020 From: asmeurer at gmail.com (Aaron Meurer) Date: Fri, 30 Oct 2020 14:27:13 -0600 Subject: [Numpy-discussion] Allow __getitem__ to support custom objects In-Reply-To: References: <5fcaeba57ae045da6a01e273643415335f91fcda.camel@sipsolutions.net> Message-ID: On Fri, Oct 30, 2020 at 9:18 AM Sebastian Berg wrote: > > On Thu, 2020-10-29 at 23:58 -0600, Aaron Meurer wrote: > > On Thu, Oct 29, 2020 at 6:09 PM Sebastian Berg > > wrote: > > > On Tue, 2020-10-27 at 17:15 -0600, Aaron Meurer wrote: > > > > For ndindex (https://quansight.github.io/ndindex/), the biggest > > > > issue > > > > with the API is that to use an ndindex object to actually index > > > > an > > > > array, you have to use a[idx.raw] instead of a[idx]. This is > > > > because > > > > for NumPy arrays, you cannot allow custom objects to be indices. > > > > The > > > > exception is objects that define __index__, but this only works > > > > for > > > > integer indices. If __index__ returns anything other than an > > > > integer, > > > > you get an IndexError. This is annoying because it's easy to > > > > forget > > > > to > > > > do this when working with the ndindex API, and the error message > > > > from > > > > NumPy isn't informative about what went wrong unless you know to > > > > expect it. > > > > > > > > I'd like to propose an API that would allow custom objects to > > > > define > > > > how they should be converted to a standard NumPy index, similar > > > > to > > > > __index__ but that supports all index types. I think there are > > > > two > > > > options here: > > > > > > > > - Allow __index__ to return any index type, not just integers. > > > > This > > > > is > > > > the simplest because it reuses an existing API, and __index__ is > > > > the > > > > best possible name for this API. However, I'm not sure, but this > > > > may > > > > actually conflict with the text of PEP 357 > > > > (https://www.python.org/dev/peps/pep-0357/). Also, some other > > > > APIs > > > > use > > > > __index__ to check if something is an indexable integer, which > > > > wouldn't accept generic index. For example, elements of a slice > > > > can > > > > be > > > > any object that defines __index__. > > > > > > > > > > Index converts to an integer (safely). There is an assumptions > > > that > > > the integer is good for indexing, but I the name shouldn't be taken > > > to > > > mean it is specific to indexing (even if that was the main > > > motivation). > > > > > > > > > > - Add a new __numpy_index__ API that works like > > > > > > > > def __numpy_index__(self): > > > > return > > > or > > > > boolean array> > > > > > > > > In NumPy, __getitem__ and __setitem__ on ndarray would first > > > > check if > > > > the input index type is one of the known types as it currently > > > > does, > > > > then it would try __index__, and if neither of those fails, it > > > > would > > > > call __numpy_index__(index) and use that. > > > > > > Do you anticipate just: > > > > > > arr[index] > > > > > > or also: > > > > > > arr[index1, index2] > > > > I think both should work. If the second one doesn't work it would be > > surprising. > > > > > Would you expect pandas or array-like objects to support this as > > > well? > > > > Yes, it would probably be best for array-like to also work with the > > same API. > > > > I don't know much about Pandas. It seems like it already allows a lot > > of indexing stuff. Do Series/Dataframe already have such an API? > > I do not think so, but indexing in pandas works differently often. So I > was curious whether y > > > > > > If we only do `arr[index]` might subclassing tuple be sufficient? > > > > I guess that technically works, except now your objects have to act > > like a tuple, even if they represent something like a slice (Python > > does not allow subclassing slice). For ndindex I've tried to make a > > distinction between objects as representing indices and the built-in > > objects that happen to be used to represent those indices by default. > > So an ndindex.Tuple explicitly doesn't work like a Tuple, an > > ndindex.Integer doesn't work like an int, and so on. That way there > > is > > a clear distinction between ndindex operations and operations on the > > built-in types. > > > > > Do > > > you have any thought on how this might play out with a potential > > > `arr.oindex[...]`? > > > > I think oindex[idx] would call the same API on idx. I'm not sure if > > it > > matters that it's oindex, since that's at a higher level. > > It is at a higher level, but it seemed to me that `ndindex` largely > plays at that level. For example, you have a method to implement index > chaining: > > arr[idx1][idx2] == arr[idx1.as_subindex(idx2)] > > (or similar). But this will not work: > > arr.oindex[idx1].oindex[idx2] != arr.idx[idx1.as_subindex(idx2)] Just to be clear, this isn't how as_subindex works. as_subindex is actually the inverse of composition (composition isn't implemented yet). But I get the point anyway. Most of the ndindex API won't be valid for oindex. I haven't thought too much yet about how outer indexing fits into ndindex, but it is something a lot of people seem to be interested in. > > Also the "result" shape, or even questions like `.isempty()` will give > different answers when used as an `.oindex[...]`. > > This is why I though that `arr[idx1, idx2]` is possibly very different > case from `arr[idx]` at least for current NumPy indexing logic (it > would be better with `arr.oindex[]`). > The difference doesn't matter in your proposal, but I had the > impression that the `arr[idx1, idx2]` form might be rare/unused and > that form would not be able to carry information such as whether this > is supposed to be an "oindex". > > Maybe it helps to look back at `.oindex` to explain this. A possible > solution to subclass handling if we add `arr.oindex` is to make it so > that: > > myarr.oindex[indx] > > could call: > > myarr.__getitem__(indx_object) > > Where `index_object` knows that this is was an oindex. The main reason > is the expectation that many subclasses may implement `__getitem__`, > but probably just do: > > def __getitem__(self, indx): > new_data = self.data[indx] > # Do something with new_data. > > Now for `ndindex` it would seem to make a lot of sense to have an > OIndex object, etc. for the same reason. > > Of course how we implement `.oindex` can be pretty separate from this. Yeah, one of the ideas for the more general API is that you could have a[oindex(idx)] where oindex() returns some object that does outer indexing. If outer indices always map to normal indices, this could be done with the simpler API (I haven't looked at it enough to say whether that's the case or not yet). > > > > > > Adding either to NumPy is probably fairly straight forward, > > > although I > > > prefer either not slow down every single indexing operation for an > > > extremely niche use-case (which is likely possible) or timing that > > > it > > > is insignificant. > > > > I'm not sure it would. The current cases would all be tried first. > > The > > only time the new protocol would be used is when the index type isn't > > one of the currently allowed types, which currently raises > > IndexError. > > > > > What might help me is understanding that `ndindex` itself better. > > > Since > > > it seems like asking to add a protocol that may very well be used > > > by > > > only this one project? > > > > That's fair. Maybe the more general API would make more sense then? I > > think it would need more thinking out, but it would allow a lot more > > use-cases. > > > > A general API might make sense, but I am edgy about reversing the roles > of who performs the indexing. For one thing that probably would break > subclassing and overriding of `__getitem__`? Yeah it might. In Python, we have __getattr__, which lets A define how A.x works, and __get__ (i.e., descriptors), which allows x to define how A.x works. The whole thing is tied together by the higher level __getattribute__, which defines the logic for both (as well as __dict__ and all that other stuff). You should almost never override __getattribute__ (unless you *really* know what you're doing). I'm not sure what that says here. Maybe that __getattr__ shouldn't be overridden by subclasses but rather some other NumPy specific method that __getattr__ calls? Aaron Meurer > > > Cheers, > > Sebastian > > > > > Aaron Meurer > > > > > > Note: there is a more general way that NumPy arrays could allow > > > > __getitem__ to be defined on custom objects, which I am NOT > > > > proposing. > > > > Instead of an API that returns one of the current predefined > > > > index > > > > types (tuple, integer, slice, newaxis, ellipsis, or integer or > > > > boolean > > > > array), there could instead be an API that takes the array as > > > > input > > > > and returns another array (or view) as an output. This would > > > > allow an > > > > object to define itself as an index in arbitrary ways, even if > > > > such > > > > an > > > > index would not actually be possible via traditional indexing. > > > > There > > > > are definitely some interesting ideas that could be done with > > > > this, > > > > but this idea would be much more complicated, and isn't something > > > > that > > > > I need. Unless the community feels that a more general API like > > > > this > > > > would be preferred, I would suggest deferring something like it > > > > to a > > > > later discussion. > > > > > > > > What would be the best way to go about getting something like > > > > this > > > > implemented? Is it simple enough that we can just work out the > > > > details > > > > here and on a pull request, or should I write a NEP? > > > > > > A short NEP may make sense, at least if this is supposed to be a > > > generic protocol for general array-likes, which I guess it would > > > have > > > to be ready for. > > > > > > Cheers, > > > > > > Sebastian > > > > > > > > > > Aaron Meurer > > > > _______________________________________________ > > > > NumPy-Discussion mailing list > > > > NumPy-Discussion at python.org > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion at python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From ralf.gommers at gmail.com Sat Oct 31 08:22:36 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 31 Oct 2020 12:22:36 +0000 Subject: [Numpy-discussion] NumPy 1.20.x branch in two weeks In-Reply-To: References: Message-ID: On Thu, Oct 29, 2020 at 2:25 PM Charles R Harris wrote: > Hi All, > > Time to start planning for the 1.20.x branch. These are my thoughts at the > moment: > > - Keep support for Python 3.6. Python 3.7 came out in June 2018, which > seems too recent to be our oldest supported version. > - Drop Python 3.6 for 1.21.x, that will make the oldest supported > version about three years old. > - Drop manylinux1 for 1.21.x. It would be nice to drop earlier, but > manylinux2010 is pretty recent. > > There were 33 wheels in the 1.19.3 release, I think we can live with that > for 1.20.x. I'm more worried about our tools aging out. After Python has > settled into its yearly release cycle, I think we will end up supporting > the latest 4 versions. > > Thoughts? > Seems reasonable to me. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdupree at speakeasy.net Sat Oct 31 21:03:23 2020 From: sdupree at speakeasy.net (Samuel Dupree) Date: Sat, 31 Oct 2020 21:03:23 -0400 Subject: [Numpy-discussion] Do not understand what f2py is reporting Message-ID: I'm attempting to build wrappers around two Fortran routines. One is a Fortran 77 subroutine (see file gravity_derivs.f) that calls a Fortran 90 package that performs automatic differentiation (see file auto_deriv.f90). I'm running he Anaconda distribution for Python 3.7.6 on a Mac Pro (2019) under Mac OS X Catalina (ver. 10.15.6). The version of NumPy I'm running is 1.18.3. The commands I used to attempt the build are contained in the file auto_deriv_build. The messages output by f2py are captured in the file auto_derivs_build_report.txt. I don't understand the cause behind the error messages I got, so any advice would be welcomed. Sam Dupree. -------------- next part -------------- (base) user at Samuels-Mac-Pro auto_deriv % ./auto_deriv_build f2py build for auto_deriv deleting previous build rm: *.so: No such file or directory building Python wrappers running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building extension "gravity_derivs" sources f2py options: [] f2py:> /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmpada983e0/src.macosx-10.9-x86_64-3.7/gravity_derivsmodule.c creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmpada983e0/src.macosx-10.9-x86_64-3.7 Reading fortran codes... Reading file 'gravity_derivs.f' (format:fix,strict) {'before': '', 'this': 'use', 'after': 'deriv_class ! make the module accessible'} Line #111 in gravity_derivs.f:" USE deriv_class ! make the module accessible" analyzeline: Could not crack the use statement. Line #119 in gravity_derivs.f:" integer * 4 degree" updatevars: no name pattern found for entity='*4degree'. Skipping. Line #121 in gravity_derivs.f:" integer * 4 order" updatevars: no name pattern found for entity='*4order'. Skipping. Line #122 in gravity_derivs.f:" integer * 4 Ndim" updatevars: no name pattern found for entity='*4ndim'. Skipping. Line #124 in gravity_derivs.f:" integer * 4 Mdim" updatevars: no name pattern found for entity='*4mdim'. Skipping. Line #127 in gravity_derivs.f:" integer * 4 iret" updatevars: no name pattern found for entity='*4iret'. Skipping. Line #145 in gravity_derivs.f:" integer * 4 deriv" updatevars: no name pattern found for entity='*4deriv'. Skipping. Line #148 in gravity_derivs.f:" integer * 4 i" updatevars: no name pattern found for entity='*4i'. Skipping. Line #149 in gravity_derivs.f:" integer * 4 j" updatevars: no name pattern found for entity='*4j'. Skipping. Line #150 in gravity_derivs.f:" integer * 4 k" updatevars: no name pattern found for entity='*4k'. Skipping. Line #151 in gravity_derivs.f:" integer * 4 n" updatevars: no name pattern found for entity='*4n'. Skipping. Line #153 in gravity_derivs.f:" integer * 4 m" updatevars: no name pattern found for entity='*4m'. Skipping. Post-processing... Block: gravity_derivs {'attrspec': ['intent(in)']} In: :gravity_derivs:gravity_derivs.f:gravity_derivs vars2fortran: No typespec for argument "ndim". {'attrspec': ['intent(in)']} In: :gravity_derivs:gravity_derivs.f:gravity_derivs vars2fortran: No typespec for argument "mdim". {'attrspec': ['intent(in)']} In: :gravity_derivs:gravity_derivs.f:gravity_derivs vars2fortran: No typespec for argument "degree". {'attrspec': ['intent(in)']} In: :gravity_derivs:gravity_derivs.f:gravity_derivs vars2fortran: No typespec for argument "order". {'attrspec': ['intent(out)']} In: :gravity_derivs:gravity_derivs.f:gravity_derivs vars2fortran: No typespec for argument "iret". Block: gravity_derivs In: :gravity_derivs:gravity_derivs.f:gravity_derivs analyzevars: typespec of variable 'ndim' is not defined in routine gravity_derivs. In: :gravity_derivs:gravity_derivs.f:gravity_derivs analyzevars: typespec of variable 'mdim' is not defined in routine gravity_derivs. In: :gravity_derivs:gravity_derivs.f:gravity_derivs analyzevars: typespec of variable 'degree' is not defined in routine gravity_derivs. In: :gravity_derivs:gravity_derivs.f:gravity_derivs analyzevars: typespec of variable 'order' is not defined in routine gravity_derivs. In: :gravity_derivs:gravity_derivs.f:gravity_derivs analyzevars: typespec of variable 'iret' is not defined in routine gravity_derivs. Post-processing (stage 2)... Building modules... Building module "gravity_derivs"... Constructing wrapper function "gravity_derivs"... getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['out']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. getctype: No C-type found in "{'attrspec': [], 'intent': ['in']}", assuming void. Traceback (most recent call last): File "/Users/user/opt/anaconda3/bin/f2py3", line 33, in sys.exit(load_entry_point('numpy==1.19.0', 'console_scripts', 'f2py3')()) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 694, in main run_compile() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 661, in run_compile setup(ext_modules=[ext]) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/core.py", line 171, in setup return old_setup(**new_attr) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/core.py", line 148, in setup dist.run_commands() File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 966, in run_commands self.run_command(cmd) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build.py", line 42, in run old_build.run(self) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/command/build.py", line 135, in run self.run_command(cmd_name) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 146, in run self.build_sources() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 163, in build_sources self.build_extension_sources(ext) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 323, in build_extension_sources sources = self.f2py_sources(sources, ext) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 566, in f2py_sources ['-m', ext_name]+f_sources) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 468, in run_main ret = buildmodules(postlist) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 394, in buildmodules dict_append(ret[mnames[i]], rules.buildmodule(modules[i], um)) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/rules.py", line 1214, in buildmodule api, wrap = buildapi(nb) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/rules.py", line 1383, in buildapi vrd = capi_maps.sign2map(a, var[a]) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/capi_maps.py", line 615, in sign2map ret['pydocsign'], ret['pydocsignout'] = getpydocsign(a, var) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/capi_maps.py", line 424, in getpydocsign sig = '%s : %s %s%s' % (a, opt, c2py_map[ctype], init) KeyError: 'void' running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building extension "auto_deriv" sources f2py options: [] f2py:> /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp3iuof2ym/src.macosx-10.9-x86_64-3.7/auto_derivmodule.c creating /var/folders/2r/4bw6nw0x58z0_ybx632_h14m0000gq/T/tmp3iuof2ym/src.macosx-10.9-x86_64-3.7 Reading fortran codes... Reading file 'auto_deriv.f90' (format:free) rmbadname1: Replacing "int" with "int_bn". rmbadname1: Replacing "max" with "max_bn". rmbadname1: Replacing "min" with "min_bn". rmbadname1: Replacing "int" with "int_bn". rmbadname1: Replacing "max" with "max_bn". rmbadname1: Replacing "min" with "min_bn". crackline: groupcounter=3 groupname={0: '', 1: 'module', 2: 'interface', 3: 'module', 4: 'module', 5: 'function'} crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement. crackline: groupcounter=2 groupname={0: '', 1: 'module', 2: 'interface', 3: 'module', 4: 'module', 5: 'function'} crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement. crackline: groupcounter=1 groupname={0: '', 1: 'module', 2: 'interface', 3: 'module', 4: 'module', 5: 'function'} crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement. Post-processing... Block: auto_deriv Block: ieeex_exceptions Block: ieee_set_flag Block: ad_types Block: func In: :auto_deriv:auto_deriv.f90:ad_types:func getarrlen:variable "n" undefined In: :auto_deriv:auto_deriv.f90:ad_types:func getarrlen:variable "nhes" undefined Block: ad_utilities Block: independent Block: derivative Block: indep_scalar Block: indep_vector Block: extract Block: ad_auxiliary In: :auto_deriv:auto_deriv.f90:ad_auxiliary get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_auxiliary get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: tensor appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_auxiliary:tensor analyzevars: prefix ('pure') were not used Block: is_small In: :auto_deriv:auto_deriv.f90:ad_auxiliary:is_small analyzevars: prefix ('elemental') were not used Block: ad_assign Block: assignment In: :auto_deriv:auto_deriv.f90:ad_assign:assignment determineexprtype: could not determine expressions ('=') type. Block: ad_relational Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('<') type. Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('<=') type. Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('>') type. Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('>=') type. Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('==') type. Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:operator determineexprtype: could not determine expressions ('/=') type. Block: less_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_fr analyzevars: prefix ('elemental') were not used Block: less_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_fs analyzevars: prefix ('elemental') were not used Block: less_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_fi analyzevars: prefix ('elemental') were not used Block: less_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_rf analyzevars: prefix ('elemental') were not used Block: less_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_sf analyzevars: prefix ('elemental') were not used Block: less_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_if analyzevars: prefix ('elemental') were not used Block: less_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_ff analyzevars: prefix ('elemental') were not used Block: less_equal_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_fr analyzevars: prefix ('elemental') were not used Block: less_equal_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_fs analyzevars: prefix ('elemental') were not used Block: less_equal_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_fi analyzevars: prefix ('elemental') were not used Block: less_equal_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_rf analyzevars: prefix ('elemental') were not used Block: less_equal_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_sf analyzevars: prefix ('elemental') were not used Block: less_equal_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_if analyzevars: prefix ('elemental') were not used Block: less_equal_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:less_equal_ff analyzevars: prefix ('elemental') were not used Block: greater_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_fr analyzevars: prefix ('elemental') were not used Block: greater_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_fs analyzevars: prefix ('elemental') were not used Block: greater_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_fi analyzevars: prefix ('elemental') were not used Block: greater_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_rf analyzevars: prefix ('elemental') were not used Block: greater_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_sf analyzevars: prefix ('elemental') were not used Block: greater_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_if analyzevars: prefix ('elemental') were not used Block: greater_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_ff analyzevars: prefix ('elemental') were not used Block: greater_equal_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_fr analyzevars: prefix ('elemental') were not used Block: greater_equal_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_fs analyzevars: prefix ('elemental') were not used Block: greater_equal_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_fi analyzevars: prefix ('elemental') were not used Block: greater_equal_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_rf analyzevars: prefix ('elemental') were not used Block: greater_equal_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_sf analyzevars: prefix ('elemental') were not used Block: greater_equal_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_if analyzevars: prefix ('elemental') were not used Block: greater_equal_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:greater_equal_ff analyzevars: prefix ('elemental') were not used Block: equal_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_fr analyzevars: prefix ('elemental') were not used Block: equal_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_fs analyzevars: prefix ('elemental') were not used Block: equal_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_fi analyzevars: prefix ('elemental') were not used Block: equal_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_rf analyzevars: prefix ('elemental') were not used Block: equal_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_sf analyzevars: prefix ('elemental') were not used Block: equal_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_if analyzevars: prefix ('elemental') were not used Block: equal_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:equal_ff analyzevars: prefix ('elemental') were not used Block: not_equal_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_fr analyzevars: prefix ('elemental') were not used Block: not_equal_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_fs analyzevars: prefix ('elemental') were not used Block: not_equal_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_fi analyzevars: prefix ('elemental') were not used Block: not_equal_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_rf analyzevars: prefix ('elemental') were not used Block: not_equal_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_sf analyzevars: prefix ('elemental') were not used Block: not_equal_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_if analyzevars: prefix ('elemental') were not used Block: not_equal_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_relational:not_equal_ff analyzevars: prefix ('elemental') were not used Block: ad_operator_plus Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:operator determineexprtype: could not determine expressions ('+') type. Block: unary_plus In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:unary_plus analyzevars: prefix ('elemental') were not used Block: add_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_rf analyzevars: prefix ('elemental') were not used Block: add_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_sf analyzevars: prefix ('elemental') were not used Block: add_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_if analyzevars: prefix ('elemental') were not used Block: add_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_fr analyzevars: prefix ('elemental') were not used Block: add_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_fs analyzevars: prefix ('elemental') were not used Block: add_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_fi analyzevars: prefix ('elemental') were not used Block: add_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_plus:add_ff analyzevars: prefix ('elemental') were not used Block: ad_operator_minus Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:operator determineexprtype: could not determine expressions ('-') type. Block: negate In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:negate analyzevars: prefix ('elemental') were not used Block: sub_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_rf analyzevars: prefix ('elemental') were not used Block: sub_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_sf analyzevars: prefix ('elemental') were not used Block: sub_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_if analyzevars: prefix ('elemental') were not used Block: sub_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_fr analyzevars: prefix ('elemental') were not used Block: sub_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_fs analyzevars: prefix ('elemental') were not used Block: sub_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_fi analyzevars: prefix ('elemental') were not used Block: sub_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_minus:sub_ff analyzevars: prefix ('elemental') were not used Block: ad_operator_star In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:operator determineexprtype: could not determine expressions ('*') type. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:operator get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:operator get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: mul_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_rf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_rf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_rf analyzevars: prefix ('elemental') were not used Block: mul_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_sf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_sf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_sf analyzevars: prefix ('elemental') were not used Block: mul_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_if get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_if get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_if analyzevars: prefix ('elemental') were not used Block: mul_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fr get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fr get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fr analyzevars: prefix ('elemental') were not used Block: mul_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fs get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fs get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fs analyzevars: prefix ('elemental') were not used Block: mul_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fi get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fi get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_fi analyzevars: prefix ('elemental') were not used Block: mul_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_ff get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_ff get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_star:mul_ff analyzevars: prefix ('elemental') were not used Block: ad_operator_slash In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:operator determineexprtype: could not determine expressions ('/') type. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:operator get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:operator get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: div_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fr get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fr get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fr analyzevars: prefix ('elemental') were not used Block: div_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fs get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fs get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fs analyzevars: prefix ('elemental') were not used Block: div_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fi get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fi get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_fi analyzevars: prefix ('elemental') were not used Block: div_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_rf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_rf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_rf analyzevars: prefix ('elemental') were not used Block: div_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_sf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_sf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_sf analyzevars: prefix ('elemental') were not used Block: div_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_if get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_if get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_if analyzevars: prefix ('elemental') were not used Block: div_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_ff get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_ff get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_slash:div_ff analyzevars: prefix ('elemental') were not used Block: ad_fortran_library In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library get_useparameters: no module ad_assign info used by ad_fortran_library In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: abs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs get_useparameters: no module ad_assign info used by abs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: acos In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos get_useparameters: no module ad_assign info used by acos In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: aint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint get_useparameters: no module ad_assign info used by aint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: anint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint get_useparameters: no module ad_assign info used by anint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: asin In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin get_useparameters: no module ad_assign info used by asin In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: atan In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan get_useparameters: no module ad_assign info used by atan In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: atan2 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2 get_useparameters: no module ad_assign info used by atan2 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: ceiling In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling get_useparameters: no module ad_assign info used by ceiling In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: cos In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos get_useparameters: no module ad_assign info used by cos In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: cosh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh get_useparameters: no module ad_assign info used by cosh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: digits In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits get_useparameters: no module ad_assign info used by digits In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: dim In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim get_useparameters: no module ad_assign info used by dim In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: dot_product In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product get_useparameters: no module ad_assign info used by dot_product In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: epsilon In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon get_useparameters: no module ad_assign info used by epsilon In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: exp In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp get_useparameters: no module ad_assign info used by exp In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: exponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent get_useparameters: no module ad_assign info used by exponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: floor In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor get_useparameters: no module ad_assign info used by floor In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: fraction In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction get_useparameters: no module ad_assign info used by fraction In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: huge In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge get_useparameters: no module ad_assign info used by huge In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: int_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_bn get_useparameters: no module ad_assign info used by int_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_bn get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_bn get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: kind In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind get_useparameters: no module ad_assign info used by kind In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: log In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log get_useparameters: no module ad_assign info used by log In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: log10 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10 get_useparameters: no module ad_assign info used by log10 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: matmul In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul get_useparameters: no module ad_assign info used by matmul In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: max_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max_bn get_useparameters: no module ad_assign info used by max_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max_bn get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max_bn get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: maxexponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent get_useparameters: no module ad_assign info used by maxexponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: maxloc In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc get_useparameters: no module ad_assign info used by maxloc In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: maxval In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval get_useparameters: no module ad_assign info used by maxval In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: min_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min_bn get_useparameters: no module ad_assign info used by min_bn In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min_bn get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min_bn get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: minexponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent get_useparameters: no module ad_assign info used by minexponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: minloc In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc get_useparameters: no module ad_assign info used by minloc In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: minval In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval get_useparameters: no module ad_assign info used by minval In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: mod In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod get_useparameters: no module ad_assign info used by mod In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: modulo In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo get_useparameters: no module ad_assign info used by modulo In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: nearest In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest get_useparameters: no module ad_assign info used by nearest In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: nint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint get_useparameters: no module ad_assign info used by nint In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: precision In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision get_useparameters: no module ad_assign info used by precision In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: product In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product get_useparameters: no module ad_assign info used by product In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: radix In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix get_useparameters: no module ad_assign info used by radix In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: range In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range get_useparameters: no module ad_assign info used by range In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: rrspacing In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing get_useparameters: no module ad_assign info used by rrspacing In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: scale In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale get_useparameters: no module ad_assign info used by scale In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: set_exponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent get_useparameters: no module ad_assign info used by set_exponent In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: sign In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign get_useparameters: no module ad_assign info used by sign In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: sin In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin get_useparameters: no module ad_assign info used by sin In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: sinh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh get_useparameters: no module ad_assign info used by sinh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: spacing In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing get_useparameters: no module ad_assign info used by spacing In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: sqrt In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt get_useparameters: no module ad_assign info used by sqrt In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: sum In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum get_useparameters: no module ad_assign info used by sum In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: tan In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan get_useparameters: no module ad_assign info used by tan In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: tanh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh get_useparameters: no module ad_assign info used by tanh In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: tiny In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny get_useparameters: no module ad_assign info used by tiny In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' Block: abs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs_ get_useparameters: no module ad_assign info used by abs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:abs_ analyzevars: prefix ('elemental') were not used Block: acos_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos_ get_useparameters: no module ad_assign info used by acos_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:acos_ analyzevars: prefix ('elemental') were not used Block: aint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint_ get_useparameters: no module ad_assign info used by aint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:aint_ analyzevars: prefix ('elemental') were not used Block: anint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint_ get_useparameters: no module ad_assign info used by anint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:anint_ analyzevars: prefix ('elemental') were not used Block: asin_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin_ get_useparameters: no module ad_assign info used by asin_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:asin_ analyzevars: prefix ('elemental') were not used Block: atan_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan_ get_useparameters: no module ad_assign info used by atan_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan_ analyzevars: prefix ('elemental') were not used Block: atan2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_ff_ get_useparameters: no module ad_assign info used by atan2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_ff_ analyzevars: prefix ('elemental') were not used Block: atan2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_rf_ get_useparameters: no module ad_assign info used by atan2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_rf_ analyzevars: prefix ('elemental') were not used Block: atan2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fr_ get_useparameters: no module ad_assign info used by atan2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fr_ analyzevars: prefix ('elemental') were not used Block: atan2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_sf_ get_useparameters: no module ad_assign info used by atan2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_sf_ analyzevars: prefix ('elemental') were not used Block: atan2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fs_ get_useparameters: no module ad_assign info used by atan2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:atan2_fs_ analyzevars: prefix ('elemental') were not used Block: ceiling_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling_ get_useparameters: no module ad_assign info used by ceiling_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:ceiling_ analyzevars: prefix ('elemental') were not used Block: cos_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos_ get_useparameters: no module ad_assign info used by cos_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cos_ analyzevars: prefix ('elemental') were not used Block: cosh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh_ get_useparameters: no module ad_assign info used by cosh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:cosh_ analyzevars: prefix ('elemental') were not used Block: digits_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits_ get_useparameters: no module ad_assign info used by digits_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:digits_ analyzevars: prefix ('elemental') were not used Block: dim_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim_ get_useparameters: no module ad_assign info used by dim_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dim_ analyzevars: prefix ('elemental') were not used Block: dot_product_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_ff_ get_useparameters: no module ad_assign info used by dot_product_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_ff_ analyzevars: prefix ('pure') were not used Block: dot_product_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_rf_ get_useparameters: no module ad_assign info used by dot_product_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_rf_ analyzevars: prefix ('pure') were not used Block: dot_product_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_sf_ get_useparameters: no module ad_assign info used by dot_product_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_sf_ analyzevars: prefix ('pure') were not used Block: dot_product_if_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_if_ get_useparameters: no module ad_assign info used by dot_product_if_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_if_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_if_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_if_ analyzevars: prefix ('pure') were not used Block: dot_product_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fr_ get_useparameters: no module ad_assign info used by dot_product_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fr_ analyzevars: prefix ('pure') were not used Block: dot_product_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fs_ get_useparameters: no module ad_assign info used by dot_product_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fs_ analyzevars: prefix ('pure') were not used Block: dot_product_fi_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fi_ get_useparameters: no module ad_assign info used by dot_product_fi_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fi_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fi_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:dot_product_fi_ analyzevars: prefix ('pure') were not used Block: epsilon_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon_ get_useparameters: no module ad_assign info used by epsilon_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:epsilon_ analyzevars: prefix ('elemental') were not used Block: exp_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp_ get_useparameters: no module ad_assign info used by exp_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exp_ analyzevars: prefix ('elemental') were not used Block: exponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent_ get_useparameters: no module ad_assign info used by exponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:exponent_ analyzevars: prefix ('elemental') were not used Block: floor_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor_ get_useparameters: no module ad_assign info used by floor_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:floor_ analyzevars: prefix ('elemental') were not used Block: fraction_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction_ get_useparameters: no module ad_assign info used by fraction_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:fraction_ analyzevars: prefix ('elemental') were not used Block: huge_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge_ get_useparameters: no module ad_assign info used by huge_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:huge_ analyzevars: prefix ('elemental') were not used Block: int_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_ get_useparameters: no module ad_assign info used by int_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:int_ analyzevars: prefix ('elemental') were not used Block: kind_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind_ get_useparameters: no module ad_assign info used by kind_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:kind_ analyzevars: prefix ('elemental') were not used Block: log_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log_ get_useparameters: no module ad_assign info used by log_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log_ analyzevars: prefix ('elemental') were not used Block: log10_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10_ get_useparameters: no module ad_assign info used by log10_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:log10_ analyzevars: prefix ('elemental') were not used Block: matmul_ff_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_12_ get_useparameters: no module ad_assign info used by matmul_ff_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_12_ analyzevars: prefix ('pure') were not used Block: matmul_rf_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_12_ get_useparameters: no module ad_assign info used by matmul_rf_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_12_ analyzevars: prefix ('pure') were not used Block: matmul_sf_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_12_ get_useparameters: no module ad_assign info used by matmul_sf_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_12_ analyzevars: prefix ('pure') were not used Block: matmul_if_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_12_ get_useparameters: no module ad_assign info used by matmul_if_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_12_ analyzevars: prefix ('pure') were not used Block: matmul_fr_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_12_ get_useparameters: no module ad_assign info used by matmul_fr_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_12_ analyzevars: prefix ('pure') were not used Block: matmul_fs_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_12_ get_useparameters: no module ad_assign info used by matmul_fs_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_12_ analyzevars: prefix ('pure') were not used Block: matmul_fi_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_12_ get_useparameters: no module ad_assign info used by matmul_fi_12_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_12_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_12_ analyzevars: prefix ('pure') were not used Block: matmul_ff_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_21_ get_useparameters: no module ad_assign info used by matmul_ff_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_21_ analyzevars: prefix ('pure') were not used Block: matmul_rf_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_21_ get_useparameters: no module ad_assign info used by matmul_rf_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_21_ analyzevars: prefix ('pure') were not used Block: matmul_sf_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_21_ get_useparameters: no module ad_assign info used by matmul_sf_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_21_ analyzevars: prefix ('pure') were not used Block: matmul_if_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_21_ get_useparameters: no module ad_assign info used by matmul_if_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_21_ analyzevars: prefix ('pure') were not used Block: matmul_fr_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_21_ get_useparameters: no module ad_assign info used by matmul_fr_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_21_ analyzevars: prefix ('pure') were not used Block: matmul_fs_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_21_ get_useparameters: no module ad_assign info used by matmul_fs_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_21_ analyzevars: prefix ('pure') were not used Block: matmul_fi_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_21_ get_useparameters: no module ad_assign info used by matmul_fi_21_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_21_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_21_ analyzevars: prefix ('pure') were not used Block: matmul_ff_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_22_ get_useparameters: no module ad_assign info used by matmul_ff_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_ff_22_ analyzevars: prefix ('pure') were not used Block: matmul_rf_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_22_ get_useparameters: no module ad_assign info used by matmul_rf_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_rf_22_ analyzevars: prefix ('pure') were not used Block: matmul_sf_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_22_ get_useparameters: no module ad_assign info used by matmul_sf_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_sf_22_ analyzevars: prefix ('pure') were not used Block: matmul_if_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_22_ get_useparameters: no module ad_assign info used by matmul_if_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_if_22_ analyzevars: prefix ('pure') were not used Block: matmul_fr_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_22_ get_useparameters: no module ad_assign info used by matmul_fr_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fr_22_ analyzevars: prefix ('pure') were not used Block: matmul_fs_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_22_ get_useparameters: no module ad_assign info used by matmul_fs_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fs_22_ analyzevars: prefix ('pure') were not used Block: matmul_fi_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_22_ get_useparameters: no module ad_assign info used by matmul_fi_22_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_22_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:matmul_fi_22_ analyzevars: prefix ('pure') were not used Block: max2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_ff_ get_useparameters: no module ad_assign info used by max2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_ff_ analyzevars: prefix ('elemental') were not used Block: max2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fr_ get_useparameters: no module ad_assign info used by max2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fr_ analyzevars: prefix ('elemental') were not used Block: max2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_rf_ get_useparameters: no module ad_assign info used by max2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_rf_ analyzevars: prefix ('elemental') were not used Block: max2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fs_ get_useparameters: no module ad_assign info used by max2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_fs_ analyzevars: prefix ('elemental') were not used Block: max2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_sf_ get_useparameters: no module ad_assign info used by max2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max2_sf_ analyzevars: prefix ('elemental') were not used Block: max3_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max3_ get_useparameters: no module ad_assign info used by max3_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max3_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max3_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:max3_ analyzevars: prefix ('elemental') were not used Block: maxexponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent_ get_useparameters: no module ad_assign info used by maxexponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxexponent_ analyzevars: prefix ('elemental') were not used Block: maxloc_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc_1 get_useparameters: no module ad_assign info used by maxloc_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc_1 analyzevars: prefix ('pure') were not used Block: maxloc__dim_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_1 get_useparameters: no module ad_assign info used by maxloc__dim_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_1 analyzevars: prefix ('pure') were not used Block: maxloc__mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__mask_1 get_useparameters: no module ad_assign info used by maxloc__mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__mask_1 analyzevars: prefix ('pure') were not used Block: maxloc__dim_mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_mask_1 get_useparameters: no module ad_assign info used by maxloc__dim_mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxloc__dim_mask_1 analyzevars: prefix ('pure') were not used Block: maxval_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval_1 get_useparameters: no module ad_assign info used by maxval_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:maxval_1 analyzevars: prefix ('pure') were not used Block: min2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_ff_ get_useparameters: no module ad_assign info used by min2_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_ff_ analyzevars: prefix ('elemental') were not used Block: min2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fr_ get_useparameters: no module ad_assign info used by min2_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fr_ analyzevars: prefix ('elemental') were not used Block: min2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_rf_ get_useparameters: no module ad_assign info used by min2_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_rf_ analyzevars: prefix ('elemental') were not used Block: min2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fs_ get_useparameters: no module ad_assign info used by min2_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_fs_ analyzevars: prefix ('elemental') were not used Block: min2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_sf_ get_useparameters: no module ad_assign info used by min2_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min2_sf_ analyzevars: prefix ('elemental') were not used Block: min3_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min3_ get_useparameters: no module ad_assign info used by min3_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min3_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min3_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:min3_ analyzevars: prefix ('elemental') were not used Block: minexponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent_ get_useparameters: no module ad_assign info used by minexponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minexponent_ analyzevars: prefix ('elemental') were not used Block: minloc_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc_1 get_useparameters: no module ad_assign info used by minloc_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc_1 analyzevars: prefix ('pure') were not used Block: minloc__dim_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_1 get_useparameters: no module ad_assign info used by minloc__dim_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_1 analyzevars: prefix ('pure') were not used Block: minloc__mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__mask_1 get_useparameters: no module ad_assign info used by minloc__mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__mask_1 analyzevars: prefix ('pure') were not used Block: minloc__dim_mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_mask_1 get_useparameters: no module ad_assign info used by minloc__dim_mask_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_mask_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' appenddecl: "dimension" not implemented. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minloc__dim_mask_1 analyzevars: prefix ('pure') were not used Block: minval_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval_1 get_useparameters: no module ad_assign info used by minval_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:minval_1 analyzevars: prefix ('pure') were not used Block: mod_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_ff_ get_useparameters: no module ad_assign info used by mod_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_ff_ analyzevars: prefix ('elemental') were not used Block: mod_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_fr_ get_useparameters: no module ad_assign info used by mod_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_fr_ analyzevars: prefix ('elemental') were not used Block: mod_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_rf_ get_useparameters: no module ad_assign info used by mod_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:mod_rf_ analyzevars: prefix ('elemental') were not used Block: modulo_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_ff_ get_useparameters: no module ad_assign info used by modulo_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_ff_ analyzevars: prefix ('elemental') were not used Block: modulo_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_fr_ get_useparameters: no module ad_assign info used by modulo_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_fr_ analyzevars: prefix ('elemental') were not used Block: modulo_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_rf_ get_useparameters: no module ad_assign info used by modulo_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:modulo_rf_ analyzevars: prefix ('elemental') were not used Block: nearest_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_ff_ get_useparameters: no module ad_assign info used by nearest_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_ff_ analyzevars: prefix ('elemental') were not used Block: nearest_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_rf_ get_useparameters: no module ad_assign info used by nearest_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_rf_ analyzevars: prefix ('elemental') were not used Block: nearest_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fr_ get_useparameters: no module ad_assign info used by nearest_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fr_ analyzevars: prefix ('elemental') were not used Block: nearest_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_sf_ get_useparameters: no module ad_assign info used by nearest_sf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_sf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_sf_ analyzevars: prefix ('elemental') were not used Block: nearest_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fs_ get_useparameters: no module ad_assign info used by nearest_fs_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fs_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nearest_fs_ analyzevars: prefix ('elemental') were not used Block: nint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint_ get_useparameters: no module ad_assign info used by nint_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:nint_ analyzevars: prefix ('elemental') were not used Block: precision_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision_ get_useparameters: no module ad_assign info used by precision_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:precision_ analyzevars: prefix ('elemental') were not used Block: product_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product_1 get_useparameters: no module ad_assign info used by product_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:product_1 analyzevars: prefix ('pure') were not used Block: radix_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix_ get_useparameters: no module ad_assign info used by radix_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:radix_ analyzevars: prefix ('elemental') were not used Block: range_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range_ get_useparameters: no module ad_assign info used by range_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:range_ analyzevars: prefix ('elemental') were not used Block: rrspacing_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing_ get_useparameters: no module ad_assign info used by rrspacing_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:rrspacing_ analyzevars: prefix ('elemental') were not used Block: scale_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale_ get_useparameters: no module ad_assign info used by scale_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:scale_ analyzevars: prefix ('elemental') were not used Block: set_exponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent_ get_useparameters: no module ad_assign info used by set_exponent_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:set_exponent_ analyzevars: prefix ('elemental') were not used Block: sign_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_ff_ get_useparameters: no module ad_assign info used by sign_ff_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_ff_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_ff_ analyzevars: prefix ('elemental') were not used Block: sign_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_rf_ get_useparameters: no module ad_assign info used by sign_rf_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_rf_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_rf_ analyzevars: prefix ('elemental') were not used Block: sign_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_fr_ get_useparameters: no module ad_assign info used by sign_fr_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_fr_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sign_fr_ analyzevars: prefix ('elemental') were not used Block: sin_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin_ get_useparameters: no module ad_assign info used by sin_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sin_ analyzevars: prefix ('elemental') were not used Block: sinh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh_ get_useparameters: no module ad_assign info used by sinh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sinh_ analyzevars: prefix ('elemental') were not used Block: spacing_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing_ get_useparameters: no module ad_assign info used by spacing_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:spacing_ analyzevars: prefix ('elemental') were not used Block: sqrt_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt_ get_useparameters: no module ad_assign info used by sqrt_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sqrt_ analyzevars: prefix ('elemental') were not used Block: sum_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum_1 get_useparameters: no module ad_assign info used by sum_1 In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum_1 get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum_1 get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:sum_1 analyzevars: prefix ('pure') were not used Block: tan_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan_ get_useparameters: no module ad_assign info used by tan_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tan_ analyzevars: prefix ('elemental') were not used Block: tanh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh_ get_useparameters: no module ad_assign info used by tanh_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tanh_ analyzevars: prefix ('elemental') were not used Block: tiny_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny_ get_useparameters: no module ad_assign info used by tiny_ In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny_ get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny_ get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_fortran_library:tiny_ analyzevars: prefix ('elemental') were not used Block: ad_operator_power In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power get_useparameters: no module ad_assign info used by ad_operator_power Block: operator In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:operator determineexprtype: could not determine expressions ('**') type. In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:operator get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:operator get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:operator get_useparameters: no module ad_assign info used by operator Block: power_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fr get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fr get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fr get_useparameters: no module ad_assign info used by power_fr In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fr analyzevars: prefix ('elemental') were not used Block: power_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fs get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fs get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fs get_useparameters: no module ad_assign info used by power_fs In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fs analyzevars: prefix ('elemental') were not used Block: power_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fi get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fi get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fi get_useparameters: no module ad_assign info used by power_fi In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_fi analyzevars: prefix ('elemental') were not used Block: power_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_rf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_rf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_rf get_useparameters: no module ad_assign info used by power_rf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_rf analyzevars: prefix ('elemental') were not used Block: power_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_sf get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_sf get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_sf get_useparameters: no module ad_assign info used by power_sf In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_sf analyzevars: prefix ('elemental') were not used Block: power_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_if get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_if get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_if get_useparameters: no module ad_assign info used by power_if In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_if analyzevars: prefix ('elemental') were not used Block: power_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_ff get_parameters: got "invalid syntax (, line 1)" on '(/((i, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_ff get_parameters: got "invalid syntax (, line 1)" on '(/((j, i=j,n), j=1,n)/)' In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_ff get_useparameters: no module ad_assign info used by power_ff In: :auto_deriv:auto_deriv.f90:ad_assign:ad_operator_power:power_ff analyzevars: prefix ('elemental') were not used Block: deriv_class In: :auto_deriv:auto_deriv.f90:ad_assign:deriv_class get_useparameters: no module ad_assign info used by deriv_class Post-processing (stage 2)... Block: auto_deriv Block: unknown_interface Block: ieeex_exceptions Block: ieee_set_flag Block: ad_types Block: func Block: ad_utilities Block: derivative Block: indep_scalar Block: indep_vector Block: extract Block: ad_auxiliary Block: tensor Block: is_small Block: ad_assign Block: ad_relational Block: less_fr Block: less_fs Block: less_fi Block: less_rf Block: less_sf Block: less_if Block: less_ff Block: less_equal_fr Block: less_equal_fs Block: less_equal_fi Block: less_equal_rf Block: less_equal_sf Block: less_equal_if Block: less_equal_ff Block: greater_fr Block: greater_fs Block: greater_fi Block: greater_rf Block: greater_sf Block: greater_if Block: greater_ff Block: greater_equal_fr Block: greater_equal_fs Block: greater_equal_fi Block: greater_equal_rf Block: greater_equal_sf Block: greater_equal_if Block: greater_equal_ff Block: equal_fr Block: equal_fs Block: equal_fi Block: equal_rf Block: equal_sf Block: equal_if Block: equal_ff Block: not_equal_fr Block: not_equal_fs Block: not_equal_fi Block: not_equal_rf Block: not_equal_sf Block: not_equal_if Block: not_equal_ff Block: ad_operator_plus Block: unary_plus Block: add_rf Block: add_sf Block: add_if Block: add_fr Block: add_fs Block: add_fi Block: add_ff Block: ad_operator_minus Block: negate Block: sub_rf Block: sub_sf Block: sub_if Block: sub_fr Block: sub_fs Block: sub_fi Block: sub_ff Block: ad_operator_star Block: mul_rf Block: mul_sf Block: mul_if Block: mul_fr Block: mul_fs Block: mul_fi Block: mul_ff Block: ad_operator_slash Block: div_fr Block: div_fs Block: div_fi Block: div_rf Block: div_sf Block: div_if Block: div_ff Block: ad_fortran_library Block: abs_ Block: acos_ Block: aint_ Block: anint_ Block: asin_ Block: atan_ Block: atan2_ff_ Block: atan2_rf_ Block: atan2_fr_ Block: atan2_sf_ Block: atan2_fs_ Block: ceiling_ Block: cos_ Block: cosh_ Block: digits_ Block: dim_ Block: dot_product_ff_ Block: dot_product_rf_ Block: dot_product_sf_ Block: dot_product_if_ Block: dot_product_fr_ Block: dot_product_fs_ Block: dot_product_fi_ Block: epsilon_ Block: exp_ Block: exponent_ Block: floor_ Block: fraction_ Block: huge_ Block: int_ Block: kind_ Block: log_ Block: log10_ Block: matmul_ff_12_ Block: matmul_rf_12_ Block: matmul_sf_12_ Block: matmul_if_12_ Block: matmul_fr_12_ Block: matmul_fs_12_ Block: matmul_fi_12_ Block: matmul_ff_21_ Block: matmul_rf_21_ Block: matmul_sf_21_ Block: matmul_if_21_ Block: matmul_fr_21_ Block: matmul_fs_21_ Block: matmul_fi_21_ Block: matmul_ff_22_ Block: matmul_rf_22_ Block: matmul_sf_22_ Block: matmul_if_22_ Block: matmul_fr_22_ Block: matmul_fs_22_ Block: matmul_fi_22_ Block: max2_ff_ Block: max2_fr_ Block: max2_rf_ Block: max2_fs_ Block: max2_sf_ Block: max3_ Block: maxexponent_ Block: maxloc_1 Block: maxloc__dim_1 Block: maxloc__mask_1 Block: maxloc__dim_mask_1 Block: maxval_1 Block: min2_ff_ Block: min2_fr_ Block: min2_rf_ Block: min2_fs_ Block: min2_sf_ Block: min3_ Block: minexponent_ Block: minloc_1 Block: minloc__dim_1 Block: minloc__mask_1 Block: minloc__dim_mask_1 Block: minval_1 Block: mod_ff_ Block: mod_fr_ Block: mod_rf_ Block: modulo_ff_ Block: modulo_fr_ Block: modulo_rf_ Block: nearest_ff_ Block: nearest_rf_ Block: nearest_fr_ Block: nearest_sf_ Block: nearest_fs_ Block: nint_ Block: precision_ Block: product_1 Block: radix_ Block: range_ Block: rrspacing_ Block: scale_ Block: set_exponent_ Block: sign_ff_ Block: sign_rf_ Block: sign_fr_ Block: sin_ Block: sinh_ Block: spacing_ Block: sqrt_ Block: sum_1 Block: tan_ Block: tanh_ Block: tiny_ Block: ad_operator_power Block: power_fr Block: power_fs Block: power_fi Block: power_rf Block: power_sf Block: power_if Block: power_ff Block: deriv_class Building modules... Building module "auto_deriv"... Constructing F90 module support for "ieeex_exceptions"... Variables: ieee_overflow ieee_divide_by_zero ieee_invalid ieee_underflow ieee_inexact Constructing wrapper function "ieeex_exceptions.ieee_set_flag"... ieee_set_flag(flag,flag_value) Constructing F90 module support for "ad_types"... Variables: n dpk spk ik nhes order_is_1or2 order_is_2 Skipping type func Constructing F90 module support for "ad_utilities"... Constructing wrapper function "ad_utilities.derivative"... derivative(order) Constructing wrapper function "ad_utilities.indep_scalar"... getctype: No C-type found in "{'typespec': 'type', 'typename': 'func', 'attrspec': [], 'intent': ['out']}", assuming void. getctype: No C-type found in "{'typespec': 'type', 'typename': 'func', 'attrspec': [], 'intent': ['out']}", assuming void. getctype: No C-type found in "{'typespec': 'type', 'typename': 'func', 'attrspec': [], 'intent': ['out']}", assuming void. Traceback (most recent call last): File "/Users/user/opt/anaconda3/bin/f2py3", line 33, in sys.exit(load_entry_point('numpy==1.19.0', 'console_scripts', 'f2py3')()) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 694, in main run_compile() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 661, in run_compile setup(ext_modules=[ext]) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/core.py", line 171, in setup return old_setup(**new_attr) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/core.py", line 148, in setup dist.run_commands() File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 966, in run_commands self.run_command(cmd) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build.py", line 42, in run old_build.run(self) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/command/build.py", line 135, in run self.run_command(cmd_name) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/Users/user/opt/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 146, in run self.build_sources() File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 163, in build_sources self.build_extension_sources(ext) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 323, in build_extension_sources sources = self.f2py_sources(sources, ext) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/distutils/command/build_src.py", line 566, in f2py_sources ['-m', ext_name]+f_sources) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 468, in run_main ret = buildmodules(postlist) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f2py2e.py", line 394, in buildmodules dict_append(ret[mnames[i]], rules.buildmodule(modules[i], um)) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/rules.py", line 1231, in buildmodule mr, wrap = f90mod_rules.buildhooks(m) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/f90mod_rules.py", line 202, in buildhooks api, wrap = rules.buildapi(b) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/rules.py", line 1383, in buildapi vrd = capi_maps.sign2map(a, var[a]) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/capi_maps.py", line 615, in sign2map ret['pydocsign'], ret['pydocsignout'] = getpydocsign(a, var) File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/numpy/f2py/capi_maps.py", line 424, in getpydocsign sig = '%s : %s %s%s' % (a, opt, c2py_map[ctype], init) KeyError: 'void' done. (base) user at Samuels-Mac-Pro auto_deriv % -------------- next part -------------- subroutine gravity_derivs( Ndim, Mdim, degree, order, Ae, GM, 1 C, S, state_bdyf, acc_bdyf, 2 acc_partials_bdyf, iret ) ! ---------------------------------------------------------------------- ! ! Purpose: Compute geopotential acceleration and its Hessian Matrix ! ------- ! ! Variable ! Name Type I/O Units Description ! -------- ---- --- ------- ---------------------------------- ! Ndim I*4 I None Declared row dimension for ! spherical harmonics matrices ! ! Mdim I*4 I None Declared column dimension for ! spherical harmonics matrices ! ! degree I*4 I None Degree of the gravity model ! to be used ! ! order I*4 I None Order of the gravity model ! to be used ! ! Ae R*8 I C.U. Body equatorial radius in ! canonical units (C.U.) ! ! GM R*8 I C.U. Body gravitational parameter in ! canonical units (C.U.) ! ! C R*8 I None Matrix dimensioned containing: ! (Ndim,Ndim) 1. unnormalized ! 2. normalized ! ! S R*8 I None Matrix dimensioned containing: ! (Ndim,Ndim) 1. unnormalized ! 2. normalized ! ! state_bdyf R*8 I C.U. Vector containing the vehicle's ! (6) position and velocity in body ! fixed centered frame in ! canonical units ! ! acc_bdyf R*8 O C.U. Vector containing the vehicle's ! (3) acceleration in body fixed ! centered frame in canonical units ! acc_partials_bdyf ! (6,6) R*8 O C.U. Matrix containing Hessian Matrix ! for the acceleration in canonical ! units ! ! iret I*4 I None Return code where: ! iret = 0 - no errors ! iret = 1 - error encountered ! ! ! ! Author: HKK - INPE - May 2012 - Version 1.0 ! ------ ! ! ! ! Background ! ---------- ! This subroutine is an adaptation of Subroutine Leg_ForCol_Ac ! developed by Kuga and Carrara to return both the body fixed ! acceleration and the acceleration Hessian Matrix. ! ! The acceleration Hessian matrix is computed using the Auto_Deriv ! code developed by Stamatiadis and Farantos that uses Automatic ! Differentiation (AD) to compute the derivatives. ! ! ! ! Restrictions and Limitations ! ---------------------------- ! 1. This implementation requires that the full size gravity model ! be input, whether the coefficients be normalized or ! unnormalized. ! ! 2. The degree and order of the gravity model to be used must ! be equal, otherwise the return iret is set to one (1) and ! an error return is executed. ! ! 3. The order of the partial derivatives returned in the Hessian ! Matrix reflects an order used by the differential equation ! solver DIVA (Math77) applied to systems of second order ! variational equations. ! ! ! ! References ! ---------- ! 1. Kuga, H.K.; Carrara, V. "Fortran- and C-codes for higher order ! and degree geopotential computation." ! URL: http://www.dem.inpe.br/~hkk/software/high_geopot.htm ! Date Last Accessed: 26-Jan-2020 ! ! 2. S. Stamatiadis, S.C. Farantos, "Auto_Deriv: Tool for automatic ! differentiation of a Fortran code," Computer Physics ! Communications, Vol. 181, pp. 1818-1819, 2010, ! URL: ! https://www.sciencedirect.com/science/article/pii/S0010465510002444, ! Date Last Accessed: 26-Jan-2020 ! ! 3. [TBD] ! !----------------------------------------------------------------------- USE deriv_class ! make the module accessible implicit none c ---------------------------------------------------------------------- c Argument List Variables c ---------------------------------------------------------------------- integer * 4 degree integer * 4 order integer * 4 Ndim integer * 4 Mdim integer * 4 iret double precision Ae double precision GM double precision C(0:Ndim,0:Mdim) double precision S(0:Ndim,0:Mdim) double precision state_bdyf(6) double precision acc_bdyf(3) double precision acc_partials_bdyf(6,6) ! Locals ! ------ c ---------------------------------------------------------------------- c Local Variables c ---------------------------------------------------------------------- integer * 4 deriv parameter ( deriv = 2 ) integer * 4 i integer * 4 j integer * 4 k integer * 4 n integer * 4 m double precision grav_pot double precision mu double precision pos_bdyf(3) double precision vel_bdyf(3) double precision Dacc(6) double precision gradV(6) double precision DDacc(21) double precision anm, bnm, am, an c ---------------------------------------------------------------------- c variables containing the independent variable used for the c differentiation c ---------------------------------------------------------------------- TYPE (func) :: var_(6), 1 acc_(3), 2 RxovR_, RyovR_, RzovR_, Rmag_, q, 3 t, u, tf, 4 al, sl, cl, 5 GMr, 6 Vl, Vf, Vr, 7 pn(0:degree), qn(0:degree), 8 Pnm, dPnm, 9 Pnm1m, Pnm2m, sm, cm, sml, cml, A qC, qS, Xc, Xs, Xcf, Xsf, Xcr, Xsr, B Omega, V C Cf2py intent(in) Ndim, Mdim, degree, order, Ae, GM, C, S Cf2py intent(in) state_bdyf Cf2py intent(out) acc_bdyf, acc_partials_bdyf, iret Cf2py depend(Ndim,Mdim) C, S Cf2py depend(degree) pn, qn C c ---------------------------------------------------------------------- c ---------------------------------------------------------------------- iret = 0 c ---------------------------------------------------------------------- c load the input position and velocity vectors to local variables c ---------------------------------------------------------------------- pos_bdyf(1:3) = state_bdyf(1:3) vel_bdyf(1:3) = state_bdyf(4:6) c ---------------------------------------------------------------------- c copy the body's gravitational parameter to a local variable c ---------------------------------------------------------------------- mu = GM c ---------------------------------------------------------------------- c call derivative() to declare the order of the derivatives c ---------------------------------------------------------------------- CALL derivative( deriv ) c ---------------------------------------------------------------------- c declare as independent variables the (x, y, z) and assign them c them their values (x_, y_, z_) c ---------------------------------------------------------------------- CALL independent( 1, var_(1), pos_bdyf(1) ) CALL independent( 3, var_(2), pos_bdyf(2) ) CALL independent( 5, var_(3), pos_bdyf(3) ) CALL independent( 2, var_(4), vel_bdyf(1) ) CALL independent( 4, var_(5), vel_bdyf(2) ) CALL independent( 6, var_(6), vel_bdyf(3) ) c ---------------------------------------------------------------------- c define variables for use by Automatic Differentiation code c ---------------------------------------------------------------------- Rmag_ = sqrt( var_(1)**2 + var_(2)**2 + var_(3)**2 ) RxovR_ = var_(1) / Rmag_ RyovR_ = var_(2) / Rmag_ RzovR_ = var_(3) / Rmag_ q = Ae / Rmag_ t = RzovR_ ! sin (lat) u = sqrt( 1.d0 - RzovR_ * RzovR_ ) tf = RzovR_ / sqrt( 1.d0 - RzovR_ * RzovR_ ) ! tan (lat) al = atan2( RyovR_, RxovR_ ) sl = sin( al ) ! sin (long) cl = cos( al ) ! cos (long) GMr = mu / Rmag_ c ---------------------------------------------------------------------- c Summation initialization c ---------------------------------------------------------------------- Vl = 0.d0 Vf = 0.d0 Vr = 0.d0 Omega = 0.d0 c ---------------------------------------------------------------------- c ---------------------------------------------------------------------- if( degree .gt. 0 .and. order .ge. 0 ) then c ---------------------------------------------------------------------- c pre-store sectoral polynomials and q(m) = (Ae/r)**m c ---------------------------------------------------------------------- pn(0) = 1.d0 pn(1) = 1.7320508075688773D0 * u ! sqrt(3) * cos (lat) qn(0) = 1.d0 qn(1) = q !do m = 2, Nm do m = 2, degree am = dble(m) pn(m) = u * dsqrt(1.d0+0.5d0/am) * pn(m-1) qn(m) = q * qn(m-1) end do ! Initialize sin and cos recursions sm = 0.d0 cm = 1.d0 ! Outer loop !do m=0,Nm do m=0,order ! init am = dble(m) ! For m = n Pnm = pn(m) ! m=n sectoral Pnm1m = Pnm Pnm2m = 0.d0 ! Init Xc, Xs sums Xc = qn(m) * C(m,m) * Pnm Xs = qn(m) * S(m,m) * Pnm ! Inner Loop !do n=m+1,Nm do n=m+1,degree an = dble(n) anm = dsqrt( ((an+an-1.d0)*(an+an+1.d0)) & / ((an-am)*(an+am)) ) bnm = dsqrt( ((an+an+1.d0)*(an+am-1.d0)*(an-am-1.d0)) & / ((an-am)*(an+am)*(an+an-3.d0)) ) ! Pnm recursion Pnm = anm * t * Pnm1m - bnm * Pnm2m ! Store Pnm2m = Pnm1m Pnm1m = Pnm ! Inner sum if (n .lt. 2) cycle Xc = Xc + qn(n) * C(n,m) * Pnm Xs = Xs + qn(n) * S(n,m) * Pnm end do ! Outer sum Omega = Omega + (Xc*cm + Xs*sm) ! sin and cos recursions to next m cml = cl*cm - sm*sl sml = cl*sm + cm*sl cm = cml ! save to next m sm = sml ! save to next m end do end if ! Finalization, include n=0 (P00=1), ! for n=1 all terms are zero: C,S(1,1), C,S(1,0) = 0 V = -GMr * (1.d0+Omega) c ---------------------------------------------------------------------- c CALL extract() to compute the acceleration and its partials c store the acceleration and its partials in output variables c ---------------------------------------------------------------------- CALL extract( V, grav_pot, Dacc, DDacc ) acc_bdyf(1) = -Dacc(1) acc_bdyf(2) = -Dacc(3) acc_bdyf(3) = -Dacc(5) gradV(1:6) = Dacc(1:6) k = 0 DO i = 1, 6 DO j = i, 6 write( *, * ) 'i, j, k, k+j = ', i, j, k, k+j acc_partials_bdyf(i,j) = DDacc(k+j) acc_partials_bdyf(j,i) = DDacc(k+j) END DO k = k + 6 - i END DO WRITE( *, * ) WRITE( *, * ) WRITE( *, * ) WRITE( *, * ) ' in gravity_derivs' WRITE( *, * ) ' -----------------' WRITE( *, * ) WRITE( *, 1040 ) ' grav potential = ', grav_pot WRITE( *, * ) WRITE( *, 1040 ) ' grav_acc = ', acc_bdyf WRITE( *, * ) WRITE( *, 1050 ) ' gradient (NxM) = ', gradV WRITE( *, * ) WRITE( *, 1050 ) ' partials (NxM) = ', 1 ( acc_partials_bdyf(1,j), j = 1, 6 ), 2 ( acc_partials_bdyf(2,j), j = 1, 6 ), 3 ( acc_partials_bdyf(3,j), j = 1, 6 ), 4 ( acc_partials_bdyf(4,j), j = 1, 6 ), 5 ( acc_partials_bdyf(5,j), j = 1, 6 ), 6 ( acc_partials_bdyf(6,j), j = 1, 6 ) c ---------------------------------------------------------------------- c return to the calling routine c ---------------------------------------------------------------------- RETURN c ---------------------------------------------------------------------- c format statements c --------------------------------------------------------------------- 1040 FORMAT( a27, 1p, e27.16, 3x, e27.16, 3x, e27.16, 0p, /, 1 ( 1p, t28, e27.16, 3x, e27.16, 3x, e27.16, 0p ) ) 1050 FORMAT( a27, 1p, e27.16, 3x, e27.16, 3x, e27.16, 3x, e27.16, 3x, 1 e27.16,3x, e27.16, 0p, /, 2 ( t28, 1p, e27.16, 3x, e27.16, 3x, e27.16, 3x, e27.16, 3x, 3 e27.16,3x, e27.16, 0p ) ) c ---------------------------------------------------------------------- c end of subroutine gravity_derivs c ---------------------------------------------------------------------- END -------------- next part -------------- !! Source conforms to !! Fortran 95 (ISO/IEC 1539-1:1997) "Base language" + !! TR-15580: Floating-point exception handling !! If your f95 compiler does not support "TR-15580: Floating-point exception !! handling", i.e. warns about (the lack of) the IEEEx_EXCEPTIONS module, !! please uncomment the following module MODULE IEEEx_EXCEPTIONS IMPLICIT NONE INTEGER, PARAMETER :: IEEE_OVERFLOW = 1 INTEGER, PARAMETER :: IEEE_DIVIDE_BY_ZERO = 2 INTEGER, PARAMETER :: IEEE_INVALID = 3 INTEGER, PARAMETER :: IEEE_UNDERFLOW = 4 INTEGER, PARAMETER :: IEEE_INEXACT = 5 CONTAINS ELEMENTAL SUBROUTINE IEEE_SET_FLAG(flag, flag_value) IMPLICIT NONE INTEGER, INTENT (in) :: flag LOGICAL, INTENT (in) :: flag_value REAL :: x, y IF (flag_value .EQV. .FALSE.) RETURN SELECT CASE (flag) CASE (IEEE_INVALID) x = -1.0 y = SQRT(x) CASE (IEEE_DIVIDE_BY_ZERO) x = 0.0 y = 1.0/x END SELECT END SUBROUTINE IEEE_SET_FLAG END MODULE IEEEx_EXCEPTIONS MODULE ad_types IMPLICIT NONE ! INTEGER, PARAMETER :: n = 3 ! number of independent variables INTEGER, PARAMETER :: n = 6 ! number of independent variables ! INTEGER, PARAMETER :: n = 8 ! number of independent variables !---------------------------------------------------------------------------- ! You SHOULD NOT NEED to change anything below. !---------------------------------------------------------------------------- ! ***************** WARNING: dpk, spk MUST BE NOT EQUAL. ****************** INTEGER, PARAMETER :: dpk = KIND(1.d0) ! kind for real for dependent and independent variables INTEGER, PARAMETER :: spk = KIND(1.0) ! other kind for real variables in mixed-mode arithmetic INTEGER, PARAMETER :: ik = KIND(1) ! kind for integer variables in mixed-mode arithmetic ! the above to support expressions like: f = 2 * x + 3.0 * y + 4.d0 !---------------------------------------------------------------------------- ! You MUST NOT change anything below. !---------------------------------------------------------------------------- INTEGER, PARAMETER :: nhes = (n * (n + 1)) / 2 ! dimension of the Hessian pack LOGICAL :: order_is_1or2, order_is_2 TYPE func SEQUENCE ! for use with common and equivalence blocks REAL (dpk) :: value = 0.0_dpk REAL (dpk) :: x(n) = 0.0_dpk REAL (dpk) :: xx(nhes) = 0.0_dpk END TYPE func END MODULE ad_types MODULE ad_utilities USE ad_types IMPLICIT NONE INTERFACE independent MODULE PROCEDURE indep_scalar, indep_vector END INTERFACE independent CONTAINS SUBROUTINE derivative(order) IMPLICIT NONE INTEGER, INTENT (in) :: order order_is_2 = order == 2 order_is_1or2 = (order == 1) .OR. (order_is_2) END SUBROUTINE derivative SUBROUTINE indep_scalar(i, x, val) IMPLICIT NONE INTEGER, INTENT (in) :: i TYPE (func), INTENT (out) :: x REAL (dpk), INTENT (in) :: val IF ((i < 1) .OR. (i > n)) STOP "error in auto_deriv: indep_scalar" x%value = val IF (order_is_1or2) THEN x%x = 0.0_dpk x%x(i) = 1.0_dpk ENDIF IF (order_is_2) x%xx = 0.0_dpk END SUBROUTINE indep_scalar SUBROUTINE indep_vector(x, val) IMPLICIT NONE TYPE (func), DIMENSION(:), INTENT (out) :: x REAL (dpk), DIMENSION(:), INTENT (in) :: val INTEGER :: i IF (SIZE(x) /= n) STOP "error in auto_deriv: indep_vector" DO i=1,n CALL indep_scalar(i, x(i), val(i)) ENDDO END SUBROUTINE indep_vector PURE SUBROUTINE extract(x, val, Dx, DDx) IMPLICIT NONE TYPE (func), INTENT (in) :: x REAL (dpk), INTENT (out) :: val REAL (dpk), INTENT (out), OPTIONAL :: Dx(n), DDx(nhes) val = x%value IF (PRESENT(Dx) .AND. order_is_1or2) Dx = x%x IF (PRESENT(DDx) .AND. order_is_2 ) DDx = x%xx END SUBROUTINE extract END MODULE ad_utilities MODULE ad_auxiliary USE ad_types IMPLICIT NONE INTEGER, PRIVATE :: i,j INTEGER, PARAMETER :: row(nhes) = (/ ( (i, i=j,n), j=1,n) /) INTEGER, PARAMETER :: col(nhes) = (/ ( (j, i=j,n), j=1,n) /) CONTAINS PURE FUNCTION tensor(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b REAL (dpk), DIMENSION (nhes) :: res res = a%x(col) * b%x(row) END FUNCTION tensor ! is_small is used for checking denominators in fractions. ELEMENTAL FUNCTION is_small(x) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: x LOGICAL :: res res = ABS(x) < TINY(x) END FUNCTION is_small END MODULE ad_auxiliary MODULE ad_assign USE ad_types IMPLICIT NONE INTERFACE ASSIGNMENT (=) MODULE PROCEDURE assig_FF, assig_FR, assig_FS, assig_FI END INTERFACE ASSIGNMENT (=) PRIVATE PUBLIC :: ASSIGNMENT (=) CONTAINS ELEMENTAL SUBROUTINE assig_FF(res, a) ! res = a IMPLICIT NONE TYPE (func), INTENT (out) :: res TYPE (func), INTENT (in) :: a res%value = a%value IF (order_is_1or2) res%x = a%x IF (order_is_2) res%xx = a%xx END SUBROUTINE assig_FF ELEMENTAL SUBROUTINE assig_FR(res, lambda) ! res = lambda IMPLICIT NONE TYPE (func), INTENT (inout) :: res REAL (dpk), INTENT (in) :: lambda res%value = lambda ! what is the correct value for the derivatives? END SUBROUTINE assig_FR ELEMENTAL SUBROUTINE assig_FS(res, lambda) ! res = lambda IMPLICIT NONE TYPE (func), INTENT (inout) :: res REAL (spk), INTENT (in) :: lambda res = REAL(lambda, dpk) END SUBROUTINE assig_FS ELEMENTAL SUBROUTINE assig_FI(res, lambda) ! res = lambda IMPLICIT NONE TYPE (func), INTENT (inout) :: res INTEGER (ik), INTENT (in) :: lambda res = REAL(lambda, dpk) END SUBROUTINE assig_FI END MODULE ad_assign MODULE ad_relational USE ad_types IMPLICIT NONE INTERFACE OPERATOR (<) MODULE PROCEDURE less_FF MODULE PROCEDURE less_FR, less_FS, less_FI, less_RF, less_SF, less_IF END INTERFACE INTERFACE OPERATOR (<=) MODULE PROCEDURE less_equal_FF MODULE PROCEDURE less_equal_FR, less_equal_RF MODULE PROCEDURE less_equal_FI, less_equal_IF MODULE PROCEDURE less_equal_FS, less_equal_SF END INTERFACE INTERFACE OPERATOR (>) MODULE PROCEDURE greater_FF MODULE PROCEDURE greater_FR, greater_FS, greater_FI MODULE PROCEDURE greater_RF, greater_SF, greater_IF END INTERFACE INTERFACE OPERATOR (>=) MODULE PROCEDURE greater_equal_FR, greater_equal_RF MODULE PROCEDURE greater_equal_FI, greater_equal_IF MODULE PROCEDURE greater_equal_FF, greater_equal_SF, greater_equal_FS END INTERFACE INTERFACE OPERATOR (==) MODULE PROCEDURE equal_FR, equal_FI, equal_RF, equal_IF MODULE PROCEDURE equal_FF, equal_SF, equal_FS END INTERFACE INTERFACE OPERATOR (/=) MODULE PROCEDURE not_equal_FR, not_equal_FI, not_equal_RF MODULE PROCEDURE not_equal_IF, not_equal_FF, not_equal_SF, not_equal_FS END INTERFACE PRIVATE PUBLIC :: OPERATOR (<), OPERATOR (<=), OPERATOR (>), OPERATOR (>=) PUBLIC :: OPERATOR (/=), OPERATOR (==) CONTAINS ELEMENTAL FUNCTION less_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value < lambda END FUNCTION less_FR ELEMENTAL FUNCTION less_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value < REAL(lambda, dpk) END FUNCTION less_FS ELEMENTAL FUNCTION less_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value < REAL(lambda, dpk) END FUNCTION less_FI ELEMENTAL FUNCTION less_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) < a%value END FUNCTION less_RF ELEMENTAL FUNCTION less_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) < a%value END FUNCTION less_SF ELEMENTAL FUNCTION less_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) < a%value END FUNCTION less_IF ELEMENTAL FUNCTION less_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value < b%value END FUNCTION less_FF ELEMENTAL FUNCTION less_equal_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value <= lambda END FUNCTION less_equal_FR ELEMENTAL FUNCTION less_equal_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value <= REAL(lambda,dpk) END FUNCTION less_equal_FS ELEMENTAL FUNCTION less_equal_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value <= REAL(lambda,dpk) END FUNCTION less_equal_FI ELEMENTAL FUNCTION less_equal_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = lambda <= a%value END FUNCTION less_equal_RF ELEMENTAL FUNCTION less_equal_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) <= a%value END FUNCTION less_equal_SF ELEMENTAL FUNCTION less_equal_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) <= a%value END FUNCTION less_equal_IF ELEMENTAL FUNCTION less_equal_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value <= b%value END FUNCTION less_equal_FF ELEMENTAL FUNCTION greater_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value > lambda END FUNCTION greater_FR ELEMENTAL FUNCTION greater_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value > REAL(lambda,dpk) END FUNCTION greater_FS ELEMENTAL FUNCTION greater_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value > REAL(lambda,dpk) END FUNCTION greater_FI ELEMENTAL FUNCTION greater_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = lambda > a%value END FUNCTION greater_RF ELEMENTAL FUNCTION greater_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) > a%value END FUNCTION greater_SF ELEMENTAL FUNCTION greater_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) > a%value END FUNCTION greater_IF ELEMENTAL FUNCTION greater_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value > b%value END FUNCTION greater_FF ELEMENTAL FUNCTION greater_equal_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value >= lambda END FUNCTION greater_equal_FR ELEMENTAL FUNCTION greater_equal_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value >= REAL(lambda,dpk) END FUNCTION greater_equal_FS ELEMENTAL FUNCTION greater_equal_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value >= REAL(lambda,dpk) END FUNCTION greater_equal_FI ELEMENTAL FUNCTION greater_equal_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = lambda >= a%value END FUNCTION greater_equal_RF ELEMENTAL FUNCTION greater_equal_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) >= a%value END FUNCTION greater_equal_SF ELEMENTAL FUNCTION greater_equal_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) >= a%value END FUNCTION greater_equal_IF ELEMENTAL FUNCTION greater_equal_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value >= b%value END FUNCTION greater_equal_FF ELEMENTAL FUNCTION equal_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value == lambda END FUNCTION equal_FR ELEMENTAL FUNCTION equal_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value == REAL(lambda,dpk) END FUNCTION equal_FS ELEMENTAL FUNCTION equal_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value == REAL(lambda,dpk) END FUNCTION equal_FI ELEMENTAL FUNCTION equal_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = lambda == a%value END FUNCTION equal_RF ELEMENTAL FUNCTION equal_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) == a%value END FUNCTION equal_SF ELEMENTAL FUNCTION equal_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) == a%value END FUNCTION equal_IF ELEMENTAL FUNCTION equal_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value == b%value END FUNCTION equal_FF ELEMENTAL FUNCTION not_equal_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = a%value /= lambda END FUNCTION not_equal_FR ELEMENTAL FUNCTION not_equal_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = a%value /= REAL(lambda,dpk) END FUNCTION not_equal_FS ELEMENTAL FUNCTION not_equal_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = a%value /= REAL(lambda,dpk) END FUNCTION not_equal_FI ELEMENTAL FUNCTION not_equal_RF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda LOGICAL :: res res = lambda /= a%value END FUNCTION not_equal_RF ELEMENTAL FUNCTION not_equal_SF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) /= a%value END FUNCTION not_equal_SF ELEMENTAL FUNCTION not_equal_IF(lambda, a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda LOGICAL :: res res = REAL(lambda,dpk) /= a%value END FUNCTION not_equal_IF ELEMENTAL FUNCTION not_equal_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b LOGICAL :: res res = a%value /= b%value END FUNCTION not_equal_FF END MODULE ad_relational MODULE ad_operator_plus USE ad_types IMPLICIT NONE INTERFACE OPERATOR (+) MODULE PROCEDURE unary_plus MODULE PROCEDURE add_FF, add_FR, add_FS, add_FI, add_RF, add_SF, add_IF END INTERFACE PRIVATE PUBLIC :: OPERATOR (+) CONTAINS ELEMENTAL FUNCTION unary_plus(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res = a END FUNCTION unary_plus ELEMENTAL FUNCTION add_RF(lambda, a) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = a res%value = lambda + res%value END FUNCTION add_RF ELEMENTAL FUNCTION add_SF(lambda, a) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) + a END FUNCTION add_SF ELEMENTAL FUNCTION add_IF(lambda, a) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) + a END FUNCTION add_IF ELEMENTAL FUNCTION add_FR(a, lambda) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + a END FUNCTION add_FR ELEMENTAL FUNCTION add_FS(a, lambda) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + a END FUNCTION add_FS ELEMENTAL FUNCTION add_FI(a, lambda) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + a END FUNCTION add_FI ELEMENTAL FUNCTION add_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res res%value = a%value + b%value IF (order_is_1or2) res%x = a%x + b%x IF (order_is_2) res%xx = a%xx + b%xx END FUNCTION add_FF END MODULE ad_operator_plus MODULE ad_operator_minus USE ad_types USE ad_operator_plus IMPLICIT NONE INTERFACE OPERATOR (-) MODULE PROCEDURE negate MODULE PROCEDURE sub_FF, sub_FR, sub_FS, sub_FI, sub_RF, sub_SF, sub_IF END INTERFACE PRIVATE PUBLIC :: OPERATOR (-) CONTAINS ELEMENTAL FUNCTION negate(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res%value = -a%value IF (order_is_1or2) res%x = -a%x IF (order_is_2) res%xx = -a%xx END FUNCTION negate ELEMENTAL FUNCTION sub_RF(lambda, a) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + (-a) END FUNCTION sub_RF ELEMENTAL FUNCTION sub_SF(lambda, a) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + (-a) END FUNCTION sub_SF ELEMENTAL FUNCTION sub_IF(lambda, a) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda + (-a) END FUNCTION sub_IF ELEMENTAL FUNCTION sub_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = a + (-lambda) END FUNCTION sub_FR ELEMENTAL FUNCTION sub_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda TYPE (func) :: res res = a + (-lambda) END FUNCTION sub_FS ELEMENTAL FUNCTION sub_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda TYPE (func) :: res res = a + (-lambda) END FUNCTION sub_FI ELEMENTAL FUNCTION sub_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res res = a + (-b) END FUNCTION sub_FF END MODULE ad_operator_minus MODULE ad_operator_star USE ad_types USE ad_auxiliary IMPLICIT NONE INTERFACE OPERATOR (*) MODULE PROCEDURE mul_FF, mul_FR, mul_FS, mul_FI, mul_RF, mul_SF, mul_IF END INTERFACE PRIVATE PUBLIC :: OPERATOR (*) CONTAINS ELEMENTAL FUNCTION mul_RF(lambda, a) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res%value = lambda * a%value IF (order_is_1or2) res%x = lambda * a%x IF (order_is_2) res%xx = lambda * a%xx END FUNCTION mul_RF ELEMENTAL FUNCTION mul_SF(lambda, a) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) * a END FUNCTION mul_SF ELEMENTAL FUNCTION mul_IF(lambda, a) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) * a END FUNCTION mul_IF ELEMENTAL FUNCTION mul_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = lambda * a END FUNCTION mul_FR ELEMENTAL FUNCTION mul_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda TYPE (func) :: res res = lambda * a END FUNCTION mul_FS ELEMENTAL FUNCTION mul_FI(a, lambda) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = lambda * a END FUNCTION mul_FI ELEMENTAL FUNCTION mul_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res res%value = a%value * b%value IF (order_is_1or2) res%x = a%value * b%x + b%value * a%x IF (order_is_2) THEN res%xx = a%value * b%xx + tensor(a,b) + tensor(b,a) + b%value * a%xx ENDIF END FUNCTION mul_FF END MODULE ad_operator_star MODULE ad_operator_slash USE ad_types USE ad_operator_star USE ad_auxiliary IMPLICIT NONE INTERFACE OPERATOR (/) MODULE PROCEDURE div_FF, div_FR, div_FS, div_FI, div_RF, div_SF, div_IF END INTERFACE PRIVATE PUBLIC :: OPERATOR (/) CONTAINS ELEMENTAL FUNCTION div_FR(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = (1.0_dpk / lambda) * a END FUNCTION div_FR ELEMENTAL FUNCTION div_FS(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda TYPE (func) :: res res = (1.0_dpk / REAL(lambda,dpk)) * a END FUNCTION div_FS ELEMENTAL FUNCTION div_FI(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda TYPE (func) :: res res = (1.0_dpk / REAL(lambda,dpk)) * a END FUNCTION div_FI ELEMENTAL FUNCTION div_RF(lambda, a) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res%value = lambda / a%value IF (order_is_1or2) res%x = (-res%value / a%value) * a%x IF (order_is_2) THEN res%xx = -( res%value * a%xx + 2.0_dpk * tensor(res,a) ) / a%value ENDIF END FUNCTION div_RF ELEMENTAL FUNCTION div_SF(lambda, a) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) / a END FUNCTION div_SF ELEMENTAL FUNCTION div_IF(lambda, a) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk) / a END FUNCTION div_IF ELEMENTAL FUNCTION div_FF(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res res = a * (1.0_dpk / b) END FUNCTION div_FF END MODULE ad_operator_slash MODULE ad_fortran_library USE ad_types USE ad_relational USE ad_assign USE ad_operator_plus USE ad_operator_minus USE ad_operator_star USE ad_operator_slash USE ad_auxiliary USE IEEEx_EXCEPTIONS IMPLICIT NONE INTERFACE abs MODULE PROCEDURE abs_ END INTERFACE INTERFACE acos MODULE PROCEDURE acos_ END INTERFACE INTERFACE aint MODULE PROCEDURE aint_ END INTERFACE INTERFACE anint MODULE PROCEDURE anint_ END INTERFACE INTERFACE asin MODULE PROCEDURE asin_ END INTERFACE INTERFACE atan MODULE PROCEDURE atan_ END INTERFACE INTERFACE atan2 MODULE PROCEDURE atan2_FF_, atan2_RF_, atan2_FR_, atan2_SF_, atan2_FS_ END INTERFACE INTERFACE ceiling MODULE PROCEDURE ceiling_ END INTERFACE INTERFACE cos MODULE PROCEDURE cos_ END INTERFACE INTERFACE cosh MODULE PROCEDURE cosh_ END INTERFACE INTERFACE digits MODULE PROCEDURE digits_ END INTERFACE INTERFACE dim MODULE PROCEDURE dim_ END INTERFACE INTERFACE dot_product MODULE PROCEDURE dot_product_FF_ MODULE PROCEDURE dot_product_RF_, dot_product_SF_, dot_product_IF_ MODULE PROCEDURE dot_product_FR_, dot_product_FS_, dot_product_FI_ END INTERFACE INTERFACE epsilon MODULE PROCEDURE epsilon_ END INTERFACE INTERFACE exp MODULE PROCEDURE exp_ END INTERFACE INTERFACE exponent MODULE PROCEDURE exponent_ END INTERFACE INTERFACE floor MODULE PROCEDURE floor_ END INTERFACE INTERFACE fraction MODULE PROCEDURE fraction_ END INTERFACE INTERFACE huge MODULE PROCEDURE huge_ END INTERFACE INTERFACE int MODULE PROCEDURE int_ END INTERFACE INTERFACE kind MODULE PROCEDURE kind_ END INTERFACE INTERFACE log MODULE PROCEDURE log_ END INTERFACE INTERFACE log10 MODULE PROCEDURE log10_ END INTERFACE INTERFACE matmul MODULE PROCEDURE matmul_FF_12_ MODULE PROCEDURE matmul_RF_12_, matmul_SF_12_, matmul_IF_12_ MODULE PROCEDURE matmul_FR_12_, matmul_FS_12_, matmul_FI_12_ MODULE PROCEDURE matmul_FF_21_ MODULE PROCEDURE matmul_RF_21_, matmul_SF_21_, matmul_IF_21_ MODULE PROCEDURE matmul_FR_21_, matmul_FS_21_, matmul_FI_21_ MODULE PROCEDURE matmul_FF_22_ MODULE PROCEDURE matmul_RF_22_, matmul_SF_22_, matmul_IF_22_ MODULE PROCEDURE matmul_FR_22_, matmul_FS_22_, matmul_FI_22_ END INTERFACE INTERFACE max MODULE PROCEDURE max2_FF_, max2_RF_, max2_FR_, max2_SF_, max2_FS_, max3_ END INTERFACE INTERFACE maxexponent MODULE PROCEDURE maxexponent_ END INTERFACE INTERFACE maxloc MODULE PROCEDURE maxloc_1, maxloc__dim_1, maxloc__mask_1 MODULE PROCEDURE maxloc__dim_mask_1 END INTERFACE INTERFACE maxval MODULE PROCEDURE maxval_1 END INTERFACE INTERFACE min MODULE PROCEDURE min2_FF_, min2_RF_, min2_FR_, min2_SF_, min2_FS_, min3_ END INTERFACE INTERFACE minexponent MODULE PROCEDURE minexponent_ END INTERFACE INTERFACE minloc MODULE PROCEDURE minloc_1, minloc__dim_1, minloc__mask_1 MODULE PROCEDURE minloc__dim_mask_1 END INTERFACE INTERFACE minval MODULE PROCEDURE minval_1 END INTERFACE INTERFACE mod MODULE PROCEDURE mod_FF_, mod_RF_, mod_FR_ END INTERFACE INTERFACE modulo MODULE PROCEDURE modulo_FR_, modulo_RF_, modulo_FF_ END INTERFACE INTERFACE nearest MODULE PROCEDURE nearest_FF_, nearest_FR_, nearest_RF_ MODULE PROCEDURE nearest_FS_, nearest_SF_ END INTERFACE INTERFACE nint MODULE PROCEDURE nint_ END INTERFACE INTERFACE PRECISION MODULE PROCEDURE precision_ END INTERFACE INTERFACE product MODULE PROCEDURE product_1 END INTERFACE INTERFACE radix MODULE PROCEDURE radix_ END INTERFACE INTERFACE range MODULE PROCEDURE range_ END INTERFACE INTERFACE rrspacing MODULE PROCEDURE rrspacing_ END INTERFACE INTERFACE scale MODULE PROCEDURE scale_ END INTERFACE INTERFACE set_exponent MODULE PROCEDURE set_exponent_ END INTERFACE INTERFACE sign MODULE PROCEDURE sign_RF_, sign_FR_, sign_FF_ END INTERFACE INTERFACE sin MODULE PROCEDURE sin_ END INTERFACE INTERFACE sinh MODULE PROCEDURE sinh_ END INTERFACE INTERFACE spacing MODULE PROCEDURE spacing_ END INTERFACE INTERFACE sqrt MODULE PROCEDURE sqrt_ END INTERFACE INTERFACE sum MODULE PROCEDURE sum_1 END INTERFACE INTERFACE tan MODULE PROCEDURE tan_ END INTERFACE INTERFACE tanh MODULE PROCEDURE tanh_ END INTERFACE INTERFACE tiny MODULE PROCEDURE tiny_ END INTERFACE PRIVATE PUBLIC :: abs, acos, aint, anint, asin, atan, atan2, ceiling, cos, cosh PUBLIC :: digits, dim, dot_product, epsilon, exp, exponent, floor, fraction PUBLIC :: huge, int, log, log10, matmul, max, maxexponent, maxloc, maxval PUBLIC :: min, minexponent, minloc, minval, mod, modulo, nearest, nint PUBLIC :: precision, product, radix, range, rrspacing, scale, set_exponent PUBLIC :: sign, sin, sinh, spacing, sqrt, sum, tan, tanh, tiny, kind CONTAINS ELEMENTAL FUNCTION abs_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res = a IF (a%value < 0.0_dpk) res = -res IF (a%value == 0.0_dpk) CALL IEEE_SET_FLAG(IEEE_INVALID, .TRUE.) ! discontinuous function. END FUNCTION abs_ ELEMENTAL FUNCTION acos_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: sin_ res%value = ACOS(a%value) IF (order_is_1or2) THEN sin_ = SIN(res%value) IF (is_small(sin_)) CALL IEEE_SET_FLAG(IEEE_DIVIDE_BY_ZERO, .TRUE.) res%x = -a%x / sin_ END IF IF (order_is_2) res%xx = -(a%xx + a%value * tensor(res, res)) / sin_ END FUNCTION acos_ ELEMENTAL FUNCTION aint_(a) RESULT (res) ! optional argument kind cannot be implemented IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = AINT(a%value) END FUNCTION aint_ ELEMENTAL FUNCTION anint_(a) RESULT (res) ! optional argument kind cannot be implemented IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = ANINT(a%value) END FUNCTION anint_ ELEMENTAL FUNCTION asin_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: cos_ res%value = ASIN(a%value) IF (order_is_1or2) THEN cos_ = COS(res%value) IF (is_small(cos_)) CALL IEEE_SET_FLAG(IEEE_DIVIDE_BY_ZERO, .TRUE.) res%x = a%x / cos_ END IF IF (order_is_2) res%xx = (a%xx + a%value * tensor(res, res)) / cos_ END FUNCTION asin_ ELEMENTAL FUNCTION atan_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: cos2 res%value = ATAN(a%value) IF (order_is_1or2) THEN cos2 = 1.0_dpk / (1.0_dpk + a%value**2) ! COS(res%value)**2 res%x = cos2 * a%x ENDIF IF (order_is_2) THEN ! res%xx = -SIN(2.0_dpk * res%value) * tensor(a,res) + cos2 * a%xx ! res%xx = -2.0_dpk * SIN(res%value) * COS(res%value) * tensor(a,res) + cos2 * a%xx ! res%xx = cos2 * (-2.0_dpk * TAN(res%value) * tensor(a,res) + a%xx) ! res%xx = -2.0_dpk * a%value * cos2 * tensor(a,res) + cos2 * a%xx res%xx = -2.0_dpk * a%value * tensor(res,res) + cos2 * a%xx ENDIF END FUNCTION atan_ ELEMENTAL FUNCTION atan2_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res IF (is_small(b%value)) CALL IEEE_SET_FLAG(IEEE_DIVIDE_BY_ZERO, .TRUE.) res = ATAN(a / b) res%value = ATAN2(a%value, b%value) END FUNCTION atan2_FF_ ELEMENTAL FUNCTION atan2_RF_(a_, b) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: a_ TYPE (func), INTENT (in) :: b TYPE (func) :: res TYPE (func) :: a a = func(a_, 0.0_dpk, 0.0_dpk) res = ATAN2(a,b) END FUNCTION atan2_RF_ ELEMENTAL FUNCTION atan2_FR_(a, b_) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: b_ TYPE (func) :: res TYPE (func) :: b b = func(b_, 0.0_dpk, 0.0_dpk) res = ATAN2(a,b) END FUNCTION atan2_FR_ ELEMENTAL FUNCTION atan2_SF_(a, b) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: a TYPE (func), INTENT (in) :: b TYPE (func) :: res res = ATAN2(REAL(a,dpk), b) END FUNCTION atan2_SF_ ELEMENTAL FUNCTION atan2_FS_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: b TYPE (func) :: res res = ATAN2(a, REAL(b,dpk)) END FUNCTION atan2_FS_ ELEMENTAL FUNCTION ceiling_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = CEILING(a%value) END FUNCTION ceiling_ ELEMENTAL FUNCTION cos_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: minus_sin res%value = COS(a%value) IF (order_is_1or2) THEN minus_sin = -SIN(a%value) res%x = minus_sin * a%x ENDIF IF (order_is_2) res%xx = minus_sin * a%xx - res%value * tensor(a,a) END FUNCTION cos_ ELEMENTAL FUNCTION cosh_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: sinha res%value = COSH(a%value) IF (order_is_1or2) THEN sinha = SINH(a%value) res%x = sinha * a%x ENDIF IF (order_is_2) res%xx = res%value * tensor(a,a) + sinha * a%xx END FUNCTION cosh_ ELEMENTAL FUNCTION digits_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = DIGITS(a%value) END FUNCTION digits_ ELEMENTAL FUNCTION dim_(x, y) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: x, y TYPE (func) :: res res = func(0.0_dpk, 0.0_dpk, 0.0_dpk) IF (x > y) res = x - y END FUNCTION dim_ PURE FUNCTION dot_product_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a, b TYPE (func) :: res INTEGER :: i res = a(1) * b(1) DO i = 2, SIZE(a) res = res + a(i) * b(i) ENDDO END FUNCTION dot_product_FF_ PURE FUNCTION dot_product_RF_(lambda, b) RESULT (res) IMPLICIT NONE REAL (dpk), DIMENSION (:), INTENT (in) :: lambda TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res INTEGER :: i res%value = DOT_PRODUCT(lambda, b%value) IF (order_is_1or2) FORALL (i=1:n) res%x(i) =DOT_PRODUCT(lambda, b%x(i)) IF (order_is_2) FORALL (i=1:nhes) res%xx(i)=DOT_PRODUCT(lambda, b%xx(i)) !!% !!% res = 0.0_dpk !!% DO i = 1, SIZE(lambda) !!% res = res + lambda(i) * b(i) !!% ENDDO END FUNCTION dot_product_RF_ PURE FUNCTION dot_product_SF_(a, b) RESULT (res) IMPLICIT NONE REAL (spk), DIMENSION (:), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res res = DOT_PRODUCT(REAL(a,dpk), b) END FUNCTION dot_product_SF_ PURE FUNCTION dot_product_IF_(a, b) RESULT (res) IMPLICIT NONE INTEGER (ik), DIMENSION (:), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res res = DOT_PRODUCT(REAL(a,dpk), b) END FUNCTION dot_product_IF_ PURE FUNCTION dot_product_FR_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a REAL (dpk), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res res = DOT_PRODUCT(b, a) END FUNCTION dot_product_FR_ PURE FUNCTION dot_product_FS_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a REAL (spk), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res res = DOT_PRODUCT(b, a) END FUNCTION dot_product_FS_ PURE FUNCTION dot_product_FI_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER (ik), DIMENSION (:), INTENT (in) :: b TYPE (func) :: res res = DOT_PRODUCT(b, a) END FUNCTION dot_product_FI_ ELEMENTAL FUNCTION epsilon_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = EPSILON(a%value) END FUNCTION epsilon_ ELEMENTAL FUNCTION exp_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res%value = EXP(a%value) IF (order_is_1or2) res%x = res%value * a%x IF (order_is_2) res%xx = res%value * a%xx + tensor(a,res) END FUNCTION exp_ ELEMENTAL FUNCTION exponent_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = EXPONENT(a%value) END FUNCTION exponent_ ELEMENTAL FUNCTION floor_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = FLOOR(a%value) END FUNCTION floor_ ELEMENTAL FUNCTION fraction_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = FRACTION(a%value) END FUNCTION fraction_ ELEMENTAL FUNCTION huge_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = HUGE(a%value) END FUNCTION huge_ ELEMENTAL FUNCTION int_(a) RESULT (res) ! optional argument kind cannot be implemented IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = INT(a%value) END FUNCTION int_ ELEMENTAL FUNCTION kind_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = KIND(a%value) ! by default = dpk END FUNCTION kind_ ELEMENTAL FUNCTION log_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res%value = LOG(a%value) IF (order_is_1or2) res%x = a%x / a%value IF (order_is_2) res%xx = a%xx / a%value - tensor(res, res) END FUNCTION log_ ELEMENTAL FUNCTION log10_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res res = LOG(a) / LOG(10.0_dpk) END FUNCTION log10_ PURE FUNCTION matmul_FF_12_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(a%value, b%value) IF (order_is_1or2) THEN FORALL (i = 1:n) & res%x(i) = MATMUL(a%x(i), b%value) + MATMUL(a%value, b%x(i)) END IF IF (order_is_2) THEN FORALL (i=1:nhes) res%xx(i) = & MATMUL(a%xx(i), b%value) + & MATMUL(a%x(col(i)), b%x(row(i))) + & ! tensor MATMUL(a%value, b%xx(i)) END IF END FUNCTION matmul_FF_12_ PURE FUNCTION matmul_RF_12_(lambda, b) RESULT (res) IMPLICIT NONE REAL (dpk), DIMENSION (:), INTENT (in) :: lambda TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(lambda, b%value) IF (order_is_1or2) FORALL(i=1:n) res%x(i) = MATMUL(lambda, b%x(i)) IF (order_is_2) FORALL (i=1:nhes) res%xx(i) = MATMUL(lambda, b%xx(i)) END FUNCTION matmul_RF_12_ PURE FUNCTION matmul_SF_12_(lambda, b) RESULT (res) IMPLICIT NONE REAL (spk), DIMENSION (:), INTENT (in) :: lambda TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res res = MATMUL(REAL(lambda,dpk), b) END FUNCTION matmul_SF_12_ PURE FUNCTION matmul_IF_12_(lambda, b) RESULT (res) IMPLICIT NONE INTEGER (ik), DIMENSION (:), INTENT (in) :: lambda TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res res = MATMUL(REAL(lambda,dpk), b) END FUNCTION matmul_IF_12_ PURE FUNCTION matmul_FR_12_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a REAL (dpk), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(a%value, b) IF (order_is_1or2) FORALL(i=1:n) res%x(i) = MATMUL(a%x(i), b) IF (order_is_2) FORALL(i=1:nhes) res%xx(i) = MATMUL(a%xx(i), b) END FUNCTION matmul_FR_12_ PURE FUNCTION matmul_FS_12_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a REAL (spk), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FS_12_ PURE FUNCTION matmul_FI_12_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER (ik), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(b, 2)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FI_12_ PURE FUNCTION matmul_FF_21_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res INTEGER :: i res%value = MATMUL(a%value, b%value) IF (order_is_1or2) THEN FORALL (i = 1:n) & res%x(i) = MATMUL(a%x(i), b%value) + MATMUL(a%value, b%x(i)) END IF IF (order_is_2) THEN FORALL (i=1:nhes) res%xx(i) = & MATMUL(a%xx(i), b%value) + & MATMUL(a%x(col(i)), b%x(row(i))) + & ! tensor MATMUL(a%value, b%xx(i)) END IF END FUNCTION matmul_FF_21_ PURE FUNCTION matmul_RF_21_(a, b) RESULT (res) IMPLICIT NONE REAL (dpk), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res INTEGER :: i res%value = MATMUL(a, b%value) IF (order_is_1or2) FORALL(i=1:n) res%x(i) = MATMUL(a, b%x(i)) IF (order_is_2) FORALL(i=1:nhes) res%xx(i) = MATMUL(a, b%xx(i)) END FUNCTION matmul_RF_21_ PURE FUNCTION matmul_SF_21_(a, b) RESULT (res) IMPLICIT NONE REAL (spk), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res res = MATMUL(REAL(a,dpk), b) END FUNCTION matmul_SF_21_ PURE FUNCTION matmul_IF_21_(a, b) RESULT (res) IMPLICIT NONE INTEGER (ik), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res res = MATMUL(REAL(a,dpk), b) END FUNCTION matmul_IF_21_ PURE FUNCTION matmul_FR_21_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a REAL (dpk), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res INTEGER :: i res%value = MATMUL(a%value, b) IF (order_is_1or2) FORALL (i=1:n) res%x(i) = MATMUL(a%x(i), b) IF (order_is_2) FORALL (i=1:nhes) res%xx(i) = MATMUL(a%xx(i), b) END FUNCTION matmul_FR_21_ PURE FUNCTION matmul_FS_21_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a REAL (spk), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FS_21_ PURE FUNCTION matmul_FI_21_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a INTEGER (ik), DIMENSION (:), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FI_21_ PURE FUNCTION matmul_FF_22_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(a%value, b%value) IF (order_is_1or2) THEN FORALL (i=1:n) & res%x(i) = MATMUL(a%x(i), b%value) + MATMUL(a%value, b%x(i)) END IF IF (order_is_2) THEN FORALL (i=1:nhes) res%xx(i) = & MATMUL(a%xx(i), b%value) + & MATMUL(a%x(col(i)), b%x(row(i))) + & ! tensor MATMUL(a%value, b%xx(i)) END IF END FUNCTION matmul_FF_22_ PURE FUNCTION matmul_RF_22_(a, b) RESULT (res) IMPLICIT NONE REAL (dpk), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(a, b%value) IF (order_is_1or2) FORALL (i=1:n) res%x(i) = MATMUL(a, b%x(i)) IF (order_is_2) FORALL (i=1:nhes) res%xx(i) = MATMUL(a, b%xx(i)) END FUNCTION matmul_RF_22_ PURE FUNCTION matmul_SF_22_(a, b) RESULT (res) IMPLICIT NONE REAL (spk), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res res = MATMUL(REAL(a, dpk), b) END FUNCTION matmul_SF_22_ PURE FUNCTION matmul_IF_22_(a, b) RESULT (res) IMPLICIT NONE INTEGER (ik), DIMENSION (:, :), INTENT (in) :: a TYPE (func), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res res = MATMUL(REAL(a, dpk), b) END FUNCTION matmul_IF_22_ PURE FUNCTION matmul_FR_22_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a REAL (dpk), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res INTEGER :: i res%value = MATMUL(a%value, b) IF (order_is_1or2) FORALL (i=1:n) res%x(i) = MATMUL(a%x(i), b) IF (order_is_2) FORALL (i=1:nhes) res%xx(i) = MATMUL(a%xx(i), b) END FUNCTION matmul_FR_22_ PURE FUNCTION matmul_FS_22_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a REAL (spk), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FS_22_ PURE FUNCTION matmul_FI_22_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:, :), INTENT (in) :: a INTEGER (ik), DIMENSION (:, :), INTENT (in) :: b TYPE (func), DIMENSION (SIZE(a, 1), SIZE(b, 2)) :: res res = MATMUL(a, REAL(b,dpk)) END FUNCTION matmul_FI_22_ ELEMENTAL FUNCTION max2_FF_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1 TYPE (func), INTENT (in) :: a2 TYPE (func) :: res IF (a1 >= a2) THEN res = a1 ELSE res = a2 END IF END FUNCTION max2_FF_ ELEMENTAL FUNCTION max2_FR_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1 REAL (dpk), INTENT (in) :: a2 TYPE (func) :: res res = MAX(a1, func(a2, 0.0_dpk, 0.0_dpk)) END FUNCTION max2_FR_ ELEMENTAL FUNCTION max2_RF_(a1, a2) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: a1 TYPE (func), INTENT (in) :: a2 TYPE (func) :: res res = MAX(a2, a1) END FUNCTION max2_RF_ ELEMENTAL FUNCTION max2_FS_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1 REAL (spk), INTENT (in) :: a2 TYPE (func) :: res res = MAX(a1, REAL(a2,dpk)) END FUNCTION max2_FS_ ELEMENTAL FUNCTION max2_SF_(a1, a2) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: a1 TYPE (func), INTENT (in) :: a2 TYPE (func) :: res res = MAX(a2, a1) END FUNCTION max2_SF_ ELEMENTAL FUNCTION max3_(a1, a2, a3) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1, a2, a3 TYPE (func) :: res res = MAX(a1, MAX(a2,a3)) END FUNCTION max3_ ELEMENTAL FUNCTION maxexponent_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = MAXEXPONENT(a%value) END FUNCTION maxexponent_ PURE FUNCTION maxloc_1(a) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MAXLOC(a%value) END FUNCTION maxloc_1 PURE FUNCTION maxloc__dim_1(a, dim) RESULT (res) ! F95 interface IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in) :: dim ! not optional INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MAXLOC(a%value, dim) END FUNCTION maxloc__dim_1 PURE FUNCTION maxloc__mask_1(a, mask) RESULT (res) ! F90 interface IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a LOGICAL, DIMENSION (:), INTENT (in) :: mask ! not optional INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MAXLOC(a%value, mask) END FUNCTION maxloc__mask_1 PURE FUNCTION maxloc__dim_mask_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in) :: dim LOGICAL, DIMENSION (:), INTENT (in) :: mask INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MAXLOC(a%value, dim, mask) END FUNCTION maxloc__dim_mask_1 PURE FUNCTION maxval_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in), OPTIONAL :: dim LOGICAL, DIMENSION (:), INTENT (in), OPTIONAL :: mask ! same rank with a TYPE (func) :: res ! res is scalar INTEGER :: ind(SIZE(SHAPE(a))) INTEGER :: mydim LOGICAL, DIMENSION (SIZE(a)) :: mymask mydim = 1 IF (PRESENT(dim)) mydim = dim mymask = .TRUE. IF (PRESENT(mask)) mymask = mask ind = MAXLOC(a, mydim, mymask) res = a(ind(1)) END FUNCTION maxval_1 ELEMENTAL FUNCTION min2_FF_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1, a2 TYPE (func) :: res IF (a1 <= a2) res = a1 IF (a2 <= a1) res = a2 END FUNCTION min2_FF_ ELEMENTAL FUNCTION min2_FR_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1 REAL (dpk), INTENT (in) :: a2 TYPE (func) :: res res = MIN(a1, func(a2, 0.0_dpk, 0.0_dpk)) END FUNCTION min2_FR_ ELEMENTAL FUNCTION min2_RF_(a1, a2) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: a1 TYPE (func), INTENT (in) :: a2 TYPE (func) :: res res = MIN(a2, a1) END FUNCTION min2_RF_ ELEMENTAL FUNCTION min2_FS_(a1, a2) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1 REAL (spk), INTENT (in) :: a2 TYPE (func) :: res res = MIN(a1, REAL(a2,dpk)) END FUNCTION min2_FS_ ELEMENTAL FUNCTION min2_SF_(a1, a2) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: a1 TYPE (func), INTENT (in) :: a2 TYPE (func) :: res res = MIN(a2, a1) END FUNCTION min2_SF_ ELEMENTAL FUNCTION min3_(a1, a2, a3) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a1, a2, a3 TYPE (func) :: res res = MIN(a1, MIN(a2,a3)) END FUNCTION min3_ ELEMENTAL FUNCTION minexponent_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = MINEXPONENT(a%value) END FUNCTION minexponent_ PURE FUNCTION minloc_1(a) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MINLOC(a%value) END FUNCTION minloc_1 PURE FUNCTION minloc__dim_1(a, dim) RESULT (res) ! F95 interface IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in) :: dim ! not optional INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MINLOC(a%value, dim) END FUNCTION minloc__dim_1 PURE FUNCTION minloc__mask_1(a, mask) RESULT (res) ! F90 interface IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a LOGICAL, DIMENSION (:), INTENT (in) :: mask ! not optional INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MINLOC(a%value, mask) END FUNCTION minloc__mask_1 PURE FUNCTION minloc__dim_mask_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in) :: dim LOGICAL, DIMENSION (:), INTENT (in) :: mask INTEGER, DIMENSION (SIZE(SHAPE(a))) :: res res = MINLOC(a%value, dim, mask) END FUNCTION minloc__dim_mask_1 PURE FUNCTION minval_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in), OPTIONAL :: dim LOGICAL, DIMENSION (:), INTENT (in), OPTIONAL :: mask ! same rank with a TYPE (func) :: res ! res is scalar INTEGER :: ind(SIZE(SHAPE(a))) INTEGER :: mydim LOGICAL, DIMENSION (SIZE(a)) :: mymask mydim = 1 IF (PRESENT(dim)) mydim = dim mymask = .TRUE. IF (PRESENT(mask)) mymask = mask ind = MINLOC(a, mydim, mymask) res = a(ind(1)) END FUNCTION minval_1 ELEMENTAL FUNCTION mod_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res INTEGER :: div res%value = MOD(a%value, b%value) IF (order_is_1or2) THEN div = (a%value - res%value) / b%value res%x = a%x - div * b%x END IF IF (order_is_2) res%xx = a%xx - div * b%xx END FUNCTION mod_FF_ ELEMENTAL FUNCTION mod_FR_(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = a res%value = MOD(a%value, lambda) END FUNCTION mod_FR_ ELEMENTAL FUNCTION mod_RF_(lambda, b) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: b REAL (dpk) :: res res = MOD(lambda, b%value) END FUNCTION mod_RF_ ! no mod_sf, mod_fs; a, lambda must be of the same kind ELEMENTAL FUNCTION modulo_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res INTEGER :: div res%value = MODULO(a%value, b%value) IF (order_is_1or2) THEN div = (a%value - res%value) / b%value res%x = a%x - div * b%x END IF IF (order_is_2) res%xx = a%xx - div * b%xx END FUNCTION modulo_FF_ ELEMENTAL FUNCTION modulo_FR_(a, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = a res%value = MODULO(a%value, lambda) END FUNCTION modulo_FR_ ! no modulo_sf, modulo_fs; a, lambda must be of the same kind ELEMENTAL FUNCTION modulo_RF_(lambd, a) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: lambd TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = MODULO(lambd, a%value) END FUNCTION modulo_RF_ ELEMENTAL FUNCTION nearest_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res ! the derivatives should be kept. Otherwise, don't use nearest(). res = a res = NEAREST(a%value, b%value) END FUNCTION nearest_FF_ ELEMENTAL FUNCTION nearest_RF_(a, b) RESULT (res) IMPLICIT NONE REAL (dpk), INTENT (in) :: a TYPE (func), INTENT (in) :: b REAL (dpk) :: res res = NEAREST(a, b%value) END FUNCTION nearest_RF_ ELEMENTAL FUNCTION nearest_FR_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: b TYPE (func) :: res res = NEAREST(a, func(b, 0.0_dpk, 0.0_dpk)) END FUNCTION nearest_FR_ ELEMENTAL FUNCTION nearest_SF_(a, b) RESULT (res) IMPLICIT NONE REAL (spk), INTENT (in) :: a TYPE (func), INTENT (in) :: b REAL (spk) :: res res = NEAREST(a, b%value) END FUNCTION nearest_SF_ ELEMENTAL FUNCTION nearest_FS_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: b TYPE (func) :: res res = NEAREST(a, REAL(b, dpk)) END FUNCTION nearest_FS_ ELEMENTAL FUNCTION nint_(a) RESULT (res) ! optional argument kind cannot be implemented IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = NINT(a%value) END FUNCTION nint_ ELEMENTAL FUNCTION precision_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = PRECISION(a%value) END FUNCTION precision_ PURE FUNCTION product_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in), OPTIONAL :: dim LOGICAL, DIMENSION (:), INTENT (in), OPTIONAL :: mask TYPE (func) :: res ! res is array with rank = rank(a) - 1 INTEGER :: i, j, k REAL (dpk) :: old_a, old_a_2 REAL (dpk), DIMENSION(SIZE(a,1)) :: a_ ! copy of a INTEGER :: mydim LOGICAL, DIMENSION (SIZE(a)) :: mymask mydim = 1 IF (PRESENT(dim)) mydim = dim mymask = .TRUE. IF (PRESENT(mask)) mymask = mask a_ = a%value res%value = PRODUCT(a_, mydim, mymask) IF (order_is_1or2) THEN DO j = 1, n res%x(j) = 0.0_dpk DO i = 1, SIZE(a) old_a = a_(i) a_(i) = a(i)%x(j) res%x(j) = res%x(j) + PRODUCT(a_, mydim, mymask) a_(i) = old_a ENDDO ENDDO ENDIF IF (order_is_2) THEN ! First add to the sum the terms : ! a_1%xx() * a_2 * a_3 ... + a_1 * a_2%xx() * a_3 ... + ... DO j = 1, nhes res%xx(j) = 0.0_dpk DO i = 1, SIZE(a) old_a = a_(i) a_(i) = a(i)%xx(j) res%xx(j) = res%xx(j) + PRODUCT(a_, mydim, mymask) a_(i) = old_a ENDDO ENDDO ! Now compute the tensor products DO j = 1, nhes DO k = 1, SIZE(a) old_a = a_(k) a_(k) = a(k)%x(col(j)) DO i = 1, SIZE(a) IF (i == k) CYCLE old_a_2 = a_(i) a_(i) = a(i)%x(row(j)) res%xx(j) = res%xx(j) + PRODUCT(a_, mydim, mymask) a_(i) = old_a_2 ENDDO a_(k) = old_a ENDDO ENDDO ENDIF END FUNCTION product_1 ELEMENTAL FUNCTION radix_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = RADIX(a%value) END FUNCTION radix_ ELEMENTAL FUNCTION range_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER :: res res = RANGE(a%value) END FUNCTION range_ ELEMENTAL FUNCTION rrspacing_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = RRSPACING(a%value) END FUNCTION rrspacing_ ELEMENTAL FUNCTION scale_(a, i) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER, INTENT (in) :: i TYPE (func) :: res res%value = SCALE(a%value, i) IF (order_is_1or2) res%x = SCALE(a%x, i) IF (order_is_2) res%xx = SCALE(a%xx, i) END FUNCTION scale_ ELEMENTAL FUNCTION set_exponent_(a, i) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER, INTENT (in) :: i REAL (dpk) :: res res = SET_EXPONENT(a%value, i) END FUNCTION set_exponent_ ELEMENTAL FUNCTION sign_FF_(a, b) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func), INTENT (in) :: b TYPE (func) :: res res = ABS(a) IF (b < 0.0_dpk) res = -res END FUNCTION sign_FF_ ELEMENTAL FUNCTION sign_RF_(lambda, a) RESULT (res) IMPLICIT NONE REAL (dpk) , INTENT (in) :: lambda TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = SIGN(lambda, a%value) END FUNCTION sign_RF_ ELEMENTAL FUNCTION sign_FR_(b, lambda) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: b REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res res = ABS(b) IF (lambda < 0.0_dpk) res = -res END FUNCTION sign_FR_ ! no sign_sf_, sign_fs_; a, lambda must be of the same kind ELEMENTAL FUNCTION sin_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: cosa res%value = SIN(a%value) IF (order_is_1or2) THEN cosa = COS(a%value) res%x = cosa * a%x ENDIF IF (order_is_2) res%xx = -res%value * tensor(a,a) + cosa * a%xx END FUNCTION sin_ ELEMENTAL FUNCTION sinh_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: cosha res%value = SINH(a%value) IF (order_is_1or2) THEN cosha = COSH(a%value) res%x = cosha * a%x ENDIF IF (order_is_2) res%xx = res%value * tensor(a,a) + cosha * a%xx END FUNCTION sinh_ ELEMENTAL FUNCTION spacing_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = SPACING(a%value) END FUNCTION spacing_ ELEMENTAL FUNCTION sqrt_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res IF (a%value == 0.0_dpk) CALL IEEE_SET_FLAG(IEEE_INVALID, .TRUE.) ! discontinuous function. res%value = SQRT(a%value) IF (order_is_1or2) res%x = 0.5_dpk / res%value * a%x IF (order_is_2) res%xx = (0.5_dpk * a%xx - tensor(res, res)) / res%value END FUNCTION sqrt_ PURE FUNCTION sum_1(a, dim, mask) RESULT (res) IMPLICIT NONE TYPE (func), DIMENSION (:), INTENT (in) :: a INTEGER, INTENT (in), OPTIONAL :: dim LOGICAL, DIMENSION (:), INTENT (in), OPTIONAL :: mask ! mask has the shape of a TYPE (func) :: res ! res is array with rank = rank(a) - 1 INTEGER :: i, mydim LOGICAL, DIMENSION (SIZE(a)) :: mymask mydim = 1 IF (PRESENT(dim)) mydim = dim mymask = .TRUE. IF (PRESENT(mask)) mymask = mask res%value = SUM(a%value, mydim, mymask) IF (order_is_1or2) FORALL(i=1:n) res%x(i) = SUM(a%x(i), mydim, mymask) IF (order_is_2) FORALL(i=1:nhes) res%xx(i) = SUM(a%xx(i), mydim, mymask) END FUNCTION sum_1 ELEMENTAL FUNCTION tan_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: sec2 res%value = TAN(a%value) IF (order_is_1or2) THEN sec2 = 1.0_dpk + res%value**2 ! 1.0_dpk / COS(a%value)**2 res%x = sec2 * a%x ENDIF IF (order_is_2) res%xx = sec2 * a%xx + 2.0_dpk * res%value * tensor(a,res) END FUNCTION tan_ ELEMENTAL FUNCTION tanh_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a TYPE (func) :: res REAL (dpk) :: sech2 res%value = TANH(a%value) IF (order_is_1or2) THEN sech2 = 1.0_dpk - res%value**2 ! 1.0_dpk / COSH(a%value)**2 res%x = sech2 * a%x ENDIF IF (order_is_2) res%xx = sech2 * a%xx - 2.0_dpk * res%value * tensor(a,res) END FUNCTION tanh_ ELEMENTAL FUNCTION tiny_(a) RESULT (res) IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk) :: res res = TINY(a%value) END FUNCTION tiny_ END MODULE ad_fortran_library MODULE ad_operator_power USE ad_types USE ad_auxiliary USE ad_assign USE IEEEx_EXCEPTIONS IMPLICIT NONE INTERFACE OPERATOR (**) MODULE PROCEDURE power_FF, power_FR, power_FS, power_FI MODULE PROCEDURE power_RF, power_SF, power_IF END INTERFACE PRIVATE PUBLIC :: OPERATOR (**) CONTAINS ELEMENTAL FUNCTION power_FR(a, lambda) RESULT (res) ! res = a**lambda IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (dpk), INTENT (in) :: lambda TYPE (func) :: res IF (lambda == 0.0_dpk) THEN IF (a%value == 0.0_dpk) CALL IEEE_SET_FLAG(IEEE_INVALID, .TRUE.) res%value = 1.0_dpk IF (order_is_1or2) res%x = 0.0_dpk IF (order_is_2) res%xx = 0.0_dpk RETURN END IF IF (lambda == 1.0_dpk) THEN res = a RETURN ENDIF IF (a%value == 0.0_dpk) THEN res%value = 0.0_dpk IF (order_is_1or2) res%x = 0.0_dpk IF (order_is_2) res%xx = 0.0_dpk RETURN ENDIF res%value = a%value**lambda IF (order_is_1or2) res%x = lambda * res%value / a%value * a%x IF (order_is_2) res%xx = ((lambda - 1.0_dpk) * tensor(res,a) & + lambda * res%value * a%xx) / a%value END FUNCTION power_FR ELEMENTAL FUNCTION power_FS(a, lambda) RESULT (res) ! res = a**lambda IMPLICIT NONE TYPE (func), INTENT (in) :: a REAL (spk), INTENT (in) :: lambda TYPE (func) :: res res = a**REAL(lambda, dpk) END FUNCTION power_FS ELEMENTAL FUNCTION power_FI(a, lambda) RESULT (res) ! res = a**lambda IMPLICIT NONE TYPE (func), INTENT (in) :: a INTEGER (ik), INTENT (in) :: lambda TYPE (func) :: res res = a**REAL(lambda, dpk) END FUNCTION power_FI ELEMENTAL FUNCTION power_RF(lambda, a) RESULT (res) ! res = lambda**a IMPLICIT NONE REAL (dpk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res IF (lambda <= 0.0_dpk) CALL IEEE_SET_FLAG(IEEE_INVALID, .TRUE.) res%value = lambda**a%value IF (order_is_1or2) res%x = LOG(lambda) * res%value * a%x IF (order_is_2) res%xx = LOG(lambda) * (tensor(res,a) + res%value * a%xx) END FUNCTION power_RF ELEMENTAL FUNCTION power_SF(lambda, a) RESULT (res) ! res = lambda**a IMPLICIT NONE REAL (spk), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk)**a END FUNCTION power_SF ELEMENTAL FUNCTION power_IF(lambda, a) RESULT (res) IMPLICIT NONE INTEGER (ik), INTENT (in) :: lambda TYPE (func), INTENT (in) :: a TYPE (func) :: res res = REAL(lambda, dpk)**a END FUNCTION power_IF ELEMENTAL FUNCTION power_FF(a, b) RESULT (res) ! res = a**b USE ad_operator_star USE ad_fortran_library, ONLY : exp, log IMPLICIT NONE TYPE (func), INTENT (in) :: a, b TYPE (func) :: res res = EXP(LOG(a) * b) END FUNCTION power_FF END MODULE ad_operator_power MODULE deriv_class USE ad_types USE ad_utilities USE ad_fortran_library USE ad_assign USE ad_operator_plus USE ad_operator_minus USE ad_operator_star USE ad_operator_slash USE ad_operator_power USE ad_relational IMPLICIT NONE PRIVATE :: n, nhes, order_is_2, order_is_1or2, dpk, spk, ik END MODULE deriv_class -------------- next part -------------- echo f2py build for auto_deriv echo deleting previous build rm -i *.so echo building Python wrappers f2py3 -c gravity_derivs.f -m gravity_derivs --f77flags="-c -O -Wall" f2py3 -c auto_deriv auto_deriv.f90 -m auto_deriv auto_deriv echo done.