D3 Release Version 7.5.0.LINUX
Most recent mload into boot abs performed at 17:44:42 on 29 Jun 2009.


D3 Linux 7.5.0 with all patches loaded

System Release Information
==========================
D3 Release Version 7.5.0.LINUX
Most recent mload into boot abs performed at 17:44:42 on 29 Jun 2009.


I have a file with 461851 records. Atribute 1 is D or H. Atribute 2 is
a number with 2 decimals.

I have a program that adds to 2 variables the D and the H records.

Compiled without flashbasic:
REGS 461851
DEBE 1512942489.36
HABER 1512942489.36

Compiled with flashbasic without F option

REGS 461851
DEBE 1512942489.36
HABER 1512942489.36


Compiled with flashbasic with F option
REGS 461851
DEBE 1512942489.3599
HABER 1512942489.3598

NO RECORD OF THE FILE HAS MORE THAN 2 DECIMALS.
THE PROGRAM ONLY ADDS

*---------------------------
IF R<1> = 'D' THEN
DEBE = DEBE + R<2>
END ELSE
HABER = HABER + R<2>
END
*----------------------------

How can the result has 4 decimals?

It happens the same with D3 Linux 7.4.0

joseba

Let me get this one before Tony weighs in:

It's probably a floating point processor interface error in the OS. Get
around it this way:

IF R<1> = 'D' THEN
DEBE = DEBE + R<2> 2 <-- round to two decimals
END ELSE
HABER = HABER + R<2> 2 <-- ditto
END

This could have implications for TL if the math isn't perfect. It may have
already been fixed in a patch/release. See your support people.

Ed


"jra" <jrajoseba (AT) gmail (DOT) com> wrote

It's the same in D3 Windows 7.4.7 so i do not think it's something in
the OS (and in Linux i have tested it with different versions of
RedHat and with Fedora
And yes, if you round it to two decimals it works well (actually it's
what we are doing), But why must i round a 2 decimal number to 2
decimals in an add instruction.

joseba

On 29 jun, 18:27, "Ed Sheehan" <NOedsS... (AT) xmission (DOT) com> wrote:

jra wrote:
Have you tried

PRECISION 2

--
frosty

Ed is right, check with TL to see if there is a recent 7.5.x patch, or
report the problem. That said, in MV most of us have always used
integers rather than floats, in part to avoid these specific problems.
I think it's been so long that most people don't know why they
(should) use integers anymore.

FP has never really been an integral part of data processing. Floats
are internally just approximations. The data isn't stored as
11010101010100111.101010101010111. There is no decimal character in
binary so floats are processed as integers with exponents, and
calculations to resolve the intended number are performed at runtime,
subject to higher error as the numbers get larger. In "the old days"
the more advanced systems had a chip outside of the CPU called an FPU,
and floating point operations were exported to this chip for
processing. That chip essentially took integers like 1 and 3, divided
them, and returned a result like .333333333336. Later the FPU was
brought on-board with the CPU, but the logic circuits are still not
"inline" with the other CPU functions.

D3 may or may not have a float issue of its own, the issue could be in
the OS, the C or assembler languages over the OS, or the CPU. I'm not
in a very familiar area here but I believe proper management of floats
requires compliance with IEEE standard 754, which actually changed
just last year from a 1985 or 2000 standard. I'm surprised much of
anything works when standards like that change, given the permutations
of old/new hardware, patched and unpatched operating systems, C/C++
toolkits, and other nuances.
http://en.wikipedia.org/wiki/IEEE_fl...point_standard
Google for "floating point approximations" and similar queries and
you'll see this is topic is far from being as easy as people assume.

My advice would be to simply not trust floats unless you're coding
much closer to the metal. Scale up your data to integers before
storage - I believe rounding up can be trusted. That said, sure, if
you need floats try them, discuss issues with your vendors, and let
the rest of us know what info you get.

I wrote a blog on D3 precision a while back, I hope people find it
helpful:
nospamNebula-RnD.com/blog/tech/mv/2008/08/d3precision1.html

T

The floating-point algorithm has a built in anomaly that is not unique
to D3.

Here's one document to read about it: ww.rwc.uc.edu/koehler/comath/
14.html

If you're looking for numbers to be exact don't use it.

Hi Joseba
First rule of Pick math programming always scale before doing any operation.
Things have improved. In the early days the leading bit just fell off at
fifteen so those of us used to HP calculators and only scaling at the end of
a calculation got some shocks.
Second rule. Stick to Precision 4 for the overall program. If you need to
go to Precision 6 as the lunatic Australian Tax office demanded that we do
for GST calculations then scale up the number during the calculation and
scale back at the end
JimR's link is great for the science of it.
Peter McMurray
"jra" <jrajoseba (AT) gmail (DOT) com> wrote

On Jun 29, 11:30*pm, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote:
Is this similar to the "wide zero" thing in U2?

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Is this similar to the "wide zero" thing in U2?

Yep the very same idea. After a rethink I believe that Joseba is possibly
storing his results in external format rather than internal, or as TG called
it integer format,. That could explain why the problem is occuring on a
simple add with no other processing. The original entry if not ICONVed when
stored would have the "wide zero" issue truncated to 4 decimal places as the
default precision is 4. I would like to check the data stored before
blaming the C code.

Peter McMurray

Actually it's not one of my installations, it's one customer in Spain
with his own code.
If you see the data with a CT you see:

001 H
002 580

001 H
002 228.34

001 D
002 73.13

001 D
002 19056.03

......

Actually the necesity cames from PRECISION. You can read an excellent
post about this in TG's blog. And with you use the F option in BASIC
or COMPILE, precision has no effect.

joseba



On 1 jul, 00:39, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote: