Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide precision-preserving edit descriptors #570

Closed
milancurcic opened this issue Nov 18, 2021 · 2 comments · Fixed by #617
Closed

Provide precision-preserving edit descriptors #570

milancurcic opened this issue Nov 18, 2021 · 2 comments · Fixed by #617
Labels
API Discussion on a specific API for a proposal (exploratory) enhancement New feature or request good first issue Good for newcomers idea Proposition of an idea and opening an issue to discuss it topic: IO Common input/output related features

Comments

@milancurcic
Copy link
Member

Motivation

In #505 @epagone proposed:

Considering that these formats are more useful than only for savetxt and loadtxt, would it make sense to make them available on their own in stdlib_io and simply use them? I am thinking, for example, of any sort of I/O where round-trip accuracy is required (e.g. writing to a CSV, JSON, TOML, YAML, etc...) to override a default behaviour that might be less strict.

Prior Art

Currently the formats used for savetxt and loadtxt are private to the stdlib_io and not usable from the outside:

! Format strings with edit descriptors for each type and kind
character(*), parameter :: &
FMT_INT = '(*(i0,1x))', &
FMT_REAL_SP = '(*(es15.8e2,1x))', &
FMT_REAL_DP = '(*(es24.16e3,1x))', &
FMT_REAL_XDP = '(*(es26.18e3,1x))', &
FMT_REAL_QP = '(*(es44.35e4,1x))', &
FMT_COMPLEX_SP = '(*(es15.8e2,1x,es15.8e2))', &
FMT_COMPLEX_DP = '(*(es24.16e3,1x,es24.16e3))', &
FMT_COMPLEX_XDP = '(*(es26.18e3,1x,es26.18e3))', &
FMT_COMPLEX_QP = '(*(es44.35e4,1x,es44.35e4))'

They work with scalars and arrays alike:

print FMT_REAL_DP, 1.23d0
print FMT_REAL_DP, [1.23d0, 4.56d0]

outputs

 1.2300000000000000E+000
 1.2300000000000000E+000  4.5599999999999996E+000

So it seems to me that the solution could be to make the existing constants public. @epagone @certik do you foresee any scenario where it wouldn't work?

Additional Information

@epagone would you like to submit a PR for this?

@milancurcic milancurcic added enhancement New feature or request good first issue Good for newcomers idea Proposition of an idea and opening an issue to discuss it API Discussion on a specific API for a proposal (exploratory) topic: IO Common input/output related features labels Nov 18, 2021
@certik
Copy link
Member

certik commented Nov 18, 2021

I think this might work and should cover the use cases I had in mind. I initially thought to have just es15.8e2, but the full format string is even easier for the end user.

@epagone
Copy link

epagone commented Nov 19, 2021

@milancurcic I am quite tight on time for the next few weeks but if it not urgent, I am happy to give it a try. On the other hand, if you or someone else wants to go ahead, I am happy too (I am eager to complete first a fpm PR already assigned to me).

PS: I know it's a trivial PR but my GitHub development skills are very rusty and I can use it only very occasionally so I need to re-learn all the command line steps every time, so the time investment in my case is non-trivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Discussion on a specific API for a proposal (exploratory) enhancement New feature or request good first issue Good for newcomers idea Proposition of an idea and opening an issue to discuss it topic: IO Common input/output related features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants