What's the maximum integer allowable in Basic+ OI 7.x?

It varies.

Using AREV (which I am told has the same maths routines),

EVAL PRINT 2^49

doesn't resolve to scientific notation, yet

EVAL PRINT 10^15

which is smaller does resolve to scientific notation.

I think the maximum integer is in the vicinity of 10^14 (reliably, using integer precision), before a result might be cast into scientific notation.

There are in existence for Basic+ a library of handrolled routines for math on huge integers up to 400 digits and beyond. Slow, but accurate.

The problem usually becomes one of volume of transactions versus size of integer. Even for very large integers, using machine code, there are problems of size and volume.

Consider an *assembly* language program which counts from zero to a target number (say 2^42) using two 32 bit registers (no memory accesses involved). Something like:

MAIN SEGMENT

    ASSUME CS:MAIN,DS:MAIN,ES:MAIN,SS:MAIN

    ORG 100h

.486

START: jmp begin

begin:

clc

mov ecx,0

mov edx,0

outerloop:

inc edx

cmp edx,1024D

ja  exit

clc

innerloop:

add ecx,1

jnc innerloop

jmp outerloop

EXIT:

INT 20h

MAIN ENDS

END START

This will complete in about 32 minutes on a Pentium III 800 mHz, or about 10 minutes on a Pentium 4 3.0Ghz processor. To count up to 2^54 (nearly 10^51) would then take about 60 days!!!!!

If you add division or multiplication into the loops then the time is way longer again. Any memory accesses (non-register based data) increase the time over using plain old 32 bit CPU registers.

So if you encounter maths problems involving 200+ digit numbers, then you're looking at something that even when optimized, is way too great to contemplate without some "outside" assistance or parallel processing, unless you have a few hundred years to spare…

If you want to explore large numbers, and don't simply have an application problem, you might consider programs like PARI or MATHEMATICA - purpose built for pure maths problems.

What sort of task are you looking at?

I was fiddling around with a RLIST Callback to make CSVs with the first record being the column headers. The problem is that the column headers get repeated at the page breaks. If I set @LPTRHIGH to a large integer I can hopefully avoid the redundant column headers on page breaks.

Maybe an enhancement would be to set @LPTRHIGH ⇐ 0 to kill page breaks :)

I end up handcoding the programming in most reports anyway.

I was exploring generic means to produce CSVs, which is sort of moot since it has been added to Report Builder+/RUN_REPORT. However we probably won't be upgrading to 7.1 on the live system for some time.

I can use the CSV utility we have from REV G days, as well. I already modified it for OI.

View this thread on the Works forum...