Issue-#147 Fraction function in System Math
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Issue-#147 Fraction function in System Math
Thank you Josef and Robert. Now am I understanding this better.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#147 Fraction function in System Math
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
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
Re: Issue-#147 Fraction function in System Math
Updated the code to reflect the new issue name:
Diffs: https://redmine.blackboxframework.org/p ... acfaf998fe
Diffs: https://redmine.blackboxframework.org/p ... acfaf998fe
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#147 Fraction function in System Math
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
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
Re: Issue-#147 Fraction function in System Math
Good question, I wish I could say the same about the answer!Josef Templ wrote:Just a general question, Robert:
How did you find out the code sequence for Mod1?
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;
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#147 Fraction function in System Math
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.
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
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
Re: Issue-#147 Fraction function in System Math
Firstly several topics have been raised, and this post only addresses one; I will reply to the others later.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.
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.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Issue-#147 Fraction function in System Math
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
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
Re: Issue-#147 Fraction function in System Math
No it does not.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.
The semantics are defined in the Docu:
The proposed text includes comparisons with 10^16, which has nothing to do with either the meaning or implementation of the new function.Mod1 is the fractional part of the argument.
The following equation holds: x = Floor(x) + Mod1(x).
Post
0 ≤ Mod1 < 1
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.