Bug 81337 - BASIC: Long integer support
Summary: BASIC: Long integer support
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version: 4.1.0.4 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-14 10:27 UTC by Ηλίας Ηλιάδης
Modified: 2014-07-27 10:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

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).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.