Bug 81337 - BASIC: Long integer support
Summary: BASIC: Long integer support
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: BASIC-IDE Macro-StarBasic
  Show dependency treegraph
 
Reported: 2014-07-14 10:27 UTC by Ηλίας Ηλιάδης
Modified: 2021-02-02 12:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ηλίας Ηλιάδης 2014-07-14 10:27:18 UTC
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
Comment 1 Robinson Tryon (qubit) 2014-07-27 02:08:00 UTC
(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?
Comment 2 Ηλίας Ηλιάδης 2014-07-27 10:49:57 UTC
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).
Comment 3 QA Administrators 2015-02-19 04:34:41 UTC Comment hidden (obsolete)
Comment 4 LeMoyne Castle 2015-02-26 01:56:27 UTC
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.