Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
update strnum to handle valx functionality, and remove valx #406
update strnum to handle valx functionality, and remove valx #406
Changes from all commits
93c0b55
de6a8a9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why strsuc? Can't trim() do this already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at my new strsuc in this PR (where I've completely rewritten it and migrated it to F90), you'll see that it now does nothing more than call the intrinsic functions adjustl and len_trim ;-)
It's true that, after having done that, I could have just done away with strsuc altogether and just called adjustl and len_trim directly from within strnum.F90. But then I'd have to do likewise in a bunch of different subprograms in the library which also call strsuc, so I decided (again, just IMHO) to do it this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If non-numeric characters are in the string, won't this fail? In which case, why try to detect non-numeric characters? Why not just try to read and if there is a failure, report a failure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, the prior
verify
check was a cleaner and clearer way to confirm that str2(1:lens) contained only valid characters, and in such cases to go ahead and report the failure by setting iret to a value of -1.That said, I certainly could change this to add an err= option to the read statement and have it reroute control to a new numbered statement to set iret = -1 and return that way, if you and/or Jack think that would be a better way to do it. Again, this was just my personal preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I just saw your #409 (sorry, it's hard keeping track of all of these overlapping conversations and PR's flying around ;-)
So I take it you would indeed prefer that I just modify the new strnum.F90 to add an iostat= check to the read and remove the verify check, and I see where you've already included some very thorough strnum testing in test_misc.F90, so I'll go ahead and remove my less thorough tests from intest7.F90 as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to reduce code to the smallest amount that can meet current requirements. This is the lowest cost for NOAA over the long term, and the least amount of work for us.
So if using iostat can save us a few lines of code, those are lines NOAA does not have to pay for. Recall that maintenance costs for a line of code are an order of magnitude more than the cost to write the line of code. Code is not free to keep, it's like owning a horse - it costs a lot of money even if you don't use it much.
We must always prefer the solution that meets current requirements with the least lines of code.
This file was deleted.
This file was deleted.