You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
Fixesciren#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.
Fixesciren#287
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.
The text was updated successfully, but these errors were encountered: