Issue-#151 Extending the domain of Math.ArcTan2

[cfbsoftware]

The following is a message that I received by email from Robert:

Chris - can you post this for me please.
I don’t have access to a computer (or my passwords) at the moment, so expect only superficial remarks.

Josef:
1 - Sin looks like an improvement. Why are you comparing ABS (x) with -2…. ?
2 - Please don’t TRAP, returning 0 for finite x is fine.

Chris:
1 - I haven’t said what “work as you would like” is.
2 - What is the significance of your 922…295 number; can you spell it out?
3 -What I would like is:

For positive x, while it is too big divide by 2^32, then take “m := ENTIER (x)”.
“too big” means that the ENTIER call will TRAP.
Do you still think I have a problem?

Thanks, Robert.

[cfbsoftware]

2 - What is the significance of your 922…295 number; can you spell it out?

It is the largest number that causes the assertion to fail. 9223372036854775295. is the smallest number that passes the assertion.

Note that only approx the first 16 digits of a 64-bit REAL number are reliable so attempting to call ENTIER for any REAL with more than 16 digits to the left of the decimal point is going to give you an approximate answer.

e.g.

Code: Select all

  x := 88888888888888888.;
  IF x < maxLongInt THEN
    i := ENTIER(x);
    StdLog.Int(i); StdLog.Ln();
  END


Displays the result: 88888888888888896

[Robert]

Please review this latest suggestion:

Diffs: https://redmine.blackboxframework.org/p ... 09ddc6ad20

[Robert]

Staying off topic ...
Chris' number 9223372036854775295 is 2^63 - 513. Since (in this part of the world) the representable REAL numbers are multiples of 1024, this is almost exactly midway between possible REALs, and will not be represented exactly.
This situation obviously requires care, but is not quite my problem, which was to test representable numbers , and determine which ones could safely be converted to LONGINT by calling ENTIER.
The following example tests two "algorithms", flgC & flgL. The first is basically my previous mistake, the second my current thinking.

The problem with flgC is that the promotion from LONGINT to REAL occurs at compile time, and suffers from 64-bit rounding.
With flgL this promotion occurs at run time, used the FPU 80-bit extended precision, suffers NO rounding, and provides the test result I need.

It is a bit tricky, but less so, I think, than apparently comparing x with the wrong number, namely MAX (INTEGER) rounded down to the adjacent representable REAL.

Code: Select all

PROCEDURE  DoEntier*;
  VAR
    maxLongInt, m  :  LONGINT;
    x              :  REAL;
    k              :  INTEGER;
    flgC, flgL     :  BOOLEAN;
  BEGIN
    maxLongInt  :=  MAX (LONGINT);
    m           :=  43E0000000000000L - 1;   (*  REAL before MAX (LONGINT)  *)
    FOR  k  :=  0  TO  2  DO
      x  :=  SYSTEM.VAL (REAL, m);

      flgC  :=  x  >  MAX (LONGINT);   (*  Painful rounding  *)
      flgL  :=  x  >  maxLongInt;   (*  No rounding       *)
(*
      Print x, MAX (LONGINT), flgC, flgL
*)
      INC (m);   (*  Creates next REAL  *)
    END
  END  DoEntier;

   9223372036854774784.0000000000   9223372036854775807   FALSE   FALSE
   9223372036854775808.0000000000   9223372036854775807   FALSE   TRUE
   9223372036854777856.0000000000   9223372036854775807   TRUE    TRUE

[Josef Templ]

Please review this latest suggestion:

Diffs: https://redmine.blackboxframework.org/p ... 09ddc6ad20

The line spacing between equal results can be fine tuned by using a para symbol.
This allows for smaller (IMHO nicer) line gaps.

0 now appears only once in the table and a key is no longer required, I think.

StdCoder.Decode ..,, ...S....3QwdONl9RhOO9vRbf9b8R7fJHPNGomCrlAyIhgs,CbKBhZ
xi2,CoruKu4qouqm8rtuGfa4.hOO9vRb1Y66wb8RTfQ9vQRtIdvPZHWKqtCa.E.U5UBw.2U.Qk
lbeZ3DPuP7PNNvQRtId9NPuP7X2hgnRAXDJ.QCPuP7PNG2sET1.PuP.MHT9N9nt.G2sIdvPZnt
gcghghZcZRC8T0E.kfK.T.TO,2.,.3y.cU.ktAcoZimBhWhiohgnZcZRC.,.Z,0.x.0.4.AcmB
hVZBl6w1.0E65.2.c8fP3d8mBE,5TeEdKLqKKtCLLCJuIepZBGomCrl0ksH3.bf9ZORNPNG20E
tD.0E.6ls,si6.,k,,UnpZHldGrwmqmGomCb.AS.c9Ajg,0EtX.0.U6Um,,U00.umUG5.E.Y.2
..ESE.8.2.2gwS9ltMYZQD.,Ce2lqK.5.5E.nT3MyfEEvLKA.6.A.6.1cUZj0E.s86.,US.,.1
6.ME.M.6YE.4.8E,9T3U.kOE.0.x.0.4.A6.Q.2GE8k.4.IU.k,8Mtf.0E.coE.c5E.k.0.426
h1d.E.07M.k5k,4.QU.2.4.2,Q.E0k,.F.5.A,,k,U.Q,.2,Q.k6k,U.A,Q.6.k,U.Q,.A0Q.6
.7.5.A,Q.6.7.,.I3.Zz06.,U9W5Ul,,k,9z4U..2,we.E.0.3gwT.0..Y52U0.,.,1,U.YZQ1
.k,0EUur02ovi,az82.0k.U..OA2.c8..,6..D.n00U102.U6UzU.2.86E..UYU.A.6.6M.,69
..E.sz3M0,76,NS,76,N0lP0,76ZPNbPRN9R,76Pc1HMgVN0L7AN76BPOR99,NGReFHMgVN1HM
gBPORP0HeHBO0c1HkYuIXAdClM1ro0mL0GOqE5aUaBBqGMmGEiGMakM1roENqk24vYu2PdNHfP
NFMmGEO4HMgV1c1HMgH0aIbOYlSaU2id3Yj6BEMakKaIbYZUgZaBhilK0n24PsgV7Aqal2qmYM
005Pc.HsG9PSpN1HM0L7AH6JFPN,dS9fQT96jPOd9O,NM,7QTvQH9RHfR996bPODfP,dMH9R,7
8VN8PM0HM9VN0d8O..ohZxgVZidpC.UlAZBAV7ogdpB1ePn96BPORPOdPN,7QT1ErKrq8qm8LE
aKr0GI0HEuGLuGEaIbOoIqk2akMbkJ0mr8LEqGK0GlKLu0GlyKuWKEyqlCqu8rkuqlKqt0mouK
E4KEmqouqm0mk8rm0GuWqm0mt4qqKKLqk4qE,8ssHpmsETfPdfQT9PNPNZvQRtIGqVGLtmKWKq
tCK.4D..umVyKrG5EWE.Q6AA.cQ...sQR,.G20EtV.UIU.U72.2..AU0u06.,UV3.S.a30E.QE
U..2,w52U.E,,0..Y22U,2.2.2YXK90U.YjyC.zwPA.A.2U.E,J,6..EBU.U,.J7.tfj1E.6.V
Q.E...Tt1...
--- end of encoding ---

- Josef

[Josef Templ]

When reviewing the table more carefully now, I noticed that 0 appears twice indeed.
So we do need the key or we need the enumeration into -0, +0 in line 5.

- Josef

[Robert]

Any more comments ?

Diffs: https://redmine.blackboxframework.org/p ... 09ddc6ad20