I observed a code clone from the following files. function : mpd_qexp @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4092)~4165 function : mpd_qln @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4525)~4612 In the first few lines of this clone, the function mpd_qexp only calls mpd_setspecial when mpd_isnegative is false while the function mpd_qln calls mpd_setspecial independent of the value of mpd_isnegative. I wonder the checking is necessary in the function mpd_qln. The source code is included in the attachment. Hope it helps.
The code looks fine to me. > In the first few lines of this clone, the function mpd_qexp only calls > mpd_setspecial when mpd_isnegative is false while the function mpd_qln > calls mpd_setspecial independent of the value of mpd_isnegative. That would probably be because exp(-infinity) is 0, which isn't a floating-point special value, and ln(-infinity) is NaN, which is. In general, I don't think this kind of report is terribly helpful unless you've also examined *and understood* the code, and based on that understanding you've established that there's a high likelihood of a real bug.
> That would probably be because exp(-infinity) is 0, which isn't a > floating-point special value, and ln(-infinity) is NaN, which is. Actually, looking at the code, mpd_setspecial is called under exactly the same circumstances (namely for +inf) in *both* cases; for -inf, the exp code calls _settriple, while the ln code calls mpd_seterror.
Mark has already said it all. -- Ken, I want to add that in the case of _decimal it's pretty easy to test any suspected misbehavior against decimal.py. This would have shown very quickly that there is no bug.
History
Date
User
Action
Args
2022-04-11 14:57:31
admin
set
github: 59312
2012-06-20 14:05:42
skrah
set
messages: +
2012-06-19 16:20:07
mark.dickinson
set
messages: +
2012-06-19 16:15:18
mark.dickinson
set
status: open -> closednosy: + mark.dickinson, skrahmessages: + resolution: not a bug
