I got an error when i divide 2 fields. Both the fields are from a record but one of them is in exponential where

AAA=-1.01157197138118E16 and BBB=-28

The program will break at CCC=OCONV(AAA,'MD2')/OCONV(BBB,'MD0')

and i found out if i change it to

CCC=AAA/BBB

it will not break. The break message is 'Non numeric data when numeric is reguired.Zero used'

The test program i use is as follow:

SUBROUTINE TESTING(ARG)

OPEN 'STOCK' TO STOCK ELSE STOP

STOCK_CODE=5008520'

READ STOCK_REC FROM STOCK, STOCK_CODE THEN

AAA=STOCK_REC

BBB=STOCK_REC

CCC=OCONV(AAA,'MD2')/OCONV(BBB,'MD0')

END

RETURN

Is there a limit to the division ? Please advise ASAP.

Thanks.

Why can't you use CCC=AAA/BBB ?

To help, it sure would be good to know the values of AAA and BBB.

Why don't you look them up in the record, and then assign AAA and BBB the actual values? Also try to assign XXX to OCONV(AAA,'MD2') and YYY to OCONV(BBB,'MD0') then ZZZ=XXX/YYY. Put in debug statements and look at your intermediate results.

By the way, OI math has an upper limit of about 2^1024 and a lower limit of 2^-1024, so I don't think that this is a problem, but if your values are super big or small, then resylts will look like "1#INF" or something like this.

AAA=-1.01157197138118E16 and BBB=-28

as stated in my first question. I looked it up from my record already . I have not tried xxx=oconv(aaa,'md2') and yyy=oconv(bbb,'md0') and then zzz=xxx/yyy but if i dont oconv and just do aaa/bbb then it wont break. Why? Is it the oconv and division combination?

I cant cause the actual program, the fields have different decimal points set by parameter. Eg md2 or md3. Any work around?

Just tried as suggested and it will break on zzz=xxx/yyy.

The value i gave for aaa is it over the 2^-1024 ? Whats "resylts will look like "1#inf" " ?

Hi Chee,

I think your problem is the result of the OConv of AAA. The resultant value is too long for a numeric value with a decimal point.

Is the value to that many decimal places important, if you use MD0 instead of MD2 it works ok.

Regards,

Simon

While not trying to address your specific problem, maybe this will help.

A decimal number in OI can have no more than a maximum of 16 digits plus a decimal point and - sign. BASIC+ is unreliable when numbers have more than 16 digits. For example, NUM() will fail and ABS() will cause a drop to debugger, if 17 digit numbers are used. This is a limit of full precision math in a 32 bit operating system.

If you need more digits (for more precision) than this, I suggest getting a copy of SRP's Utilities which has a Math function that can handle any precision.

Don Muskopf is right. You can download our free SRP Utilities and use its SRP_Math method, which is documented in the help file placed in your OI directory upon install: SRP_Utilities.chm.

Just to make sure it's clear, arbitrary precision math is a little slower than BASIC+ math. So, if these calculations are part of a large number crunching report, you might find that the report takes longer. However, if this is being used only on occasion, you won't notice a difference.

kfournier@srpcs.com

SRP Computer Solutions, Inc.

Hi Chee,

How about CCC=AAA*100/BBB

Cheers, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

You might want to restructure your database not to save numbers that have so many numbers to the right of the decimal point.

If AAA (field 23 of the record) is suppose to be "MD2" converted, then I do not understand why it is saved in the record with a decimal point. "MD2" means only two numbers to the right of the decimal point.

See $12.34 when ICONVed using "MD2" would turn into 1234 (and saved in the record as 1234). And then 1234 OCONVed using "MD2" would turn into 12.34

Basically you would not want to save numbers with decimal points in records unless you really have to. This allows for proper selecting, sorting and math.

Somehow it seems that your intention to have "MD2" and "MD0" numbers is not quite so.

Tell that to the revelation guys. The field became -1.01157197138118E16 after much transaction being updated. And for your information i did not design or save the field with decimal point. Thats why i had to use md2 and md0 in my program. So happen this case the user set their decimals as 2 and 0. Others will set differently. I do not hardcode the decimal.What i posted was just a test program i derived from the original cause it does much more thing that is not relevent here.

My user was running and one day he got a problem and after i troubleshoot found the data stored in that field was with this huge negative exponential. What gives?

Thank you for sharing. I will try out the srp utilities.

Thanks. Will try it out.

View this thread on the Works forum...