Issue-#151 Extending the domain of Math.ArcTan2

[DGDanforth]

I have changed the bounds from exclusive "()" to inclusive "[]"

By making those small changes the column for x can be
reduced to a single word for each y.

Doug, are you sure that this is correct for all cases?
This must be checked carefully.
My impression was that it does not work.
Can you show the complete table?

- Josef

OK, here is the modified with discussion and original table.

StdCoder.Decode ..,, ..Nu....3Qw7uP5PRPPNR9Rbf9b8R79FTvMf1GomCrlAy2xhX,Cb2x
hXhC6FU1xhiZiVBhihgmRiioedhgrZcZRiXFfaqmSrtuGfa4700zdGrr8rmCLLCJuyKtYcZRiX
7.2.s,c5R.0k,5TWyql.bnayKmKKqGomC5XzET1.PuP.MHT9N9ntumaU2,CJuyKtQC98P9PP7O
NbXmb.2.YhBk2Emq.,6.,U08J99SdfJHPNjvQCJuGKfaqmY6MwdONl1QCh0708T,U..w.oVB.,
sUGpmWbBxhYhAbndMHT9NY6Mw.sQq2Y6cwB.0.Xw0w,Al9E.0E.kfG.86.QC18RdfQHfMf9R9v
Q7ONb17.,.L,0.x6.6.M.kU8ro4Kq2XkD.6.th.k4k.8Mtr.0E.s70.,UO.,.16.c8mLT5.2UE
C.M.c.3gwP.,6.I46.o16.M.kU.A.6.V22.c8fP3d8mBE,5TeEdKLqKKtCLLCJuIepZBGomCrl
0ks,ktuGdKLqKa2V.Iy1.,UQX5UHX.2.52.CLLC3b8Rn9P99F9vQ0ks,Uikwm46.Zz,E..W.e6
2.86.c918R..,E0E...d0,c.,.,.,9jr00EKmx.2scG2PP,Q.o.,eT9EUfL62sdi18zJ2gjY4i
yUA.A..,6..1.0k,8Mtr.,E.s86.,US.,.1.42.4.072U,U2Ikmj,2U.kZU.EDU.U,.10.5.V2
Y0QU,U0oDAU,.N136.2U.I3.Zj1E.sTs,MN6.,k,9T66.,.E2kZU.E,9T7U...V,,M.,.,.,9j
U.Y3..QU.2wjJ,,TCbE.vSPE,8z,c.6.,c8..0.B4D.HA.6.C60E.0.U6Uj,,U000E..UIV.IU
.U.UU,2Ug..U46E..Z5.U,.6.,.M.E.g,IU,U1A.YUIU1.3MaM.1.3sVc.,.,c8..0.k1kmE.0
U10,6..W.i22.86E..Uk2.0k.0.0.0KS,,69..s.,6s..8EjlzrorGqoOqoKKm0GnyKtqq48k2
0GE0mw0GE0m2Wr20GE8rmCrumKu0GEqk2iGMaEsyqtakJ0n4aEsyqtAdCpc7QZkg,HeHBmYuIX
2id3Yj2YogV72C2a72id328n4akYu21fPnP0VPO,,.PNGReFCHE0ro0mLY4i0RPNDP0VPOPM0V
vPgZ7p70bBcP9vNqmYkK0roqUh2a7ohZVkBBAdCV7,b76V1kKa244qGsaKEcAohZFMakK0ro.q
mYkYkK05Y4uqmMGR0VN1HM9VFsy40n2qk48kZKqwen4akJ0XI3hZ3YuhgmxhUwidZic3YV3Ykx
hnBhoBhqhgUQidxgi3YWBho3Yc2adgV76AGJo..cP9vN19RHfR..XN8PM0VN0186pPN.cPn96b
PO.2aUwhm3YlAZB6QMERPS,dNHfPH9R996VvP.uquqKlKKt0Wi3YPRZk2YioZi2Y7pd4hfBAVi
V,pBUoFrK4..kKaIbOIEuGLuWh2aRhV7AgiBD1ePn1.f1.a2U7p7gVI3hZNQfPNb9RHvPR96Hv
Q,7OTvR,7RT96HfPdPNZ9QZPNd96d9O996HfPdXqBggRii2YUocgxhVZidphb3Ykxhdpho3Yih
ihVnhVXBgi3Yixho3YmhgkJiZRiZpho3YVZhg3YkxhndMNPN,dQ9PMN96RPRUg2YjphgBjUAgU
YgdRiXJiZZiZ3YnhiWRiZZiUwha3Yo3hZhhBAgn3YbBhqhgi3YWBjUYichgUoBEEyKn0Glaan3
YpRiZZgUAhi3YV3YaZhjBA.Er.R76,7I9fQFPMVvQPMM,dM99RdPNZ96RvP4Kuaqru4YijNRbH
E8mqaKr8GE4KrGKE8mq4Kw8GEOqr8LEGLocNN1Uj,99SdfQ9PP9vQ,tRHXBgZ7p74KrMGReF,7
R1vMLPN796TfPdvP,7RFPNCrmGLECruCKo0GuWqkGr4qkZKqwe1.e5.,FE05G5QC.,Vd...Ui,
O5.kMEM..cPQC.2aU.6Q.O4G5V1Ui,0mosKL,MP19SN76HeHqZ7..UihA..UhUg2YhBhi3Yio3
q0a...gC.MG.Ui22mGEiGM0GL66P1.qkvWqm8rm0GLuGLAhnNRR9N9fQb9RTvP796dvP,dQ99Q
.GLoKakltaKlEI8qoGrI0Gv4KqKrmCLEyKn0GuEn.Rn40rraKrcQ91kkGroc9PM13sHZPODPOR
PMN96BvPqa72YU2YtV7.QipZBkJs8V79,7QTHK0mYuY7Q32CA7a.AdClYEs2Yj.V1VFsa481H0
RPND99,7AN76VX72id32.gZ7Vn.Y4i0PNGRGKohZxggM9VN0Vn42CgZ7l20bBcPAVhA7gZkBhB
M9gZ7FK.kK05A7aU7,b,.PNGcPY3V,Es2281RX724P,Uh.H0P7QEOcPMGEMEMQZk.m0U7g,.Ee
Ex.UU2Ca4sQ.00H,VFe..ErMMoC.UlUk..ErsQ.6A,,EskUEn.05.R1Er2Zk2Yio3aIbAZBAVi
V,,6RohZ,..gZ7pd43YiUhM8PcUXDJ9X1xhiZimxhgZhZJinpZH7N58RZ9P7ONbvM,Mw..c95u
PR9R.70,kVkk.R,85...CLL.U2V.IS2U.UIU.U72U.E..k.8cCU.2.4K.2U5UNV.2.52,6.,.E
2kTU.E,,0..Y22U,2.,E.EECOhU.YjyC.zwPA.A.2U.E,h,0U...pU.6.M.EJ0.2.0E65.2..N
6yY,YZPS9L6y0I,5TW.kVy4..f.0..2,2.M00.VDahHEfrA3kwL,,AzJEsmtpcTR2WH....
--- end of encoding ---

[Robert]

Doug
I disagree with your post in so many ways I don't know where to start!

I shall start with your last suggestion, where I don't think you are wrong, but I still dislike it.
We could call "neg, 0, pos" "any". This would save (a small amount of) ink, but at the intellectual expense of creating another concept (any) which has to be defined. Already we have many concepts, and reducing their number, not increasing it, is the way to simplification.
In my key, where I have two definitions (eg "finite positive number" & "(0 ... INF)") the intention was that both were the same, but expressed both informally in words and more formally in symbols to be comprehensible to the widest possible audience. Your text "Any finite number in [-INF ... +INF]" describes two different ranges, in two formats, and asks the reader to take their intersection. This is NOT simpler.
But you have caused me to realise that my key was not as clear as I intended: the revised text is

Code: Select all

     pos, +pos     Any finite positive number, ie (0 … INF)
     neg, -pos     Any finite negative number, ie (-INF … 0)


It gets more serious when you suggest changing the definition of "pos" to "Any finite positive number in [+0 ... INF]".
Even if we suppose this is correct for line 1 (it is not) since the definition of pos has changed all its other uses become wrong.

Why is it wrong on line 1? We are getting into the GO situation here. The human brain has evolved to be extremely good at resolving ambiguities in context, so much so that in the GO case the text is apparently so simple that it is hard to actually see the ambiguities. That is what makes it dangerous, but if 1 line is used out of context an error is quite likely because the individual lines are wrong.

Why so? We have (at least) two ideas here: bit patterns and numbers. In most cases the mapping between them is so straight forward it does not seem necessary to have separate notations; we can let the brain resolve these harmless ambiguities. But zero is an exception, it must be described carefully.

I shall use the notation here: -0 ~ 1 bit pattern, +0 ~ the other bit pattern, 0 ~ either bit pattern, 0. is the number zero.
The notation (a ... b) means all numbers x satisfying a < x & x < b, where a & b are numbers. (Similarly for [a .. b].)
Is INF a number? Or a third concept - it is definately not a "Real" number. I shall not dwell on this because it is not the most acute problem.

You can't write [+0 ... INF] unless you mean "+0" represents the number 0.
You can't write [-INF .. -0] unless you mean "-0" represents the number 0.

But now these ranges overlap, and you definately don't have an unambiguous specification.

In summary the problem is:
- The edges of the ranges' specifications must be numbers, not bit patterns
- The number corresponding to the bit pattern +0 is not greater than the number corresponding to the bit pattern -0; they are both the same number: zero.

[DGDanforth]

In summary the problem is:
- The edges of the ranges' specifications must be numbers, not bit patterns
- The number corresponding to the bit pattern +0 is not greater than the number corresponding to the bit pattern -0; they are both the same number: zero.

Ah, but we are discussing the evaluation of ArcTan using computers AND that function only operates on bit patterns, not numbers.
As such the bit patterns -0 and +0 are not equal.

I see that I am distracting this thread and (since I am not really interested in it) will step out and make no further comments.
-Doug

[Robert]

Ah, but we are discussing the evaluation of ArcTan using computers AND that function only operates on bit patterns, not numbers.

Agree.

As such the bit patterns -0 and +0 are not equal.

Agree.
But they both represent the same number. And that is why using numbers to describe this operation on bit patterns is so fraught.

On a completely different note I had a problem yesterday with some code I have been using for years.

Code: Select all

VAR x : REAL;
...
IF x > MAX (LONGINT) THEN ...

When x = MAX (LONGINT) + 1 exactly it fails the test, which caused a crash.
It took me some time to work that one out.

[Josef Templ]

OK, here is the modified with discussion and original table.

Line 2 is wrong. It uses a different definition of pos for y now.

This rules out using inclusive ranges.

- Josef

[Josef Templ]

Code: Select all

     pos, +pos     Any finite positive number, ie (0 … INF)
     neg, -pos     Any finite negative number, ie (-INF … 0)


would it be OK to refactor all the definitions of pos and neg into

Code: Select all

fin  Any positive finite number, ie (0 ... INF)

Since 0 is excluded, there is no ambiguity by using it as
+fin, -fin, or +/-fin.

- Josef

[Josef Templ]

On a completely different note I had a problem yesterday with some code I have been using for years.

Code: Select all

VAR x : REAL;
...
IF x > MAX (LONGINT) THEN ...

When x = MAX (LONGINT) + 1 exactly it fails the test, which caused a crash.
It took me some time to work that one out.

You get into a loss of precision here, I think.
MAX(LONGINT) uses more bits than the REAL mantissa has.
Adding 1 does not change the REAL bit pattern.

You may want to use
IF x >= MAX (LONGINT) THEN ...

- Josef

[Robert]

You get into a loss of precision here, I think.
MAX(LONGINT) uses more bits than the REAL mantissa has.
Adding 1 does not change the REAL bit pattern.

You may want to use
IF x >= MAX (LONGINT) THEN ...

It is common folklore that you have to be careful with REAL comparisons. In this case I had analysed the real expression (x) and knew it contained no error. I overlooked to analyse the error in the integer expression (MAX(LONGINT)) - caused by the invisible type promotion. One lives, and learns, and forgets.

The solution I prefer here is

Code: Select all

  CONST
    maxLongInt  =  9223372036854774784.;
(*  This is the greatest representable REAL <= MAX (LONGINT)  *)
...
    IF x  >  maxLongInt  ...

because the higher level intention is to separate out of range values, and the other alternative gives the superficial impression that an apparently in-range value is also being rejected.

Getting half-way back to topic, I think that this is the right comparison to use in Math.Reduce, and the "incomplete" comment should be deleted.

Getting fully back to topic, I am away for a few days, so expect to update the diffs by Wedenesday.

[Josef Templ]

Getting half-way back to topic, I think that this is the right comparison to use in Math.Reduce, and the "incomplete" comment should be deleted.

The Reduce in Sin is also a bit questionable but this would be another issue.
Anyway, you may want to try out the following variant of Sin(), which simplifies and inlines the test
and does it after the FSIN where you get it (almost) for free.
The action could then be RETURN 0 as it was so far or something else, e.g. HALT(20).

Code: Select all

   PROCEDURE Sin* (x: REAL): REAL;
   BEGIN
      (* 143, ABS(x) # INF *)
      (* 20, -2.0^63 < ABS(x) < 2.0^63 *)
      FLD(x); FSIN;
      IF 10 IN FSWs() THEN HALT(20) END;
      WAIT; RETURN TOP()
   END Sin;


- Josef

[cfbsoftware]

The solution I prefer here is

Code: Select all

  CONST
    maxLongInt  =  9223372036854774784.;
(*  This is the greatest representable REAL <= MAX (LONGINT)  *)
...
    IF x  >  maxLongInt  ...

I don't believe this will work as you would like it to. Try running this:

Code: Select all

MODULE TestLongInt1;

CONST
    maxLongInt  =  9223372036854774784.;
(*  This is the greatest representable REAL <= MAX (LONGINT)  *)


PROCEDURE Run*();
VAR
  x: REAL;
BEGIN
  x := 9223372036854775295.;
  ASSERT(x > maxLongInt);
END Run;

END TestLongInt1.