By "I don't think the widest variable should be saved" what exactly do you mean? If I have email A32 in one file and email A31 in a second file, if the final merged file has email A31 then one or more email will be truncated by one character, which means data will be lost. For some people and some situations, data loss will be unacceptable. It seems obvious to me that the only way to prevent data loss would be to make the final merged string length equal to the longest of the widths encountered while merging.
It sounds like you're suggesting that PSPP should just ignore this and continue but, if so, I don't understand what you mean by "ignore" and "continue"? Also, I've outlined why not saving the widest string for a variable is a problem; what harm would be created if the widest string was saved? Why is that a bad solution? -Alan On 3/26/2015 6:49 AM, Frans Houweling wrote: > I don't think the widest variable should be saved - the same old rules > should be followed (eg. in MATCH, if the var is already present leave > it alone). Point is, in 99% of cases the incompatible-width vars are > completely irrelevant for the MATCH at hand, which will fail only > because a feeding file happens to have the same var somewhere but with > different width. > To ftr: people create .sav files from Excel data, or using import > wizards. And even trained staff may need to cope with a name that is > longer than expected. > Cheers > frans -- Alan D. Mead, Ph.D. President, Talent Algorithms Inc. science + technology = better workers +815.588.3846 (Office) +267.334.4143 (Mobile) http://www.alanmead.org Announcing the Journal of Computerized Adaptive Testing (JCAT), a peer-reviewed electronic journal designed to advance the science and practice of computerized adaptive testing: http://www.iacat.org/jcat _______________________________________________ Pspp-users mailing list Pspp-users@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-users
