What value can cause this error?

[alexandru]

I got this error message from a customer and no further information is
available.
What could have caused this error?

integer value too large to represent
while executing
"expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}"

I know that "val" is a proper number and that "decimals" is 6.

I tried to run this expression with very high "val" values and could not
reproduce the error.

Many thanks
Alexandru

[Rich]

Post by alexandru
I got this error message from a customer and no further information is
available.
What could have caused this error?
integer value too large to represent
while executing
"expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}"
I know that "val" is a proper number and that "decimals" is 6.
I tried to run this expression with very high "val" values and could not
reproduce the error.

Are you *absolutely* sure that decimals is 6, because I can generate
the error via a smallish change to decimals:

$ rlwrap tclsh
% set val 123
123
% set decimals 999
999
% expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}
integer value too large to represent
% set tcl_patchLevel
8.6.12

[alexandru]

Actually yes, I'm sure.
I have the errorInfo that shows the stack of procedure calls.
The procedure is called with "decimals" equal to 6.
The the error is thrown.
The errorInfo does not show the value of variable arguments, so I don't
know that "val" was.
I also checked my source code an all the calls to that procedure never
use higher values than 6 for the second argument.
Here is the complete procedure:

proc NumberReadmm {val {decimals 3}} {
if {![string is double -strict $val]} {
return $val
}
return [expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}]mm
}

Here is the errorInfo:

*** ERROR ***
Time: Monday, das 16 von September, 2024, um 13:24:37
integer value too large to represent
while executing
"expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}"
(procedure "NumberReadmm" line 5)
invoked from within
"NumberReadmm $contact_offset 6"
(procedure "ContactOffsetFormat" line 7)
invoked from within
"ContactOffsetFormat $contact_offset_min"
(procedure "UIRelationApplyContactOffset" line 45)
invoked from within
"UIRelationApplyContactOffset %W"
invoked from within
".valid.notebook.f5.buttons.b2 invoke "
invoked from within
".valid.notebook.f5.buttons.b2 instate !disabled {
valid.notebook.f5.buttons.b2 invoke } "
invoked from within
".valid.notebook.f5.buttons.b2 instate pressed {
valid.notebook.f5.buttons.b2 state !pressed;
valid.notebook.f5.buttons.b2 instate !disabled { .valid..."
(command bound to event)

[Rich]

Post by alexandru
Actually yes, I'm sure.
I have the errorInfo that shows the stack of procedure calls.
The procedure is called with "decimals" equal to 6.

A very large number in val can also trigger the same error, even with
decimals at 6:

$ rlwrap tclsh
% set decimals 6
6
% set val 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
% expr {round($val*(10.0**($decimals+3)))/(10.0**$decimals)}
integer value too large to represent
%

So if you are certian decimals is 6, then a very large number is
ending up in val somehow.

[alexandru]

Ok thanks, I did tried very large values, but I gave up trying to early,
as no error came.

[Christian Gollwitzer]

Post by alexandru
Ok thanks, I did tried very large values, but I gave up trying to early,
as no error came.

You get this for an infinite argumment:

(chris) 69 % expr round(Inf)
integer value too large to represent

Christian

[alexandru]

Thanks Christian!
I'll implement this check.