Anonymous  Login  20191212 03:06 UTC 
Main  My View  View Issues  Change Log  Docs 
Viewing Issue Simple Details [ Jump to Notes ]  [ Issue History ] [ Print ]  
ID  Category  Severity  Type  Date Submitted  Last Update  
0000714  [1003.1(2013)/Issue7+TC1] System Interfaces  Editorial  Clarification Requested  20130618 00:54  20140325 13:43  
Reporter  nsz  View Status  public  
Assigned To  
Priority  normal  Resolution  Accepted As Marked  
Status  Interpretation Required  
Name  Szabolcs Nagy  
Organization  musl  
User Reference  
Section  yn  
Page Number  2297  
Line Number  72770  
Interp Status  Approved  
Final Accepted Text  Note: 0001658  
Summary  0000714: yn(n,0) is incorrect for odd n<0  
Description 
the return value description for y0, y1 and yn says: "If x is 0.0, HUGE_VAL shall be returned and a pole error may occur." "If the correct result would cause overflow, HUGE_VAL or 0.0 shall be returned and a range error may occur." this is fine for y0 and y1 but it is inconsistent with the mathematical definition of yn when n is negative and odd the sign is flipped according to yn(n,x) = (1)^n yn(n,x) or lim yn(n,x) = +Inf, for all n<0 and n%2==1 x>+0 it seems historical implementations got this wrong at x==0 eg. the original v7 implementation of yn starts with if (x <= 0) { errno = EDOM; return(HUGE); } but if x>0 and x is close to 0 then yn(odd,x) overflows and the mathematically reasonable +Inf is returned which is inconsistent with the description in posix (i assume most historical implementations work this way) 

Desired Action 
at least allow the +HUGE_VAL return value for yn(n,x) for odd negative n in case of overflow and x==0 

Tags  issue8  
Attached Files  

Notes  
(0001658) geoffclare (manager) 20130627 15:25 edited on: 20130919 15:28 
Interpretation response  The standard states that HUGE_VAL shall be returned, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale:  The standard does not match the mathematical behavior of yn(). Notes to the Editor (not part of this interpretation):  Make the changes in Note: 0001835 
(0001791) msbrown (manager) 20130905 15:22 
Reopening the issue based on this email exchange, for further discussion. we will be contacting Fred Tydeman for further assistance. nsz@port70.net wrote: * Vincent Lefevre <vincentopgr@vinc17.net> [20130827 18:02:40 +0200]: > and http://austingroupbugs.net/view.php?id=714 [^] proposes to fix this > by changing > > If x is 0.0, HUGE_VAL shall be returned and a pole error may occur. > > to: > > If x is 0.0, y0() and y1() shall return HUGE_VAL and a pole error > may occur. > If x is 0.0 and n is not both negative and odd, yn() shall return > HUGE_VAL and a pole error may occur. > If x is 0.0 and n is negative and odd, yn() shall return +HUGE_VAL > and a pole error may occur. > > (see Notes). > > There remain several issues with this: > > 1. Overflows should be taken into account too about the sign of > HUGE_VAL (as said in some parts of the bug report). > > 2. Why allowing 0.0 in case of overflow? I don't see a good reason > and this is unintuitive. IMHO, 0.0 should no longer be allowed, or > at least obsoleted. > yes it does not make sense i think this is the original yn implementation by robert h morris in v7 unix: http://minnie.tuhs.org/cgibin/utree.pl?file=V7/usr/src/libm/jn.c [^] the last loop does not exit when b becomes HUGE so it will become HUGE  HUGE and i guess the arithmetics of that machine was such that HUGE  HUGE == 0 (there was clearly no nan) so this might be the source of that strange requirement i wanted to propose a minimal change so existing implementations dont become invalid, but at least correct implementations are allowed, but i'm fine if the correct mathematical behaviour becomes the standard > 3. For x = 0, why HUGE_VAL and not Inf ([MX]) with the correct sign? > For instance, see the spec for log. > > 4. Why allowing HUGE_VAL on negative values? I think that the > requirements should be the same as for log: > > For finite values of x that are less than 0, [MX] [Option Start] > or if x is Inf, [Option End] a domain error shall occur, and > [MX] [Option Start] either a NaN (if supported), or [Option End] > an implementationdefined value shall be returned. > > or sqrt: > > For finite values of x < 0, a domain error shall occur, and > [MX] [Option Start] either a NaN (if supported), or [Option End] > an implementationdefined value shall be returned. > 
(0001835) geoffclare (manager) 20130916 14:48 edited on: 20130919 15:30 
At line 72758 after: The y0(), y1(), and yn() functions shall compute Bessel functions of x of the second kind of orders 0, 1, and n, respectively. append: y0(x) shall be equivalent to yn(0,x), and y1(x) shall be equivalent to yn(1,x). At line 72768 change: If the x argument to these functions is negative, HUGE_VAL or NaN shall be returned, and a domain error may occur. to: If the x argument to these functions is negative, [MXX]either NaN (if supported) or[/MXX] the same return value as when x is 0.0 (see below) shall be returned, and a domain error may occur. At line 72770 change: If x is 0.0, HUGE_VAL shall be returned and a pole error may occur. to: If x is 0.0, y0() and y1() shall return HUGE_VAL and a pole error may occur. If x is 0.0 and n is not both negative and odd, yn() shall return HUGE_VAL and a pole error may occur. If x is 0.0 and n is negative and odd, yn() shall return +HUGE_VAL and a pole error may occur. [MXX]If x is +Inf, +0 shall be returned.[/MXX] At line 72771 change: If the correct result would cause underflow, 0.0 shall be returned and a range error may occur. to: If the correct result would cause underflow [MXX]and is not representable[/MXX], a range error may occur, and the function shall return [MXX]0.0, or[/MXX] (if the IEC 60559 FloatingPoint option is not supported) an implementationdefined value no greater in magnitude than DBL_MIN. [MXX]If the correct result would cause underflow, and is representable, a range error may occur and the correct value shall be returned.[/MXX] At line 72772 change: If the correct result would cause overflow, HUGE_VAL or 0.0 shall be returned and a range error may occur. to: If the correct result of calling y1() would cause overflow, HUGE_VAL shall be returned and a range error may occur. If n is not both negative and odd, and the correct result of calling yn() would cause overflow, HUGE_VAL shall be returned and a range error may occur. If n is negative and odd, and the correct result of calling yn() would cause overflow, +HUGE_VAL shall be returned and a range error may occur. After line 72796 add: The y1() and yn() functions may fail if: and move the overflow error from lines 7278672790 to after this line. At page 1208 line 40249 section j0 change: If the x argument is too large in magnitude, or the correct result would cause underflow, 0 shall be returned and a range error may occur. to: If the x argument is finite and too large in magnitude, or the correct result would cause underflow [MXX]and is not representable[/MXX], a range error may occur, and the function shall return [MXX]0.0, or[/MXX] (if the IEC 60559 FloatingPoint option is not supported) an implementationdefined value no greater in magnitude than DBL_MIN. [MXX]If the correct result would cause underflow, and is representable, a range error may occur and the correct value shall be returned.[/MXX] [MXX]If x is +Inf, +0 shall be returned.[/MXX] 
(0002160) ajosey (manager) 20140221 15:41 
Interpretation Proposed 21 Feb 2014 
(0002203) ajosey (manager) 20140325 13:43 
Interpretation Approved: 25 March 2014 
Issue History  
Date Modified  Username  Field  Change 
20130618 00:54  nsz  New Issue  
20130618 00:54  nsz  Name  => Szabolcs Nagy 
20130618 00:54  nsz  Organization  => musl 
20130618 00:54  nsz  Section  => yn 
20130627 15:25  geoffclare  Note Added: 0001658  
20130627 15:26  geoffclare  Note Edited: 0001658  
20130627 15:27  geoffclare  Page Number  => 2297 
20130627 15:27  geoffclare  Line Number  => 72770 
20130627 15:27  geoffclare  Interp Status  => Pending 
20130627 15:27  geoffclare  Final Accepted Text  => Note: 0001658 
20130627 15:27  geoffclare  Status  New => Interpretation Required 
20130627 15:27  geoffclare  Resolution  Open => Accepted As Marked 
20130627 15:29  geoffclare  Tag Attached: issue8  
20130905 15:20  geoffclare  Interp Status  Pending =>  
20130905 15:20  geoffclare  Status  Interpretation Required => Under Review 
20130905 15:20  geoffclare  Resolution  Accepted As Marked => Reopened 
20130905 15:22  msbrown  Note Added: 0001791  
20130916 14:48  geoffclare  Note Added: 0001835  
20130918 09:29  geoffclare  Note Edited: 0001835  
20130919 15:28  geoffclare  Note Edited: 0001658  
20130919 15:29  geoffclare  Interp Status   => Pending 
20130919 15:29  geoffclare  Status  Under Review => Interpretation Required 
20130919 15:29  geoffclare  Resolution  Reopened => Accepted As Marked 
20130919 15:30  geoffclare  Note Edited: 0001835  
20140221 15:41  ajosey  Interp Status  Pending => Proposed 
20140221 15:41  ajosey  Note Added: 0002160  
20140325 13:43  ajosey  Interp Status  Proposed => Approved 
20140325 13:43  ajosey  Note Added: 0002203 
Mantis 1.1.6[^] Copyright © 2000  2008 Mantis Group 