[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #9 from e...@helpidea.net --- Thank you Alain for your suggests. In my 30 thousand code rows app, the general function structure is Basic --> Array --> python --> Array --> Basic for improve the faster execution. For me it is not good idea for each array value in Python call an LO API service, maybe I will add a little number like : round(x + 10**-(digits+3), digits), or the classic Round = Int(x * 10 ^ digits + 0.5) / 10 ^ digits What do you think? And about the bug (or incompatibility), it is not correctable? By Nicola -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #8 from Alain Romedenne --- Hi Edil, I suggest you use Calc rounding - Round, RoundDown, RoundUp - functions instead of user defined functions: https://help.libreoffice.org/latest/en-US/text/scalc/01/04060106.html?=CALC ScriptForge Session service ExecuteCalcFunction() method provides such programming facility.. https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03/sf_session.html?DbPAR=BASIC .. and is based on "com.sun.star.sheet.FunctionAccess" UNO service. Refer to https://help.libreoffice.org/latest/en-US/text/sbasic/shared/calc_functions.html?DbPAR=BASIC#bm_id291592361063458 if you still require to resort to BASIC. Hope that helps -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #7 from e...@helpidea.net --- Thank you Buovjaga and Alain Romedenne for help me, I apologize if you think I wasn't polite. I thought LO cell.Value as Double and Python floating point number, both 8 bytes was from IEEE 754. My app use for big ranges and complex calculation Range.DataArray to get an Array(Array()) of values from Calc Sheet, call python function for process them as argument and round results, and return an array(array()) to set values in the same sheet range. This make my routine very fast. The problem is that python must round some numbers ad then multiply them to other number, so the round difference is important. Do you have any idea to solve this behavior, or work around ? Is this a bug o simplicity -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #6 from Alain Romedenne --- Edil, You're obviously tackling a complex topic here! The difference LIES in the way Python and Basic store FP numbers, as well as in the way libO Scripting Framework converts FP numbers from a language to another. One needs such information to fully diagnose your bug. I would strongly advise to use Calc cells content - for Python & Basic tests - to guarantee that input numbers share identical FP formats. As well as I would resort to Calc rounding functions for your very case. more in: https://en.wikipedia.org/wiki/Floating-point_arithmetic PS: Observe the steps to reproduce such anomaly aren't precise enough, please amend them instead of pointing fingers the person assisting you.. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 Buovjaga changed: What|Removed |Added CC||alain.romedenne@libreoffice ||.org --- Comment #5 from Buovjaga --- Alain: any idea about this? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 e...@helpidea.net changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from e...@helpidea.net --- Dear Buovjaga, why don't you test in the same my environment (windows) and in the same location (user) ? "The statement BASIC runtime error. Argument is not optional pointing to line vRoundUp = oScript.invoke(Array(num, dec), Array(), Array()) " i think simplicity to try : oScript.invoke(Array(num, dec, 5), Array(), Array()) If you know a better code or advice to obtain the round up, please notice me. Thank you -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #3 from QA Administrators --- Dear edil, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 Buovjaga changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO Whiteboard| QA:needsComment| CC||ilmari.lauhakangas@libreoff ||ice.org --- Comment #2 from Buovjaga --- I copied it to instdir/share/RoundUP.py as: from decimal import Decimal, getcontext, ROUND_HALF_UP # # Round UP round_context = getcontext() round_context.rounding = ROUND_HALF_UP # - def roundUp(x, digits, precision=5): tmp = round(Decimal(x), precision) fRet = float(tmp.__round__(digits)) return fRet # --- if __name__ == '__main__': fRU = roundUp(2.125, 2) # -> 2.13 fRU = roundUp(3.125, 2) # -> 3.13 fRU = roundUp(-2.125, 2) # -> -2.13 fRU = roundUp(4.125, 2) # -> 4.13 fRU = roundUp(2.225, 2) # -> 2.23 pass Accordingly, in the Basic script I changed the location to share: sFunctionPy = "vnd.sun.star.script:RoundUP.py$roundUp"& _ "?language=Python=share" When I run it, I get BASIC runtime error. Argument is not optional pointing to line vRoundUp = oScript.invoke(Array(num, dec), Array(), Array()) Please advise. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f0ff4243d45b11f372a2ed824fbb8806de9cb595 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 17 March 2023 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 QA Administrators changed: What|Removed |Added Whiteboard|| QA:needsComment -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152739] Round ROUND_HALF_UP is OK in Python, but NO in Basic when call the same Python def.
https://bugs.documentfoundation.org/show_bug.cgi?id=152739 --- Comment #1 from e...@helpidea.net --- Created attachment 184399 --> https://bugs.documentfoundation.org/attachment.cgi?id=184399=edit macro -- You are receiving this mail because: You are the assignee for the bug.