05-28-2023, 06:46 AM
(This post was last modified: 05-28-2023, 06:58 AM by mnrvovrfc.
Edit Reason: I have to take more time composing explanations
)
I suggest you take a look at this document:
https://qb64phoenix.com/qb64wiki/index.p...statement)
Noticed the "PRINT # USING" statement in the code snippet you provided. A period is only for demarcating the decimal point in a floating-point value. The formatting rules for "PRINT USING" might be different from what you might be used to.
Please note that FORTRAN might have math libraries that offer better floating-point support than QB64. This is important if you need scientific-grade precision in your calculations. You might want to run a few tests like this:
For a bit more "security" you could use _FLOAT type instead of DOUBLE.
This page is a poor way to describe it:
https://qb64phoenix.com/qb64wiki/index.p...able_Types
Factorials could get large very quickly, so for DOUBLE it goes up to 18 digits without scientific notation, for _UNSIGNED _INTEGER64 and maybe for _FLOAT it could go to 22 without one wrapping around (which is really bad) and the other without scientific notation. If you only need to make calculations with integers you have to be careful about wrap-around because it could really screw things up.
If the precision you require is no more than four digits after decimal point, as it's often the case with financial computations, then it could be faked with _INTEGER64, having positive and negative amounts and having at least 13 digits of precision "on the integer side." That's at least one trillion dollars! Then it's how it's displayed that matters there (ie. where to place the decimal point).
https://qb64phoenix.com/qb64wiki/index.p...statement)
Noticed the "PRINT # USING" statement in the code snippet you provided. A period is only for demarcating the decimal point in a floating-point value. The formatting rules for "PRINT USING" might be different from what you might be used to.
Please note that FORTRAN might have math libraries that offer better floating-point support than QB64. This is important if you need scientific-grade precision in your calculations. You might want to run a few tests like this:
Code: (Select All)
DIM mynum AS DOUBLE
mynum = 1e-9
PRINT USING "-#.##########"; mynum
print mynum
mynum = mynum + 1e-8
PRINT USING "-#.##########"; mynum
print mynumFor a bit more "security" you could use _FLOAT type instead of DOUBLE.
This page is a poor way to describe it:
https://qb64phoenix.com/qb64wiki/index.p...able_Types
Factorials could get large very quickly, so for DOUBLE it goes up to 18 digits without scientific notation, for _UNSIGNED _INTEGER64 and maybe for _FLOAT it could go to 22 without one wrapping around (which is really bad) and the other without scientific notation. If you only need to make calculations with integers you have to be careful about wrap-around because it could really screw things up.
If the precision you require is no more than four digits after decimal point, as it's often the case with financial computations, then it could be faked with _INTEGER64, having positive and negative amounts and having at least 13 digits of precision "on the integer side." That's at least one trillion dollars! Then it's how it's displayed that matters there (ie. where to place the decimal point).