SPSS Statistics

Expand all | Collapse all

a curious case of the equal sign

  • 1.  a curious case of the equal sign

    Posted Tue August 31, 2021 08:34 AM



    I have yet a curious issue happening. We have a macro that gets fed a list of questions (items) with corresponding scoring keys (keys) and maximum total score for each question (maxscrs). It uses this information to score the item (right/wrong or number correct, and then compute the proportion correct for the item).


    Part of the call for the macro looks like the 3 lines below:




               items        =  PE51S01 PE51S02 PE51S03 PE51S04 PE51S05 PE51S06 PE51S07 PE51S08 PE51S09 PE51S10 ...  /

               keys         =  X 3 X X X 2 1 4 2 1 ...  /

               maxscrs      =  2 1 1 2 1 1 1 1 1 1 ...  /




    One of my colleagues using the macro reports, and I confirmed, the following behavior:


    1. When specifying the call with all "intended" items in the test, a total of 230, it uses "=" as the first key and then the keys for the remaining items are all out of sequence by 1.
    2. When deleting the first item, it runs fine.
    3. When deleting the second item, it runs fine.
    4. When deleting the last item, it runs fine.
    5. When swapping items 1 & 2 it also uses "=" as the first key
    6. When feeding the program the first 15 items in the original order it runs fine.
    7. When specifying a call with a different set of items, over 300 of them, it runs fine.


    He is observing this behavior using v26.

    I am running the exact same code in v27 and observe no problems at all.


    I modified the macro so that you can use quotes around the string that is passed on to the macro, and then the string gets unquoted, and he observes the same behavior.


    Any clues as to what could be happening?







    Eugene Gonzalez
    Research and Analysis Unit/Sampling Unit

    International Association for the Evaluation of Educational Achievement
    Tel: +49 (0)40 48500 609 | Fax: +49 (0)40 48500 501 | www.iea.nl
    IEA Hamburg | Überseering 27 | 22297 Hamburg | Germany



    This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

    Thank you for your compliance.

  • 2.  RE: a curious case of the equal sign

    Posted Tue August 31, 2021 08:52 AM
    I don't think this question can be answered without a lot more detail.

    If you haven't already run this with SET MPRINT ON, that might help figure out what is wrong.

    One thing to check is that none of the lines in the code exceed the maximum allowed length of 255 bytes.


  • 3.  RE: a curious case of the equal sign

    Posted Tue August 31, 2021 09:29 AM

    Thank you Jon!

    I suspected that would be the answer, but did not want to overload the chat.


    I did set MPRINT ON and can clearly see the error.  When it comes to the first item, it treats "=" as the key for that item and it creates a line like:


    RECODE PE51S01 (= = 1) ( 9 = 0 ) ( 6 = 0 ) (-999 = sysmis) (else = 0).


    Then the keys are all off by 1 after that.


    I also used ECHO to print the string of keys and it prints "These are the keys: = X 3 X X X 2 1 4 2 1 ... "


    Within the macro code I also replaced !keys with !unquote(!keys) so that I could quote the string of keys going in. it gets worse and I get this back from the ECHO command: "These are the keys: = 'X..."


    He has also shorten each line to 132 character wide, and observes the same problem.

    In this instance he's using 230 items, but he has used many more items before and it has worked.


    The strange thing is that it works fine on my v27.






  • 4.  RE: a curious case of the equal sign

    Posted Tue August 31, 2021 09:33 AM
    Here's one wild guess.  Might an apparent blank character in the code or input actually be a non-breaking space, so that it isn't treated as a delimiter?


  • 5.  RE: a curious case of the equal sign

    Posted Tue August 31, 2021 09:39 AM

    Thanks Jon.

    We looked at that as well...