$TT{1000001}[1][1]  = '4342';
$TT{1000002}[1][1] = also gets the value!
[download]

Ahh . . . because they point to the SAME address space. This happens when you are not careful when assigning references. Again, pull out Data::Dumper and see what is really happening.

Oh, and associative arrays ARE hashes. A hash is simply an array whose indexes are assicated with a key, a key is simply a value that is 'hashed' to produce the proper index slot. When two keys share the same slot, they are said to 'collide' with each other, and a list is created to hold both values for the key. Keys that are very similar tend to collide, such as 1000001 vs 1000002.

jeffa

I believe what you saw on the chatterbox was perhaps a bit of word play.

An associative array is as The Dictionary of Data Structures says, an abstract concept that extends the idea of a data structure indexable by numbers to an array indexable by keys, or by the association of a key with a value.

It may be implemented in a number of ways including the way that Perl chose, a hash table or hash for short. Ideas like this are present 'natively' in many modern languages and in libraries in older ones. They are called many names, often deriving from their implementation, including collections, dictionaries and hashes.

An Associative Array is then the general term to apply to all of the above. For instance it is notable that the term is not present in any of the indexes of Knuths Art of Computer Programming, specifically vol 3. Hashing however is covered in detail and is considered to be a subset of the over all problem of searching, along with Binary Trees, Linked lists, B+Trees, etc.

HTH

Yves / DeMerphq
--
Have you registered your Name Space?

I already told you why you are having the problem. Delete your initializations of $TT{1000001}[1] and you will eliminate this bug when you try to access $TT{1000001}[1]. If you want to remember that what you are dealing with is named 'mname' (and yes, I consider it good to keep this kind of textual context around) then you can use a hash of hashes of arrays rather than a hash of arrays of arrays. Accessing that would be written as $TT{1000001}{mname}[1], and again it is important not to initialize $TT{1000001}{mname} or else you can get into the same error.

Furthermore if you want to avoid the possibility of this bug or any of a number of other common bugs happening, you can use strict, and declare each of %INPUT, %STUDQT, @sorted, and every other variable with my. If going through and putting in the declarations is too much work for you, you can just catch this bug with adding the line:

no strict 'refs';
[download]

at the top of your program. Note that for any program over 20 lines, my experience is that the time saved in tracking down typos amply pays for the effort of declaring everything with my. My experience seems to be par for the course among experienced Perl programmers.

So if you want a quick fix, remove the dangerous initializations, check for strict references using the line I showed you above, and continue on.

But a piece of advice from much painful experience. One of the biggest things every programmer needs to learn is how easily you can think that you are just about to finish when you are not going to finish any time soon. The mantra, "There is just going to be one more bug, this one is it!" can go on for months. Or for larger projects, for years. It is, in fact, quite common for a year long project to appear to be on schedule until 2 weeks before the deadline. Then it starts to slip, and the estimate stays at about 2 more weeks. It can then easily continue to slip couple of years of developing and bug fixing, always seeming to be about 2 weeks off before it is finally cancelled, unfinished.

Based on the code sample that you have shown, the length of what you claim the code to be, and your inexperience, I strongly suspect that you are about to get a milder form of this lesson first hand. Please don't take my saying that personally. I am saying this based on memories of my own learning curve, how difficult I think that code organized that way would be for me to work with, and knowledge of how virtually all programmers tend to chronically underestimate how much work is really left.

That said, unless you can find a mentor who can really work with you on the design of your code, I don't think you are likely to do much better by trying to rewrite from scratch right now. But make a point of redoing this project from scratch when you have some more experience. If you have only been programming Perl for 2 months, and don't have a lot of programming experience, then you should be on a pretty steep part of your learning curve. When you have learned a little more, you should find that you would do things rather differently, and doing them differently will really make a difference. It is worthwhile sometimes to remind yourself of how much you have learned.

And to help that learning curve along, I would suggest the following:

1. As soon as you can, read tye's article, strict.pm. It will tell you a lot about how Perl can make your life easier for you.
2. Read Coping With Scoping, by Dominus, because that will help you to use strict.pm effectively.
3. Read use CGI or die; for the quick demonstration of how to use the param() and header() functions from the classic CGI module. When you know how to use those, you should not want to hand-roll that code again.
4. For more on what symbolic references (the thing that is biting you) are, and why they are so dangerous, read avoid symbolic references by Dominus. Read all three parts, largely because it has a wonderful explanation of why modularization of code matters so much.
5. To gain a better understanding of references, read references quick reference carefully. Also figure out how to use Data::Dumper, and start using it to create debugging dumps of your data structures. That will allow you to see how what you have in there compares with what you think is in there.
6. As soon as you can, pick up some good books about general programming. The usual one I like to recommend is Code Complete.
Good luck.