Working with large numbers

Question

question

Diana Lubow asked Jun 10, '16 Logan Gold edited Jun 10, '16

Working with large numbers

I'm dealing with huge numbers and need to be able to select a random number between 1 and 6.8e17. When I try to do this using a uniform distribution, I don't get any numbers bigger than about 9 billion. Is there a good way to work with these really large numbers?

Software Version:

FlexSim 16.0.1

random large numbers

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 1 · 2016-06-10T17:42:36Z

Brandon Peterson answered Jun 10, '16 Ben Wilson edited Jun 10, '16

The 64-bit version of FlexSim should not have a problem with the numbers that you are trying to use. 6.8e17 should still have enough space in a double for decimal places.

I ran some tests using the script console and the following code:

double returnval = 6.8 * pow(10,17);
double maxvalue = 10000;
double temp;
for (int i1 = 1; i1 <= 1000000000; i1++) {
	returnval = min(returnval, uniform(0, maxvalue));
}
return returnval;

With maxvalue set to 10,000 the result was 0.8351.

With maxvalue set to 1,000,000 the result was 1.1325.

Withmax value set to 1,000,000,000 the result was 734896719.4557.

With maxvalue set to 6.8*pow(10,17) the result was 228457643985748290.0000.

Based on the above results I tried the following in the script console:

double minval = 6.8 * pow(10,17);
double maxval = 0;
double temp;
for (int i1 = 1; i1 <= 10000000; i1++) {
	temp = uniform(0, 6.8) * pow(10, duniform(1, 17));
	maxval = max(maxval, temp);
	minval = min(minval, temp);
}
pr(); pt("Min: "); pf(minval);
pr(); pt("Max: "); pf(maxval);

With the results:

Min: 0.000004
Max: 679999716281890940.000000

So, by changing the code a little I think you can get results closer to what you are looking for.

I hope this helps,

Brandon

P.S. That first block of code will take a while to run!

@anthony.johnson @phil.bobo

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 2 · 2016-06-10T16:28:55Z

Logan Gold answered Jun 10, '16 Logan Gold edited Jun 10, '16

We run into an issue with how many digits we can play with. This is a common problem with computers using floating point numbers and if you are at all interested in the specifics, you can find more information at https://en.wikipedia.org/wiki/Double-precision_floating-point_format. The gist of it is we have a limit to the number of digits we can use for one number, and the range of significant digits goes from 15 to 17.

I admit I'm not terribly familiar with the specifics, so I'm not sure why you can't get numbers greater than about 9 billion normally. However, we should be able to get numbers bigger than that as long as we don't use more than 15 to 17 significant digits and/or if there are zeros after the significant digits and before the decimal point. And I believe we can do what you want to do with some multiplication.

I believe you can use the uniform distribution to find a number between 0 and 1, then multiply it by the max we really want. So you can use the following expression to get a representation when the max is 6.8e17:

uniform(0,1) * 6.8 * pow(10,17) + 1

I have the plus 1 at the end so that we can't get a number less than 1. But since we're working at the limit of how many significant digits we can have, we'll probably lose out on some precision. That means the numbers may be biased to the bigger numbers, so you may need to validate your data if you can.

If you wanted this to be a uniform distribution, you would still need to use the uniform() command, but you can add a trunc() command to make sure all numbers are integers. It would be something like this:

trunc(uniform(0,1) * 6.8 * pow(10,17)) + 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

question