 | |
#11
 
| |||
| |||
|
Re: D3/Linux and Flash Basic -
07-02-2009
, 12:32 PM
|
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 |
be used?"
If you are getting extremely large numbers the answer may be yes. But
I don't know of any great advantages for using floating point
calculations. Speed may be one of them but if it is causing rounding
errors, you may wish to consider all your options.
Dale
#12
| |||
| |||
|
|
On Jun 29, 8:53*am, jra <jrajos... (AT) gmail (DOT) com> wrote: 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 A question that I guess should be asked is, "Does the F option need to be used?" If you are getting extremely large numbers the answer may be yes. *But I don't know of any great advantages for using floating point calculations. *Speed may be one of them but if it is causing rounding errors, you may wish to consider all your options. Dale- Hide quoted text - - Show quoted text - |
where I sit (a looong way from Spain!)
#13
| |||
| |||
|
|
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 ..... |
we use data with decimal (normaly 2) to write the data whitout the
dot. In your case we will have in the data
001 D
002 1905603
or
001 H
002 58000
After in the basic programme or in access we used the conversion but
we have no problem with the precision.
Pierre
#14
| |||
| |||
|
|
"Tony Gravagno" wrote I'll summarize up topside here: The problem Joseba describes isn't with precision or decimals, it's the D3 F option that causes BASIC to use floating point calculations. At least that's what he said right at the very beginning. All the rest of this worldly knowledge about how decimals don't belong in data, or how precision must be 4, is simply hogwash. You know Tony, it's hard to believe you actually mean this sort of thing. One of the cardinal (but unwritten) rules of Pick data is that you never store dates and numbers in external form. I guess we should be lucky that so few novices are on this forum to be misled by this. Chandru |
I disagree that it's a "cardinal" or "absolute" rule.
As soon as you create a firm rule like that people will come up with
exceptions. Translating "good idea" into "rule" is exactly the sort
of thing Pick people dislike about other tools. The MV environment is
versatile and we have different ways to approach problems. We
appreciate having enough rope to hang ourselves, though yes, we try to
encourage others not to hang themselves with the versatility. But I
don't think we should limit how the tools are used because we usually
find it's better to use them differently. That just goes too far in
the other direction.
We don't know what problem the developers are trying to solve or their
constraints. We shouldn't impose an arbitrary rule without
understanding what they're trying to accomplish: Where is the data
coming from, what will be done, where will it go later?
My point remains that while we have reasons for using internal format,
if someone uses floating point math and a specific number of decimals,
they should expect the platform to yield logical and accurate results.
T
#15
| |||
| |||
|
|
"Chandru Murthi" wrote: "Tony Gravagno" wrote I'll summarize up topside here: The problem Joseba describes isn't with precision or decimals, it's the D3 F option that causes BASIC to use floating point calculations. *At least that's what he said right at the very beginning. *All the rest of this worldly knowledge about how decimals don't belong in data, or how precision must be 4, is simply hogwash. You know Tony, it's hard to believe you actually mean this sort of thing.. One of the cardinal (but unwritten) rules of Pick data is that you never store dates and numbers in external form. I guess we should be lucky that so few novices are on this forum to be misled by this. Chandru I agree that it's a very good idea in most (nearly all) cases. I disagree that it's a "cardinal" or "absolute" rule. As soon as you create a firm rule like that people will come up with exceptions. *Translating "good idea" into "rule" is exactly the sort of thing Pick people dislike about other tools. *The MV environment is versatile and we have different ways to approach problems. *We appreciate having enough rope to hang ourselves, though yes, we try to encourage others not to hang themselves with the versatility. *But I don't think we should limit how the tools are used because we usually find it's better to use them differently. *That just goes too far in the other direction. We don't know what problem the developers are trying to solve or their constraints. *We shouldn't impose an arbitrary rule without understanding what they're trying to accomplish: Where is the data coming from, what will be done, where will it go later? My point remains that while we have reasons for using internal format, if someone uses floating point math and a specific number of decimals, they should expect the platform to yield logical and accurate results. T |
that the AQL processor does only integer math. (Has that changed
lately??) Pick BASIC should handle the numbers with embedded decimal
points, no matter what the precision is. I use the precision
statement when I need to control the rounding of numbers when using
math that will generate fractions of numbers. I also try and setup
the divisions and such at the end of the equation to minimize the
effect of loosing precision.
Regards, Dale
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.