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

Prevent invalid usages of Objective and Position #287

Closed
gpampara opened this issue Jun 28, 2018 · 1 comment
Closed

Prevent invalid usages of Objective and Position #287

gpampara opened this issue Jun 28, 2018 · 1 comment
Assignees
Labels
bug Something isn't working
Milestone

Comments

@gpampara
Copy link
Member

It's possible to allow the user to destructure Position into the constructors. This can cause problems where the needed functions already exist to allow this usage, but in a controlled fashion. Position is a very critical structure, which should always be managed by the Position functions and not changed externally. The fact that a Position transitions between Point and Solution should be irrelevant to the usage. The same can be said for Objective.

Although some of the lenses provided in the library for data access are convenient, they unfortunately provide a loophole with some logic as they are implemented at the moment. For example: it should be impossible to change the objective of a position - but you actually can right now with how the lenses are defined. In some lenses the "setter" portion is simply not valid. Such lenses should be reworked to be Getter instances, or removed.

Furthermore, this scalac bug is extremely troublesome for us.

@gpampara gpampara added the bug Something isn't working label Jun 28, 2018
@gpampara gpampara added this to the 2.1.0 milestone Jun 28, 2018
@gpampara gpampara self-assigned this Jun 28, 2018
@gpampara
Copy link
Member Author

gpampara commented Jul 3, 2018

The planned changes are currently located within gpampara/cilib@151a93e64

gpampara added a commit to gpampara/cilib that referenced this issue Jul 15, 2018
The objective code was only considering data that _had_ a fitness
value already assigned. Unfortunately this is a partial solution so
this commit adds the needed changes to allow `Infeasible`, `Adjusted`
and `Feasible` sum cases to be compared against each other.

The test cases for `Fitness` have also have a significant overhaul to
ensure that the various cases are arbitrarily created and compared
against each other.

Fixes ciren#287
gpampara added a commit to gpampara/cilib that referenced this issue Aug 5, 2018
The objective code was only considering data that _had_ a fitness
value already assigned. Unfortunately this is a partial solution so
this commit adds the needed changes to allow `Infeasible`, `Adjusted`
and `Feasible` sum cases to be compared against each other.

The test cases for `Fitness` have also have a significant overhaul to
ensure that the various cases are arbitrarily created and compared
against each other.

Fixes ciren#287
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant