|
Hello. I have the following question.
I have an array of floating-point values and I want to sum them all. Does the accuracy of result depend on the order in which I sum them? Should I sort this array for best accuracy?
I'll be grateful for any help
Dmitry
|
|
|
|
|
Technically, you should sum the values from smallest to largest (in magnitude, -1000.0 is larger than 0.1). In practice, it really only makes a difference if your numbers have an large range (no, I'm not going to define 'large' - it depends on your data).
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you for reply!
Can you explain in a few words, why it is so? (why should I
sum from smallest to largest)?
Dmitry
|
|
|
|
|
Floating point variables only have a limited amount of precision. They can represent very large and very small numbers, but if they represent a very large number, they can't keep track of all the decimal places. A double has about 15 digits of precision, but can represent numbers up to about 10308.
Say you're adding two numbers, 100000000000000.0 and 0.000001. The answer is obviously 100000000000000.000001. However, a double type only has 15 digits of precision, so it rounds this to 100000000000000. Even if you add 0.000001 to this number a billion times, you'll still get the same result - the intermediate results are rounded down because the double type can't support enough digits of precision.
The solution is to add the numbers from smallest to largest - so that you're always adding together numbers that have similar numbers of digits. This way the double type is not required to have large numbers of digits of precision. Therefore, your results do not lose as much precision, and the result is more accurate.
Technically, you can go even better than summing smallest to largest. The most accurate solution is actually to sum the results in a sort of tree structure, where you sum each pair of adjacent values and store the intermediate results, then go back and sum the adjacent pairs of intermediate results, until you get to a single result at the end:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
3 7 11 15 19 23 27 31
10 26 42 58
36 100
136This will give you the absolute greatest accuracy possible, but the effort is not worth the complexity in the calculation unless you absolutely need the accuracy. Summing smallest to largest is usually the best solution.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
In VC++ How to read the data directly from file into CSring object.
anil
|
|
|
|
|
use CStdioFile mfc class
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Dear friends,
we have Install mac os on PearPC. we have create 6GB hard disk image.
During Installation, we are getting error" unable to install bundle
software on this computer".I think this error is due to 6 GB hard disk
image. so pls suggest any proper solution to us, so we are able to solve
our problem. also suggest any forums related to this issue, so i will
post my query on this forums.
I know this is not related to Mac Os forum. But if you know soln of this
problem , give me a reply.
Regards
kedar
Girish
Software Developer
|
|
|
|
|
vcforums wrote: know this is not related to Mac Os forum. But if you know soln of this problem , give me a reply.
I believe, you will get better answer at MAC forums.. as user here are more Familiar wityh Windows Os only
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Dear All
I want to write a dialog based application where user is prompted to choose some file using CFileDialog. I have to open the file selected by the user with default Shell editor associated
with that file from my application ( For e.g, if user selecets "Sample.bmp", i must be able to
run "mspaint.exe" application with "sample.bmp" opened for editing from my application ) and i must not allow user not to do any operation with my application till he closes the opened application.
Can somebody help me in implementing this functionality.
Thanks in advance
Regards
Krishna
|
|
|
|
|
Hi,
you can use ShellExecuteEx() and the use the handle to the created process returned by it to check its existence.
Bye,
Cool Ju 
Dream Ur Destiny
-- modified at 4:07 Friday 10th February, 2006
|
|
|
|
|
Try this :
CString csCommand = "C:\\WINDOWS\\system32\\mspaint.exe c:\somewhere\sample.bmp";
DoExecCommand( csCommand, TRUE );
BOOL CMyDialog::DoExecCommand( CString csCommand, BOOL bWait )
{
STARTUPINFO si;
::ZeroMemory(&si, sizeof si);
PROCESS_INFORMATION pi;
::ZeroMemory(&pi, sizeof pi);
char* pszCmd = csCommand.GetBuffer(0);
BOOL bResult = CreateProcess( NULL, // pointer to name of executable module
pszCmd, // pointer to command line string
NULL, // process security attributes
NULL, // thread security attributes
FALSE, // handle inheritance flag
NORMAL_PRIORITY_CLASS, // creation flags
NULL, // pointer to new environment block
NULL, // pointer to current directory name
&si, // pointer to STARTUPINFO
&pi // pointer to PROCESS_INFORMATION
);
if(bResult)
{
if(bWait)
{
DWORD dwResult = WaitForSingleObject( pi.hProcess, INFINITE );
}
CloseHandle( pi.hProcess );
}
return( bResult );
}
|
|
|
|
|
Hi all,
I'm wondering would you prefer to use typedef to define a new type name than using the #define? Since macro should be avoided as much as possible, would you say typedef is better?
Is there any difference?
Thanks
|
|
|
|
|
hi
if you use typedef , you can't use the typdef specifiers inside function definitions ,however if you use #define you need to be careful with arguments since they may produce unexpected results.
"Every morning I go through Forbes list of 40 richest
people in the world. If my name is not in there, I go to
work..!!!"
|
|
|
|
|
Link2006 wrote: typedef is better
Sure, typedef is a thousand times better. First, a type defined by a typedef is ... a type, whereas a #define does not have any type. Type checking at compilation type is not done with #defines, type casting is much safer when used with types. Avoid #defines as much as possible.
~RaGE();
|
|
|
|
|
Rage wrote: Type checking at compilation type is not done with #defines, type casting is much safer when used with types
Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
Rage wrote: Avoid #defines as much as possible
I can agree on this if you would use it solely as a typedef replacement.
But #defines are very usefull to make codeing easier like constants and macros
codito ergo sum
|
|
|
|
|
BadKarma wrote: Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
#define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
BadKarma wrote: #defines are very usefull to make codeing easier like constants and macros
I won't go into a flame war, but const is definitely better than a #define.
I agree though than SIMPLE macros can be useful.
~RaGE();
|
|
|
|
|
Hi,
don't take this wrong, but the question was which is preferred,
using #define or typedef to create a new type. You said its preferred
to use typedef (which I agree ) because when using #define the compiler
wouldn't be able to check the types.
I just stated the latter, as false.
Rage wrote: #define a 3
I agree that the 3 doesn't resemble a single type, but that wasn't what i meant.
Rage wrote: ..., but const is definitely better than a #define.
I could agree to this if one is writing an application for Computer based systems.
But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
And when it comes to MFC there is no such thing as a SIMPLE macros 
codito ergo sum
|
|
|
|
|
BadKarma wrote: to create a new type
Actually I even never considered using #define for creating types.
BadKarma wrote: I just stated the latter, as false.
Well, Ok.
BadKarma wrote: But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
If the const is loaded in RAM, which it should not, then the compiler does not optimize it correctly.
If the const is used in ROM, then it makes no difference with the #define, since the #define is replaced in-place in the code before compilation, but the value is also in the ROM.
~RaGE();
|
|
|
|
|
Rage wrote: I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
You save memory because if you use const, the value is placed in ROM as a variable, and the compiler creates code to load it from memory like a variable every time it is needed. It (usually) takes more time and memory than if the compiler just loads an constant value.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Rage wrote: #define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
My guess to the answer - the type of "a" is not determined in the #define statement - it depends on where "a" is used in the program. As far as I know, "a" is replaced by "3" by the pre-compiler before compilation, so it may be treated as a char in one part of the program and as an int in another, etc.
So if you had the following code:
#define defValue3 3
char cOneChar;
int iIntVar;
cOneChar = defValue3 + 32;
iIntVar = defValue3 + 32;
|
|
|
|
|
Never, ever use #define to define new types. It's just asking for trouble.
One reason the others haven't mentioned yet is multiple variable definitions on one line. Say you do this:
#define INTPTR int*
INPTR p1, p2; You may think that p1 and p2 have the same type... They do not. p1 is an int* and p2 is an int. The preprocessor expands the macro definition to produce
int* p1, p2; Remember that the * modifies the variable, not the type, so the * only makes p1 a pointer.
Typedefs don't have this problem
typedef int* INTPTR;
INTPTR p1, p2; behaves exactly as expected.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
int* p1, p2;
You would not advertise this style, no? 
Were not doing C here - this is C++! 
When you really need the variable - that is when you are ready to give it a value - declare it like so:
int* p1 = WhateverGetsMeAnIntPtr();
or better still
int* p2( WhateverGetsMeAnIntPtr());
Stop definig variable you might end up not using.
Start definig variables when you need them.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Right ...
Until your compiler says "initialization of variable declared when needed skipped by goto" ... then you go back to declaring them all at the top of your function 
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: ...goto...
Hmm - this sounds like Linux driver code.
Or is someone else still using goto on a regular basis?
Anyway, if you jump over one part of your code and are missing variables later, your code is deeply flawed anyway.
Some variables do need to exist throughout the whole function - most are not.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
