a!integerField() length validation issue

Hi Shubam,

While other practitioners have explained how to get around this problem, I will explain why it happened.

Why do you see the number is too large/number is too small:

1. Because Appian uses Java datatypes.

2. An Integer in Java datatype is 32 bits. 1 bit is reserved for the sign. So only 31 bits are avaialble to be used. All computers use the two's complement representation.

3. Hence maximum magnitude of a number is (2^31)-1 - which is equal to  2,147,483,647 

4. If you try the above number in a!integerField , you will get "number is too large"

5. But, if you try the number which is just one less than the above number i.e  2,147,483,646, no error will come.

6. So you can see , the max number is limited by the size of the CPU registers.

7. Now if you have a number larger than the max number,  the CPU will get an overflow exception. In this case, it will wrap it in negative numbers. So a number like  2,147,483,649 will be considered as -2 ( 2,147,483,647 - 2,147,483,649   )

8. That is why technically we can say - max allowed number (int) by Appian is  2,147,483,646. (See it has 10 digits). Note that 10 digit numbers greater than this number would also get validation error.

9. An underflow can occur when CPU encounters a very very negative number (big magnitude but negative sign).

10. In point 7, just consider that the user has entered a very very big number in the SAIL field. Twenty 1s as mentioned by you.. then the overflow exception will happen in CPU and CPU will actually think of it a negative number - but if the number was too big, the result will be considered a very big negative number ( 2,147,483,647  - 11111111111111111111)

11. That is why you got "number is too small" error.

12. By the way it seems Appian has fixed the latter part.

I am not sure what Appian version you tested on.

But, in Appian version I have Appian is behaving as per user expectation. For a very very large number (like twenty 1s) the error is still "value is too large".

Now note that from a CPU perspective: it is actually overflow and a very small value (large magnitude but negative sign), but for end user it is  a very large number.

So we have a interesting situation here: CPU is actually showing the correct error when it says number is too small. It is all because of the way numbers are stored in registers.

But for the end user it is not the same case. The end user and the CPU would be on same page only if the regsiters had infinite bits :-)

It seems Appian has fixed this -  so that for all numbers greater than  2,147,483,646 - you will simply get number is too large error. 

This is observed in Appian env that I have.

Hope this clarified the "why" part.

Also try the following SAIL code:

It will show "infinity" symbol in the Integer field.

But . you can enter the same number by hand - and it will give the validation error that  you got.

load(

local!num1: 2147483647,


a!integerField(
label: "Integer",
labelPosition: "ABOVE",
saveInto: local!num1,
value: local!num1,
refreshAfter: "UNFOCUS",
validations: {}
)

)

Hi Shubam,

While other practitioners have explained how to get around this problem, I will explain why it happened.

Why do you see the number is too large/number is too small:

1. Because Appian uses Java datatypes.

2. An Integer in Java datatype is 32 bits. 1 bit is reserved for the sign. So only 31 bits are avaialble to be used. All computers use the two's complement representation.

3. Hence maximum magnitude of a number is (2^31)-1 - which is equal to  2,147,483,647 

4. If you try the above number in a!integerField , you will get "number is too large"

5. But, if you try the number which is just one less than the above number i.e  2,147,483,646, no error will come.

6. So you can see , the max number is limited by the size of the CPU registers.

7. Now if you have a number larger than the max number,  the CPU will get an overflow exception. In this case, it will wrap it in negative numbers. So a number like  2,147,483,649 will be considered as -2 ( 2,147,483,647 - 2,147,483,649   )

8. That is why technically we can say - max allowed number (int) by Appian is  2,147,483,646. (See it has 10 digits). Note that 10 digit numbers greater than this number would also get validation error.

9. An underflow can occur when CPU encounters a very very negative number (big magnitude but negative sign).

10. In point 7, just consider that the user has entered a very very big number in the SAIL field. Twenty 1s as mentioned by you.. then the overflow exception will happen in CPU and CPU will actually think of it a negative number - but if the number was too big, the result will be considered a very big negative number ( 2,147,483,647  - 11111111111111111111)

11. That is why you got "number is too small" error.

12. By the way it seems Appian has fixed the latter part.

I am not sure what Appian version you tested on.

But, in Appian version I have Appian is behaving as per user expectation. For a very very large number (like twenty 1s) the error is still "value is too large".

Now note that from a CPU perspective: it is actually overflow and a very small value (large magnitude but negative sign), but for end user it is  a very large number.

So we have a interesting situation here: CPU is actually showing the correct error when it says number is too small. It is all because of the way numbers are stored in registers.

But for the end user it is not the same case. The end user and the CPU would be on same page only if the regsiters had infinite bits :-)

It seems Appian has fixed this -  so that for all numbers greater than  2,147,483,646 - you will simply get number is too large error. 

This is observed in Appian env that I have.

Hope this clarified the "why" part.

Also try the following SAIL code:

It will show "infinity" symbol in the Integer field.

But . you can enter the same number by hand - and it will give the validation error that  you got.

load(

local!num1: 2147483647,


a!integerField(
label: "Integer",
labelPosition: "ABOVE",
saveInto: local!num1,
value: local!num1,
refreshAfter: "UNFOCUS",
validations: {}
)

)

Thank you, Chetany. From my view, this workaround is a sloppy way for Appian do deal with this limitation, and I see it as a bug since there are other applications out there that have addressed this.

I wonder if there will be any fix for this in the future releases. We are using 20.1 now and the issue persists.

Thanks,

Roberta

Hi Chetany, It was very explanation. but it is not working for me.

{
a!sectionLayout(
label: "Section",
contents: {
a!localVariables(

load(
local!number:2147483647,
a!integerField(
label: "Phone Number",
labelPosition: "JUSTIFIED",
value: ri!number,
saveInto: ri!number,
validations: if(
length(local!number)>=10,{},
"Eneter 10 digits only."
)
)
)
)
}

getting below error. can you pls help on this

For a phone number, you should just use a text field (and save it as a text value).  The length() function you're trying won't work for a number data type, since numbers don't actually have a "length" in terms of character count.

Also, this is a very old thread -- if you're having a new issue you might consider creating your own new thread.