/= doesn't do what you think it does?

It will make sense once you're done reading...

Code:

---

for ( ...k++)
for (int i = 0; i <= argc-3; i++){                       
        cout << kFmap[k][namesmap[i]] << " kFmap | ";
        cout << F[kFmap[k][namesmap[i]]] << " | ";
        F[kFmap[k][namesmap[i]]] /= argc-2;
        cout << F[kFmap[k][namesmap[i]]];
        cout << endl;
}

---

I would have something like this as result:

F(before /=) probability(Fafter /=)
1 0.10
1 0.10
1 0.10
3 0.30
1 0.10
1 0.10
3 0.03 --> It took the value above, 0.3, and divided it by the total
1 0.10
1 0.10
1 0.10

..so it took the probability twice on the second value that was the same as a value already calculated! Whats the deal with this? Logically, F[kFmap[k][namesmap[i]]] /= argc-2, should replace the current value of each F value with the divided by (argc-2) value of the current F. Why is it doing dividing the the n-1 value of F for the calculation of F(n). This behavior seems to be recursive as I get multiple divisions for multiple similar values. Removing the identical occuring values is planned but why am I seeing this weird behavior? This behavior may be limited to vectors.

This raises a concern. I want to create a function that takes a vector, and removes multiple occurances of members, like this: vectA = removecopies(vectA). This may not work since vectA is made to equal a called(and modified) instance of itself. Is this the case?

I suggest that you post the smallest and simplest compilable program that demonstrates the problem.

Quote:

---

Originally Posted by laserlight

I suggest that you post the smallest and simplest compilable program that demonstrates the problem.

---

I'm trying,

cout << F[kFmap[k][namesmap[i]]] / (argc-2); worked as it should though, and all F[kFmap[k][namesmap[i]]] values are legit. I tried storing F[kFmap[k][namesmap[i]]] / (argc-2) in an intermediate variable and then make F[kFmap[k][namesmap[i]]] = midvar, casting everything to float, but that failed too.

Quote:

---

Originally Posted by laserlight

I suggest that you post the smallest and simplest compilable program that demonstrates the problem.

---

I don't know if this is possible as this calls multiple classes, which call various libs. But could you tell me about how vectors store values [in detail, i.e memory allocation]? Somehow the program mistakes the percentage calculation of F[n-1] to be F[n], and theres no reason for this as the loop begins a new instance each run. I'm compiling g++ with ansi option and I'm getting no warnings. ansi conforms to ISO C90, but not C99 as it is a work in progress, I'll try passing C99 ansi flag...

here is some more info:

F[ kFmap[k][ namesmap[i] ] ]

kFmap[k] is vector<map<string,int> > //returns an int
namesmap[i] is <string,int> , returns the string of truncated filenames of argv's
F[] is vector<int> //returns an int

Quote:

---

I'm trying

---

Obviously, I cannot compile and run your code. In the meantime, I can only guess what kFmap, namesmap and F (F? That is a terribly undescriptive name!) are. My guess is that you are looking at a problem with integer division or floating point inaccuracy, but I am not good enough to determine anything given your code snippet.

I've added more information.

Quote:

---

But could you tell me about how vectors store values [in detail, i.e memory allocation]?

---

Since vectors are required to store their elements contiguously, they pretty much always use an internal dynamically allocated array. Quoting from Josuttis' The C++ Standard Library: "Inserting or removing elements invalidates references, pointers, and iterators that refer to the following elements. If an insertion causes reallocation, it invalidates all references, iterators, and pointers."

Quote:

---

I don't know if this is possible as this calls multiple classes, which call various libs.
...
Somehow the program mistakes the percentage calculation of F[n-1] to be F[n], and theres no reason for this as the loop begins a new instance each run.

---

So, are you sure that the problem is not elsewhere? Maybe you have a bug elsewhere, and a bug in this code, and the interaction between those two bugs are producing the current problem. Basically, you need to isolate this current code such that you can determine that it really works (and ideally write unit tests for it). If that does not fix the problem, then there is probably another bug elsewhere that needs to be fixed.

Quote:

---

Originally Posted by laserlight

Since vectors are required to store their elements contiguously, they pretty much always use an internal dynamically allocated array. Quoting from Josuttis' The C++ Standard Library: "Inserting or removing elements invalidates references, pointers, and iterators that refer to the following elements. If an insertion causes reallocation, it invalidates all references, iterators, and pointers."


So, are you sure that the problem is not elsewhere? Maybe you have a bug elsewhere, and a bug in this code, and the interaction between those two bugs are producing the current problem. Basically, you need to isolate this current code such that you can determine that it really works (and ideally write unit tests for it). If that does not fix the problem, then there is probably another bug elsewhere that needs to be fixed.

---

iso c++98 doesn't tell me anything. everything works fine except for that one line, I have made sure that all the vals are in their right place, havent I? I've shown what the values of F are before the /= operation. Whatever happens before this point is redundant.

"Inserting or removing elements invalidates references, pointers, and iterators that refer to the following elements." --> I guess this explains it doesn't it? "and iterators".

Its bad luck for me that this shocking that this effect is recursive, although quite unprobable to start with. Same goes for the fact that iso c98 doesn't cover this issue. Right? I have made this sample program, but it works fine:

Code:

---

#include <iostream>
#include <vector>
using namespace std;

int main(){
        vector<int>        A;
        A.resize(10);
        A[0] = 10;
        A[1] = 20;
        A[2] = 30;
        A[3] = 40;
        A[4] = 50;
        A[5] = 10;
        A[6] = 10;
        A[7] = 80;
        A[8] = 90;
        A[9] = 100;
       
        for (int i = 0; i < 10; i++){
                cout << A[i] << " | ";
                A[i] /= 10;
                cout << A[i] << endl;
        }
return 0;
}

---

To be fully accurate I would have to emulate the entire sequence of events of things being passed from container to container. But, I fail to understand how this is necessary. Containers should only keep track of their assigned values - not how it was assigned in the container where it came from.

Quote:

---

I have made sure that all the vals are in their right place, havent I? I've shown what the values of F are before the /= operation

---

I don't know, since your code snippet does not correspond to your example output.

Quote:

---

"Inserting or removing elements invalidates references, pointers, and iterators that refer to the following elements." --> I guess this explains it doesn't it? "and iterators".

---

I don't know, just given the information at hand.

Quote:

---

Same goes for the fact that iso c98 doesn't cover this issue. Right?

---

The 1998 version of the C++ Standard does not guarantee that vectors store their elements contiguously. On the other hand, this is fixed in the 2003 version of the C++ Standard, and it is highly unlikely that any sane standard library implementation would have implemented vectors such that they comply with C++98 but do not comply with C++03.

Quote:

---

To be fully accurate I would have to emulate the entire sequence of events of things being passed from container to container.

---

What you can do is to populate F, kFmap and namesmap with test data, then use them in this part of the code. When you show us this test program, show everything, from the population of the containers to both of the loops to the exact output. Do not truncate anything, do not change anything, not even the sample output.

what is the g++ parameter for iso c++03? I don't think there is one (according to the man page).

Quote:

---

what is the g++ parameter for iso c++03? I don't think there is one (according to the man page).

---

You're barking up the wrong tree. I am certain that g++ is not so brain damaged as to implement vector such that it does not comply with C++03. If it did, then it would have been filed as a bug more than 5 years ago.

Looking at your example, it is obvious that no reference, pointer or iterator can be invalidated. We're talking about things like this:

Code:

---

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> vec(1, 123);
    int& r = vec[0];
    std::cout << vec[0] << " == " << r << std::endl;
    vec.resize(vec.capacity() + 1); // r is invalidated
    vec[0] = 456;
    std::cout << vec[0] << " == " << r << std::endl;
}

---

I have simplified code to demonstrate my example, please feel free to extend it to wider sets.

edit: fixed that annoying error message at the end.

Code:

---

#include <iostream>
#include <vector>
#include <map>
using namespace std;

int main(){
        vector<vector<float> > kF;
        vector<float> F;
        map <int, string> namesmap;
       
        namesmap[1] = "one";
        namesmap[2] = "two";
        namesmap[3] = "three";
        namesmap[4] = "four";
       
        vector<map<string,int> > kFmap;
        kFmap.resize(2);
        kFmap[0][namesmap[1]] = 5;
        kFmap[0][namesmap[2]] = 10;
        kFmap[0][namesmap[3]] = 5;
        kFmap[0][namesmap[4]] = 20;
       
        kFmap[1][namesmap[1]] = 5;
        kFmap[1][namesmap[2]] = 5;
        kFmap[1][namesmap[3]] = 5;
        kFmap[1][namesmap[4]] = 20;
       
        for (unsigned int k = 0; k < 2; k++){
                cout << "k = " << k << endl;
                F.resize(6);
                for (int i = 1; i <= 4; i++){
                        F[kFmap[k][namesmap[i]]]++;
                }
                for (int i = 1; i <= 4; i++){                       
                        cout << kFmap[k][namesmap[i]] << " kFmap | ";
                        cout << F[kFmap[k][namesmap[i]]] << " | ";
                        F[kFmap[k][namesmap[i]]] /= (10); //bug
                        cout << F[kFmap[k][namesmap[i]]] << " | ";
                        cout << endl;
                } cout << endl;
                kF.push_back(F);
                F.clear();
        }
        return 0;
}

---

Quote:

---

Originally Posted by laserlight

You're barking up the wrong tree. I am certain that g++ is not so brain damaged as to implement vector such that it does not comply with C++03. If it did, then it would have been filed as a bug more than 5 years ago.

Looking at your example, it is obvious that no reference, pointer or iterator can be invalidated. We're talking about things like this:

Code:

---

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> vec(1, 123);
    int& r = vec[0];
    std::cout << vec[0] << " == " << r << std::endl;
    vec.resize(vec.capacity() + 1); // r is invalidated
    vec[0] = 456;
    std::cout << vec[0] << " == " << r << std::endl;
}

---

---

I was referring to pointers as the possible pointers that exist within the vector or map class during its operation.

Given the complexity of your original post, I'm going to assume that this is part of some much larger program.

When dealing with apparent memory corruption, there is always a "cause" and an "effect".

For simple bugs, like say
a = 42 / 0;
the cause and effect are in the same place. As soon as the bug happens, you get to know about it.

Memory corruption on the other hand is much trickier.

In short, excessive analysis of where the problem appears (the effect) isn't going to help you understand the real problem (the cause). The true cause of the problem could be in a completely different area of the code.

If you extract this code, put a minimal support environment around it, and it works, then you can be pretty sure the real problem is somewhere else.

Upon further research, it appears that c++99 isn't fully supported. Some of 03 is supported, but you still pass the 99 flag to it, and it says you can also use -pedantic but it won't tell you which of 03 is in passing -c++99 and which is in pedantic.

What I did is use the at method where the index for F comes from an "untrusted" source (in very indirect ways from a map). Try this:

Code:

---

#include <iostream>
#include <vector>
#include <map>
#include <exception>
using namespace std;

int main(){
    try {
            vector<vector<float> > kF;
            vector<float> F;
            map <int, string> namesmap;

            namesmap[1] = "one";
            namesmap[2] = "two";
            namesmap[3] = "three";
            namesmap[4] = "four";

            vector<map<string,int> > kFmap;
            kFmap.resize(2);
            kFmap[0][namesmap[1]] = 5;
            kFmap[0][namesmap[2]] = 10;
            kFmap[0][namesmap[3]] = 5;
            kFmap[0][namesmap[4]] = 20;

            kFmap[1][namesmap[1]] = 5;
            kFmap[1][namesmap[2]] = 5;
            kFmap[1][namesmap[3]] = 5;
            kFmap[1][namesmap[4]] = 20;

            for (unsigned int k = 0; k < 2; k++){
                    cout << "k = " << k << endl;
                    F.resize(6);
                    for (int i = 1; i <= 4; i++){
                            F.at(kFmap[k][namesmap[i]])++;
                    }
                    for (int i = 1; i <= 4; i++){
                            cout << kFmap[k][namesmap[i]] << " kFmap | ";
                            cout << F.at(kFmap[k][namesmap[i]]) << " | ";
                            F.at(kFmap[k][namesmap[i]]) /= (10); //bug
                            cout << F.at(kFmap[k][namesmap[i]]) << " | ";
                            cout << endl;
                    } cout << endl;
                    kF.push_back(F);
                    F.clear();
            }
    }
    catch (exception& e) {
        cout << e.what() << '\n';
    }
        return 0;
}

---

What is the reasoning behind this? Can you tell me about untrusted sources? I'd like to know how this stuff works...

Edit: that didn't do it for me, I get vector::_M_range_check error. And when I try it in my main program I don't even get that - just the same faulty results!

Quote:

---

Originally Posted by Salem

If you extract this code, put a minimal support environment around it, and it works, then you can be pretty sure the real problem is somewhere else.

---

Indeed, hence the idea is not "to extend it to wider sets", but to use it to determine if the problem is in that portion of code, or likely to be elsewhere.

Quote:

---

Originally Posted by elninio

What is the reasoning behind this? Can you tell me about untrusted sources? I'd like to know how this stuff works...

---

I think anon made the same mistake as me: talking too much :)

Here "untrusted" merely means that you cannot be sure that the index provided by the "source" is a valid index for use with the vector. You can either perform a check yourself (compare the index with the vector's size()), or use at() with the index, upon which a std::out_of_range exception will be thrown if the index is invalid (out of range).

Quote:

---

Originally Posted by elninio

Edit: that didn't do it for me, I get vector::_M_range_check error.

---

That means that an exception was thrown, and you are using an index that is out of range (i.e., trying to access the vector out of bounds).

It looks that you are trying to use the values in the map, such as 10 and 20, to index into a vector that has only size 6. Your logic doesn't hold.

By "untrusted" I meant a value that doesn't come from an obvious place (such as a loop counter) and that isn't validated.

There's no such thing as C++99. There's C99, which is completely irrevelant to your problem.

Stop seeking the problem with the compiler. It does not contain bugs that any application that is not extremely complex or irregular will uncover.

Quote:

---

Originally Posted by CornedBee

There's no such thing as C++99. There's C99, which is completely irrevelant to your problem.

Stop seeking the problem with the compiler. It does not contain bugs that any application that is not extremely complex or irregular will uncover.

---

Not seeking to put blame on the compiler, just hoping that maybe some newer standard could give me a warning about some bad practice which i may be doing that may be contributing to the problem.

Quote:

---

Originally Posted by anon

It looks that you are trying to use the values in the map, such as 10 and 20, to index into a vector that has only size 6. Your logic doesn't hold.

By "untrusted" I meant a value that doesn't come from an obvious place (such as a loop counter) and that isn't validated.

---

The size 6 refers to the span of maps, 10 and 20 are INSIDE the map, right?


vector [ map1 map2 ...]
5 5
10 5
5 5
20 20

Quote:

---

Originally Posted by elninio

The size 6 refers to the span of maps, 10 and 20 are INSIDE the map, right?


vector [ map1 map2 ...]
5 5
10 5
5 5
20 20

---

so kFmap returns 5, 10, and 20 as above, yes. Then you do F[number you just got] -- but F[10] and F[20] don't exist....

One example of a possible out of bounds access is this:

Code:

---

for (int i = 1; i <= 4; i++){
    F.at(kFmap[k][namesmap[i]])++;
}

---

kFmap only has 2 elements, but you access kFmap[2], kFmap[3] and kFmap[4].

Quote:

---

Originally Posted by laserlight

One example of a possible out of bounds access is this:

Code:

---

for (int i = 1; i <= 4; i++){
    F.at(kFmap[k][namesmap[i]])++;
}

---

kFmap only has 2 elements, but you access kFmap[2], kFmap[3] and kFmap[4].

---

Yep, it looks to me like that explains the problem too.

Quote:

---

Originally Posted by laserlight

One example of a possible out of bounds access is this:

Code:

---

for (int i = 1; i <= 4; i++){
    F.at(kFmap[k][namesmap[i]])++;
}

---

kFmap only has 2 elements, but you access kFmap[2], kFmap[3] and kFmap[4].

---

And k only looped from zero to one.

Quote:

---

Originally Posted by laserlight

One example of a possible out of bounds access is this:

Code:

---

for (int i = 1; i <= 4; i++){
    F.at(kFmap[k][namesmap[i]])++;
}

---

kFmap only has 2 elements, but you access kFmap[2], kFmap[3] and kFmap[4].

---

the ith elemeth of kFmap exists. I have two maps of size 4 in it.

I don't access kFmap[3] and [4] because the k for loop only goes up to 2.

F.at(kFmap[k][namesmap[i]])++; , namesmap[i] goes up to 4, and that is VALID.

kFmap[k] goes up to < 2 , and that is also VALID.

Quote:

---

Originally Posted by tabstop

And k only looped from zero to one.

---

Yes, thats the whole point. kFmap is only defined from 0 to 1. The elements within its map are defined from 1 2 3 4. Valid again.

Quote:

---

Originally Posted by tabstop

so kFmap returns 5, 10, and 20 as above, yes. Then you do F[number you just got] -- but F[10] and F[20] don't exist....

---

you never access F[10], F increments in terms of k. so only 0 and 1 are accessed. We are accessing the kth element. Look at the K for loop, it only goes to < 2.

Quote:

---

Originally Posted by elninio

you never access F[10], F increments in terms of k. so only 0 and 1 are accessed. We are accessing the kth element. Look at the K for loop, it only goes to < 2.

---

Read your own code:

Code:

---

F.at(kFmap[k][namesmap[i]]) /= (10);

---

Let's suppose k is 0 and i is 4.
Then kFmap[0] is fine, that gets us a map. namesmap[4] is "four". We can then do the mapping -- kFmap[0]["four"] = 20. (You assigned it as kFmap[0][namesmap[4]], but that's fine.) So, the bit inside the at is 20 -- but F.at(20) throws an exception, since F only goes to 5.

Quote:

---

And k only looped from zero to one.

---

That's right, so my example is not correct.

In my defense, we're looking at code that has undescriptive variable names and magic numbers, with a complex mix of data structures that really should be simplified with the use of classes.

Quote:

---

Originally Posted by iMalc

Yep, it looks to me like that explains the problem too.

---

kFmap is a vector of maps:

vector<map<string,int> > kFmap

Its elements are defined for the following:

kFmap[0][1]
kFmap[0][2]
kFmap[0][3]
kFmap[0][4]
kFmap[1][1]
kFmap[1][2]
kFmap[1][3]
kFmap[1][4]

In your argument your saying I'm accesssing kFmap[2, 3] , thats impossible, it would have given seg fault, or not complained at all and returned 0. Its actually acessing kFmap[k][2] ,kFmap[k][3], kFmap[k][4]. and k | [0,2).

Quote:

---

Originally Posted by laserlight

That's right, so my example is not correct.

In my defense, we're looking at code that has undescriptive variable names and magic numbers, with a complex mix of data structures that really should be simplified with the use of classes.

---

k only looped from zero to one is completely valid, because kFmap is only defined from 0 to 1. Whats the problem here?

Look at the data types.

Quote:

---

Originally Posted by tabstop

Read your own code:

Code:

---

F.at(kFmap[k][namesmap[i]]) /= (10);

---

Let's suppose k is 0 and i is 4.
Then kFmap[0] is fine, that gets us a map. namesmap[4] is "four". We can then do the mapping -- kFmap[0]["four"] = 20. (You assigned it as kFmap[0][namesmap[4]], but that's fine.) So, the bit inside the at is 20 -- but F.at(20) throws an exception, since F only goes to 5.

---

You're absolutely right. Whats the point in using at() then? I want to divide some number that fits in int, by 10.

We can then do the mapping -- kFmap[0]["four"] = 20. 20/10 = 2. Thats what I want. My program is supposed to replace the '20' inside kFmap[0]["four"] with (20/10 = 2). So kFmap[0]["four"] should have 2 instead of 20.

Quote:

---

Originally Posted by elninio

Yes, thats the whole point. kFmap is only defined from 0 to 1.

---

Then you should write it in this way:

Code:

---

for (vector<vector<float> >::size_type k = 0; k < kF.size(); ++k) {

---

Then instead of:

Code:

---

for (int i = 1; i <= 4; i++){
    F.at(kFmap[k][namesmap[i]])++;
}

---

Write:

Code:

---

for (map<int, string>::iterator i = namesmap.begin(); i != namesmap.end(); ++i) {
    ++F.at(kFmap[k][i->second]);
}

---

Quote:

---

Originally Posted by elninio

k only looped from zero to one is completely valid, because kFmap is only defined from 0 to 1. Whats the problem here?

---

• It is hard to tell just what the 2 means.
• If kFmap's size changed, you must change the magic number 2.
• unsigned int is not quite the correct type to use (although it probably is).

Do you want to replace the value in the mapping, or just use the value/10?

This leads me to think you want something like

Code:

---

F[k] = kFmap[k][namesmap[i]] / 10.0;

---

or perhaps

Code:

---

F[i] = kFmap[k][namesmap[i]] / 10.0;

---

or something like that.

Quote:

---

Originally Posted by tabstop

Do you want to replace the value in the mapping, or just use the value/10?

This leads me to think you want something like

Code:

---

F[k] = kFmap[k][namesmap[i]] / 10.0;

---

or perhaps

Code:

---

F[i] = kFmap[k][namesmap[i]] / 10.0;

---

or something like that.

---

I want F[kFmap[k][namesmap[i]]] = ( F[kFmap[k][namesmap[i]]] / 10 );

Divide the current value by 10, and replace the value that was just divided.

Example:

If F[kFmap[k][namesmap[i]]] = 40. Then take 40, and replace it by 40/10, so before the loop we have 40, after the loop we have 4, at position k, i.

Quote:

---

I want F[kFmap[k][namesmap[i]]] = ( F[kFmap[k][namesmap[i]]] / 10 );

Divide the current value by 10, and replace the value that was just divided.

---

If that works, then just write:

Code:

---

F[kFmap[k][namesmap[i]]] /= 10.0;

---

Quote:

---

Originally Posted by elninio

I want F[kFmap[k][namesmap[i]]] = ( F[kFmap[k][namesmap[i]]] / 10 );

Divide the current value by 10, and replace the value that was just divided.

Example:

If F[kFmap[k][namesmap[i]]] = 40. Then take 40, and replace it by 40/10, so before the loop we have 40, after the loop we have 4, at position k, i.

---

But you can't do that -- F doesn't have a position (k, i), nor does it have a position 40. Is all you really want then

Code:

---

kFmap[k][namesmap[i]] /= 10;

---

to change the 40 where it is (inside kFmap)? I think you defined kFmap as a map from string to int, so you'll get integer division, and surely not a floating point.

Quote:

---

Originally Posted by laserlight

If that works, then just write:

Code:

---

F[kFmap[k][namesmap[i]]] /= 10.0;

---

---

THATS WHAT I'VE BEEN DOING! BUT IT DOESN'T WORK!!!! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!

That was the whole point of this thread.

Quote:

---

Originally Posted by elninio

THATS WHAT I'VE BEEN DOING! BUT IT DOESN'T WORK!!!! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!

That was the whole point of this thread.

---

You missed the very important word "If". What you said you wanted

Quote:

---

I want F[kFmap[k][namesmap[i]]] = ( F[kFmap[k][namesmap[i]]] / 10 );

---

doesn't make any sense, since F[stuff] never existed in the first place, so you certainly can't divide it by ten.

Perhaps what you have written is in fact what you want, but if so you need to make sure that every element of kFmap is a valid index into F. Neither your original nor the example we've been working with has satisfied that requirement, which means you've been trying to divide <nonexistent memory> by 10, and failing at it.

Quote:

---

Originally Posted by tabstop

You missed the very important word "If". What you said you wanted

doesn't make any sense, since F[stuff] never existed in the first place, so you certainly can't divide it by ten.

Perhaps what you have written is in fact what you want, but if so you need to make sure that every element of kFmap is a valid index into F. Neither your original nor the example we've been working with has satisfied that requirement, which means you've been trying to divide <nonexistent memory> by 10, and failing at it.

---

Your right - I'm investigating...

I guess its pure luck that its worked at all for single values?

I suggest that your post your updated test program, along with the sample output. I really do suggest that you incorporate my suggested changes (though kF.size() should be kFmap.size()) - it pretty much eliminates two sets of possible out of bound errors that might occur.

Admittedly, I forgot one very important point: what exactly are you trying to do? You have to express that in words, not in code, since your code might not accurately express what you want.

Quote:

---

Originally Posted by elninio

Your right - I'm investigating...

I guess its pure luck that its worked at all for single values?

---

I've tried making sure all the elements of kFmap[k][namesmap[i]] are within the resize value of F, but that didn't fix things.

Ok we were mistaken earlier. But can you please write clearer code, and by that I mean common sub-expression elimination.
Something like this:

Code:

---

                    map<string,int> &myMap = kFmap[k];
                    for (int i = 1; i <= 4; i++){
                            int pos = myMap[namesmap[i]];
                            cout << pos << " kFmap | ";
                            cout << F.at(pos) << " | ";
                            F.at(pos) /= (10);
                            cout << F.at(pos) << " | ";
                            cout << endl;
                    }

---

You may find that it's more efficient too if the compiler was failing to do the approariate common sub-expression elimination, and if it's more readable - everyone wins.

To see what was going on to the example, I added this wide line:

cout << i << " i | " << namesmap[i] << " namesmap[" << i << "] | " << kFmap[k][namesmap[i]] << " kFmap[" << k << "][" << nam\
esmap[i] << "] | ";

This way, I can see what is going on to what where. The output becomes this:

k = 0
1 i | one namesmap[1] | 5 kFmap[0][one] | 5 kFmap | 2 | 0.2 |
2 i | two namesmap[2] | 10 kFmap[0][two] | 10 kFmap | 1 | 0.1 |
3 i | three namesmap[3] | 5 kFmap[0][three] | 5 kFmap | 0.2 | 0.02 |
4 i | four namesmap[4] | 20 kFmap[0][four] | 20 kFmap | 1 | 0.1 |

k = 1
1 i | one namesmap[1] | 5 kFmap[1][one] | 5 kFmap | 3 | 0.3 |
2 i | two namesmap[2] | 5 kFmap[1][two] | 5 kFmap | 0.3 | 0.03 |
3 i | three namesmap[3] | 5 kFmap[1][three] | 5 kFmap | 0.03 | 0.003 |
4 i | four namesmap[4] | 20 kFmap[1][four] | 20 kFmap | 1.1 | 0.11 |


For k=1, we can now see that he's accessing F[5] three times, producing the behaviour he observes, as it redivides the quotient it just calculated. As pointed out, he accesses F[20] which is uninitialised (hence why he got 1.1).

Cheers.

Quote:

---

Originally Posted by pedestrian879

To see what was going on to the example, I added this wide line:

cout << i << " i | " << namesmap[i] << " namesmap[" << i << "] | " << kFmap[k][namesmap[i]] << " kFmap[" << k << "][" << nam\
esmap[i] << "] | ";

This way, I can see what is going on to what where. The output becomes this:

k = 0
1 i | one namesmap[1] | 5 kFmap[0][one] | 5 kFmap | 2 | 0.2 |
2 i | two namesmap[2] | 10 kFmap[0][two] | 10 kFmap | 1 | 0.1 |
3 i | three namesmap[3] | 5 kFmap[0][three] | 5 kFmap | 0.2 | 0.02 |
4 i | four namesmap[4] | 20 kFmap[0][four] | 20 kFmap | 1 | 0.1 |

k = 1
1 i | one namesmap[1] | 5 kFmap[1][one] | 5 kFmap | 3 | 0.3 |
2 i | two namesmap[2] | 5 kFmap[1][two] | 5 kFmap | 0.3 | 0.03 |
3 i | three namesmap[3] | 5 kFmap[1][three] | 5 kFmap | 0.03 | 0.003 |
4 i | four namesmap[4] | 20 kFmap[1][four] | 20 kFmap | 1.1 | 0.11 |


For k=1, we can now see that he's accessing F[5] three times, producing the behaviour he observes, as it redivides the quotient it just calculated. As pointed out, he accesses F[20] which is uninitialised (hence why he got 1.1).

Cheers.

---

Thank you.