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

[ParU] Use boolean and enum types instead of integers #597

Open
gruenich opened this issue Dec 17, 2023 · 2 comments
Open

[ParU] Use boolean and enum types instead of integers #597

gruenich opened this issue Dec 17, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@gruenich
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The interface as defined by ParU.hpp uses signed integer int64_t where boolean or enum types would be better.
Example for variables that should be boolean: ParU_Control->scale, Examples for variables that should be enums: ParU_Symbolic->strategy, ParU_Control->paru_strategy`

Describe the solution you'd like
Introduce boolean and enum types. Technically, this is an interface change and should happen before releasing SuiteSparse 7.4.0. Internally, more changes like the named above might improve readability and semantic.

Describe alternatives you've considered
Sticking to the way it is.

Additional context
Overall, the interface follows a C style, less C++ way of doing an interface.

@DrTimothyAldenDavis
Copy link
Owner

Thanks for the feedback. Yes, the API does need some polishing. That's why I've tagged it as 0.1.0, since the API will change soon. I plan to spend some time rethinking the interface after I release Suitesparse 7.4.0. I think it needs more work than just the integer/ bool types though. Those do need some rework as you've pointed out. But it's likely I will make more changes.

If I make these changes for ParU 0.1.0 that you suggest, I will probably find more API breaking changes to make when I get the time to polish it for a 1.0.0
release.

So my preference is to release it as is and rewrite the API later

@DrTimothyAldenDavis
Copy link
Owner

I'll leave this issue open though, so I don't forget any of your suggestions.

@DrTimothyAldenDavis DrTimothyAldenDavis added the enhancement New feature or request label Dec 21, 2023
@DrTimothyAldenDavis DrTimothyAldenDavis self-assigned this Dec 21, 2023
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

2 participants