Skip to content

Conversation

@chris-maes
Copy link
Contributor

@chris-maes chris-maes commented Oct 13, 2025

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.

@chris-maes chris-maes requested a review from a team as a code owner October 13, 2025 20:47
@chris-maes chris-maes requested review from nguidotti and rg20 October 13, 2025 20:47
@copy-pr-bot
Copy link

copy-pr-bot bot commented Oct 13, 2025

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@chris-maes chris-maes added non-breaking Introduces a non-breaking change improvement Improves an existing functionality labels Oct 13, 2025
@chris-maes chris-maes added this to the 25.10 milestone Oct 13, 2025
@chris-maes
Copy link
Contributor Author

/ok to test c8f810b

@chris-maes
Copy link
Contributor Author

/ok to test f9f07b5

@rgsl888prabhu rgsl888prabhu requested a review from hlinsen October 13, 2025 22:02
}

template <typename i_t, typename f_t>
i_t optimization_problem_t<i_t, f_t>::get_n_integers() const
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you compute the scaling info on problem_t we already have a method to compute integer info

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rgsl888prabhu
Copy link
Collaborator

/merge

@rapids-bot rapids-bot bot merged commit 83ec311 into NVIDIA:branch-25.10 Oct 14, 2025
173 of 174 checks passed
@chris-maes chris-maes deleted the print_scaling branch October 14, 2025 02:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants