BlackBox Framework Center

Thank you Josef and Robert. Now am I understanding this better.

The diffs are here: https://redmine.blackboxframework.org/p ... bd90a41bd0

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

Updated the code to reflect the new issue name:

Diffs: https://redmine.blackboxframework.org/p ... acfaf998fe

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

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.

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

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.

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

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.