The gui will accept a radius_p lower than the minimum set value for the rapid rotator.

[bkloppenborg]

Hi @therob762 , is this from the user interface or from a save file? I am not able to replicate the issue in the GUI. Could you please elaborate on how you were able to generate this error?

[therob762]

Sorry, I am attempting to be better at adding more information. This is a gui issue where the nominal value is 1.0 and I change the minimum value to 1.5. Normally a window pops up that warns me that the nominal value is out of range, however not in this case. I have not attempted to reproduce this issue with a save file.

Peace, Rob

Hi @therob762 , is this from the user interface or from a save file? I am not able to replicate the issue in the GUI. Could you please elaborate on how you were able to generate this error?

---

Reply to this email directly or view it on GitHub: https://github.com/bkloppenborg/simtoi/issues/142#issuecomment-127054191

[bkloppenborg]

Ah ha. Ok. Bug confirmed. I'll fix this shortly.

[bkloppenborg]

Humm. I thought about this problem a little more last night and I'm not sure how we want to fix it. If I were to replicate the behavior that is presently in SIMTOI (namely the value must be in range of the specified min/max values), then we would get error messages every time the min/max parameters were changed. I see three options:

1) Leave it as-is and hope the user recognizes this error and corrects it. This should not be an issue for the minimization engines as most of them use the min/max bounds when searching (the only exception is Bootstrap Levmar which uses the values as a starting point... I can fix this issue though). 2) Emit error messages which revert any invalid changes (this would be very verbose and annoying) 3) Emit warning messages so the user can correct it (I think this would be similarly annoying) 4) Silently move the value to remain within [min,max] when the upper/lower bounds are changed.

@fabienbaron @therob762 , have you guys any preferred behavior?

[therob762]

I would say that I am not a fan of option 1 or 4. Option 1 might lead a user who is not as observant to spend an undue amount of time tracking down a problem that would have supplied an error anywhere else.

I generally do not like non-transparency in programs that doesn't require it. Again this could lead the user to wonder why changing the nominal value does nothing to the result of any minimization attempted. Granted this is probably the case anyway (if I took a serious look at the minimizers) but it still deludes the user somewhat.

As for options 2 & 3, I am not certain as to the functional difference between the two.

Peace, Rob

Sent from my iPhone

On Aug 3, 2015, at 9:40 AM, Brian Kloppenborg notifications@github.com wrote:

Humm. I thought about this problem a little more last night and I'm not sure how we want to fix it. If I were to replicate the behavior that is presently in SIMTOI (namely the value must be in range of the specified min/max values), then we would get error messages every time the min/max parameters were changed. I see three options:

1) Leave it as-is and hope the user recognizes this error and corrects it. This should not be an issue for the minimization engines as most of them use the min/max bounds when searching (the only exception is Bootstrap Levmar which uses the values as a starting point... I can fix this issue though). 2) Emit error messages which revert any invalid changes (this would be very verbose and annoying) 3) Emit warning messages so the user can correct it (I think this would be similarly annoying) 4) Silently move the value to remain within [min,max] when the upper/lower bounds are changed.

@fabienbaron @therob762 , have you guys any preferred behavior?

— Reply to this email directly or view it on GitHub.

[therob762]

Option 4 is the only choice that makes sense to me, and the way this is handled in most polished codes. Simtoi should print a warning on command line output when doing this.

On August 3, 2015 10:26:05 AM EDT, Rob Parks parksj@astro.gsu.edu wrote:

I would say that I am not a fan of option 1 or 4. Option 1 might lead a user who is not as observant to spend an undue amount of time tracking down a problem that would have supplied an error anywhere else.

I generally do not like non-transparency in programs that doesn't require it. Again this could lead the user to wonder why changing the nominal value does nothing to the result of any minimization attempted. Granted this is probably the case anyway (if I took a serious look at the minimizers) but it still deludes the user somewhat.

As for options 2 & 3, I am not certain as to the functional difference between the two.

Peace, Rob

Sent from my iPhone

On Aug 3, 2015, at 9:40 AM, Brian Kloppenborg notifications@github.com wrote:

Humm. I thought about this problem a little more last night and I'm not sure how we want to fix it. If I were to replicate the behavior that is presently in SIMTOI (namely the value must be in range of the specified min/max values), then we would get error messages every time the min/max parameters were changed. I see three options:

1) Leave it as-is and hope the user recognizes this error and corrects it. This should not be an issue for the minimization engines as most of them use the min/max bounds when searching (the only exception is Bootstrap Levmar which uses the values as a starting point... I can fix this issue though). 2) Emit error messages which revert any invalid changes (this would be very verbose and annoying) 3) Emit warning messages so the user can correct it (I think this would be similarly annoying) 4) Silently move the value to remain within [min,max] when the upper/lower bounds are changed.

@fabienbaron @therob762 , have you guys any preferred behavior?

— Reply to this email directly or view it on GitHub.

[therob762]

If the user is made aware what is happening, then I remove my objection to Option 4.

Peace, Rob

On Monday, August 03, 2015 02:30:55 PM Fabien Baron wrote:

Option 4 is the only choice that makes sense to me, and the way this is handled in most polished codes. Simtoi should print a warning on command line output when doing this. On August 3, 2015 10:26:05 AM EDT, Rob Parks parksj@astro.gsu.edu wrote:

I would say that I am not a fan of option 1 or 4. Option 1 might lead a user who is not as observant to spend an undue amount of time tracking down a problem that would have supplied an error anywhere else.

I generally do not like non-transparency in programs that doesn't require it. Again this could lead the user to wonder why changing the nominal value does nothing to the result of any minimization attempted. Granted this is probably the case anyway (if I took a serious look at the minimizers) but it still deludes the user somewhat.

As for options 2 & 3, I am not certain as to the functional difference between the two.

Peace, Rob

Sent from my iPhone

On Aug 3, 2015, at 9:40 AM, Brian Kloppenborg

notifications@github.com wrote:

Humm. I thought about this problem a little more last night and I'm

not sure how we want to fix it. If I were to replicate the behavior that is presently in SIMTOI (namely the value must be in range of the specified min/max values), then we would get error messages every time

the min/max parameters were changed. I see three options:

1) Leave it as-is and hope the user recognizes this error and

corrects it. This should not be an issue for the minimization engines as most of them use the min/max bounds when searching (the only exception is Bootstrap Levmar which uses the values as a starting point... I can fix this issue though).

2) Emit error messages which revert any invalid changes (this would

be very verbose and annoying)

3) Emit warning messages so the user can correct it (I think this

would be similarly annoying)

4) Silently move the value to remain within [min,max] when the

upper/lower bounds are changed.

@fabienbaron @therob762 , have you guys any preferred behavior?

— Reply to this email directly or view it on GitHub.

J. Robert Parks Sponsored Funded Professional Astronomer Department of Physics & Astronomy Georgia State University 25 Park Place South Room# 615 Atlanta, GA 30303 404-413-6081