Issue-#147 Fraction function in System Math

Merged to the master branch

Re: Issue-#147 Fraction function in System Math

Postby Ivan Denisov » Thu Feb 23, 2017 7:33 pm

Thank you Josef and Robert. Now am I understanding this better.
Ivan Denisov
 
Posts: 1698
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: Issue-#147 Fraction function in System Math

Postby Robert » Fri Feb 24, 2017 11:29 am

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

Re: Issue-#147 Fraction function in System Math

Postby Josef Templ » Fri Feb 24, 2017 2:26 pm

I took the freedom to adapt the redmine issue text slightly
in order to make the changelist for 1.7.1 easier to read,
i.e. closer to the actual changes.

In particular, the new name "Mod1" instead of the original proposal of "Fraction"
should appear in the issue.
Also System.Frac was changed to Math.Frac in the issue.

- Josef
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#147 Fraction function in System Math

Postby Robert » Fri Feb 24, 2017 6:00 pm

Updated the code to reflect the new issue name:

Diffs: https://redmine.blackboxframework.org/p ... acfaf998fe
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#147 Fraction function in System Math

Postby Josef Templ » Sat Feb 25, 2017 7:51 am

Just a general question, Robert:
How did you find out the code sequence for Mod1?

And a little warning: you will get a merge conflict with System/Rsrc/Strings because
this has also been changed in issue-#139.

- Josef
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#147 Fraction function in System Math

Postby Robert » Sat Feb 25, 2017 12:23 pm

Josef Templ wrote:Just a general question, Robert:
How did you find out the code sequence for Mod1?

Good question, I wish I could say the same about the answer!

Basically I looked at Math.Frac, and guessed. I then wrote a wrapper in LibReals, that I have used for, literally, years. Since it has never reported a problem I feel
reasonably confident that the code is ok.

Code: Select all
PROCEDURE  Fraction* (x : REAL) : REAL;
  VAR
    a, b  :  REAL;
  BEGIN
    a  :=  M.Fraction (x);
    b  :=  x - M.Floor (x);
    ASSERT (a = b, 30);   (*  Testing code  *)
    RETURN  a
  END  Fraction;
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#147 Fraction function in System Math

Postby Josef Templ » Mon Feb 27, 2017 8:15 am

The code sequence looks OK to me.
The only thing that I don't fully understand is the WAIT instruction.
Some procedures use it some don't. Frac uses it so it
seems OK also for Mod1 and it probably does not hurt
because it is for synchronizing in case of exceptions.


For the sake of completeness I would suggest to add the code
for expressing Mod1 in terms of ENTIER at the end of the source file.

Code: Select all
   PROCEDURE Mod1* (x: REAL): REAL;
   BEGIN
      IF ABS(x) >= 1.0E16 THEN RETURN 0
      ELSE RETURN x - ENTIER(x)
      END
   END Mod1;



Robert, why did you remove the empty line at the end of System/Rsrc/Strings?
Please leave it. It serves to group the added entries when adding the build information.

You will still get a merge conflict with System/Rsrc/Strings.

- Josef
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#147 Fraction function in System Math

Postby Robert » Mon Feb 27, 2017 3:04 pm

Josef Templ wrote:For the sake of completeness I would suggest to add the code
for expressing Mod1 in terms of ENTIER at the end of the source file.


Firstly several topics have been raised, and this post only addresses one; I will reply to the others later.

This "stuff" - technically they are not source code comments, as they are neither comments, nor in the source code; they are hidden in the source code file after the source code itself, which stops at the line "END Math." - should, I think, be removed.

It has no mathematical value - and if it did it should be displayed proudly in the Docu file, not hidden in the source code file.

It has no algorithmic value - it does not "explain" the assembler routines in terms of higher level procedures. It is not numerically equivalent.
Just one example: ArcCosh(8.885071267786003). The assembler gives 2.874337731688072, the text gives 2.874337731688071.

It may have some historical truth, in that maybe these routines were used in early versions, then replaced when other routines, presumably judged to be "better", were used.
Irrespective of the history, I think they add no value now, and should be removed. They certainly should not be increased without good reason, and "completeness" does not count as good reason for me.
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Issue-#147 Fraction function in System Math

Postby Josef Templ » Mon Feb 27, 2017 3:57 pm

Completeness is a very good reason for me no matter in which form it is added.
It should certainly not be removed because it gives us the high level definition
of the semantics of those functions.

The difference in the last digit is irrelevant because this is unavoidable
due to rounding effects. It is also not possible to say which one is right
and which one is wrong. They are both correct with respect to a very small epsilon.
For Mod1, by the way, i would not expect any difference at all.
Did you test it?

I agree that it should be moved to the docu but that is actually an aspect that
goes beyond this very issue. Currently the issue is a feature issue.
By improving the docu it would at the same time become a documentation issue.
The point is that if this is done in a separate documentation issue later, it will be
much harder to get ALL the info if the Mod1 definition we know now is not
written down at an appropriate place.



The other topic is the naming.
Is there a similar function in any other language or library?
This could also be used as a source for a well-established name.

Mod1 has the advantage that it documents pretty well what it does.
In C libraries the function "fmod()" is quite common for floating point
modulo operations. And our function is exactly fmod(x, 1).

- Josef
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: Issue-#147 Fraction function in System Math

Postby Robert » Mon Feb 27, 2017 8:01 pm

Josef Templ wrote:Completeness is a very good reason for me no matter in which form it is added.
It should certainly not be removed because it gives us the high level definition
of the semantics of those functions.

No it does not.
The semantics are defined in the Docu:
Mod1 is the fractional part of the argument.
The following equation holds: x = Floor(x) + Mod1(x).
Post
0 ≤ Mod1 < 1

The proposed text includes comparisons with 10^16, which has nothing to do with either the meaning or implementation of the new function.

Take ArcTanh as another example: the text (which includes four variants) does not help clarify the meaning of ArcTanh. And why should there be such text? - there is no (hidden) text that attempts to clarify the meaning of Exp, is that an omission that should be rectified?

I do not want to discuss this forever. This text is just a useless distraction, and we would all be better off if it were deleted.
Last edited by Robert on Mon Feb 27, 2017 8:18 pm, edited 1 time in total.
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