Re^3: unxpected sort warnings while using sort

As AnomalousMonk has pointed out, the way your data is formatted is important.

The way most programmers would expect to see your data is like this:

2
3
3
3
5
7
8
12
...
[download]

If, instead, it looks like this:

2 3 3 3 5 7 8 12 ...
[download]

then you have a problem .. or rather, it needs to be handled differently in your code.

For the second case, you need:

my @data = split /\s+/,<$in>;
[download]

In addition, the way the "sort_num" is called has some issues in your code.

This is how it should be called:

 my @new_sort = sort_num (@data);
[download]

And call it only ONCE.

"Despite my privileged upbringing, I'm actually quite well-balanced. I have a chip on both shoulders." - John Nash

Comment on Re^3: unxpected sort warnings while using sort Select or Download Code

Replies are listed 'Best First'.
Re^4: unxpected sort warnings while using sort by perlynewby (Scribe) on Jul 23, 2015 at 20:30 UTC
correct formatting of data is something new to me...I never thought about it once in this case of numbers vs strings but ,now, I will. One more question can anyone explain why I can't do slurp while populating the data var? I am aware of the memory issue that may arise if file is big but for these little programs is not an issue to me...but then again I am learning and you may have some experiences to share ;-) `local $/; # slurp mode` thank you all! learning to do subs and modules now so many more new things to think about	[reply] [d/l]
Re^5: unxpected sort warnings while using sort by AnomalousMonk (Archbishop) on Jul 24, 2015 at 00:19 UTC
... why I can't do slurp while populating the data var? A lot depends on the organization of data in your input file. (These little details really do matter.) The following discussion assumes you have not changed the default value of `$/` which is `"\n"` (newline); see perlvar. If you have a file in which each individual number is on a separate line that is terminated by a newline, the statement `# list context file read -- effective slurp: entire file is read` `my @each_element_has_a_line = <$input_filehandle>;` reads each and every line of the file as a string into a separate element of the array. This is the effect of reading the file in list context. See readline. If this operation is followed by a `chomp @each_element_has_a_line;` statement, each element of the array/line read from the file/string has a newline removed from the end, if one was present. See chomp. If you're lucky, you now have an array of strings which each look like a number to Perl, and so can be handled by numeric operators like `<=>`. If you have a file organized as above, the statement `# scalar context slurp` `my $all_lines_in_a_single_string = do { local $/; <$input_filehandle>; };` reads the entire content of the file, all the lines, newlines and all, into a single string. This is the effect of reading the file in scalar context with `$/` undefined; this is referred to as file slurp mode. If this operation is followed by a `chomp $all_lines_in_a_single_string;` a single newline, if present, will be removed from the end of this single string. What remains requires further processing to extract the digit groups (numbers) from the string to an array so they can be sorted. If, OTOH, you have your data in a file organized as a single line of digit groups separated by whitespace(s) (which seems to have been the case with your OPed data), reading the file in slurp mode or not really doesn't matter because there's only one thing there to read to begin with. (This is your answer to the quoted question.) If you read to an array, you get (somewhat confusingly) an array with a single element: a string that is the single string that was in the file. If you read to a scalar... again, a single string. `chomp`-ing this single element/scalar/string may or may not help you; you still must do further processing to extract the numbers. I urge you to do some experimentation with these various permutations of file organization, slurping and file-read context (list vs. scalar). I also urge you read about the general topic of context in Perl (the Context tutorial is one of the Tutorials available in the Monastery; see also Context in perldata) and, in general, RTFM! (Discussion of context should be a significant topic in any decent commercial Perl text or reference book.) Give a man a fish: `<%-(-(-(-<`	[reply] [d/l] [select]
Re^5: unxpected sort warnings while using sort by NetWallah (Canon) on Jul 23, 2015 at 22:33 UTC
The "slurp" setting reads all "records" of the file in one shot. In your case, your entire file is just one record (a string of space-separated numbers). So, for this program, there is no difference whether or not you slurp the file. Now - if you DID have multiple records, as in the first example I showed, without slurp, you get one record at a time. With slurp, it reads the entire file into memory, as a string, and it is up to you to separate the pieces. In the majority of the cases, you normally process data files one record at a time, so the default of "NO SLURP" makes sense. Sometimes, you need the entire content in memory before you can make sense of the file - for example, when reading config information, or an XML file. Typically, these would be small files, where memory consumption would not be an issue. A third case would be if you were comparing the contents of a smaller file with a larger one - you would read the smaller one into memory if possible. "After Perl everything else is just assembly language."	[reply]
Re^6: unxpected sort warnings while using sort by perlynewby (Scribe) on Jul 24, 2015 at 23:03 UTC
thank you all for your patience while explaining these basic things that you have gained, experienced and learned as a beginner, I read and try to use the stuff I've read into practice ergo my little programs I try to create to test the stuff i read...sometimes, I don't know (forsee) the problems until I get there...then read to solve and still not know the answer...so I ask coz there still too many variables for me as a new perl beginner that may be the source of issues...so I DO appreciate knowledge of practice and experience from you monks. thank you	[reply]