Next thinBasic: how numeric tokens are stored internally

[ErosOlmi]

In next thinBasic release, all numbers specified inside a script, will be stored as DOUBLE instead of EXTENDED numbers.

Example:

DIM MyVar AS LONG
MyVar = 1

thinBasic store "1" as a numeric EXTENDED value in an internal structure in order to be faster the next time the same token is parsed.
Storing as DOUBLE seems a little advantage (10 bytes EXT against 8 bytes DOUBLE) but when numbers are inside loops (and it happens a lot of times) it can be a signficative improve. Also I've not seen any script so far that requiires to store a numeric value with the magnitude of EXT numeric data.

Do you see any problems?

Thanks a lot
Eros

[GSAC3]

Eros:

Will all internal numerical calculations still be performed in EXTENDED?

If not, will the use of EXTENDED still be available, as an option, for performing calculations at higher precision?

Don

[Petr Schreiber]

I am with Don,

it would be nice to have EXT variable when declared AS EXT, for the rest DOUBLE is ok.


Petr

[ErosOlmi]

Yes, all internal calculation are always performed at the maximum precision, that is EXTENDED.

The change will only influence how the "clear text" numbers indicated in the scripts are stored and not how they are used for calculation.

[GSAC3]

Eros:

I am not clear yet regarding how inputted and/or computed numerical variables can be stored under your proposed change.

For example, will it be possible to specifically declare a variable (either inputted or computed in the program) as EXTENDED so that it is stored in the program as EXTENDED?

I particular, I am concerned about loosing computed precision if EXTENDED computed values are temporarily stored in program variables unless these program variables are also EXTENDED. For example, obital calculations frequently require high precision temporary storage between computational steps; otherwise the computed precision is lost if the computations are stored in variables of lesser significance.

Don

[ErosOlmi]

I am not clear yet regarding how inputted and/or computed numerical variables can be stored under your proposed change.


Hi Don,

here I'm not referring to "variables" but to numbers present in source script. There will not be any loosing precision in any calculation. Variables will be stored and handled with the precision of the type used when variables are declared (LONG, DOUBLE, EXT, ... whatever). All internal intermediate calculations are always done with the highest precision avaliable in thinBasic, that is EXTENDED. And this will continue.

New way of handling "source code numbers" has just to do the parsing process not calculations during execution. When thinBasic loads a source code, a big part is parsing every source tokens. Every token is than stored and optimized in internal data structures in order to be fast to retrieve them when needed. One of those token class is "numbers", all the numbers present in source code: 1, 10000, 0.0003, 1234.567890123, ... whatever. Those numbers are not parsed every time but are stored in temp areas. Currently those areas are dimensioned as 10 bytes with EXTENDED precision. In new version those numbers will be stored in 8 bytes with DOUBLE precision. DOUBLE precision has a range from 4.19x10^-307 and 1.79x10^308 (see thinBasic help at http://www.thinbasic.com/public/products/thinBasic/help/html/numericvariables.htm ) so enough for whatever number I've seen in any script so far.

Hope to have cleared the doubts, otherwise ask again or please provide a piece of source code example to check and I will make tests.

Ciao
Eros

[GSAC3]

Eros:

Thank you for your clarification. I understand what you are proposing now.

Don

[GSAC3]

Eros:

If I understand you correctly, the following syntax would no longer store the two 18 significant figure values under your proposed change.

DIM DR AS EXT VALUE = 0.0174532925199432957 '18 significant digits
DIM RD AS EXT VALUE = 57.2957795130823209 '18 significant digits

Instead, only the first 16 significant figures would be stored in the two variables.

Don

[ErosOlmi]

Result will be the following:


uses "CONSOLE"

DIM DR AS EXT VALUE = 0.0174532925199432957 '18 significant digits
DIM RD AS EXT VALUE = 57.2957795130823209 '18 significant digits

printl "DR=" & str$(DR, 18)
printl "RD=" & str$(RD, 18)
waitkey

'---Output:
'DR= 1.74532925199432957E-2
'RD= 57.2957795130823209


Are you using those kind of figures? What do you use thinBasic for?

Ciao
Eros

[ErosOlmi]

Stupid question mine :-[



uses "CONSOLE"

printl "Radians(180)=" & radians(180)
printl "Degrees(Radians(180))=" & Degrees(Radians(180))
waitkey


function radians(deg as ext) as ext
function = deg * .0174532925199432957
end function

function degrees(rad as ext) as ext
function = rad * 57.29577951308232103
end function

[ErosOlmi]

Eros:

If I understand you correctly, the following syntax would no longer store the two 18 significant figure values under your proposed change.

DIM DR AS EXT VALUE = 0.0174532925199432957 '18 significant digits
DIM RD AS EXT VALUE = 57.2957795130823209 '18 significant digits

Instead, only the first 16 significant figures would be stored in the two variables.

Don



Yes, Don, you are right: there will be a lost of calculation precision if working with those numeric constants.
I'm reconsidering a bit my decision.

[GSAC3]

Eros:

Thanks again for the clarification.

I use ThinBasic to write high precision functions and routines for planetary orbital calculations and other mathematical applications.

Don

[ErosOlmi]

Hi Don,

I will think again on how to store numbers. I need to find a clever idea on storing each litteral number present in script using the needed precision. I mean, if parser find a "1" it can store it as LONG. If it finds a "1.123456" it can store as DOUBLE. If it finds a "0.123456789012345678" it must use an EXTENDED.

The original ideas started from looking code like the following dummy example:


'...
FOR Counter = 1 to Whatever
MyResult = MyVar * 100 / (AnyVar + 12.34)
NEXT
'...

Inside the FOR loop there are 2 literals: 100 and 12.34
Each of them is currently stored into an EXT, 10 bytes. If "Whatever" is for example a number equal to 100000, the two literals will be read 100000 times each, that is a total of 2 millions bytes (2 literals * 10 bytes * 100000 times)

Matters for future versions.

Ciao
Eros

[GSAC3]

Eros:

Good luck in solving this issue. It is certainly a worthwhile effort.

Don

[ErosOlmi]

Idea set on hold.
Post closed. Maybe I will revamp in future.