bugPSPP - Bugs: bug #56363, Hash table collisions not always...

 
 

bug #56363: Hash table collisions not always properly handled.

Submitter:  John Darrington <jmd>
Submitted:  Tue 21 May 2019 01:44:29 PM UTC
   
 
Category:  Numerical Errors Severity:  7 - Major
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 01 Sep 2020 12:50:37 AM UTC, comment #3: 

This problem doesn't reproduce anymore, and I believe that it is fixed.

Commit e48391e8dee2 ("AUTORECODE: Make GROUP option work properly with multi-length strings.") fixed the problem with AUTORECODE.

It doesn't make sense to adjust value_equal(), etc., because they only work with strings that have the same width.

I can't reproduce the GRAPH problem anymore. I don't see a particular commit to cite for that.

Ben Pfaff <blp>
Group administrator
Sun 07 Jul 2019 05:46:32 AM UTC, comment #2: 

Regarding the Autorecode failures,  When I look at those tests,
I'm not sure whether the expected results are in fact correct (whatever "correct" means).

They seem to be expecting that string values which are all whitespace have the same value semantics.   So for example, the string " " will group identically to the string "           ".

I wrote those tests many years ago, and I suspect I checked it
against a version of spss which I had access to at that time.
I just wish I'd put a comment about it there.

If someone has access to spss it would be great if it could be retested.  If it does turn out that " " and "              " are
to be treated as identical, the we should make special provision for this in the functions value_equal, value_compare_3way and value_hash.

 

John Darrington <jmd>
Group administrator
Sun 07 Jul 2019 05:13:02 AM UTC, comment #1: 

I see these failures:


 440: autorecode.at:157  AUTORECODE group - string variables
 441: autorecode.at:193  AUTORECODE group vs. strings
 531: graph.at:354       GRAPH barchart percentage sub-categorical


The AUTORECODE failures appear due to improperly handling string variables of different widths.

I haven't looked at the GRAPH failure yet.

Ben Pfaff <blp>
Group administrator
Tue 21 May 2019 01:44:29 PM UTC, original submission:  

When I hack the functions in libpspp/hash-functions.c such that they unconditionally return zero, and run make check I get a number of failures.

This suggests to me that hash table collisions are in some instances not being properly resolved.

John Darrington <jmd>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by jmd (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-01 blp StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code