Print scaling information about the user model#488
Print scaling information about the user model#488rapids-bot[bot] merged 5 commits intoNVIDIA:branch-25.10from
Conversation
|
/ok to test c8f810b |
|
/ok to test f9f07b5 |
| } | ||
|
|
||
| template <typename i_t, typename f_t> | ||
| i_t optimization_problem_t<i_t, f_t>::get_n_integers() const |
There was a problem hiding this comment.
If you compute the scaling info on problem_t we already have a method to compute integer info
There was a problem hiding this comment.
What's the difference between optimization_problem_t and problem_t? The reason why I did it on optimization_problem_t is because it only make sense to warn the user about poor scaling on their input. We don't want to warn if we transformed the problem and made it worse.
There was a problem hiding this comment.
problem_t is adapted to store more info and the modified problem. We could check before any transformation on problem_t here for lp: https://github.com/NVIDIA/cuopt/blob/branch-25.10/cpp/src/linear_programming/solve.cu#L823 and here for mip: https://github.com/NVIDIA/cuopt/blob/branch-25.10/cpp/src/mip/solve.cu#L195. This also work so it's not a blocker.
| } | ||
|
|
||
| template <typename i_t, typename f_t> | ||
| void optimization_problem_t<i_t, f_t>::print_scaling_information() const |
There was a problem hiding this comment.
Should it be printed by default? I am asking because for large problems since we are computing abs values on the host for many buffers and the coefficient matrix it could add some overhead.
There was a problem hiding this comment.
Well, I think we always need to check the scaling. In case it turns out to be bad. If we are worried about speed we could move it to the GPU.
|
/merge |
Print scaling information and issue a warning if the range of coefficients is greater than 10^6.
This PR also prints out problem size information before scaling information.
It also changes 'Running' to 'Reading' so that users understand that we are still reading the file.