https://bugs.documentfoundation.org/show_bug.cgi?id=99996
--- Comment #7 from Wolfgang Jäger <j...@psilosoph.de> ---
(In reply to Laurent BP from comment #6)
Many thanks for giving me this insight, but there may be a misunderstanding.
I would neither start to work on code in C++ (I always judged very ugly) at the
age of 72 nor would I shift to the kind of designing and coding algorithms
based on a next to complete encyclopedical knowledge of related mathematics. My
style always was to rely on means as simple as possible, and to try to apply
them in a slightly creative way.
I did not yet analyze the code you linked to, and probably I wouldn't at all.
But I know that for many centuries now best approximations by fractions were
found based on developing the target value into a regular continued fraction.
As there is an indisputable worst case, we can give a fix maximum of steps
needed to convert any number to any given accuracy. For IEEE 754 accuracy e.g.
this number is 36. The experimentally determined average for denominators up to
9999 is less than 10. The number of needed steps will increase very slowly with
greater denominators permitted. The expense for any single step on this way is
mainly a Double division. The loop may be exited based on a maximum denominator
or on a condition directly aiming at relative accuracy (higher time-cost in
this case: mainly 3 multiplications per step).
The code for a reliable implementation of this algorithm in LibO BASIC, e.g. is
less than 90 lines in a very sparse notation, and is already implementing both
ways of controlling the exit from the central loop. Restricting the condition
to a maximum denominator only will cut length and complexity.
If there is evidence that this algorithm is too inefficient or too complicated,
I cannot contribute anything more concerning this issue. Otherwise I will be
glad to supply my proposal in a Pseudocode, in fully operative BASIC or in
Pascal at your choice. I cannot do it using C++ (or any flavour of C).
>
> Fractions are determined in SvNumberformat::ImpGetFractionOutput here: ...
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
