Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: atan2_sharp() -- a Motion?

9John, Michel, P1788
I support the idea to change the atan2 function.
I propose to change the semantics of current atan2 to one of those mentioned by John below and to drop the old meaning as atan(yy/xx) 
old atan2(yy,xx) = {atan(y/x) | xin xx, y in yy}
    atan2_sharp  not defined
new atan2-sharp defined below can now be noted as atan2(yy,xx) because atan(yy/xx) is nearly the same (?) 
Am 10.02.2014 14:14, schrieb John Pryce:

But for R's containing O? According to the 1788 loose-evaluation principle, we take the range of "the function" over the subset of R where it is defined. But now there is no unique "the function". For the result zz_dz:
- Clearly dz must be "trv".

yes

But
- Should zz = Entire, because we are thinking of the whole Atan2 function? no too coarse



- Or zz = [-\pi,+3\pi/2], which I think is the smallest closed interval containing the values of all the branches atan2_sharp() uses?

that is a good choice

- Or a suitably smaller interval when O is on the boundary of R, e.g. zz = [0,\pi/2] for R = ([0,1],[0,1]) ?

which can be optimized for special arguments
My scenario for these choices is a scene where boxes move slightly over the neg x-axis and do not break but enter the next leave of the complex function
We further may include the function atan2toPair which returns the 2 separate parts ,the exact solution set 

Jurgen

If these Qs are satisfactorily answered, I'll support this function's inclusion.

Regards

John Pryce


On 2014 Feb 7, at 14:52, Ralph Baker Kearfott wrote:

Michel, P-1788,

Please accept my apologies for not replying to this sooner.

I promise I will liaise with the IEEE-SA immediately to
ascertain our next steps, including submitting the final
document to the Sponsor (the Microprocessor Standardization
Committee).

We probably should have a vote on the entire document prior to
submission.  Thus, I see another month internal to P-1788
prior to the next phase, the (formally external to P-1788)
Sponsor Ballot.  In the mean time, I suggest you discuss
inclusion of atan2 with our technical editor (John Pryce).

Best regards,

Baker

On 01/24/2014 04:00 PM, Michel Hack wrote:

Is there still time for a new motion?  I would probably have to be a text
motion given this late stage -- but I would prefer to write it against
the 8.3 or 8.4 version of P1788_MAIN instead of the 8.1 version that is
the last complete (semi)public version.

The discussion of the relevant issues took place in this forum from
Nov 25 to Dec 3, 2013.

Right now 1788 requires atan2() as an interval version of the point
function atan2() that has a range of (-pi,+pi].  Such an interval
version cannot return a narrow interval enclosing pi, which is however
a natural result, and the one preferred by many interval libraries
(such as Sun/Oracle's Fortran).  It would be a shame to rule such a
function (for which Lee Winter suggested the name atan2_sharp() to
distinguish it from the above-mentioned atan2() -- the actual names
used in an implementation are not at issue here) to be non-conforming.

Would we require the availability of 1788-standard atan2() (perhaps
under the name atan2_wide or atan2_1788) in addition to atan2_sharp,
which (I believe) the implementation would be free to call just atan2?

There is more to this than just adding atan2_sharp to our list of
functions -- and it illustrates a more fundamental problem.  You see,
atan2_sharp is NOT the interval extension of ONE point function!  It
is the interval extension of three point functions:  atan2 with range
(-pi,+pi), atan2m with range (-2pi,0) and atan2p with range (0,+2pi),
the choice depending on combinations of the two inputs being positive,
containing zero, or being negative.

The problem is that several places in the document mention THE point
function of which an interval version is an interval extension.

One is the definition of "arithmetic operation", 4.2.6.

The definition of "interval extension", 4.2.30, is ok.

In 10.6, Required operations, we have "each such version shall be an
interval extension of the corresponding point function".

Actually, 10.4.1 is a bit more generous: "... and interval extension
of a point arithmetic operation".

Suggestions?

(Somewhere I came across a statement that the result of the case operation
was the extension of some point function -- but I don't quite believe this,
and I couldn't find the passage again...)

Michel.
---Sent: 2014-01-24 22:47:36 UTC



--

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------


--
                 Prof. Dr. Juergen Wolff von Gudenberg
     o           Lehrstuhl fuer Informatik II
    / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o         Tel.: +49 931 / 31 86602 Fax ../31 86603
  / \  Uni       E-Mail:wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 o   o Wuerzburg