Modulo on long numbers

[rospondek]

Is there any bug in the Java Script Modulo?

I have to add to my form validation of an account number. The problem is that it is validating by modulo of 30 digits number. I did everything right but it came out that my accounts were wrong. Each one. So I checked one by one and looks like modulo is broken after reaching 24 digits.

Just check this validation script:

app.alert("10 digits - "+1000000000%10);
app.alert("20 digits - "+10000000000000000000%10);
app.alert("21 digits - "+100000000000000000000%10);
app.alert("22 digits - "+1000000000000000000000%10);
app.alert("23 digits - "+10000000000000000000000%10);
app.alert("24 digits - "+100000000000000000000000%10);

Any idea how to bypass that? I can't do anything else besides modulo by 97 to validate bank account.

[try67]

This is a limitation of the core JS language. Read this for more information:

https://www.w3schools.com/js/js_numbers.asp

[rospondek]

So no way to change the type to bigint or any other long number?

I'm trying to find anything but without any luck so far. There has to be a way cause I saw some forms which did that validation without problems.

[try67]

Are you sure the modulo needs to be done on the entire number? Can you post the instructions for it?

There is a BigInt object in JS but it was introduced in later versions. It might work in Acrobat/Reader DC, but not in earlier versions of the application.

[rospondek]

Yes, unfortunately it looks like that.

You have to take the whole account number (26 digits): 02116022020000000337985822 

Then you add the country code to the end (30 digits total): 021160220200000003379858222521

Then you move two front digits to the back: 116022020000000337985822252102 

And then you modulo the whole number by 97: 116022020000000337985822252102  % 97

If the result is 1 the account is verified positively.

So as you can see there is no way to take only the part of it. Or at least I do not see the possibility 😄

I tried with BigInt but it is not recognizable by Acrobat.

[rospondek]

Yes, unfortunately it looks like that.

You have to take the whole account number (26 digits): 02116022020000000337985822 

Then you add the country code to the end (30 digits total): 021160220200000003379858222521

Then you move two front digits to the back: 116022020000000337985822252102 

And then you modulo the whole number by 97: 116022020000000337985822252102  % 97

If the result is 1 the account is verified positively.

So as you can see there is no way to take only the part of it. Or at least I do not see the possibility.

I tried with BigInt but it is not recognizable by Acrobat.

[try67]

Then I'm afraid you can't do it, at least not inside the file itself. You can perform the validation on the receiving end, after exporting the form data from the PDF.

[Test Screen Name]

This is by design, not a bug. Exact arithmetic on very large numbers is very difficult indeed. You have to write (or find or buy) a library to do it, you cannot use any built in aithmetic operators. 

[try67]

I think it should still display some kind of error message when you try to do arithmetic that the language can't handle. It can't just spit out wrong results.

[try67]

PS. The degree of difficulty has nothing to do with it. It fails on even the most basic commands, like this:

10000000000000000000+1

The result is:

10000000000000000000

The issue is the size of the variable used to hold numbers, not the complexity of the operation.

[Test Screen Name]

"I think it should still display some kind of error message when you try to do arithmetic that the language can't handle. It can't just spit out wrong results."  No, the language is handling it exactly as defined. The only thing "wrong" is expectations, not the design or implementation of the language, which is common to most programming languages. (Not all; for example Python supports arbitrary precision integers). The limitations of IEEE real numbers are absolute; it's not even clear how you would define "can't handle" in this case. It IS handling it, just not as you might somehow wish it.

I don't understand your point about difficultly. I said it is very difficult to implement arbitrary length arithmetic. It isn't imposisble, but it can't be done using number objects. For example, you could store an array of decimal digits; adding these together is not so difficult, could probably have it working in a day, but I wouldn't want the job of implementing the % operator.

[Test Screen Name]

By the way I found this: https://github.com/MikeMcl/big.js/ - no idea if it can be adapted to the Acrobat JavaScript world.

[Test Screen Name]

Ok... more research. I assume this is the IBAN check algorithm. No need to reinvent the wheel, especially as it is such a complicated and difficult wheel: https://github.com/arhs/iban.js

[rospondek]

Thanks guys. I always thought that basic commands should be executed without any problems. These days operations on very big numbers are nothing new or uncommon and Modulo is one of the basic commands to get the needed or unneeded rest from the equation.

Looks like I have to leave this without any validation as I can't actually think of anything to change it or validate this offline on the other end. This, by design, had to work inside PDF and only using PDF forms and validation.

[Test Screen Name]

There is no substitute for detailed knowledge of the language, it’s limitations and numeric methods, especially when doing financial work. We often hear from people for whom doing what seems logical produces wrong results, and they are left not even able to add up a column of prices correctly.