Problem description: Bigger integer usefull in libreoffice BASIC is Long (+2147483647) although Calc itself can deal with bigger integers. This means we cannot use cells containing numbers bigger than that in simple calculations such as: x MOD 10^n (must return last n digits of x) x+y x-y I think that the interpreter can use Calc's internal functions (I think so, not sure) to deal with a new data typ,e at least as big as Calc can handle. I am not talking here about big integers such as Mysql offers, just the ones that calc handles internally. Operating System: All Version: 4.1.0.4 release

(In reply to comment #0) > Problem description: > Bigger integer usefull in libreoffice BASIC is Long (+2147483647) although > Calc itself can deal with bigger integers. This means we cannot use cells > containing numbers bigger than that in simple calculations such as: > x MOD 10^n (must return last n digits of x) > x+y > x-y LibreOffice Calc operates on floating point numbers, and isn't as strong with integer math, especially with MODULO (see bug 50299). I'd definitely look into Sage or maybe Octave... > I think that the interpreter can use Calc's internal functions (I think so, > not sure) to deal with a new data typ,e at least as big as Calc can handle. > I am not talking here about big integers such as Mysql offers, just the ones > that calc handles internally. I believe that Calc is always operating on floating point numbers, regardless. Does the use-case really lend itself to use in a spreadsheet environment?

I have a LO BASIC script that converts arbitrary big numbers to greek words. (I have it also coded in python, in MS VB6, in gambas and as a command line for bash). It can also create "greek words" for currency numbers. The script can convert numbers bigger even of 10^21. In MS VB6 (where first coded), I used the string returned from text box and splitted the content. From a number cell, the LO BASIC script can only accept an integer up to +2147483647 (a small number if it comes for bank or country budgets). I use only MODULO 10,100 and 1000 in order to extract the last three digits involved in each step of convertion. I could use simple string split, but the number must be imported as string in a way that does not include scientific notation. If I can add two numbers greater than +2147483647 in two calc cells and have non erroneous results than I think that this can be done for LO BASIC also. (e.x. By passing to some random Calc cells the numbers and get from a third their sum). Of course if Calc itself has a bug in floating point arithmetic for integers used in cells, than my proposal for such an approach is also buggy. I do not know if it is safe to accept, in my function, floating point numbers (do not how they are converted inside LO BASIC to "digits"). But at least LO BASIC can include the 64 bit numbers (even just the signed ones which are 2^63 - 1).

Dear Bug Submitter, 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 INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/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 Message generated on: 2015-02-18

I will confirm that this is a true enhancement request. LibO Basic has signed Integer and Long types with dynamic ranges of 2^16 and 2^32. Although the actual ranges of Integer and Long are determined by build parameters the usual setup maintains Integer=16bit and Long=32bit for backwards compatability. I also confirm that Calc does normally use double precision floating point calculations for everything, which would not work for the purpose described in the original report. I also note that 64bit and infinite precision integers are available in other software. Basic inherited from OOo some of the internal workings for signed and unsigned 64 bit integers, including the touchy and crucial type constants. Much of the signed 64bit int fuctionality is already used by the existing Currency type. It is not only possible to add a 64bit integer type to Basic as an enhancement, it would be one of the easier types to add to the language.