mosek_direct.py : Fixed iparam parsing and added support for Task.putparam

[Utkarsh-Detha]

Fixes:

In _apply_solver

• Call to putintparam was missing in the isinstance(option, str) conditional when parsing iparam. Fixed.
• Was calling option.pop('mosek') instead of option.pop(0) within the same conditional. Fixed.

Summary/Motivation:

A user wanted to be able to pass the value of ALL parameters as strings. MOSEK's optimizer API supports this through the Task.putparam function, which accepts a parameter name (string) and a value (also string).

Changes proposed in this PR:

• Users may pass string values to any parameter (SPAR, DPAR, IPAR) as long as they use generic parameter names

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[mrmundt]

@Utkarsh-Detha - please run black -S -C on your branch (with the newest version of black)

[Utkarsh-Detha]

Thank you for the review, @mrmundt . I ran the formatter as you recommended, with the newest version thereof.

[blnicho]

@Utkarsh-Detha could you add a couple tests for these changes?

[mrmundt]

@Utkarsh-Detha - Pinging again about this! Could you please add in some tests?

[jsiirola]

Overall this looks reasonable, but could be improved by some defensive checks. In addition, it would be good to test this functionality thought the unit tests.

[Utkarsh-Detha]

@blnicho @mrmundt sorry for the delay in getting this done. I have now added a few unit tests to check the parameter adding functionality. Feel free to suggest any corrections/changes. Thank you for your help.

[Utkarsh-Detha]

@jsiirola I am starting to wonder if I should simply remove the option of allowing strings as iparam values. The idea initially was to allow users to pass MOSEK enums as strings, for example mosek.onoffkey.off. But I now think that it is more straightforward to just pass the option value directly to MOSEK, which would raise a TypeError if wrong input type is provided. As this would mean removing functionality, I wanted your opinion. (Lmk if I should rather open an Issue to discuss this)

[jsiirola]

I think this is really close. It would be good to add one extra check and clarify the error message. If you have a chance to address this in the next couple hours, great - otherwise I may try and push to this branch and try to squeeze it into tomorrow's release.

[jsiirola]

@Utkarsh-Detha Good question. I don't have a strong opinion on supporting strings for iparam. However, this is a "core" solver: if you want to remove it, I think we we would need to put in a deprecation path for several releases before deleting the functionality completely.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.75%. Comparing base (6f2a50e) to head (86ec82c).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3488      +/-   ##
==========================================
+ Coverage   88.73%   88.75%   +0.02%     
==========================================
  Files         890      890              
  Lines      102207   102209       +2     
==========================================
+ Hits        90692    90715      +23     
+ Misses      11515    11494      -21     

Flag	Coverage Δ
builders	26.62% <0.00%> (+<0.01%)	⬆️
default	84.86% <100.00%> (?)
expensive	34.00% <0.00%> (?)
linux	86.24% <0.00%> (-2.24%)	⬇️
linux_other	86.24% <0.00%> (-0.01%)	⬇️
osx	82.84% <0.00%> (-0.01%)	⬇️
win	84.74% <0.00%> (-0.01%)	⬇️
win_other	84.74% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Utkarsh-Detha]

@jsiirola I also added/changed some tests to check if the correct exceptions are raised in case wrong types are passed for values of params. If a "str" type is passed to iparam but the name is recognized as a valid MOSEK enum, then an AttributeError is raised, which is also tested for in the tests. Let me know if you don't think this is a reasonable approach. Thanks for your help on this.