c++ - std :: map - Is my idea too dirty?
-
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
-
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
In 64bit code (so using XMM registers) it'll probably work, unless any DLL secretly changes a rounding mode on you and "forgets" to set it back. In 32bit code (usually using the x87 FPU stack), who knows? The danger there as usual is that keeping a double in an FPU register keeps it at whatever value was actually computed (which depending on how `stod` works internally may have bits set in the part of the 64bit significand that extends beyond the 53 bits you usually get) while storing it to memory and reloading it changes the value, and this is something that compilers think is a normal part of how they work so they do it outside of your control, though you can force a store/reload to get a safer value to work with. So it may still work, but there are some sneaky conditions that may depend on specific codegen choices the compiler makes.
-
In 64bit code (so using XMM registers) it'll probably work, unless any DLL secretly changes a rounding mode on you and "forgets" to set it back. In 32bit code (usually using the x87 FPU stack), who knows? The danger there as usual is that keeping a double in an FPU register keeps it at whatever value was actually computed (which depending on how `stod` works internally may have bits set in the part of the 64bit significand that extends beyond the 53 bits you usually get) while storing it to memory and reloading it changes the value, and this is something that compilers think is a normal part of how they work so they do it outside of your control, though you can force a store/reload to get a safer value to work with. So it may still work, but there are some sneaky conditions that may depend on specific codegen choices the compiler makes.
Thank you so much! To be honest I don't get all of your explanations at the moment. But the most important Thing is, that you Point out, that there can be a Problem... and that corresponds with "my bad Feeling". So now it will be my part to investigate more for possible pitfalls Thank you very much again. [Edit] And please flag your Response as an answer, it is much more than a "general"
It does not solve my Problem, but it answers my question
-
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
-
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
-
Simple answer: no. Double and float values have an inherent precision problem so you can never rely on two numbers being the same. You need to rethink your design.
-
This is really too pessimistic about floating point arithmetic though. There are definitely cases where doubles will reliably have exactly equal values. They're not non-deterministic, just hard to work with and 80bit nonsense messes things up extra.
-
This is really too pessimistic No, realistic. Far too many people use floating point numbers where they are not necessary, or actually wrong.
-
That is true, but "you can never rely on two numbers being the same" is not. There are conditions that can be satisfied that will make the numbers the same.
-
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
I'm a bit late to the party. The key point of a map is that no two elements in a map container can have equivalent keys. If the number of significant digits entered is less than the precision of
doublevalues, this will not happen (besides entering the same value again which applies toints as well). But you might get problems when trying to access elements by key when the argument is from other sources (affected by rounding). That would be my bad feeling: While there is no problem with the map itself, key based operations ([]operator,erase,swap,find) might behave not as expected (no match). Even when not using such operations now but only iterator based ones, they may be used later when updating the code. So you should at least place a comment about this. Another option is creating your ownstd::mapbased class that disables the affected operations or replaces them with a version that treats close numbers as identical (defining an epsilon). -
I'm a bit late to the party. The key point of a map is that no two elements in a map container can have equivalent keys. If the number of significant digits entered is less than the precision of
doublevalues, this will not happen (besides entering the same value again which applies toints as well). But you might get problems when trying to access elements by key when the argument is from other sources (affected by rounding). That would be my bad feeling: While there is no problem with the map itself, key based operations ([]operator,erase,swap,find) might behave not as expected (no match). Even when not using such operations now but only iterator based ones, they may be used later when updating the code. So you should at least place a comment about this. Another option is creating your ownstd::mapbased class that disables the affected operations or replaces them with a version that treats close numbers as identical (defining an epsilon). -
This is really too pessimistic No, realistic. Far too many people use floating point numbers where they are not necessary, or actually wrong.
-
So with your Argumentation one Need also to say: Don't use int_64 ... which of course makes no sense. A double value has a discret number of numbers it can represent, same as an int_64 has ;)
It does not solve my Problem, but it answers my question
-
So with your Argumentation one Need also to say: Don't use int_64 ... which of course makes no sense. A double value has a discret number of numbers it can represent, same as an int_64 has ;)
It does not solve my Problem, but it answers my question
-
Try this
#define NUMBER 133333333
int main()
{
int nValue = NUMBER;
float fValue = NUMBER;printf("%d\\n", nValue); printf("%f\\n", fValue); -
Would you ever do something like this:
std :: map >
I don't see a reason why not to do it, but I have a bad feeling doing it. Any Remarks / objections? Ok, this
double - Keyis a user Input with a known/limited number of decimal places. I could also take this into acount and use astd :: map >
But why I should? Btw: Performance is out of questions, the map size is Maximum 10 items. Thank you very much in advance.
It does not solve my Problem, but it answers my question
0x01AA wrote:
std :: map<double, MyType, std :: less<double> >
Hi, I was avoiding this discussion but I wanted to just add one more comment. The FPU has a state that has an affect on the precision. In other words... when the FPU is in various states you get a different rounding value. You can control this state with [_controlfp_s](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/controlfp-s) Printer DLL and other libraries outside of your control could potentially change the thread FPU state causing your std::map to contain multiple floating point numbers from the same calculations. Unfortunately on Windows user-applications cannot always control third-party DLL from loading into your process. Those DLL could modify and then fail to reset the floating point state. The answer is "Yes" what you are proposing would work 99% of the time or in "laboratory" conditions where you control both the hardware and software. But if you tried to ship out a commercial product using the above technique... you will almost certainly have a small percentage of the conditions I described above. Best Wishes, -David Delaune
-
0x01AA wrote:
std :: map<double, MyType, std :: less<double> >
Hi, I was avoiding this discussion but I wanted to just add one more comment. The FPU has a state that has an affect on the precision. In other words... when the FPU is in various states you get a different rounding value. You can control this state with [_controlfp_s](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/controlfp-s) Printer DLL and other libraries outside of your control could potentially change the thread FPU state causing your std::map to contain multiple floating point numbers from the same calculations. Unfortunately on Windows user-applications cannot always control third-party DLL from loading into your process. Those DLL could modify and then fail to reset the floating point state. The answer is "Yes" what you are proposing would work 99% of the time or in "laboratory" conditions where you control both the hardware and software. But if you tried to ship out a commercial product using the above technique... you will almost certainly have a small percentage of the conditions I described above. Best Wishes, -David Delaune
-
0x01AA wrote:
std :: map<double, MyType, std :: less<double> >
Hi, I was avoiding this discussion but I wanted to just add one more comment. The FPU has a state that has an affect on the precision. In other words... when the FPU is in various states you get a different rounding value. You can control this state with [_controlfp_s](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/controlfp-s) Printer DLL and other libraries outside of your control could potentially change the thread FPU state causing your std::map to contain multiple floating point numbers from the same calculations. Unfortunately on Windows user-applications cannot always control third-party DLL from loading into your process. Those DLL could modify and then fail to reset the floating point state. The answer is "Yes" what you are proposing would work 99% of the time or in "laboratory" conditions where you control both the hardware and software. But if you tried to ship out a commercial product using the above technique... you will almost certainly have a small percentage of the conditions I described above. Best Wishes, -David Delaune
