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

Test CUTEst with 64-bit integer #53

Open
amontoison opened this issue Jun 18, 2024 · 6 comments
Open

Test CUTEst with 64-bit integer #53

amontoison opened this issue Jun 18, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@amontoison
Copy link
Member

@jfowkes @nimgould
What can we do to test CUTEst with 64-bit integer?
Can we add some tests here?

@amontoison amontoison added the enhancement New feature or request label Jun 18, 2024
@nimgould
Copy link
Contributor

There are already in64 tests for the makefile system. Myaybe @jfowkes can extend them to meson?

@jfowkes
Copy link
Contributor

jfowkes commented Jun 18, 2024

@nimgould you would need to add an option to use 64bit integers to the runcutest script first.

@nimgould
Copy link
Contributor

I will have a look

@nimgould
Copy link
Contributor

OK, this is a major undertaking. Firstly, sifdecode will have to be rewritten (extended)
to generate elfuns (etc) with 64 bit integer arguments if required. This will be a breaking fix, as
it will violate the presumption that these functions are standard fortran 77, as we
would need to use the iso-fortran module. OK, we could argue that nobody uses f77
anyway, but it would break that requirement.

Secondly, we would now have to have an extra set of suffices for the generated elfuns (etc),
i.e., elfuns_s_64. Again no big deal, except that every cutest function, and every interface,
would need to adapt (and to be checked that lines didn't break the 132 char limit).

And finally, the scripts would need to allow for an -64 (or something) flag (trivial).

But now ... is this really useful? No cutest example currently reaches the 32 bit limit, and
as nobody is generating new SIF files except for me, are we actually inventing a complication that is not needed? I am glad we moved to parameterised types, but is now the time to use them? Frankly I am exhausted by all of this software engineering, so if we do want to push this, perhaps someone else should lead?

Comments?

@jfowkes
Copy link
Contributor

jfowkes commented Jun 18, 2024

I personally see no need for this, the current 32bit integer CUTEst works just fine.

@amontoison
Copy link
Member Author

It's fine for me too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants