Why it is invisible? This message will be shown in the TRAP window. So there should be meaningful number.Robert wrote:Regarding the Docu pre-condition I still think that there should be no number. Neither 20 or 143 is visible to the non system programmer who uses the Math.Sin function.
Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Test code & TRAP extract - no number visible.Ivan Denisov wrote:Why it is invisible? This message will be shown in the TRAP window. So there should be meaningful number.Robert wrote:Regarding the Docu pre-condition I still think that there should be no number. Neither 20 or 143 is visible to the non system programmer who uses the Math.Sin function.
Code: Select all
z := Math.Sin (INF);
...
undefined real result (F8A1, 37E)
Pre: ABS(x) # INF
Math.Sin [000002E5H]
.x REAL inf
RdcTest.DoSin [00000732H]
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Oh, I understood now how it works. Is something traps inside the function, there is possibility to make informative message! Brilliant system!
I think, that is better not change Ominc tradition in this case. They have 20. Let's keep 20.
Code: Select all
Math.Sqrt.143 Pre: argument of Sqrt must not be negative
Math.Ln.143 Pre: argument of Ln must not be negative
Math.Log.143 Pre: argument of Log must not be negative
Math.Sin.143 Pre: ABS(x) # INF
Math.Cos.143 Pre: ABS(x) # INF
Math.Tan.143 Pre: ABS(x) # INF
Math.ArcSin.143 Pre: -1.0 <= x <= 1.0
Math.ArcCos.143 Pre: -1.0 <= x <= 1.0
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
If we changed the Strings file (which we could) to read
or something similar it would make sense for the code comment to say
"(* 20, ABS(x) # INF *)" and for the Docu to refer to Precondition #20.
But, at the moment, the 20 has no significance and is better removed.
Code: Select all
Math.Sin.143 Math.Sin Precondition #20: ABS(x) # INF
"(* 20, ABS(x) # INF *)" and for the Docu to refer to Precondition #20.
But, at the moment, the 20 has no significance and is better removed.
Yes, but it is not brilliantly explained in any Docu I know about.Brilliant system!
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Robert, I think that 20 here is the short way to say "precondition". If you will remove it, the part of semantics will be lost. And 143 is not good here, because it will change the meaning of the comment. So I prefer you keep it like Oberon microsystems did.
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Ok.Ivan Denisov wrote:Robert, I think that 20 here is the short way to say "precondition".
I prefer no number in the comment & Docu.
JT prefers 143.
ID prefers 20.
I don't feel very strongly, and hope this discussion is not too long.
I can agree to 20 in both places - ie no change.
I can agree to 143 in the comment, if the comment is clarified to say it refers to the kernel error. I do not like 143 in the Docu.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
In addition, the manual says that in case of a range error ST(0) is unchanged.Robert wrote: The manual says:which might mean it only stacks one value, so only one pop is required?Description
Computes both the sine and the cosine of the source operand in register ST(0),
stores the sine in ST(0), and pushes the cosine onto the top of the FPU register stack.
(This instruction is faster than executing the FSIN and FCOS instructions in succes-
sion.)
This means that there is no second result pushed onto the stack in case of a range overflow
and the implementation is correct.
- Josef
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Note: So far I was only talking about the error number in the source comment, not in the docu.Robert wrote:Ok.Ivan Denisov wrote:Robert, I think that 20 here is the short way to say "precondition".
I prefer no number in the comment & Docu.
JT prefers 143.
ID prefers 20.
I don't feel very strongly, and hope this discussion is not too long.
I can agree to 20 in both places - ie no change.
I can agree to 143 in the comment, if the comment is clarified to say it refers to the kernel error. I do not like 143 in the Docu.
The number in the source comment gives you a chance to see to which Strings key it refers to.
Otherwise you have to study the Kernel's trap handler in full detail to see the link.
With respect to the source comment this case is not a matter of personal preferences, I think.
20 is wrong, 143 is correct. It can of course be labelled as "Kernel error number" and it may also be
a good idea to add in a comment that it is checked internally by FSIN, FSINCOS, etc. because
this is also not obvious from the source code.
I agree that the error number in the docu is misleading either way.
20 is wrong because it is not the number being used. 143 is an internally used number
outside the valid range of 0 .. 128.
It should better be removed from the docu.
- Josef
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
I've done some timings:Robert wrote:Mystery on mystery!
The MATLAB results are all correct to the 7 digits quoted. It must be using multi-precision of some kind, which must be slow?
For small numbers (x = 5.) MATLAB and BlackBox are similar in speed. For big (x = several million) and very big (x = 5.E18) MATLAB slows down by a factor of 10; BlackBox, using the native FPU, maintains its speed.
There is quite a bit of discussion on the web about using elaborate software to improve the accuracy of the Intel FPU FSIN instruction. Personally I don't think we should consider doing that for the standard BlackBox library; the Intel hardware strikes me as a very reasonable compromise for general purpose use.
I've also timed the SinCos procedure. It is only very slightly slower than calling one of Sin or Cos. This makes it a very desirable addition to the library.
Last edited by Robert on Tue Mar 28, 2017 8:16 pm, edited 1 time in total.
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
No comments!Robert wrote:Some wording for discussion:ArcCot (x) = Math.Pi() / 2.0 - Math.ArcTan(x)
(* Refs: https://en.wikipedia.org/wiki/Inverse_t ... _functions, Maple *)
ArcCot (x) = Math.ArcTan(1.0 / x)
(* Refs: http://dlmf.nist.gov/search/search?q=arccot, MATLAB, Mathematica, Maxima, MuPAD, Wikipedia *)
I'm going to make a simpler proposal: Remove
and insertArcCot (x) = Math.Pi() / 2.0 - Math.ArcTan(x)
ArcCot (x) = Math.ArcTan(1.0 / x)