## Large Numbers

### Large Numbers

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

### Re: Large Numbers

John,

For something like the Erlang-B function the most robust way to handle it is to implement it as a GAMS extrinsic function. For more on extrinsic functions, check Appendix J of the GAMS User Guide or here: http://www.gams.com/mccarl/mccarlhtml/e ... ctions.htm.

The short version is that this is a way to implement a complicated function with special handling for overflow cases, etc., in a programming language like C/C++/F90 and make this available to your GAMS code. Once you've got it programmed, the function can be used in a manner similar to the GAMS intrinsic functions like cos and sin and sigmoid. If you're used to programming and creating shared libraries, etc., then this shouldn't be a big deal, since we provide some examples with the GAMS system.

I've seen this request, or one much like it, before. In your case, are you treating the number of trunks as a variable or a constant in your model? I ask because it wouldn't be too hard to take a derivative wrt the volume of inbound calls, but doing so wrt the number of trunks seems to be a bigger challenge.

-Steve

On Mon, Apr 21, 2014 at 1:31 PM, John Ryan wrote:

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

--

Steven Dirkse, Ph.D.

GAMS Development Corp., Washington DC

Voice: (202)342-0180 Fax: (202)342-0181

sdirkse@gams.com

http://www.gams.com

For something like the Erlang-B function the most robust way to handle it is to implement it as a GAMS extrinsic function. For more on extrinsic functions, check Appendix J of the GAMS User Guide or here: http://www.gams.com/mccarl/mccarlhtml/e ... ctions.htm.

The short version is that this is a way to implement a complicated function with special handling for overflow cases, etc., in a programming language like C/C++/F90 and make this available to your GAMS code. Once you've got it programmed, the function can be used in a manner similar to the GAMS intrinsic functions like cos and sin and sigmoid. If you're used to programming and creating shared libraries, etc., then this shouldn't be a big deal, since we provide some examples with the GAMS system.

I've seen this request, or one much like it, before. In your case, are you treating the number of trunks as a variable or a constant in your model? I ask because it wouldn't be too hard to take a derivative wrt the volume of inbound calls, but doing so wrt the number of trunks seems to be a bigger challenge.

-Steve

On Mon, Apr 21, 2014 at 1:31 PM, John Ryan wrote:

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

--

Steven Dirkse, Ph.D.

GAMS Development Corp., Washington DC

Voice: (202)342-0180 Fax: (202)342-0181

sdirkse@gams.com

http://www.gams.com

### Re: Large Numbers

Steve thanks for the quick response. I should clarify it is actually the inbound volume that I have increased to 690 calls per interval. There is a pre model process that examines this inbound volume over a number of trunk levels, generally trunks from 1 - 1000 and calculates the probability of a blocked call for each trunk level. The actual optimization model is quite simple in that it selects the minimum number of trunks that meets the service goal and then calculates the right mixture of network trunks based on the pricing for the various network termination types (DS0, DS1, DS3, SIP ...) from the telco's. Basically this is a way to use a MIP model to solve a non-linear problem by pre calculating all the non-linear stuff up front and then selecting from the matrix created. I am not exactly sure at what number of trunks the model breaks and I assume the 690^number of trunks is what hits the ceiling.

I will look at the suggestions you have made, but it also would be helpful to know the limit and if there is any ability to adjust it.

On Monday, April 21, 2014 12:31:13 PM UTC-5, John Ryan wrote:

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

### Re: Large Numbers

John,

If you work with numbers that have magnitude wrote:

Steve thanks for the quick response. I should clarify it is actually the inbound volume that I have increased to 690 calls per interval. There is a pre model process that examines this inbound volume over a number of trunk levels, generally trunks from 1 - 1000 and calculates the probability of a blocked call for each trunk level. The actual optimization model is quite simple in that it selects the minimum number of trunks that meets the service goal and then calculates the right mixture of network trunks based on the pricing for the various network termination types (DS0, DS1, DS3, SIP ...) from the telco's. Basically this is a way to use a MIP model to solve a non-linear problem by pre calculating all the non-linear stuff up front and then selecting from the matrix created. I am not exactly sure at what number of trunks the model breaks and I assume the 690^number of trunks is what hits the ceiling.

I will look at the suggestions you have made, but it also would be helpful to know the limit and if there is any ability to adjust it.

On Monday, April 21, 2014 12:31:13 PM UTC-5, John Ryan wrote:

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

--

Steven Dirkse, Ph.D.

GAMS Development Corp., Washington DC

Voice: (202)342-0180 Fax: (202)342-0181

sdirkse@gams.com

http://www.gams.com

If you work with numbers that have magnitude wrote:

Steve thanks for the quick response. I should clarify it is actually the inbound volume that I have increased to 690 calls per interval. There is a pre model process that examines this inbound volume over a number of trunk levels, generally trunks from 1 - 1000 and calculates the probability of a blocked call for each trunk level. The actual optimization model is quite simple in that it selects the minimum number of trunks that meets the service goal and then calculates the right mixture of network trunks based on the pricing for the various network termination types (DS0, DS1, DS3, SIP ...) from the telco's. Basically this is a way to use a MIP model to solve a non-linear problem by pre calculating all the non-linear stuff up front and then selecting from the matrix created. I am not exactly sure at what number of trunks the model breaks and I assume the 690^number of trunks is what hits the ceiling.

I will look at the suggestions you have made, but it also would be helpful to know the limit and if there is any ability to adjust it.

On Monday, April 21, 2014 12:31:13 PM UTC-5, John Ryan wrote:

What is the limitation in GAMS with respect to the largest number it can handle. I am looking at an ErlangB equation implementation where a subset of the formula is structured as [InboundCalls^number of trunks/Fact(number of trunks]. As the number of trunks increases I eventually receive an error message of "overflow in + operation (addop) and overflow in * operation (mulop)". It appears as the trunk number is increased to approximately 695, then the model is generating a number that is to large and you get the overflow error. I would appreciate any suggestions on how to expand the limitation on the upper bound or any other suggestions.

Thanks,

--

To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.

To post to this group, send email to gamsworld@googlegroups.com.

Visit this group at http://groups.google.com/group/gamsworld.

For more options, visit https://groups.google.com/d/optout.

--

Steven Dirkse, Ph.D.

GAMS Development Corp., Washington DC

Voice: (202)342-0180 Fax: (202)342-0181

sdirkse@gams.com

http://www.gams.com

### Re: Large Numbers

Hi,

My problem is very similar to above. I get Error: overflow in + operation (addop)

I was trying to find a solution to the summation I use in the equation (red line), but I couldn't find a solution with the similar problem. You can see that I use two "T"-temporary variables first to do this summation step by step. Before, I summed up over three dimensions at one time.

See the attachment below.

Best,

Irena

My problem is very similar to above. I get Error: overflow in + operation (addop)

I was trying to find a solution to the summation I use in the equation (red line), but I couldn't find a solution with the similar problem. You can see that I use two "T"-temporary variables first to do this summation step by step. Before, I summed up over three dimensions at one time.

See the attachment below.

Best,

Irena

### Re: Large Numbers

Hi,

it seems that the result of the assignment statement is > 1E300 which causes an overflow. Are you sure that you need such large numbers. And are you sure that you found the right line in your code? With include files this can be tricky, so I suggest to check the line number in the echo print of the input file https://www.gams.com/latest/docs/UG_GAM ... eInputFile

I hope this helps!

Fred

it seems that the result of the assignment statement is > 1E300 which causes an overflow. Are you sure that you need such large numbers. And are you sure that you found the right line in your code? With include files this can be tricky, so I suggest to check the line number in the echo print of the input file https://www.gams.com/latest/docs/UG_GAM ... eInputFile

I hope this helps!

Fred