Is it a bug on number or just me
Jack des Bouillons (4/26/07 10:49 AM)
Eric Asadoorian (4/26/07 1:10 PM)
Mikey (4/26/07 1:11 PM)
Mikey (4/26/07 1:17 PM)
Mikey (4/26/07 1:36 PM)
Mikey (4/26/07 1:55 PM)
Eric Asadoorian (4/26/07 2:14 PM)
Eric Asadoorian (4/26/07 2:24 PM)
Mikey (4/26/07 2:36 PM)
Bill Weale (4/26/07 2:51 PM)
Eric Asadoorian (4/26/07 3:27 PM)
Bill Weale (4/26/07 4:02 PM)
Basil Bourque (4/26/07 4:12 PM)
Mikey (4/26/07 4:26 PM)
Larry White (4/26/07 4:49 PM)
John DeSoi (4/26/07 5:06 PM)
Bill Weale (4/26/07 5:12 PM)
Mikey (4/26/07 5:45 PM)
4D List (4/27/07 1:01 AM)
4D List (4/27/07 1:27 AM)
4D List (4/27/07 1:44 AM)
4D List (4/27/07 2:12 AM)
4D List (4/27/07 3:14 AM)
4D List (4/27/07 3:38 AM)
Jack des Bouillons (4/26/07 10:49 AM)
What happens if you make a string out of the number, then use the NUM
function to assign it to a local variable, and THEN do you test?
Jack
On 4/26/07 10:27 AM, "4D List" <4d_list@belhk.com> wrote:
excerpt>
Hi Eric,
We were reported of a bug on calculation of a large real number. While
we
were trying to track down the issue and found this strange problem.
You're right, I can't even debug it so that's why I want to know it's
only
me:-)
2003.7, OSX 10.4.9
Alan
/excerpt>
Eric Asadoorian (4/26/07 1:10 PM)
Alan,
I cannot even re-create the method. The method editor won't accept the
two literals. In fact, the first one does not evaluate the same as the
second after the method editor is done with it.
Is this what you were expecting?
2004.5, OS X 10.3.9
Eric
On Apr 26, 2007, at 1:01 PM, 4D List wrote:
excerpt>HHi folks,
Could anyone try the following to see what you get regardless of 4D
version and platform?
C_REAL($num;$result)
$num:=170737856481621.88
$result:=Round($num;1)
$num:=1707378564816214.88
$result:=Round($num;1)
TIA
Alan Chan
-------------------
B.E.L. Systems Ltd.
www.belhk.com
Hong Kong, Shanghai, U.S., UK., Malaysia
/excerpt>
Mikey (4/26/07 1:11 PM)
You're out of the precision range for reals.
From the 2k4.5 language reference, pg. 855:
"On older 68K-based Macintosh, the precision number is 19; this means
that 1/3 is calculated
with 19 significant digits. On Windows and Power Macintosh, this
number is 15; so 1/3 is
displayed with 15 significant digits. If you display the expression
1/3 in the Debugger window
of 4th Dimension, you will get 0.3333333333333333333 on 68K-based
Macintosh and
something like 0.3333333333333333148 on Windows or Power Macintosh.
Note that the last
three digits are different because the precision on Windows and Power
Macintosh is less than
on the 68K-based Macintosh. Yet, if you display the expression
(1/3)*3, the result is 1 on both
machines."
From page 856:
"A computer can only make approximate computations. Therefore, while
comparing or
computing numbers, a computer does not treat real numbers as
mathematical objects but as
approximate values. In our example, 0.3333... multiplied by 3 gives
0.9999...; the difference
between 0.9999... and 1 is so small that the machine considers the
result equal to 1, and
consequently returns 1. For details on this subject, see the
discussion for the command SET
REAL COMPARISON LEVEL.
There is dual behavior of real numbers, so we must make the
distinction between:
ï How they are calculated and compared
ï How they are displayed on the screen or printer
Originally, 4th Dimension handled real numbers using the standard
10-byte data type
provided by the operating system of the 68K-based Macintosh.
Consequently, real values
stored in the data file on disk are saved using this format. In order
to maintain compatibility
between the 68K, Power Macintosh, and Windows versions of 4th
Dimension, the 4th
Dimension data files still hold the real values using the 10-byte data
type. Because floating
point arithmetic is performed on Windows or Power Macintosh using the
8 byte format, 4th
Dimension converts the values from 10 bytes to 8 bytes, and vice
versa. Therefore, if you load
a record containing real values, which have been saved on 68K-based
Macintosh, onto
Windows or Power Macintosh, it is possible to lose some precision
(from 19 to 15 significant
digits). Yet, if you load a record containing real values, which have
been saved on Windows or
Power Macintosh, on a 68K-based Macintosh, there will be no loss of
precision. Basically, if
you use a database on 68K or Power Macintosh and Windows, count on
floating point
arithmetic with 15 significant digits, not 19."
Mikey (4/26/07 1:17 PM)
Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay back in college, in the ACM
programming contests, there was ALWAYS a precision-overflow math
problem.
The TRADITIONAL way to solve this sort of problem is to represent the
number in an integer array and do the math by hand. In fact I have
libraries in three or four languages I had to write just for this
purpose. You can also do the math in a longint and keep track of the
decimal position so that you use Round() properly.
In 4D you can also use BLOBs, PICTUREs and ALPHAs to store your
numerics and then manipulate them from there. The easiest way is with
a PICTURE variable, IMHO, because you can easily do XOR image
manipulation to do (for example) addition (this is a trick from C).
Mikey (4/26/07 1:36 PM)
Oh, and FYI, on 2k4.5 on XP/SP2 you have the same issue - the editor
cuts you off at 15 digits, which I think is actually helpful seeing as
that's the precision limit.
Mikey (4/26/07 1:55 PM)
No. Real number precision has to do with the way that reals are
stored in memory, and how "wide" the math processor is for moving them
and manipulating them. It doesn't matter where the decimal point is.
Eric Asadoorian (4/26/07 2:14 PM)
Alan,
I do concur with some of the other posts in that as far as the
representation of real numbers, there is a limit, and the decimal
point
is not the critical limitation. I think in the docs the limits are
ï Real: A number to ±1.7e±308 (15 digits)
However, this does not explain the problem with the method editor.
Although the number that is trying to be stored is outside the
limitation, I do not understand why the method editor does not leave
the number as typed and perform the truncation(error) during execution.
The other thing that was strange was that the same number entered two
lines apart created different values in the method editor.
Furthermore, when I deleted the two digits after the decimal and
entered them again, yet another number was displayed.
Since numbers of this size are not supported, I suppose the method
editor is not responsible for accuracy beyond the limitation.
Eric
On Apr 26, 2007, at 1:44 PM, 4D List wrote:
excerpt>II thought this would affect only number of decimal and not
number
before
the decimal such as 1.7073785648162188 but not 170737856481621.88
The example I did only has 2 decimal.
C_REAL($num;$result)
$num:=170737856481621.88
$result:=Round($num;1)
$num:=1707378564816214.88
$result:=Round($num;1)
Did I understand 4D precision number wrongly:-(
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:11 AM +0800 wrote:
excerpt>YYou're out of the precision range for reals.
From the 2k4.5 language reference, pg. 855:
"On older 68K-based Macintosh, the precision number is 19; this means
that 1/3 is calculated
with 19 significant digits. On Windows and Power Macintosh, this
number is 15; so 1/3 is
displayed with 15 significant digits. If you display the expression
1/3 in the Debugger window
of 4th Dimension, you will get 0.3333333333333333333 on 68K-based
Macintosh and
something like 0.3333333333333333148 on Windows or Power Macintosh.
Note that the last
three digits are different because the precision on Windows and Power
Macintosh is less than
on the 68K-based Macintosh. Yet, if you display the expression
(1/3)*3, the result is 1 on both
machines."
From page 856:
"A computer can only make approximate computations. Therefore, while
comparing or
computing numbers, a computer does not treat real numbers as
mathematical objects but as
approximate values. In our example, 0.3333... multiplied by 3 gives
0.9999...; the difference
between 0.9999... and 1 is so small that the machine considers the
result equal to 1, and
consequently returns 1. For details on this subject, see the
discussion for the command SET
REAL COMPARISON LEVEL.
There is dual behavior of real numbers, so we must make the
distinction
between:
ï How they are calculated and compared
ï How they are displayed on the screen or printer
Originally, 4th Dimension handled real numbers using the standard
10-byte data type
provided by the operating system of the 68K-based Macintosh.
Consequently, real values
stored in the data file on disk are saved using this format. In order
to maintain compatibility
between the 68K, Power Macintosh, and Windows versions of 4th
Dimension,
the 4th
Dimension data files still hold the real values using the 10-byte data
type. Because floating
point arithmetic is performed on Windows or Power Macintosh using the
8 byte format, 4th
Dimension converts the values from 10 bytes to 8 bytes, and vice
versa. Therefore, if you load
a record containing real values, which have been saved on 68K-based
Macintosh, onto
Windows or Power Macintosh, it is possible to lose some precision
(from 19 to 15 significant
digits). Yet, if you load a record containing real values, which have
been saved on Windows or
Power Macintosh, on a 68K-based Macintosh, there will be no loss of
precision. Basically, if
you use a database on 68K or Power Macintosh and Windows, count on
floating point
arithmetic with 15 significant digits, not 19."
/excerpt></excerpt>
Eric Asadoorian (4/26/07 2:24 PM)
Alan,
This works, because unlike your other example, it does not require 15
digits to be represented.
Eric
On Apr 26, 2007, at 2:12 PM, 4D List wrote:
excerpt>TTry this
$num:=1000000000
$result:=$num*$num
it seems working???
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:55 AM +0800 wrote:
excerpt>NNo. Real number precision has to do with the way that reals
are
stored in memory, and how "wide" the math processor is for moving them
and manipulating them. It doesn't matter where the decimal point is.
/excerpt></excerpt>
Mikey (4/26/07 2:36 PM)
Eric,
The behavior is exactly the kind of thing one should expect from a
precision overflow situation, namely that beyond the significant
digits the placevalues are random.
I'm betting that the method editor is trying to help you out by not
letting you enter any more digits.
Bill Weale (4/26/07 2:51 PM)
I think it is "responsible" in that it can and will resolve one line
of code at a time as you are coding.
Try typing one digit at a time, then hit the enter key somewhere
around 16 digits, you'll begin to see the approximations. I didn't
test this, but I think the number of digits at which you see the
switch will be driven by whether or not the binary version
*precisely* equals the decimal version.
--www
On Apr 26, 2007, at 2:14 PM, Eric Asadoorian wrote:
excerpt>SSince numbers of this size are not supported, I suppose the
method
editor is not responsible for accuracy beyond the limitation.
/excerpt>
Eric Asadoorian (4/26/07 3:27 PM)
Alan,
Did you try this compiled?
One of the earlier posts spoke about the older 19 digit limit vs the
newer 15 limit depending on the machine type.
Since this is running interpreted (in my case), 4D may still use the
higher limit since it may not be as confined as it might be in a
compiled database.
This is just a guess. Otherwise, I am not sure that I have an
explanation for the behavior.
Eric
On Apr 26, 2007, at 3:14 PM, 4D List wrote:
excerpt>HHi Eric,
The result requires more than 15 digits but the result is correct. Ok,
try
another one
$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is correct
$result:=Round($result;1) `the result is wrong
As you see, both $result has more than 15 digits and including decimals
while one is correct and the other one is wrong.
Just try to figure out what really happen.
Would it be that using figures that has less than 15 digits for
calculation would be OK even if the result goes beyond 15 digits. While
using figures more than 15 digits for calculation would be wrong
regardless how many digit the result would be.
Any suggestion?
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
2:24 AM +0800 wrote:
excerpt>AAlan,
This works, because unlike your other example, it does not require 15
digits to be represented.
Eric
On Apr 26, 2007, at 2:12 PM, 4D List wrote:
excerpt>TTry this
$num:=1000000000
$result:=$num*$num
it seems working???
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:55 AM +0800 wrote:
excerpt>NNo. Real number precision has to do with the way that reals
are
stored in memory, and how "wide" the math processor is for moving
them
and manipulating them. It doesn't matter where the decimal point
is.
/excerpt></excerpt>
/excerpt></excerpt>
Bill Weale (4/26/07 4:02 PM)
Is this another way of saying the same thing?
Isn't decimal precision based upon the number of binary positions
available? And, when a max precision limit in decimal expression is
"advertised" that means that all decimal numbers of that digit count
or fewer can be expressed in the available binary places, but there
may be some decimal numbers of more digits that can be expressed
precisely in the available binary places?
--www
On Apr 26, 2007, at 3:49 PM, Larry White wrote:
excerpt>YYou really have to think carefully what 15 digits of
precision means.
What you are describing is perfectly correct. What you need to do
is look
at the numbers in scientific format -
1.770757436510807875 e 16 is more than 15 digits
But
1.0 e 18 is not!
Cheers,
--
Larry White, P.Eng.
President & Chief Engineer
excerpt>PPelican Engineering, Inc.
excerpt>IISO 9001:2000 registered
/excerpt></excerpt>llwhite@pelicaneng.ca
www.pelicaneng.ca
/excerpt>
Basil Bourque (4/26/07 4:12 PM)
excerpt>TThis is the way things
are using the native representation of reals on most modern computers.
/excerpt>
Yes, the native representation, where native means hardware such as
Floating Point Unit FPU, gives speed, but has these precision
limitations.
You can trade off speed for accuracy by doing alternative
calculations in software, as someone mentioned briefly here.
For example, in Java you have the option of the aptly named library
"BigDecimal" that can basically represent a decimal with virtually no
limits (basically 32 digits after the decimal point, and unlimited
digits before the decimal point). BigDecimal also provides a variety
of rounding algorithms.
http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html
--Basil Bourque
----------------------------------------------------------------------
**********************************************************************
Power up your web apps with the 4D Web 2.0 Pack: Data lives here
http://www.4d.com/products/4dweb20pack.html
4th Dimension Internet Users Group (4D iNUG)
FAQ: <http://www.4d.com/support/faqnug.html>
Archive: <http://dir.gmane.org/gmane.comp.lang.inug-4d.tech>
Wiki: <http://www.4dwiki.org/>
Unsub: mailto: 4D_Tech-off@lists.4Dinug.org
**********************************************************************
/excerpt>
--Apple-Mail-53--393117462--
Mikey (4/26/07 4:26 PM)
excerpt>$$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is WRONG
$num1:=1000000000
$num2:=1000000000
$result:=$num1*$num2 `the result is right
Both result goes beyond 15 digits.
/excerpt>
No it doesn't. This number is either 1 significant digit or fifteen
significant digits, a decimal position, and an exponent.
Computers approximate real number values using a certain number of
significant digits, a decimal-point-position and a power of 10.
Depending on the implementation and the processor set you are using,
your machine may either represent this number as a minimum number of
significant digits or the maximum number of significant digits. I
believe that most modern processor sets use the maximum significant
digits as it is faster to retrieve memory blocks that are of a set
length.
Larry White (4/26/07 4:49 PM)
You really have to think carefully what 15 digits of precision means.
What you are describing is perfectly correct. What you need to do is
look
at the numbers in scientific format -
1.770757436510807875 e 16 is more than 15 digits
But
1.0 e 18 is not!
Cheers,
--
Larry White, P.Eng.
President & Chief Engineer
excerpt>PPelican Engineering, Inc.
excerpt>IISO 9001:2000 registered
/excerpt></excerpt>llwhite@pelicaneng.ca
www.pelicaneng.ca
On 4/26/07 4:38 PM, "4D List" <4d_list@belhk.com> wrote:
excerpt>CCorrection.
$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is WRONG
$num1:=1000000000
$num2:=1000000000
$result:=$num1*$num2 `the result is right
Both result goes beyond 15 digits.
All of our systems run on compiled and the bug was reported. During the
test, we run interpreted to debug.
/excerpt>
----------------------------------------------------------------------
**********************************************************************
Power up your web apps with the 4D Web 2.0 Pack: Data lives here
http://www.4d.com/products/4dweb20pack.html
4th Dimension Internet Users Group (4D iNUG)
FAQ: <http://www.4d.com/support/faqnug.html>
Archive: <http://dir.gmane.org/gmane.comp.lang.inug-4d.tech>
Wiki: <http://www.4dwiki.org/>
Unsub: mailto: 4D_Tech-off@lists.4Dinug.org
**********************************************************************
/excerpt>
--Apple-Mail-47--405722041--
John DeSoi (4/26/07 5:06 PM)
Even with "small" numbers exact value can't always be expressed
precisely. I was surprised to see this in 4D the other day:
290.4 - 288.0 = 2.399999999999977263
On Apr 26, 2007, at 4:02 PM, Bill Weale wrote:
excerpt>IIsn't decimal precision based upon the number of binary
positions
available? And, when a max precision limit in decimal expression is
"advertised" that means that all decimal numbers of that digit
count or fewer can be expressed in the available binary places, but
there may be some decimal numbers of more digits that can be
expressed precisely in the available binary places?
/excerpt>
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
Bill Weale (4/26/07 5:12 PM)
I knew there had to be a reason for using ROUND() all the time...
8-)
Bill
On Apr 26, 2007, at 5:06 PM, John DeSoi wrote:
excerpt>EEven with "small" numbers exact value can't always be
expressed
precisely. I was surprised to see this in 4D the other day:
290.4 - 288.0 = 2.399999999999977263
On Apr 26, 2007, at 4:02 PM, Bill Weale wrote:
excerpt>IIsn't decimal precision based upon the number of binary
positions
available? And, when a max precision limit in decimal expression
is "advertised" that means that all decimal numbers of that digit
count or fewer can be expressed in the available binary places,
but there may be some decimal numbers of more digits that can be
expressed precisely in the available binary places?
/excerpt>
J
/excerpt>
Mikey (4/26/07 5:45 PM)
Understand that this isn't a 4D issue, though. This is the way things
are using the native representation of reals on most modern computers.
You can use BCD's or other techniques to gain additional precision
and accuracy.
4D List (4/27/07 1:01 AM)
Hi folks,
Could anyone try the following to see what you get regardless of 4D
version and platform?
C_REAL($num;$result)
$num:=170737856481621.88
$result:=Round($num;1)
$num:=1707378564816214.88
$result:=Round($num;1)
TIA
Alan Chan
-------------------
B.E.L. Systems Ltd.
www.belhk.com
Hong Kong, Shanghai, U.S., UK., Malaysia
4D List (4/27/07 1:27 AM)
Hi Eric,
We were reported of a bug on calculation of a large real number. While
we
were trying to track down the issue and found this strange problem.
You're right, I can't even debug it so that's why I want to know it's
only
me:-)
2003.7, OSX 10.4.9
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:10 AM +0800 wrote:
excerpt>AAlan,
I cannot even re-create the method. The method editor won't accept the
two literals. In fact, the first one does not evaluate the same as the
second after the method editor is done with it.
Is this what you were expecting?
2004.5, OS X 10.3.9
Eric
On Apr 26, 2007, at 1:01 PM, 4D List wrote:
excerpt>HHi folks,
Could anyone try the following to see what you get regardless of 4D
version and platform?
C_REAL($num;$result)
$num:=170737856481621.88
$result:=Round($num;1)
$num:=1707378564816214.88
$result:=Round($num;1)
TIA
/excerpt>
/excerpt>
4D List (4/27/07 1:44 AM)
I thought this would affect only number of decimal and not number
before
the decimal such as 1.7073785648162188 but not 170737856481621.88
The example I did only has 2 decimal.
C_REAL($num;$result)
$num:=170737856481621.88
$result:=Round($num;1)
$num:=1707378564816214.88
$result:=Round($num;1)
Did I understand 4D precision number wrongly:-(
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:11 AM +0800 wrote:
excerpt>YYou're out of the precision range for reals.
From the 2k4.5 language reference, pg. 855:
"On older 68K-based Macintosh, the precision number is 19; this means
that 1/3 is calculated
with 19 significant digits. On Windows and Power Macintosh, this
number is 15; so 1/3 is
displayed with 15 significant digits. If you display the expression
1/3 in the Debugger window
of 4th Dimension, you will get 0.3333333333333333333 on 68K-based
Macintosh and
something like 0.3333333333333333148 on Windows or Power Macintosh.
Note that the last
three digits are different because the precision on Windows and Power
Macintosh is less than
on the 68K-based Macintosh. Yet, if you display the expression
(1/3)*3, the result is 1 on both
machines."
From page 856:
"A computer can only make approximate computations. Therefore, while
comparing or
computing numbers, a computer does not treat real numbers as
mathematical objects but as
approximate values. In our example, 0.3333... multiplied by 3 gives
0.9999...; the difference
between 0.9999... and 1 is so small that the machine considers the
result equal to 1, and
consequently returns 1. For details on this subject, see the
discussion for the command SET
REAL COMPARISON LEVEL.
There is dual behavior of real numbers, so we must make the distinction
between:
ï How they are calculated and compared
ï How they are displayed on the screen or printer
Originally, 4th Dimension handled real numbers using the standard
10-byte data type
provided by the operating system of the 68K-based Macintosh.
Consequently, real values
stored in the data file on disk are saved using this format. In order
to maintain compatibility
between the 68K, Power Macintosh, and Windows versions of 4th
Dimension,
the 4th
Dimension data files still hold the real values using the 10-byte data
type. Because floating
point arithmetic is performed on Windows or Power Macintosh using the
8 byte format, 4th
Dimension converts the values from 10 bytes to 8 bytes, and vice
versa. Therefore, if you load
a record containing real values, which have been saved on 68K-based
Macintosh, onto
Windows or Power Macintosh, it is possible to lose some precision
(from 19 to 15 significant
digits). Yet, if you load a record containing real values, which have
been saved on Windows or
Power Macintosh, on a 68K-based Macintosh, there will be no loss of
precision. Basically, if
you use a database on 68K or Power Macintosh and Windows, count on
floating point
arithmetic with 15 significant digits, not 19."
**********************************************************************
Power up your web apps with the 4D Web 2.0 Pack: Data lives here
http://www.4d.com/products/4dweb20pack.html
4th Dimension Internet Users Group (4D iNUG)
FAQ: <http://www.4d.com/support/faqnug.html>
Archive: <http://dir.gmane.org/gmane.comp.lang.inug-4d.tech>
Wiki: <http://www.4dwiki.org/>
Unsub: mailto: 4D_Tech-off@lists.4Dinug.org
**********************************************************************
/excerpt>
4D List (4/27/07 2:12 AM)
Try this
$num:=1000000000
$result:=$num*$num
it seems working???
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:55 AM +0800 wrote:
excerpt>NNo. Real number precision has to do with the way that reals
are
stored in memory, and how "wide" the math processor is for moving them
and manipulating them. It doesn't matter where the decimal point is.
**********************************************************************
Power up your web apps with the 4D Web 2.0 Pack: Data lives here
http://www.4d.com/products/4dweb20pack.html
4th Dimension Internet Users Group (4D iNUG)
FAQ: <http://www.4d.com/support/faqnug.html>
Archive: <http://dir.gmane.org/gmane.comp.lang.inug-4d.tech>
Wiki: <http://www.4dwiki.org/>
Unsub: mailto: 4D_Tech-off@lists.4Dinug.org
**********************************************************************
/excerpt>
4D List (4/27/07 3:14 AM)
Hi Eric,
The result requires more than 15 digits but the result is correct. Ok,
try
another one
$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is correct
$result:=Round($result;1) `the result is wrong
As you see, both $result has more than 15 digits and including decimals
while one is correct and the other one is wrong.
Just try to figure out what really happen.
Would it be that using figures that has less than 15 digits for
calculation would be OK even if the result goes beyond 15 digits. While
using figures more than 15 digits for calculation would be wrong
regardless how many digit the result would be.
Any suggestion?
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
2:24 AM +0800 wrote:
excerpt>AAlan,
This works, because unlike your other example, it does not require 15
digits to be represented.
Eric
On Apr 26, 2007, at 2:12 PM, 4D List wrote:
excerpt>TTry this
$num:=1000000000
$result:=$num*$num
it seems working???
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:55 AM +0800 wrote:
excerpt>NNo. Real number precision has to do with the way that reals
are
stored in memory, and how "wide" the math processor is for moving them
and manipulating them. It doesn't matter where the decimal point is.
/excerpt></excerpt>
/excerpt>
4D List (4/27/07 3:38 AM)
Correction.
$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is WRONG
$num1:=1000000000
$num2:=1000000000
$result:=$num1*$num2 `the result is right
Both result goes beyond 15 digits.
All of our systems run on compiled and the bug was reported. During the
test, we run interpreted to debug.
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
3:27 AM +0800 wrote:
excerpt>AAlan,
Did you try this compiled?
One of the earlier posts spoke about the older 19 digit limit vs the
newer 15 limit depending on the machine type.
Since this is running interpreted (in my case), 4D may still use the
higher limit since it may not be as confined as it might be in a
compiled database.
This is just a guess. Otherwise, I am not sure that I have an
explanation for the behavior.
Eric
On Apr 26, 2007, at 3:14 PM, 4D List wrote:
excerpt>HHi Eric,
The result requires more than 15 digits but the result is correct. Ok,
try
another one
$num1:=348.84
$num2:=4895007353251
$result:=$num1*$num2 `the result 1707574365108078.75 is correct
$result:=Round($result;1) `the result is wrong
As you see, both $result has more than 15 digits and including decimals
while one is correct and the other one is wrong.
Just try to figure out what really happen.
Would it be that using figures that has less than 15 digits for
calculation would be OK even if the result goes beyond 15 digits. While
using figures more than 15 digits for calculation would be wrong
regardless how many digit the result would be.
Any suggestion?
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
2:24 AM +0800 wrote:
excerpt>AAlan,
This works, because unlike your other example, it does not require 15
digits to be represented.
Eric
On Apr 26, 2007, at 2:12 PM, 4D List wrote:
excerpt>TTry this
$num:=1000000000
$result:=$num*$num
it seems working???
Alan
"4D iNUG Technical" <4D_Tech@lists.4Dinug.org> on Friday, April 27,
at
1:55 AM +0800 wrote:
excerpt>NNo. Real number precision has to do with the way that reals
are
stored in memory, and how "wide" the math processor is for moving
them
and manipulating them. It doesn't matter where the decimal point
is.
/excerpt></excerpt>
/excerpt></excerpt>
**********************************************************************
Power up your web apps with the 4D Web 2.0 Pack: Data lives here
http://www.4d.com/products/4dweb20pack.html
4th Dimension Internet Users Group (4D iNUG)
FAQ: <http://www.4d.com/support/faqnug.html>
Archive: <http://dir.gmane.org/gmane.comp.lang.inug-4d.tech>
Wiki: <http://www.4dwiki.org/>
Unsub: mailto: 4D_Tech-off@lists.4Dinug.org
**********************************************************************
/excerpt>
Reply to this message
Summary created 4/26/07 at 6:28 PM by Intellex Corporation
Comments welcome at: feedback@intellexcorp.com