Hi Jeff, Do you have further questions? Thanks Gui Haochen
在 2024/7/24 6:39, Andrew MacLeod 写道: > > On 7/23/24 15:18, Jeff Law wrote: >> >> >> On 7/11/24 9:17 PM, HAO CHEN GUI wrote: >> >>>> So why the test for real_isinf on the upper/lower bound? If op1 is known >>>> to be a NaN, then why test the bounds at all? If a bounds test is needed, >>>> why only test the upper bound? >>>> >>> IMHO, logical is if the op1 is a NAN, it's not an infinite number. If the >>> upper >>> and lower bound both are finite numbers, the op1 is not an infinite number. >>> Under both situations, the result should be set to 0 which means op1 isn't >>> an >>> infinite number. >> Understood, but that's not what the code actually implements: >> >>>>> + if (op1.known_isnan () >>>>> + || (!real_isinf (&op1.lower_bound ()) >>>>> + && !real_isinf (&op1.upper_bound ()))) >>>>> + { >>>>> + r.set_zero (type); >>>>> + return true; >>>>> + } >> If op1 is a NaN, then it it can not be Inf. Similarly if both of the bounds >> are known not to be Inf, then op1 is not Inf and thus we should be returning >> false instead of true. Or am I mis-understanding this API? >> >> > the range is in r, and is set to [0,0]. this is the false part of what is > being returned for the range. > > the "return true" indicates we determined a range, so use what is in R. > > returning false means we did not find a range to return, so r is garbage. > >