Description: ОСТАТ(721^7;1517) give me 0 - non correct result correct result is 1012 os: Ubuntu 18 Steps to Reproduce: 1.ОСТАТ(721^7;1517) 2. 3. Actual Results: 1012 Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: ru Module: SpreadsheetDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 161158 [details] non correct working function "ОСТАТ()" (mod)
Created attachment 161159 [details] picture
Created attachment 161160 [details] picture
1. It is not locale relevant, in English locale =MOD(71^7, 1517) also gives 0. 2. It is also not surprising, as the upper limit of 64-bit unsigned integer is 2^64 = 1.84E+19, which 71^7 = 1.01E+20 exceeds. For such a formula to work properly Calc needs to deal with integer overflow correctly and have inner representations of variables larger than "unsigned int" if necessary.
(In reply to Ming Hua from comment #4) > 1. It is not locale relevant, in English locale =MOD(71^7, 1517) also gives > 0. I get 662 in Version: 7.1.0.0.alpha0+ Build ID: 42bf9bdf3d551eb59604f952204c49f7d7a1e913 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Gennady, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #5) > (In reply to Ming Hua from comment #4) > > 1. It is not locale relevant, in English locale =MOD(71^7, 1517) also gives > > 0. I made a typo in comment #4, it should be 721^7, not 71^7. > I get 662 in > > Version: 7.1.0.0.alpha0+ > Build ID: 42bf9bdf3d551eb59604f952204c49f7d7a1e913 > CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded Can you test again with formula "=MOD(721^7, 1517)"? It gives 0 for me on 6.4.5: Version: 6.4.5.2 (x64) Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded
I got 0 in Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL Mike, what's your opinion here?
As explained in comment 4, it's the limitation of number representation in Calc (but note that Calc uses IEEE 754 64-bit floating point number, which means that integer range in Calc is limited to 53 bit, with upper limit of 9.01E+015, not 64 bit - so even farther from the needed range than mentioned 2^64). Since this is technology limitation, this is not a bug.
But a bug is that the formula does not error out. E.g., Excel gives #NUM.