 Relationships |
|
| Anonymous | Login | 2023-10-03 01:41 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 | 2013-06-18 00:54 | 2020-03-24 16:03 | ||
| Reporter | nsz | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | ||||||
| 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 | |||||||
|
|
|||||||
|
Relationships |
|
|
Notes |
|
|
(0001658) geoffclare (manager) 2013-06-27 15:25 edited on: 2013-09-19 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) 2013-09-05 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 <vincent-opgr@vinc17.net> [2013-08-27 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/cgi-bin/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 implementation-defined 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 implementation-defined value shall be returned. > |
|
(0001835) geoffclare (manager) 2013-09-16 14:48 edited on: 2013-09-19 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 Floating-Point option is not supported) an implementation-defined 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 72786-72790 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 Floating-Point option is not supported) an implementation-defined 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) 2014-02-21 15:41 |
Interpretation Proposed 21 Feb 2014 |
|
(0002203) ajosey (manager) 2014-03-25 13:43 |
Interpretation Approved: 25 March 2014 |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2013-06-18 00:54 | nsz | New Issue | |
| 2013-06-18 00:54 | nsz | Name | => Szabolcs Nagy |
| 2013-06-18 00:54 | nsz | Organization | => musl |
| 2013-06-18 00:54 | nsz | Section | => yn |
| 2013-06-27 15:25 | geoffclare | Note Added: 0001658 | |
| 2013-06-27 15:26 | geoffclare | Note Edited: 0001658 | |
| 2013-06-27 15:27 | geoffclare | Page Number | => 2297 |
| 2013-06-27 15:27 | geoffclare | Line Number | => 72770 |
| 2013-06-27 15:27 | geoffclare | Interp Status | => Pending |
| 2013-06-27 15:27 | geoffclare | Final Accepted Text | => Note: 0001658 |
| 2013-06-27 15:27 | geoffclare | Status | New => Interpretation Required |
| 2013-06-27 15:27 | geoffclare | Resolution | Open => Accepted As Marked |
| 2013-06-27 15:29 | geoffclare | Tag Attached: issue8 | |
| 2013-09-05 15:20 | geoffclare | Interp Status | Pending => --- |
| 2013-09-05 15:20 | geoffclare | Status | Interpretation Required => Under Review |
| 2013-09-05 15:20 | geoffclare | Resolution | Accepted As Marked => Reopened |
| 2013-09-05 15:22 | msbrown | Note Added: 0001791 | |
| 2013-09-16 14:48 | geoffclare | Note Added: 0001835 | |
| 2013-09-18 09:29 | geoffclare | Note Edited: 0001835 | |
| 2013-09-19 15:28 | geoffclare | Note Edited: 0001658 | |
| 2013-09-19 15:29 | geoffclare | Interp Status | --- => Pending |
| 2013-09-19 15:29 | geoffclare | Status | Under Review => Interpretation Required |
| 2013-09-19 15:29 | geoffclare | Resolution | Reopened => Accepted As Marked |
| 2013-09-19 15:30 | geoffclare | Note Edited: 0001835 | |
| 2014-02-21 15:41 | ajosey | Interp Status | Pending => Proposed |
| 2014-02-21 15:41 | ajosey | Note Added: 0002160 | |
| 2014-03-25 13:43 | ajosey | Interp Status | Proposed => Approved |
| 2014-03-25 13:43 | ajosey | Note Added: 0002203 | |
| 2020-03-24 16:03 | geoffclare | Status | Interpretation Required => Applied |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
