Originally posted by Walter Henn
View Post
Announcement
Collapse
No announcement yet.
64bit Precision for Extended Precision Variables Guaranteed?
Collapse
X

There is nothing to stop you from writing your own function...
Code:FUNCTION StringToExt (S AS STRING) AS EXT ... END FUNCTION Extvar = StringToExt ("3.1415926535897932385") ....
MCMMichael Mattias
Tal Systems Inc. (retired)
Racine WI USA
[email protected]
http://www.talsystems.com
Comment

Originally posted by Michael Mattias View PostThere is nothing to stop you from writing your own function...
However if I apply the method of mathematical induction to this statement I am led to conclude: "There is nothing to stop anybody from writing his own compiler ... so why to buy any compiler at all ? ..."
OK, that was a joke ... Turning serious, I must say I can't figure out how to do it, and the need is not so desperate to let me undertake the venture: I can live without it, and I am very happy of PB anyhow. However nobody can be blamed for expressing a wish, and I would certainly appreciate if the VAL and STR$ functions could in the future properly handle up to 20 digits, or if somebody writes efficient functions for doing the same.
RegardsAldo Vitagliano
alvitagl at unina it
Comment

>I must say I can't figure out how to do it
I can get you started...
Code:FUNCTION SuperVal (S as string) AS EXT LOCAL wExt AS EXT ' <<< where we build LOCAL dividend as EXT, divisor AS EXT LOCAL Z AS LONG w = (string in before any decimal point) wExt = VAL(W) ' no problem with integers Divisor = 10# W = StringAfter Decimal point FOR Z = 1 TO (number of digits in W) Dividend = VAL (MID$(W, Z,1) ' get the digit WExt = WExt + Dividend / Divisor Divisor = Divisor * 10# NEXT FUNCTION = wExt ....
The idea here is I only used VAL on integers and have avoided any decimal division... meaning you should get full precision at all times.
This simply MUST be worth a try.
You can do the same kind of thing to create a "SuperSTR$()" or "SuperFormat$()" function.. use only whole numbers and build your string using integer math.
Yes, when you have it working it would be nice of you to post these functions in the Source Code Forum.
MCMMichael Mattias
Tal Systems Inc. (retired)
Racine WI USA
[email protected]
http://www.talsystems.com
Comment

Aldo,
properly handle up to 20 digits, or if somebody writes efficient functions for doing the same.
Code to format to 19 digits has already been posted here before:
http://www.powerbasic.com/support/pb...ad.php?t=24224
To go the other way, use Michael's approach.
Paul.Last edited by Paul Dixon; 11 Dec 2007, 01:00 PM.
Comment

There is nothing to stop you from writing your own function..Last edited by Greg Lyon; 11 Dec 2007, 06:34 PM.
Comment

The compiler makes no assumptions of the "accuracy" of numeric literals in your code. It is up to the programmer to cast those numeric literals into the intended precision.
In other words, if accuracy is of importance to you, always add a typespecifier to a numeric literal.

Lance
PowerBASIC Support
In a previous post of mine, I indicated that the results for PBCC 4.03 and PBCC 4.04 are different when the same floating point literal is cast as extended precision. It now occurs to me that when PB shifted from the 16bit compiler version (4.03) to the 32bit compiler (4.04), this bug was obviously introduced into the newer compiler.
As I have previously indicated, I intend to submit this problem to support in the next couple of days. In the meantime, I would appreciate any additional comments you wish to make.Last edited by Walter Henn; 12 Dec 2007, 04:39 AM.
Comment

Originally posted by Paul Dixon View Postthe 20th digit is only valid 8% of the time so it's unwise to use it unless you really know you're in that 8%.
The "absolute" numerical accuracy of a given numerical representation of the real number X corresponds to the smallest number EPS you can add to X, getting a result Y = X+EPS different from X. The "relative" numerical accuracy is simply the ratio EPS/X.
Here is a very simple code that I encourage everybody to try, which determines the absolute and relative accuracy of the internal binary representation of whatever input decimal number. The code can be simply switched to test double precision or single precision accuracy as well.
Code:DEFEXT AZ ' DEFDBL AZ ' DEFSNG AZ FUNCTION PBMAIN() DO LINE INPUT "Enter a number: " NUM$ X = VAL(NUM$): IF X=0 THEN EXIT DO EPS=X/2^22## DO Y=X+EPS IF Y=X THEN EXIT DO EPS=EPS/2 LOOP DO EPS=EPS*1.00781250 Y=X+EPS ' ... just used to finetuning EPS IF Y<>X THEN EXIT DO LOOP PRINT "Absolute accuracy on X is "; USING$("##.#^^^^", EPS) PRINT " Relative accuracy on X is "; USING$("##.#^^^^",EPS/X) LOOP END FUNCTION
If the decimal mantissa is in the form 1.1... then the absolute error is at a minimum (about 5.5E20) and corresponds to an uncertainty of 5 units on the 21th significant digit. If the decimal mantissa is in the form 9.9 ... then the absolute error is at a maximum (about 4.5E19), and corresponds to an uncertainty of 4 units on the 20th decimal digit.
Even in this latter extreme case, from the point of view of error propagation, it is slightly better to have the 20th digit rather than to skip it.Last edited by Aldo Vitagliano; 12 Dec 2007, 08:16 AM.Aldo Vitagliano
alvitagl at unina it
Comment

An EXT literal should have better precision than a DOUBLE literal.
I don't think asking PB to take a look at this is asking too much.
However, if you need this feature ("greater number of significant digits in numeric literals") anytime before some next release, your choices are A) write it yourself; or B) Postpone the entire project. Your call.
(FWIW, you only have to write about two percent of it, since I posted the roadmap for you).
And since you feel so strongly it is worth a look by the publisher...
I assume I can bet the house you have actually invested the paltry 60 seconds or so to drop an email with this new feature suggestion to the designated address [email protected]?
MCMMichael Mattias
Tal Systems Inc. (retired)
Racine WI USA
[email protected]
http://www.talsystems.com
Comment

FWIW, here is some code which will handle generating the factorial of 100 with all signficant digits.... which you might call a "SuperFORMAT$()" function..
Tutorial and source code for Qbasic, QuickBASIC and PowerBASIC showing a technique to calculate large numbers to at least 154 significant digits. Freeware
Ok, so it's not for Windows.. but it does compile/execute "as is" for all three BASIC language products listed above, so how hard could it be to port it to PB/Windows?
Complete list of downloadable stuff at my website: http://www.talsystems.com/tsihome_html/techcorner.html
MCMMichael Mattias
Tal Systems Inc. (retired)
Racine WI USA
[email protected]
http://www.talsystems.com
Comment

Quote:
An EXT literal should have better precision than a DOUBLE literal.Literals don't have precision. But that's nitpickingthe semantics.
Furthermore, you're wrong. Greg did not say that a literal has precision; he stated that an EXT literal and a DOUBLE literal have a precision. The obvious meaning of his statement is that the literal cast as an EXT should be stored with a better precision than a literal cast as a DOUBLE. And everyone knew what he was saying!
I assume I can bet the house you have actually invested the paltry 60 seconds or so to drop an email with this new feature suggestion to the designated address [email protected]?
If you've read all of the posts on this thread, I indicated that I would submit this issue to support in a couple of days (to get the benefit of any additional constructive comments from the PB community).Last edited by Walter Henn; 12 Dec 2007, 04:57 PM.
Comment

...(casting floating point literals to extended precision) be implemented correctly [bold mine. MCM]
8. A numeric constant with a decimal point and more than six significant digits, but less than 17, or a whole number too large to be a Quadinteger but small enough to fall within the range of Doubleprecision floatingpoint, is stored in Doubleprecision floatingpoint format. Larger values (with up to 18 significant digits) are stored in Extendedprecision format.Michael Mattias
Tal Systems Inc. (retired)
Racine WI USA
[email protected]
http://www.talsystems.com
Comment

it's not elegant but works!
Code:z = 3.1415926535## + 0.0000000000897932385## = 3.14159265358979324 memory contents: 40 00 C9 0F DA A2 21 68 C2 35 stored dec value: 3.141 5926 5358 9793 1160 pi: 3.141 5926 5358 9793 2385 z = 4 * atn(1)= 3.14159265358979324 memory contents: 40 00 C9 0F DA A2 21 68 C2 35 stored dec value: 3.141 5926 5358 9793 2385 pi: 3.141 5926 5358 9793 2385
"The trouble with quotes on the Internet is that you can never know if they are genuine."  Abraham Lincoln.
Comment

Michael,
Yes but if you look above that list you will find ( at least in v4.04 )
Code:If a typespecifier does not follow a numeric constant, the following rules are used to determine the precision the value will be stored in:
Code:You can also force a literal value to be stored with a given precision by following the constant with one of the variable typespecifiers (%, &, &&, ?, ??, ???, !, #, ##, @, @@). This ability becomes very important when working with Currency and other floatingpoint numbers.
I found this under Constants and Literals.
So I'm throwing in my 2 cents for sending the matter on to support and
hearing an official reply.Last edited by Paul D. Elliott; 13 Dec 2007, 02:23 PM.
Comment

PBCC users are mathematicians, scientists, etc. to whom accuracy is not just a lofty ideal.
Walter, throughout this thread you've been talking about "precision." Now you are equating precision with accuracy. Those are horses of a different color. Precision has to do with the number of digits displayed. Accuracy has to do with the "correctness" of the displayed digits. For example, what is the difference between "1" and "1.0?" Nothing except precision. The first is correct to one digit of precision, the second is correct to two digits of precision.
However, if I have code that does:
A## = 1. 00000000000000000
PRINT FORMAT$(A##, 18)
and I get a result of 1.000000000000000234
then I can say that the number is incorrect past 15 digits of precision.
I highly doubt that a scientist or mathematician who needed accurate results to greater than 15 digits of precision would us a PC.Walt Decker
Comment

Originally posted by Michael Mattias View PostIt appears to me that 18 significant [decimal] digits is the documented limit for numeric literals; ergo the compiler has implemented the storage of said numeric literals "correctly."
You've been shouting so loudly that I don't think you're able to listen to what others are saying. You claim that, "the compiler has implemented the storage of said [extended] numeric literals correctly." If so, can you please explain why the following code does not produce the same results (as it should) for the variable, z?
Code:#COMPILE EXE #REGISTER NONE #DIM ALL FUNCTION PBMAIN () AS LONG DIM z AS EXT, value_string AS STRING z = 4 * ATN(1) value_string = "z = 4 * ATN(1) = " PRINT TAB(32  LEN(value_string));value_string;STR$(z,18) !finit !fldpi 'put the value of pi on the FPU stack !fstp z 'store that value in z value_string = "z = fldpi = " PRINT:PRINT TAB(32  LEN(value_string));value_string;STR$(z,18) z = 3.141592653589793238## 'pi literal value_string = "z = 3.141592653589793238## = " PRINT:PRINT TAB(32  LEN(value_string));value_string;STR$(z,18) WAITKEY$ END FUNCTION
z = 4 * ATN(1) = 3.14159265358979324
z = fldpi = 3.14159265358979324
z = 3.141592653589793238## = 3.14159265358979312
The value of the literal, pi, cast to extended precisionl, 3.14159265358979312, has 18 significant digits, but is only accurate to 16 places. The values for "4 * ATN(1)" and "fldpi", 3.14159265358979324, have 18 significant digits and are accurate to 18 places.
Had the result for the extended precision literal been, .14000000000000000, would you have argued that this result would have been the correct implementation of casting the literal, 3.141592653589793238, to extended precision because it has 18 significant digits?
Comment

Originally posted by Walt Decker View PostWalter, throughout this thread you've been talking about "precision." Now you are equating precision with accuracy. Those are horses of a different color. Precision has to do with the number of digits displayed. Accuracy has to do with the "correctness" of the displayed digits..
However, if I have code that does:
A## = 1. 00000000000000000
PRINT FORMAT$(A##, 18)
and I get a result of 1.000000000000000234
then I can say that the number is incorrect past 15 digits of precision.
I highly doubt that a scientist or mathematician who needed accurate results to greater than 15 digits of precision would us a PC.Last edited by Walter Henn; 13 Dec 2007, 07:38 PM. Reason: Correction: 15 bits should have been 15 digits.
Comment

Walter, nowhere in my post did I say anything about power basic nor did I say anything about bits. Folks who need accuracy greater than 15 significant digits use computers created for that and languages created for that.
Yes, I'm aware that there are math libraries that perform calculations greater than 15 significant digits. I also notice that you used the result for PI you obtained from "toy maker." How do you know the result is accurate even though it is carried out to 16 digits?Walt Decker
Comment
Comment