Simplified boundary enforcement by gpampara · Pull Request #283 · ciren/cilib

gpampara · 2018-05-13T15:26:54Z

These changes build on the contribution by @KyleErwin, but instead attempt to simplify
the usage/enforcement of boundary constraints by just letting the strategies be functions passed
to an enforce function.

The usage within Step etc is not part of these changes, albeit trivial. It shouldn't be
needed to provide these functions, but if needed they will be added in a separate PR.

KyleErwin

This looks really great. Especially seeing how the code as evolved since the first iteration of bchms. The enforce and eforceTo methods are also really clever. Will definitely help in the long run.

filinep · 2018-05-14T07:31:51Z

+  def clamp[A](implicit N: spire.math.Numeric[A]) =
+    (a: A, b: Interval[Double]) =>
+      if (N.toDouble(a) > b.lowerValue) N.fromDouble(b.upperValue)
+      else if (N.toDouble(a) < b.upperValue) N.fromDouble(b.lowerValue)


Shouldn't this be if a > upperValue and a < lowerValue?

filinep · 2018-05-14T07:36:19Z

+      if (b.contains(N.toDouble(a))) a else N.fromAlgebraic((b.upperValue + b.lowerValue) / 2.0)
+
+  def reflect[A](implicit N: spire.math.Numeric[A]) =
+    (a: A, b: Interval[Double]) => if (b.contains(N.toDouble(a))) a else -a


What happens if b does not contain -a?

You're right. I just did a plain translation of the original code. I'll check what we did in the java version - I know it was right there - and port the logic over.

gpampara · 2018-05-15T09:27:50Z

@filinep Please can you comment on the new changes. I think that they are more sane now :)

filinep · 2018-05-15T09:34:16Z

+        val z = N.toDouble(a)
+
+        if (z < b.lowerValue) N.fromDouble(b.lowerValue - (z - b.lowerValue))
+        else if (z > b.upperValue) N.fromDouble(b.upperValue - (z - b.upperValue))


What about cases where the reflection makes it go passed the other bound? e.g. b=(5,6) a=3 the reflected value is 7

Looking at some more literature, the paper I originally was basing these equations off of, was actually wrong. The equation has been adjusted and some tests have been added to ensure that they are correctly within the bounds.

filinep · 2018-05-15T09:45:48Z

+        val z = N.toDouble(a)
+
+        if (z < b.lowerValue) N.fromDouble(b.lowerValue + (z - b.lowerValue))
+        else if (z > b.upperValue) N.fromDouble(b.upperValue + (z - b.upperValue))


If I understand this correctly, shouldn't the logic be
if (z < lowerValue) upperValue - (z - lowerValue) else if (z > upperValue) lowerValue - (z - upperValue) else z
You have to come from the other side instead of the same side it has gone over.

Yip, exactly right - it does an environment "wrap", kinda like the old platform games.

filinep · 2018-05-16T08:42:55Z

+  implicit def fooGen = Arbitrary {
+    for {
+      i <- intervalGen
+      range = math.abs(i.upperValue - i.lowerValue) * 0.4


Using 0.4 never generates the breaking example I gave above if b=(5,6) and a=3, this case still breaks the equation.

I think it needs to be at least 2 times the range

This is a fundamental issue with this boundary mechanism. Do we just keep reflecting until the value is in range? Does that even make sense? I've not seen such an adjustment in anything that I've read so far.

Hehe, I guess you can keep reflecting, it's similar to what the periodic one does with the mod.

Yeah, that's the only thing that could possibly work... seems a little strange though. I guess it can't be too bad then, because the point of the schemes to to bring something back into the valid search space. They all make the assumption that the initial starting point is within the bounds.

filinep · 2018-05-17T07:37:51Z

+
+        val result =
+          if (z < b.lowerValue) N.fromDouble(b.lowerValue + (b.lowerValue - z) % range)
+          else if (z > b.upperValue) N.fromDouble(b.upperValue - (z - b.upperValue) % range)


I pictured reflection to bounce between the upper and lower bound until it's valid. To do that you'd need to know how many bounces to do to know whether to come from the lower or upper side. But since we don't know how reflection is supposed to be dealt with if it's still out of bounds I'll approve it. I'll review again if you decide to change it.

Yip, indeed. During the testing, there was a point generated with and exponent of E208 but the interval was far far smaller. it would have taken hours to reduce to the interval.

True, but wouldn't it be possible to calculate how many bounces with a mod, instead of using a recursive function?

Yes, it should be - as long as the function is decreasing to ensure a solution.

filinep

I have a feeling reflect can be done with one equation but this looks good to me

This new scheme now allows for a context for a given boundary handling mechanism. Some of the strategies require that the new value is randomly initialized between the domain bounds.

The reflect strategy behaves a bit strangely. It will work correctly until the value is: > 2*range of domain If the value is larger, the resulting value will _still_ be outside the feasible range of the problem space. This change will essentially ignore and then shrink the value so that it is within the 2*range before doing the reflect back into the feasible space. It is not clear if this is _valid_, however, in the normal usage case this shrinking behaviour would never be done.

* Added a few bchms * Generic methods * Formating * flatten for tuples * Moved to a nchm object in Entity * Removed tuple flatten * scalafmt * No partial functions * if statements * Simplify boundary constraints to be plain functions * Cleanup (more) of functions * Some more cleanup * Simplify bondary enforcement to a single function * Adjust structures to make inference by compiler better This new scheme now allows for a context for a given boundary handling mechanism. Some of the strategies require that the new value is randomly initialized between the domain bounds. * Correct deployment branch: series/2.0.x -> master * Add tests for boundary enforcement and correct toroidal scheme * Adjust reflect to consider the offending portion only The reflect strategy behaves a bit strangely. It will work correctly until the value is: > 2*range of domain If the value is larger, the resulting value will _still_ be outside the feasible range of the problem space. This change will essentially ignore and then shrink the value so that it is within the 2*range before doing the reflect back into the feasible space. It is not clear if this is _valid_, however, in the normal usage case this shrinking behaviour would never be done. * Correct formatting * Continuous reflecting until within range * Scalafmt changes Co-authored-by: Kyle Erwin <kyle.erwin24@gmail.com>

gpampara requested review from KyleErwin, filinep, robgarden and stefanvds May 13, 2018 15:26

gpampara mentioned this pull request May 13, 2018

Boundary Constraint Handling Mechanisms #274

Closed

KyleErwin approved these changes May 13, 2018

View reviewed changes

gpampara force-pushed the simplified-enforcement branch from 65722f7 to 2d4c323 Compare May 13, 2018 16:45

filinep reviewed May 14, 2018

View reviewed changes

filinep reviewed May 15, 2018

View reviewed changes

filinep reviewed May 16, 2018

View reviewed changes

filinep previously approved these changes May 17, 2018

View reviewed changes

gpampara dismissed filinep’s stale review via 2a73e48 May 18, 2018 04:05

filinep previously approved these changes May 18, 2018

View reviewed changes

KyleErwin and others added 16 commits May 18, 2018 08:43

Added a few bchms

948c3a7

Generic methods

412ccf0

Formating

49cf33a

flatten for tuples

d328f4f

Moved to a nchm object in Entity

d849795

Removed tuple flatten

e7679b0

scalafmt

72da0f0

No partial functions

b9778bb

if statements

7d7631c

Simplify boundary constraints to be plain functions

ebccc4e

Cleanup (more) of functions

badd47a

Some more cleanup

76f3dbb

Simplify bondary enforcement to a single function

ceb7b5a

Adjust structures to make inference by compiler better

32bd702

This new scheme now allows for a context for a given boundary handling mechanism. Some of the strategies require that the new value is randomly initialized between the domain bounds.

Correct deployment branch: series/2.0.x -> master

0e760b1

Add tests for boundary enforcement and correct toroidal scheme

a9f9a24

gpampara added 4 commits May 18, 2018 08:43

Correct formatting

6c7573c

Continuous reflecting until within range

192592a

Scalafmt changes

3d33777

gpampara dismissed filinep’s stale review via 3d33777 May 18, 2018 06:43

gpampara force-pushed the simplified-enforcement branch from 7ac4a97 to 3d33777 Compare May 18, 2018 06:43

Merge branch 'master' into simplified-enforcement

64d4464

filinep approved these changes May 18, 2018

View reviewed changes

gpampara merged commit 59c6175 into ciren:master May 18, 2018

gpampara deleted the simplified-enforcement branch May 18, 2018 07:02

Conversation

gpampara commented May 13, 2018

Uh oh!

KyleErwin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gpampara commented May 15, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gpampara May 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

filinep May 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gpampara May 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

filinep left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

gpampara May 16, 2018 •

edited

Loading

filinep May 15, 2018 •

edited

Loading

gpampara May 16, 2018 •

edited

Loading