https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #16 from Commit Notification
---
Vladislav Tarakanov committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":
https://git.libreoffice.org/core/commit/ea5dbb6e3dd2fdb84cf68d95174c183aae34488c
tdf#139
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
Commit Notification changed:
What|Removed |Added
Whiteboard|target:24.2.0 |target:24.2.0
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
Vladislav Tarakanov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #15 from Commit Notification
---
Vladislav Tarakanov committed a patch related to this issue.
It has been pushed to "master":
https://git.libreoffice.org/core/commit/3f96f9cdd542bcc05cdd531da3c35bc6f0c2986b
tdf#139306 Incor
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
Commit Notification changed:
What|Removed |Added
Whiteboard||target:24.2.0
--
You are
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #14 from Mike Kaganski ---
(In reply to Amin Irgaliev from comment #13)
Please create a gerrit change; and in it, please provide comments with
estimations which number range can be for every case, and why. This way, you
can s
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #13 from Amin Irgaliev ---
(In reply to Mike Kaganski from comment #12)
> (In reply to Amin Irgaliev from comment #11)
>
> I mean, that in comment 9, you did not provide the whole set of possible
> situations, and thus, did n
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #12 from Mike Kaganski ---
(In reply to Amin Irgaliev from comment #11)
I mean, that in comment 9, you did not provide the whole set of possible
situations, and thus, did not prove that there will never be a too large
nDecPla
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #11 from Amin Irgaliev ---
(In reply to Mike Kaganski from comment #10)
> (In reply to Vladislav Tarakanov from comment #9)
>
> The list you provided does not cover everything - e.g., _F outside of the
> limits described in #
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #10 from Mike Kaganski ---
(In reply to Vladislav Tarakanov from comment #9)
The list you provided does not cover everything - e.g., _F outside of the
limits described in #2. Can you provide a complete list of possibilities?
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #9 from Vladislav Tarakanov ---
Looked at the code again. As a result, the question arose, is it necessary to
do this rounding at all (std::clamp(nDecPlaces, -20, 20))? We looked
at the values that nDecPlaces can get before th
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #8 from Mike Kaganski ---
(In reply to Vladislav Tarakanov from comment #7)
The "E-14" comes from the implementation of rtl_math_StringFormat_Automatic
(see its logic in the same function), where it tries to choose the "optim
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #7 from Vladislav Tarakanov ---
Maybe I really miscalculated.
14: E-14 is the last degree value after which a number from 0.123456 starts to
be displayed as 0.654321E-15 in the edit line. When E-14 is entered, the output
line
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #6 from Mike Kaganski ---
(In reply to Vladislav Tarakanov from comment #5)
> We got the number 36 from the sum of two values: the count of characters
> displayed before 'E' in cells (22) and the maximum count of the degree,
>
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #5 from Vladislav Tarakanov ---
(In reply to Mike Kaganski from comment #4)
> (In reply to Vladislav Tarakanov from comment #3)
>
> Yes, you found the correct line. The question is: what change do you
> suggest? Simply increa
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #4 from Mike Kaganski ---
(In reply to Vladislav Tarakanov from comment #3)
Yes, you found the correct line. The question is: what change do you suggest?
Simply increasing the value from 20 to 36 (why 36? we only show up to 1
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #3 from Vladislav Tarakanov ---
This error is still reproducible. Check with:
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 160ea29f0003812ab1d4e1f6689c608c879ef509
CPU threads: 12; OS: Linux 6.1; UI re
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
BogdanB changed:
What|Removed |Added
CC||buzea.bog...@libreoffice.or
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
--- Comment #2 from b. ---
@JBF: hmmm ... may be you missed the point ... e.g.
'6.7431640621012300E-11' is shown as a cells value, but
'0.006743164062' is shown in the formula bar, and the same is offered
for edi
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
Jean-Baptiste Faure changed:
What|Removed |Added
CC||jbfa...@libreoffice.org
https://bugs.documentfoundation.org/show_bug.cgi?id=139306
QA Administrators changed:
What|Removed |Added
Whiteboard|| QA:needsComment
--
You are
21 matches
Mail list logo
