missing accuracy

General development discussion.

Moderators: Susan Smith, admin, Gabriel

Post Reply
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

missing accuracy

Post by John »

I ran into a problem where my 17 digit numeric bank account codes are converting their last two digits to zeros. Here is a sample program that demonstrates it

Code: Select all

1 dim x$*64
2 x$='12345678901234567'
3 do
4 	pr f str$(lc+=1)&',2,c': 'take '&str$(takeCount+=1)
5 	rin f str$(lc+=1)&',2,17/#PIC(-----------------),T[textboxes],300': x$
6 	pr  f str$(lc+=1)&',2,17/#PIC(-----------------),T[textboxes]': x$
7 loop until fkey
I tried changing RD to 8 in my brconfig.sys, but it didn't seem to help any.

Any ideas? Is this a glitch or am I just not understanding it fully?

-John
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: missing accuracy

Post by Gabriel »

I'm not sure. Maybe you're running into a limitation with the PIC statement. Or it could be that PIC causes BR to treat it as a numeric variable, and perhaps there's a limitation in BR for handling numbers that big?

But, regardless, it seems like PIC might not be the way to go for a 17 digit account number.

Have you considered inputting them as a string, as a "C" spec without the PIC statement, and then processing the data yourself afterwards? What is your goal with the PIC statement anyway, in this context?

Gabriel
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Re: missing accuracy

Post by GomezL »

I updated the BR Wiki with information about Floating Point Numbers:

http://brwiki2.brulescorp.com/index.php ... nt_Numbers

Ultimately, you get 16 digits of preceision.
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Re: missing accuracy

Post by John »

In my system all the screens process through the same dynamic rinput fields statement. It brings things into string variables always. pic statements like this are used as text masks to get properly formatted data. this one is the only one I've found that is failing. I think I just need to change it to a regular string and validate it has a val if it's not blank manually. But I thought this is what RD was for, so I thought I'd ask.
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: missing accuracy

Post by Gabriel »

From the page on the Wiki, it looks like RD doesn't change how many digits of accuracy you get, it just determines how many of those digits are before the decimal and how many are after.

I thought there was something else you could set. I had this problem when I expanded my accounting software to keep track of cryptocurrency investments. Cryptocurrencies, depending on which one, can be worth tens of thousands of dollars, or they can be worth fractions of a penny. So depending on which currency you're trading, it may be necessary to track very large amounts, or very small, and in order to support both at the same time, I needed to increase the number of digits of accuracy. In one transaction you might trade several billion of some alt-coin, for a few thousandths of a bitcoin.

I can't remember how I did it though, and a quick search of my code didn't help. I'll keep trying to find out and post back if I do.


Stuff like Account numbers, I always treat as Alpha, not Numeric. If you don't do math on it, (and especially if its really long), then its alpha.

I'd use a normal validation routine to validate that they entered a correctly formatted account number (in this case that might just be verifying that they didn't enter any alpha characters, but in other cases, there are actual validations you might have to do on the number itself.)

Gabriel
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: missing accuracy

Post by Gabriel »

Ok, from some further research, I've found out whats going on.

The # next to your PIC statement is whats causing BR to treat it as a number instead of as a string. Once BR treats it as a number internally, you're limited to 15 digits of accuracy, because of a limitation of the Intel chipset with respect to how it handles floating point numbers.

Turns out, with the cryptocurrency, I had a different problem, and 15 digits was enough accuracy for my purposes.

You can still use PIC or FMT to validate that the user enters Digits. If you remove the # sign, (and stick to a string variable like you have already), then BR will treat it like a string, and you won't loose the final 2 digits.
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Re: missing accuracy

Post by John »

Thank you! you're absolutely correct! Taking the # off made it work. Now my code that builds those things simply says if something is longer than 15 characters to remove the #. That'll keep everything else working exactly as it has been and those that need it get the extra love. For me I did have to change my program to read and write as strings too, because val would round it at 15 digits as well. I don't think we've ever had any 16 digit bank account numbers yet, but it's nice to feel confident we can handle them.
John Bowman
Post Reply