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.
>
>