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.
Issue-#151 Extending the domain of Math.ArcTan2
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: Issue-#151 Extending the domain of Math.ArcTan2
It is the largest number that causes the assertion to fail. 9223372036854775295. is the smallest number that passes the assertion.Robert wrote: 2 - What is the significance of your 922…295 number; can you spell it out?
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
Re: Issue-#151 Extending the domain of Math.ArcTan2
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.
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
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#151 Extending the domain of Math.ArcTan2
The line spacing between equal results can be fine tuned by using a para symbol.Robert wrote:Please review this latest suggestion:
Diffs: https://redmine.blackboxframework.org/p ... 09ddc6ad20
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
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#151 Extending the domain of Math.ArcTan2
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
So we do need the key or we need the enumeration into -0, +0 in line 5.
- Josef