Fix for issue #620 #635
Fix for issue #620 #635
Conversation
…ion by zero and apply regularization to avoid extremely large results in exponentiation when the base is too small.
|
You are missing another error in this PR.
|
|
For which problem do you get this error? That would help me debugging the code |
This: https://gist.github.com/muazhari/deed94f293489e95a75e95c057f5e98f |
|
On my machine, I don't get that error. I have also tried with different seeds |
|
Another error again in this: https://gist.github.com/muazhari/0825646b3767402b1899881836b36c42 I don't know if mixed variable modification to the GA algorithm is interoperable with agemoea2. I think it should because it uses the same abstraction in the superset class (GA), and is not specific to agemoea2. |
damn, how? My machine is currently a bit random as in my last GitHub issues to Pymoo, wsl, and Ray. Is it because intel stability issue? haha. |
I tried to run 3 times and still got the same error. Can you try to execute in different log levels? Or make sure the stdout/stderr not obstructed? |
I also don't get this error on my machine (M3 Mac). But the last commit should consider/handle division with NaN and Inf value. This should prevent the error you have. Actually, I am looking at the stack trace you have. It seems you are not using the code after my commits as the line |
My bad. After ensuring to use your latest commit, both gists above did not display any errors. |
Sorry, this first gist still has an error (the second gist is fixed). I don't know why the stack trace can't be displayed to the stdout when using logger/try-catch. After I removed it, the stack trace displayed the error. Please rerun the modified gist. |
It should be fixed with the last commit |
|
In the second gist (https://gist.github.com/muazhari/0825646b3767402b1899881836b36c42), comes another warning: |
|
The last two commits should fix the issues in both gits. Let me know if you encounter more issues |
| @@ -209,7 +215,7 @@ def compute_geometry(front, extreme, n): | |||
| return p | |||
|
|
|||
| @staticmethod | |||
| @jit(fastmath=True) | |||
| #@jit(nopython=True, fastmath=True) | |||
There was a problem hiding this comment.
Is it true to commenting this line?
| def find_zero(point, n, precision): | ||
| x = 1 | ||
|
|
||
| epsilon = 1e-10 # Small constant for regularization |
There was a problem hiding this comment.
Can we use the epsilon of the numpy data type for consistency and precision? example: np.finfo(point.dtype).eps
| # Replace very small norms with 1 to prevent division by zero | ||
| nn[nn < 1e-8] = 1 | ||
|
|
||
| distances = self.pairwise_distances(front, p) | ||
| distances[distances < 1e-8] = 1e-8 # Replace very small entries to prevent division by zero |
There was a problem hiding this comment.
Can we use the epsilon of the numpy data type for consistency and precision? example: np.finfo(nn.dtype).eps and np.finfo(distances.dtype).eps.
|
I have merged the code for now. Please open a new PR if another fix is needed. |
|
Thanks @apanichella for taking care of it! |
This PR fixes the error in issue #620
The previous implementation can lead to division by zero or extremely large exponential values that can lead to overflow problems for constrained problems.
This PR fixes these errors as follows:
point[obj_index]before raising it to the power ofx. This prevents the base of the exponentiation from becoming too small, which can lead to extremely large results whenxis large.denominator) or the derivative (ff) is zero, the function returns a fallback value to avoid division by zero.