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

add type hints (Experimental) #755

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

CubeSugarCheese
Copy link

#650

This pr still incomplete, some functions are hard to type, like LpVariable.matrix and LpVariable.dicts.
And lots of usage of cast and # type: ignore to adapt old code base (some replace by not None assert).

@CLAassistant
Copy link

CLAassistant commented May 29, 2024

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@pchtsp pchtsp left a comment

Choose a reason for hiding this comment

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

sorry for the delay.
I've checked around half.

Many things look good. Many others require careful investigation. I'm particularly skeptic on the large Union types you have for some of the other arguments.

In some places you're changing the behavior of the code (True instead of 0)

You use casting a lot. I'm not sure if it's really required if we're correctly defining the types. Also, there are some ignore that I believe should not be needed with the correct typing.

You're also cleaning a lot of compatibility code (which is fine) but I'm not sure if that's breaking something. Could you at least comment on the pieces of code you're taking out?

Comment on lines +289 to +312
) -> Tuple[
int,
int,
int,
int,
int,
"Array[c_double]",
c_double,
"Array[c_double]",
"Array[c_double]",
"Array[c_char]",
Any,
Any,
Any,
Any,
"Array[c_double]",
"Array[c_double]",
"Array[c_double]",
"Array[c_char_p]",
"Array[c_char_p]",
"Array[c_char]",
Dict[int, "LpVariable"],
Dict[Any, Any],
]:
Copy link
Collaborator

Choose a reason for hiding this comment

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

can you define this type outside and then use it here? it's too big to be readable

Copy link
Author

Choose a reason for hiding this comment

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

I think ok. we can define a type alias in other file and import to use at this.

"""
uses existing problem information and solves the problem
If it is not implemented in the solver
just solve again
"""
self.actualSolve(lp, **kwargs)

def copy(self):
def copy(self) -> "Self":
Copy link
Collaborator

Choose a reason for hiding this comment

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

Self works here? shouldn't we put LpSolver?

"LpAffineExpression", "LpVariable", "LpConstraintVar", int, float, None
],
) -> "LpAffineExpression":
self = cast(Union[LpVariable, LpConstraintVar], self)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why is the cast necessary? doesn't LpAffineExpression accept LpElement?

Comment on lines +1008 to +1021
other: Union[
"LpAffineExpression",
Dict[LpVariable, Union[int, float]],
List[
Union["LpAffineExpression", LpVariable, "LpConstraintVar", int, float]
],
Iterable[LpVariable],
LpVariable,
"LpConstraintVar",
int,
float,
None,
],
) -> "LpAffineExpression":
Copy link
Collaborator

Choose a reason for hiding this comment

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

this other is repeated in several places. (1) I'm not sure it's correct (2) if it is, we should create it once and re-use it

Comment on lines -1306 to +1758
self.constraints = _DICT_TYPE()
self.constraints = dict()
Copy link
Collaborator

Choose a reason for hiding this comment

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

why the change? it's the same I believe

Comment on lines -1313 to +1765
self.noOverlap = 1
self.noOverlap = False
Copy link
Collaborator

Choose a reason for hiding this comment

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

this changes the code. Shouldn't it be True?

Copy link
Author

Choose a reason for hiding this comment

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

Sorry, it should be True.

Comment on lines -1325 to +1777
self.lastUnused = 0
self.lastUnused = True
Copy link
Collaborator

Choose a reason for hiding this comment

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

False?


# constraints
# we change the names for the objects:
def edit_const(const):
const = dict(const)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why are you taking out the shallow copy?

@CubeSugarCheese
Copy link
Author

Thanks for your review.

At first, I think I can typed this lib suitably. But after some research, I'm got a discouraged.
There many imprecision in old code, for example.

  1. Some place use implicit cast to bool to check None, it cant be understand by typechecker. And many places use literal 1 and 0 as bool, and some place use bool literal in the same time. they all come from [803c3d3], a 12 years ago commit. I dont know why, after search this keyword in all place just use as bool, I replace it as bool.
  2. Some place check None and some place not check in the same object/attr, even they init by None.
  3. Some recursive algorithm hard to typed.
  4. LpElement is inherited by LpVariable and LpConstraintVar, but almost all code assume a LpElement object must be LpVariable or LpConstraintVar, it violating the rules of the subtype system, so all LpElement replaced by Union[LpVariable, LpConstraintVar].

Sorry, the workload for this task far exceeds my estimation. In contrast, the benefits obtained from typed are too low. Now I no longer have courage and energy to modify these codes.
Perhaps the only feasible way to type this lib is to start writing from scratch. So that we can let go of the burden of compatibility.

You can close this pr.
Sorry again.

@pchtsp
Copy link
Collaborator

pchtsp commented Jul 17, 2024

Thank you for your efforts though! With your permission I will branch your code and I will try to make it compatible. I understand the pains of dealing with legacy code. I was not in this project at the time and it's definitely a challenge also for me.

I'm confident that I can make something useful with the work you have. Thanks again for the help!

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

Successfully merging this pull request may close these issues.

3 participants