topic Re: Numerical parameters digit limit in GDL

Numerical parameters digit limit

Piotr Dobrowolski — Mon, 07 Sep 2026 12:37:03 GMT

I am kind of surprised with a thing that i noticed while loading data via text addon. At first I thought it is a limit of the addon...but it turns out that GDL has a limit of digits. I needed to process INT numbers like 1000000000000 (needed for filtering some features of a product) and it seems that GDL can handle only 1000000000. I have never seen any info about it... So in case someone stepped on funny results of loading external data this limit can be a reason.

Operating system used: Windows 11

Re: Numerical parameters digit limit

Pertti_Paasky — Mon, 07 Sep 2026 14:39:56 GMT

i tried to open an IFC-file (yes, it is a textfile] in gdl object. The file contained terrain in

EUREF-FIN / ETRS-GK26FIN coordinate system

1st two rows:

id xcoord ycoord zcoord
8025672 477183839.999 7212389619.967 21070

-the coordinates are millimeters, not meters.

My object could read xcoord and zcoord correctly. but the ycoord gave negative values.

Re: Numerical parameters digit limit

rudl — Mon, 07 Sep 2026 15:20:46 GMT

Limits are to be expected

If its not actually a "Int numbers but features??" then splitting or use a string should work.

Coordinates.
Preprocess it, substract minx miny minz from coords,

and write minx miny minz as locked parameter.
Don't see a reason for a GDL object to process numbers that big.

Re: Numerical parameters digit limit

Piotr Dobrowolski — Mon, 07 Sep 2026 16:44:20 GMT

Exceeding 2000000000+ something will load the negatives. I tried to use the internal variables and do some modulo operations to bypass eventual limit, but the limit is also in the internal variables. It is not regarding INT numbers, but ANY numbers...

Betreff: Numerical parameters digit limit

runxel — Mon, 07 Sep 2026 17:14:08 GMT

Yeah I found out about that by accident as well.

GDL only uses what's called "Long Int" (or sometimes referred to as "MAX32") – that's a signed 32 bit integer.

So "2'147'483'647" is the highest possible number, and going over that will cause an overflow. Numbers below "-2'147'483'648" will cause an underflow accordingly.

If you need integers bigger than that: You don't.

(However, the workaround is to use floats instead. They can go larger and will just experience a loss of precision; = the available "depth" of the decimal fraction shrinks. That will yield you numbers up until 2^53. Not too bad.)