)]}'
{
  "commit": "44121a6bc9828c993932b87e442440dc4f260f3c",
  "tree": "9d8be85c1b84bbf7104fb9e0df6cbf2f347725a5",
  "parents": [
    "877a2126786bd2a8e5086fbddb05a593c40cbc51"
  ],
  "author": {
    "name": "Tim Peters",
    "email": "tim.peters@gmail.com",
    "time": "Mon Aug 12 06:17:58 2002"
  },
  "committer": {
    "name": "Tim Peters",
    "email": "tim.peters@gmail.com",
    "time": "Mon Aug 12 06:17:58 2002"
  },
  "message": "x_mul():  This failed to normalize its result.\n\nk_mul():  This didn\u0027t allocate enough result space when one input had\nmore than twice as many bits as the other.  This was partly hidden by\nthat x_mul() didn\u0027t normalize its result.\n\nThe Karatsuba recurrence is pretty much hosed if the inputs aren\u0027t\nroughly the same size.  If one has at least twice as many bits as the\nother, we get a degenerate case where the \"high half\" of the smaller\ninput is 0.  Added a special case for that, for speed, but despite that\nit helped, this can still be much slower than the \"grade school\" method.\nIt seems to take a really wild imbalance to trigger that; e.g., a\n2**22-bit input times a 1000-bit input on my box runs about twice as slow\nunder k_mul than under x_mul.  This still needs to be addressed.\n\nI\u0027m also not sure that allocating a-\u003eob_size + b-\u003eob_size digits is\nenough, given that this is computing k \u003d (ah+al)*(bh+bl) instead of\nk \u003d (ah-al)*(bl-bh); i.e., it\u0027s certainly enough for the final result,\nbut it\u0027s vaguely possible that adding in the \"artificially\" large k may\noverflow that temporarily.  If so, an assert will trigger in the debug\nbuild, but we\u0027ll probably compute the right result anyway(!).\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "fab7deee7dff02f29f3957183f8815d790b6a858",
      "old_mode": 33188,
      "old_path": "Objects/longobject.c",
      "new_id": "6dedd389f6eeae16213d020eda16e8af80b969eb",
      "new_mode": 33188,
      "new_path": "Objects/longobject.c"
    }
  ]
}