I have had issues with math calculations exceeding the 2^32 barrier
when using flash compiled code. If I compile without flash, it
performs the calculation correctly. I have had to deal with this issue
several times. It looks pretty bad to the auditors when simple math
doesn't work correctly!

If I explicitly change to precision 0 it works - I'm assuming it just
raises the barrier. If I use parenthesis it works also.

Why should I have to be concerned about the contents (size) of
variables? Is there a way to force the Flash compiler to use a larger
numeric type when doing math besides lowering the precision?

Flashed: (no precision statement)
BUDGET= 27,000,000.00
DAYS = 365
INT(BUDGET * DAYS/365)= 2,322,741.76
INT(BUDGET * (DAYS/365))= 27,000,000.00


Non-Flashed:
BUDGET= 27,000,000.00
DAYS = 365
INT(BUDGET * DAYS/365)= 27,000,000.00
INT(BUDGET * (DAYS/365))= 27,000,000.00

If you're using D3, there are extended precision arithmetic and
comparative subroutines in DM,BP, that I've found handy for more
complex calcs.

I've used them very successfully.

They're called:

XDIVX
XADDX
XSUBX
XMULX
XCMPX
XABSX
XEXPX

Etc, etc......a quick look at the code involved will give you an idea
of what each routine does, aside from the self-explanatory ones above.


DaveG wrote:

You could try compiling with the (of option to force use of floating
point math... however in my experience this may cause some arithmetic
operations to work differently than the [normal] fixed precision math.
Also, there may be issues with floating point enabled flash programs
calling or being called by non-floating point flash programs?

/Scott Ballinger
Pareto Corporaiton
Edmonds WA USA
206 713 6006

I meant to add that when using these subroutines compile fine with
flash.

Sorry - We are running D3 7.2.1 on Red Hat Linux.

All arithmetic is done in internal (no decimal places) format. The
results shown are OCONV'ed to MD2,

The (f option worked. This is the type of fix I was looking for - thank
you. I've added it to my options on the compile verb so everything
will be compile that way.

Are there any ramifications of using the f option for everything? Disk
space + memory are not an issue.

In NON-flashed Pick Basic, numbers are stored as strings until they need to
be used to calculate. If the string is too long, after adding precission
digits, to fit in 4 bytes, they use what's called String Math, so
theoritically there's no limit.

Flashed Pick Basic uses typed inters unless you use the F option, which then
types the variables as single precission floating point.

The problem on NT is that once you've done that, you are totally at the
mercy Microsoft math where 2 + 2 approaches 4 with very large values of 2.

It's fairly easy to write your own floating point math routines. I have a
set that I've tested to 100+ digits to either side of the decimal.

Mark Brown


"DaveG" <daveg_0205 (AT) iwon (DOT) com> wrote