Text to number conversion of large numbers

Replies to This Discussion

Permalink Reply by Armin Seltz on March 31, 2016 at 8:09am

The problem is, that numbers work differently to text, which can be almost infinitely long. Numbers can't. If GH is using 64bit numbers, then longest number you can have is 2 ^ 63 - 1 or 9,223,372,036,854,775,807 ie. a number that is 19 digits long.

Since GH is displaying numbers by default with the .0 at the end, I would say that removes 2 digits giving a maximum of 17 digits. Right now it seems to "break" the conversion after the 16th digit. So, close enough. 

This is still partly speculation, but makes sense.

But the real question would be why you need to identify more than 9 quintillion objects!? Are you trying to recreate the universe in GH? ;)

Permalink Reply by Pieter Segeren on March 31, 2016 at 8:10am

Hi Ludvig,
check here:
Data Type Ranges

Permalink Reply by David Rutten on March 31, 2016 at 8:19am

Grasshopper use Double Precision Floating Point numbers for anything requiring decimals, the upper limit of 'doubles' is about 10^300 which is way bigger than your numbers here. However doubles are based on scientific notation which means you get about 16 decimal places to play with. So if you convert a very large integer 10505151515052515051015200005201505052015 into a double it will take the first 16 digits and turn it into 1.0505151515052515 * 10^40. that's why you're getting all those zeroes. For big numbers like this, the distance between two adjacent double values can be much bigger than 1.0

When dealing with integers, Grasshopper uses 32-bit signed integers, that go from roughly -2billion to +2billion. That's clearly much too small to contain your value.

You will either need to stick to strings or switch to arbitrary sized integers. This requires custom coding in Python, or possibly C#.

Permalink Reply by Ludvig Haav on March 31, 2016 at 8:32am

Thanks to the both of you for fast response. I will need to work around it by splitting it up then.

The reason for such a large number is because it im mapping the UV position of 5 windows on walls. Each window is created from two points in its wall UV space. Each point needs 4 digits. That is eight digits per window. It just adds up... :(

Ahh soo much data management.. :/

Permalink Reply by Ludvig Haav on March 31, 2016 at 8:55am

Oh, thanks to the three of you that is. Very thorough response indeed! Hope it serves more ppl as well.

Permalink Reply by Mahdiyar on March 31, 2016 at 9:12am

As David mentioned, you can use "BigInteger" data type in C# to work with arbitrarily large signed integer. It's not complicated (at least for simple mathematical processes). here is an screenshot:

To work with "BigInteger" data type you must add "System.Numerics.dll" as an assembly to your C# component. It's easy, just right-click on the C# component, select "Manage Assemblies...", and then click on the "add" link to specify the location of "System.Numerics.dll" on your computer.

Here I've attached the dll file and a very simple example.

Attachments:

• System.Numerics.dll, 135 KB

Permalink Reply by Mahdiyar on March 31, 2016 at 9:15am

Sorry, I forgot to attach the example file.

Attachments:

• BigInteger.gh, 10 KB

Permalink Reply by Rémy Maurcot on March 31, 2016 at 9:30am

Thanks for your sharing, very cool !

Permalink Reply by Ludvig Haav on March 31, 2016 at 9:36am

Thanks!

However, I need to feed the large number to Octopus, which only listens to the number component. So in my specific case im better off doing a pre split and post merge work around.

I will save this for reference though..