Page 3 of 4
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Wed Mar 29, 2017 8:26 am
by Josef Templ
looks definitely simpler and more systematic.
I wonder why ominc has chosen the 'exception' for ArcCot.
Is there a difference with special values such as +0, -0, +INF, -INF
or a difference in speed or precision?
- Josef
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Wed Mar 29, 2017 5:45 pm
by Robert
Josef Templ wrote:looks definitely simpler and more systematic.
I wonder why ominc has chosen the 'exception' for ArcCot.
Is there a difference with special values such as +0, -0, +INF, -INF
or a difference in speed or precision?
I suspect you are missing the point here?
These are
definitions, not implementation suggestions. Speed and accuracy are not relevant.
Code: Select all
π / 2 - ArcTan (0.5) = 1.1071487
ArcTan (1 / 0.5) = 1.1071487
π / 2 - ArcTan (-0.5) = 2.0344439
ArcTan (1 / (-0.5)) = −1.1071487
They differ for negative x (by π ). This includes -0. They agree for +0 (= π / 2).
The ominc definition is continuous (for real x).
The NIST DLMF (Digital Library of Mathematical Functions) definition is anti-symmetric (for real x).
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Thu Mar 30, 2017 8:36 am
by Josef Templ
Robert wrote:
These are definitions, not implementation suggestions. Speed and accuracy are not relevant.
The 'definitions' are written in CP syntax.
So why shouldn't that be taken as an implementation suggestion?
Anyway, for me the proposed alternative looks simpler and is in line with
major mathematical packages. So I would say it is OK to change that.
- Josef
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Thu Mar 30, 2017 5:13 pm
by Robert
Josef Templ wrote:The 'definitions' are written in CP syntax.
So why shouldn't that be taken as an implementation suggestion?
Of course they can. And they are probably good suggestions.
My point was simply that they are described as definitions, not as implementation suggestions.
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Thu Mar 30, 2017 9:15 pm
by Robert
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Fri Mar 31, 2017 12:59 pm
by Josef Templ
One small detail in Sin:
Code: Select all
IF 10 IN FSWs() THEN FSTPst0; RETURN 0. ELSE END;
has an empty ELSE.
Some Pre/Post conditions are indented some are not.
The BlackBox standard is to not indent them.
Is this because of the missing trap number?
The trap number is usually put to the right of the condition.
I wouldn't introduce new conventions here because of consistency
with the rest of the docu.
The "changes" fold in Math/SMath docu is open, not closed as usual.
- Josef
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Fri Mar 31, 2017 1:38 pm
by Robert
Josef Templ wrote:[Some Pre/Post conditions are indented some are not.
The BlackBox standard is to not indent them.
Is this because of the missing trap number?
Yes
The trap number is usually put to the right of the condition.
I wouldn't introduce new conventions here because of consistency
with the rest of the docu.
In \\Docu\ Stores the number is to the left. I think this is better, and just
assumed that it was the newer convention!
I am away for a few days, and will address your other points when I return.
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Tue Apr 04, 2017 4:35 pm
by Josef Templ
Robert wrote:
In \\Docu\ Stores the number is to the left. I think this is better, and just assumed that it was the newer convention!
Stores is an exception, indeed.
There are not many docu files that format it that way.
The only other examples I can find are a few places in StdTables and StdFolds.
The vast majority is the other way round.
However, the guidelines in Docu/BB-Docu.odc recommend your version.
But is it really better? I am not sure.
Anyway, the guidelines don't specify explicitly the case where there is no number but
post conditions in the guidelines (and in all files I have looked up) are not indented if there is no number.
Also pre conditions are never indented, not even in Stores.
So this may be used as an indication that indentation should not be
used when there is no number.
- Josef
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Wed Apr 05, 2017 7:51 pm
by Robert
New diffs available:
https://redmine.blackboxframework.org/p ... 0e7fc24030.
Josef Templ wrote:However, the guidelines in Docu/BB-Docu.odc recommend your version.
But is it really better? I am not sure.
Originally in my own Docus I put the number to the right, but switched, years ago, to the left. I forget why; probably I saw the "Documentation Conventions". The reason I prefer it is when you see a TRAP with error code 23 (for example) it is easy to find the reason in the procedure's Docu when all the precondition numbers are neatly listed one above the other. When you get used to it the alternative looks wrong. I agree that the new convention is a "better readable style".
Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan
Posted: Thu Apr 13, 2017 7:29 pm
by Robert
I have no idea how this happened, but the System Strings file got forgotten.
Code: Select all
...
Math.Cos.143 Pre: ABS(x) # INF
Math.SinCos.143 Pre: ABS(x) # INF
Math.Tan.143 Pre: ABS(x) # INF
...
SMath.Sin.143 Pre: ABS(x) # INF
SMath.Cos.143 Pre: ABS(x) # INF
SMath.SinCos.143 Pre: ABS(x) # INF
...
The two "SinCos.143" lines above are missing.
What is the easiest way of making this correction - does it need a new issue?
Another minor problem with build 845 is the
About box - the copyright date needs to be updated. (And, to my taste, I would put the two copyright lines in chronological order.)
Perhaps this change can be added to the next issue to go to vote?