Provide callback with assumed shape arrays?

[awvwgk]

Should we have an option to provide the callback functions with deferred shape arrays rather than the current explicit shaped ones? Of course we want to retain the old API and could add a minpack_legacy for this purpose implementing the old interfaces as a thin wrapper around the new ones. Downstream users could retain their current implementation and upgrade to the newer version as needed.

[arjenmarkus]

I would say that the interfaces by default should use modern features, so deferred shape is the norm in this case. An alternative interface is possible and required to keep the library compatible (also vis-à-vis other languages) but not as the primary interface. Op zo 19 jun. 2022 om 13:14 schreef Sebastian Ehlert < ***@***.***>:

…

Should we have an option to provide the callback functions with deferred shape arrays rather than the current explicit shaped ones? Of course we want to retain the old API and could add a minpack_legacy for this purpose implementing the old interfaces as a thin wrapper around the new ones. Downstream users could retain their current implementation and upgrade to the newer version as needed. — Reply to this email directly, view it on GitHub <#76>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR3BP3TCEGJ6VS2ZAHTVP36IBANCNFSM5ZGG4LOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ivan-pi]

Would you retain the old API in a module or as external subroutines? If we want to remain backward compatible we could export external subroutines (similar to how the C API is currently exported). If fpm is to support features and variants, there would be a fpm mechanism to turn on the legacy external interface.

[arjenmarkus]

The original API used hollerith sthings, so for the sake of mental sanity I would convert them at the very least to ordinary character strings that get written to the screen.That is certainly something I can restore. If that is done via a separate routine that gets redefined as a no-op, unless asked for, then that would be as close to the original that we should want to get. Regards, Arjen Op wo 9 nov. 2022 om 11:53 schreef Ivan Pribec ***@***.***>:

…

Would you retain the old API in a module or as external subroutines? If we want to remain backward compatible we could export external subroutines (similar to how the C API <https://github.com/fortran-lang/minpack/blob/main/src/minpack_capi.f90> is currently exported). If fpm is to support features and variants <https://fortran-lang.discourse.group/t/stf-project-fortran-developer-for-fpm-registry/4686>, there would be a fpm mechanism to *turn on* the legacy external interface. — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR2X3DVRDZEFKLPUV4TWHN7BTANCNFSM5ZGG4LOA> . You are receiving this because you commented.Message ID: ***@***.***>

[ivan-pi]

By API I was only referring to the standard Netlib interface (and associated behavior to an extent). Changing the formatting of messages is of course very welcome.

[arjenmarkus]

Aha, I misunderstood that :). Give me a bit of time to reformulate my answer. Op wo 9 nov. 2022 om 13:46 schreef Ivan Pribec ***@***.***>:

…

By API I was only referring to the standard Netlib interface (and associated behavior to an extent). Changing the formatting of messages is of course very welcome. — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR67G6FKDATNQZM4SITWHOMKDANCNFSM5ZGG4LOA> . You are receiving this because you commented.Message ID: ***@***.***>

[arjenmarkus]

I have not changed the argument lists of the routines and functions, the only aspect about the behaviour that I did change is what happens when the input does not agree with the constraints (and in some cases, what happens if no convergence is reached). The original code would print an error message and stop the program. I do not think that is quite appropriate for a library and the messaging was implemented via holleriths. My current version simply returns NaN if that happens. It is definitely feasible to print an error message if that is desired or to stop the program. I would use more modern mechanisms than the holleriths though. Op wo 9 nov. 2022 om 13:49 schreef Arjen Markus ***@***.***>:

…

Aha, I misunderstood that :). Give me a bit of time to reformulate my answer. Op wo 9 nov. 2022 om 13:46 schreef Ivan Pribec ***@***.***>: > By API I was only referring to the standard Netlib interface (and > associated behavior to an extent). Changing the formatting of messages is > of course very welcome. > > — > Reply to this email directly, view it on GitHub > <#76 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAN6YR67G6FKDATNQZM4SITWHOMKDANCNFSM5ZGG4LOA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >