Austin Group Defect Tracker

Aardvark Mark IV


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
Powered by Mantis Bugtracker