I spend most of today doing research for Ray. He has decided ("decided" being a nice way to say that he was ordered to by the people that pay him) to take on the problems associated with floating point numbers and their inherit imprecision.

in C++:

double aa;

  aa = 10.5;
  printf("%.14f", aa) // print with 14 places to the right of the decimal point
 

will print the variable "aa" with a good deal of precision. On an Intel chip it will print: "10.49999999999999". This is because computers can only store, with absolute precision, fractions that can expressed as a power of two. All of the others are an approximation. So, 1/4th (0.25) can be stored absolutely correctly, but 1/10th (0.1) cannot. Usually this does not matter at all. So what if the number is off by the width of a hair on the scale of the width of the galaxy? But when one is trying to round that number at the second decimal place, that imprecision gets shifted into the integer portion of the floating point and becomes "1049" instead of the desired "1050".

So while Ray was trying out everything he could think of, I was on the internet looking for white papers and published techniques. I finally found one that looked pretty good. Ray is at home right now, testing it with, as he puts it, "all the numbers". I hope it works out. The last technique he tried worked well until the number got in the hundreds of billions. Then it got funny.

"..and later today I'm going to the airport to pick up Erika."

What's your pick up line?? 

Today the research continued. Most platforms (including Linux) come with a round() function as part of the C libraries. Like many other standard functions, MS somehow managed to miss that one. When Ray saw that Linux supported a "built-in" round() function but MS did not, he declared, "Okay, everyone switch!"

I guess that one of the reasons one shouldn't use development tools from a company that also provides competing applications.

I found a source example from MS, using a lookup table instead of the pow() function. But, Ray tried it and found it less accurate than several of the others he has tried.

We sent the best of them out to the alpha testers to see what they think of it. Hopefully, it'll be okay.

I started work on getting the generic table to know how to print itself.

I also did some more investigation on how to use bidirectional pipes to use standard I/O to communicate with other applications. All's well on Linux, but MS does not support process forks or standard I/O (in windows programs) - both of which are critical. I may be able to replace the fork with threads, but the standard I/O will probably bring up the horrible "black window" that @Shell causes (for the same reason).

Erika came back from teaching classes in Dallas today. Welcome home Erika!

http://www.karenware.com/powertools/ptcalc.asp

The above downloadable calculator is fully addressing the issue, may be, as for me, it would make sense to ask Karen how she managed the problem under VB6 ... (to get a starting point ...), VB6 source code download link:

http://www.karenware.com/progs/ptcalc-src.exe

Quote:


Citing ex karenware.com 's calculator description:

quote
Karen's Calculator is a high-precision calculator. Unlike ordinary calculators, it returns completely accurate results, even with operands containing thousands of digits. If you're patient, operands and results containing hundreds of thousands of digits are possble too!

Most calculators are only accurate when dealing with numbers containing a few digits -- usually 16 to 32. When asked to calculate using larger numbers, they either fail (displaying an error) or return results that are only approximately accurate.

Karen's Calculator can easily handle numbers and results containing many thousands of digits with complete accuracy. It also includes an on-screen "tape" -- which can be saved to disk -- versatile memory features, and more!
unquote

To say, MOFFSOFT's product is certainly NOT comparable...

http://www.gbcsci.com/products/uv/whats_new.asp

Rather than to look into Karen's VB6 source code to get some techniques, drill down to:

quote
SBasic Programming Language for UV-Visible Software
Simplify routine analyses and complex data manipulation with SBasic macros. A newly published application note from GBC Scientific Equipment describes how the SBasic language is used with GBC's Spectral software to automate data acquisition and manipulation for UV-Visible analysis.

To illustrate the structure of an SBasic program and the associated commands, a macro for the determination of Chlorophyll is discussed. This Chlorophyll analysis macro automates the calculations required for Chlorophyll determinations.

A step by step description of the Chlorophyll Macro code is described. This macro can also be used as a model and modified for any other analysis.

For your convenience this macro can be downloaded by clicking here (http://www.gbcsci.com/downloads/software/uvmacro1.exe).

For further details on this Application, the SBasic language or Spectral software, see your local GBC distributor or contact us (http://www.gbcsci.com/contact/index.asp).
unquote

Quote:



The SBasic that they are referring to is not Sesame Basic which is the SBasic that Sesame uses. The Sbasic that Sesame uses was written for Sesame by Andreas Goebel. I am going to take a guess and say that the SBasic they are referring to is Spectral Basic.

Thank you for that. What he is really looking for, for me, is a C/C++ solution to rounding floating point numbers(doubles) to a specific number of decimal places with the most accuracy that can be had.

An Example of this is below.

double MyRound(double Value, int NumPlaces)
{
   double Factor;
   long Temp;

   Factor = pow(10.0, NumPlaces);
   Temp = (Value * Factor) + 0.5;
   return Temp / Factor;
} 

Using the above code 8.745 rounds to 8.74, instead of the expected(based on what my math teacher in 2nd grade said) 8.75. Why? Well because 8.745 is passed in as 8.744999999999999200 and multiplying by 100 gives you 874.499999999999890000 which if you add .5 gives you 874.999999999999890000 which when cast to a long gives you 874. divide by 100 and you get 8.74

Now that is just a simple rounding function, and may be considered bad coding by some, but it displays the problem that I am trying to work around.

The Calculator that you referenced earlier does not use doubles, as far as I can tell, to do it's math as doubles are limited to numbers between 2.2-308 and 1.8e308. Since she can do numbers that contain hundreds of thousands of digits that rules out the use of doubles. but on a side note thank you for posting that as it may be useful to me personally.

-Ray

The routine above is pretty much the standard way of rounding in C. It is nearly identical to the code that is in @Round right now - and is the starting point for Ray's exploration.

Actually, Ray posted that example using "pow()".

The current code for @round is using almost precisely the code you posted, as it was authored by Andreas. In either case, whether looping by the number of decimal places, or using the pow() function (as in Ray's example), the result is the extremely similar. Just two different meanss to get to the same place (10 to the pwer of the number of decimal places required).

On Win32, "int" automatically declares a "long int" (32 bits).

Quote:


Ray,

read para 2.3 "Why it fails" and subsequent lines (ACCURATE METHOD) out of:

Fast Rounding of Floating Point Numbers in C/C++ on Wintel Platform
- http://ldesoras.free.fr/doc/articles/rounding_en.pdf -

- M.

Quote:



Mark,

all well noted, good luck on the "floating point" and "rounding" mission, reading this:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/ht...

I understood that the compiler must be as well capable to correctly "translate" the coding ...

- M.

Quote:
Maybe Ray can wrassle with this for a while:

It is a mathematics rule that what you do to one side of an equation must be done to the other side to keep them equal.
---------------------------------- Quote:

Now that we have proven that 2 = 1,(Hmmmm, how can this be?  we did the same to both sides of the equation), let's see how many decimals of accuracy Ray can provide after rounding the result.