Formatting numbers for PRINT and DRAW TEXT statements

[GeorgeMcGinn]

The problem with both solutions is that instead of preserving the actual number of decimal places, you force upon it the number of decimal places, regardless of how many is actually in it.

123.456789

The format program should print this number exactly as it appears, unless this is currency, then it is OK for it to be 123.46 (yes, must round up).

Neither program does this. I can't leave the number of decimals blank.

My problem is that I am writing some of my programs for the scientific field, and even writing a system for journalists, the representation of the actual value of the number, well, needs to be accurate, no matter how many decimal places, and no matter how large the integer part of the number is.

If I wanted a pure format where I only had to pass it the number, these would not be able to handle it as you have to pass it too many variables, or set GOBAL or scope variables ahead of time.

I'm working on a format function that takes the number and formats it as is. I may decide to pass it or set a GLOBAL variable that tells the function whether it is a currency and how many decimal places I want to report.

But for scientific endeavors, such as the field I work in, Astronomy, Cosmology and Physics, where there is a lot of math, they expect their numbers, if they go out to 23 decimal places, to show them all. Same if the number is 23 digits before the decimal place, they need to see them all.

I'd bet biology and chemistry and the other scientific fields are the same.

While both are good and very well written, I need a way to let the number "speak for itself" and formats exactly how it's stored or calculated.

That is why I suggested, as many other languages do, have the ability to put in a format mask, and if the numbers are not used, they just fall away. It should be a function of the language, and not need programmers to have to design and write their own formatting functions or code to do so.

George.

[Dutchman]

The numbers are 52 bits wide. That's 16 decimal places.
So you could format with Sign + 16 + 16 places and then remove the leading and trailing zeros.
Would you really leave 16 decimal places in the representation of calculations

[GeorgeMcGinn]

I would only leave them if they were needed. For example, my study and programs I've written to test theories on the temperatures of Black Holes can easily go out past 16 decimal places, and are needed in some of my and other's math equations.

But that is really a part of the internal workings of the interpreter. If I need to go out to that kind of precision when presenting a paper or showing others my results, I use as many decimal places as needed to provide a precise answer. Most are not 16 decimal places, but many do go to 6 to 10, sometimes 12. But the option needs to be there.

Same goes for large numbers. Astronomy, when you convert distances from light years to kilometers or miles easily can be in the billion trillions (that's 23 digits in front of the decimal places.). Even converting to Astronomical Units (AU) where 1 AU is the distance between the Sun and Earth can get rather large.

Right now, the largest number for Black Holes, and talking about mass, is 2*10^30, which is a 2 followed by 30 zeroes (estimate for the Sun's mass in kilograms

However, if the SmartBASIC interpreter drops off leading and trailing zeroes, like it does (type in X=0000123.4560000 and when you go back to print it without a format mask, it prints 123.456.

But thanks for letting me know that the numbers are 52 bits wide. I did not know that, as I did not see that in any document. I will make sure it is in the Programmer's Guide.

BTW: When I expand 2E+30 using Print Format, I get this: 2000000000000000039769249677312. I am supposed to get all zeroes, yet I get almost half way into the number all those other numbers. This has screwed up many of my cosmology calculations, and wondered if you might know the answer.

Thanks for your reply,

George.

The numbers are 52 bits wide. That's 16 decimal places.
So you could format with Sign + 16 + 16 places and then remove the leading and trailing zeros.
Would you really leave 16 decimal places in the representation of calculations

[Mr. Kibernetik]

But thanks for letting me know that the numbers are 52 bits wide. I did not know that, as I did not see that in any document. I will make sure it is in the Programmer's Guide.

It is written in the very beginning of documentation, in the first section "Basics".

BTW: When I expand 2E+30 using Print Format, I get this: 2000000000000000039769249677312. I am supposed to get all zeroes, yet I get almost half way into the number all those other numbers. This has screwed up many of my cosmology calculations, and wondered if you might know the answer.

It is no wonder if to know that smart BASIC operates floating numbers of double precision.

[GeorgeMcGinn]

OK, I did miss that in the manual. That's my bad. I'll make sure it is driven home in the Programmers's Guide. That is very important, and I'll give it at least 1/2 a page, if not more.

I want to make sure I understand this, so I can show it simply to those who are not math wizards. I ran a program, and I would like verification on just a couple of points:

I produced two values, 2^52, and one of the values I used for the program and data I submitted on the Black Hole data.

The maximum absolute value 2^52 = 4503599627370496
The mass of the Sun, 2*10^30 = 2000000000000000039769249677312
As an exponent, the Sun's Mass. = 2E+30

The first value, what you are saying is that any whole number larger than 4503599627370496 will not be represented correctly, is that a correct statement?

As I can see from the math to calculate the temperature of a Black Hole, I used the Sun's mass as one of the variables. Now when I do the 2*10^30, in exponential form, it is correct, at 2E+30. However, when I calculate it out to all 31 integers, because it is larger than the number produced from 2^52, it has those extraneous digits, that is correct?

I haven't checked out the hardware schematics, but are you emulating the floating point math, or does the iPhone and iPad processors also have a math processor?

I as if you know because if there is no math processor (that handles floating point numbers with better precision, depending on the math processsor), why go through all the trouble to use floating point when fixed point is easier and faster?

Sorry I missed that part of the manual, but the programmer guide will go into it more and give examples, as I just did, to show what happens.

My only other question is for decimal places, can I assume that the smallest number that will be accurate will be 2^-52, or 0.0000000000000002220446049250313080847263336181640625 ?

Or does it also stop at 16-17 decimal places (which would take it out to the two 22's?

Thanks for your help. With this information in the Programmer's Guide, it should cut down on these questions, and it will help those program more smartly, as if I had caught this up front, I would have had my data tossed back at me. When the Astronomer and the Physicists looked at my data, they said I was generally in the ballpark, but my conclusions were way off.

So I just learned a lesson that I will make sure when the guide comes out, others will not make that mistake.

Again, thanks for your help and info your provided.

George.

But thanks for letting me know that the numbers are 52 bits wide. I did not know that, as I did not see that in any document. I will make sure it is in the Programmer's Guide.

It is written in the very beginning of documentation, in the first section "Basics".

BTW: When I expand 2E+30 using Print Format, I get this: 2000000000000000039769249677312. I am supposed to get all zeroes, yet I get almost half way into the number all those other numbers. This has screwed up many of my cosmology calculations, and wondered if you might know the answer.

It is no wonder if to know that smart BASIC operates floating numbers of double precision.

[Mr. Kibernetik]

I will not go deep into this subject, but can say that smart BASIC uses standard "double" variables type which is commonly used in most compilers, and smart BASIC does not emulate it but relies on Xcode Objective C language.
So if you need more information regarding math precision, please consult corresponding papers - this topic is quite deep and interesting.

[GeorgeMcGinn]

That's good enough for me to get the rest. I will get the papers to read the rest.

I just need a yes or no on the number I identified as the largest number for top end of the accuracy. In otherwords, any number greater than that is not guaranteed to be as accurate because of the limitations of double floating point, and in the Programmer's Guide I will instruct to use exponential form of numbers greater than that number, which is 4,503,599,627,370,496 (this is 2^52) and of course it goes that way on the negative side as well, since the upper limit was described as the absolute value.

I'll read about the rest. I know Objective BASIC, and I just started a Udemy course on Objective C. I think it said by the end of the course I will have written 21 games, or something like that. Games are a great way to learn programming quickly as you use a lot of the screen, image and data. I'm looking forward to writing some code. And my next course is for SWIFT, which looks very familiar to me. Almost a mix of FORTRAN, PL/1 and either PHP or VBScript.

Thanks again for your help. (I really feel stupid missing that line in the manual. )

George.

I will not go deep into this subject, but can say that smart BASIC uses standard "double" variables type which is commonly used in most compilers, and smart BASIC does not emulate it but relies on Xcode Objective C language.
So if you need more information regarding math precision, please consult corresponding papers - this topic is quite deep and interesting.

[Mr. Kibernetik]

I just need a yes or no on the number I identified as the largest number for top end of the accuracy. In otherwords, any number greater than that is not guaranteed to be as accurate because of the limitations of double floating point, and in the Programmer's Guide I will instruct to use exponential form of numbers greater than that number, which is 4,503,599,627,370,496 (this is 2^52) and of course it goes that way on the negative side as well, since the upper limit was described as the absolute value.

The highest value without losing resolution is 2^53

[GeorgeMcGinn]

OK.

Dutchman - you need to change the reference on page 8. It says 2^52

Thanks, George.

I just need a yes or no on the number I identified as the largest number for top end of the accuracy. In otherwords, any number greater than that is not guaranteed to be as accurate because of the limitations of double floating point, and in the Programmer's Guide I will instruct to use exponential form of numbers greater than that number, which is 4,503,599,627,370,496 (this is 2^52) and of course it goes that way on the negative side as well, since the upper limit was described as the absolute value.

The highest value without losing resolution is 2^53

[Dutchman]

Is the maximum value 2^53 or is it 2^53-1
I suppose it should read:

Any integer with an absolute value smaller than 2^53 will be represented exactly.

It was: "Any integer with an absolute value smaller than 2^52 will be represented exactly."