Possible bug in bin packer

[garrettsickles]

I wrote some 3D intersection code to exhaustively verify the box packer results (1. all packed items inside container. 2. all packed items are geometrically disjoint) and found that the optimal output for the input rnd04.txt seems odd. One of the boxes in rnd04.out has a negative COOR-Z, specifically box 409:

---------------------------------------------------------------------------------------------
  NO: PACKSTA DIMEN-1  DMEN-2  DIMEN-3   COOR-X   COOR-Y   COOR-Z   PACKEDX  PACKEDY  PACKEDZ
---------------------------------------------------------------------------------------------
...
  408    1        6        7        1      103        0        2        1        7        6
  409    1        6        7        1      103        0       -4        1        7        6
 1161    1        5       16        9        0        9        0        9        5       16

I also found this set of items (including Box 409) which violate the geometric constraints:

---------------------------------------------------------------------------------------------
  NO: PACKSTA DIMEN-1  DMEN-2  DIMEN-3   COOR-X   COOR-Y   COOR-Z   PACKEDX  PACKEDY  PACKEDZ
---------------------------------------------------------------------------------------------
  122    1        1        2        3      103       16       69        1        3        2
   96    1        1        2        3      103       14       29        1        2        3
  333    1        2        4        5      102       16       36        2        5        4
  125    1        1        2        3      103       16       75        1        3        2
   68    1        1        2        3      101       14       76        3        2        1
   56    1        1        2        3      101       14        1        3        2        1
  409    1        6        7        1      103        0       -4        1        7        6
  880    1        1        3       21      103       16       67        1        3       21
   91    1        1        2        3      103       14        1        1        2        3
  702    1       14        5        3       90       16       81       14        5        3
  127    1        1        2        3      103       16       79        1        3        2
  885    1        1        3       21       91       22       62        1        3       21
  123    1        1        2        3      103       16       71        1        3        2
  126    1        1        2        3      103       16       77        1        3        2
  105    1        1        2        3      103       14       75        1        2        3
  886    1        1        3       21       91       22       62        1        3       21
   69    1        1        2        3      101       14       77        3        2        1
    2    1        1        2        3      102        0        0        2        3        1
  287    1        2        4        5      100       14       26        4        2        5
  332    1        2        4        5      102       16       36        2        5        4
  124    1        1        2        3      103       16       73        1        3        2
  128    1        1        2        3      103       16       79        1        3        2

I have tested all other provided scenarios without fail, curious what your thoughts are!

Thanks,
Garrett

[robertson-so]

It's a 19 years old bug, I was about to create an issue when I saw yours.
I found it today while I was refactoring a java version of this.
The problem is at line 636.

There is no need to decrement cboxx twice from smallestz.cumx, to then define the x-position for the box.

I won't create a pull request, as the README says this repo is only for posterity.

Regards,
Robertson.