Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Merged to the master branch

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Josef Templ » Wed Mar 29, 2017 8:26 am

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Wed Mar 29, 2017 5:45 pm

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).
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Josef Templ » Thu Mar 30, 2017 8:36 am

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Thu Mar 30, 2017 5:13 pm

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.
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Thu Mar 30, 2017 9:15 pm

User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Josef Templ » Fri Mar 31, 2017 12:59 pm

Robert wrote:Some diffs for this issue: https://redmine.blackboxframework.org/p ... 0e7fc24030.


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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Fri Mar 31, 2017 1:38 pm

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.
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Josef Templ » Tue Apr 04, 2017 4:35 pm

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Wed Apr 05, 2017 7:51 pm

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".
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#157 Extending the domain of Math.Sin, Cos, & Tan

Postby Robert » Thu Apr 13, 2017 7:29 pm

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?
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

PreviousNext

Return to Resolved (Features)

Who is online

Users browsing this forum: No registered users and 1 guest

cron