Re: String variables combining files

[Alan Mead]

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