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
The documentation for optimizerFORCES shows a second return argument success which is not used consistently throughout. Some problems are handled by throwing an error(...) (which leaves success unset), others use disp to show a message and set success = 0.
Since success is initialized as 1 I suspect potential for misreporting success, e.g. in cases where no error is thrown but success is not re-set or if it is set multiple times.
Due to the high complexity in optimizerFORCES I find it preferable to throw an error as soon as a game-breaking issue occurs, e.g. a model incompatible with FORCES Pro. success should exactly mirror the return argument of generateCode in FORCES Pro.
The text was updated successfully, but these errors were encountered:
What you described is already implemented. success is the result of combining all of the success outputs of the internal solvers (combined using logical AND). However, if one of the internal solvers couldn't be generated, an error is thrown by optimizerFORCES. disp was only used for the case that the user decided to cancel code generation after being asked about binary variables. I fixed that with commit b70630f. Instead of using disp to display the error message and returning an empty object, an actual error is thrown.
So, now, if optimizerFORCES returns a object (hence no error was thrown), success is always 1. It could be removed as output argument because it doesn't help the user.
The documentation for
optimizerFORCES
shows a second return argumentsuccess
which is not used consistently throughout. Some problems are handled by throwing anerror(...)
(which leavessuccess
unset), others usedisp
to show a message and setsuccess = 0
.Since
success
is initialized as1
I suspect potential for misreporting success, e.g. in cases where noerror
is thrown butsuccess
is not re-set or if it is set multiple times.Due to the high complexity in optimizerFORCES I find it preferable to throw an
error
as soon as a game-breaking issue occurs, e.g. a model incompatible with FORCES Pro.success
should exactly mirror the return argument ofgenerateCode
in FORCES Pro.The text was updated successfully, but these errors were encountered: