View Issue Details

IDProjectCategoryView StatusLast Update
00007141003.1(2013)/Issue7+TC1System Interfacespublic2024-06-11 09:02
Reporternsz Assigned To 
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameSzabolcs Nagy
Organizationmusl
User Reference
Sectionyn
Page Number2297
Line Number72770
Interp StatusApproved
Final Accepted Text0000714:0001658
Summary0000714: yn(n,0) is incorrect for odd n<0
Descriptionthe 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 Actionat least allow the +HUGE_VAL return value for yn(n,x)
for odd negative n in case of overflow and x==0

Tagsissue8

Activities

geoffclare

2013-06-27 15:25

manager   bugnote:0001658

Last edited: 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 0000714:0001835

msbrown

2013-09-05 15:22

manager   bugnote:0001791

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

geoffclare

2013-09-16 14:48

manager   bugnote:0001835

Last edited: 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]

ajosey

2014-02-21 15:41

manager   bugnote:0002160

Interpretation Proposed 21 Feb 2014

ajosey

2014-03-25 13:43

manager   bugnote:0002203

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 => 0000714: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
2024-06-11 09:02 agadmin Status Applied => Closed