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

Reply via email to