git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Aug 10, 2016, 19:12 UTC
Message-ID
<b54c1524-7f7d-fcc5-3bf6-471be5c33a4e@alum.mit.edu>
In-Reply-To
<CAGZ79kY40AbZ=tSRjSHtNsO26Wj9PS2AzD6qF_ZhsOF=9tzeuA@mail.gmail.com>
On 08/04/2016 02:04 AM, Stefan Beller wrote:
Show 20 quoted lines
> On Wed, Aug 3, 2016 at 4:30 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Stefan Beller wrote:
>>> [...]
>>> Rather the 10 describes the ratio of "advanced magic" to pure indentation
>>> based scoring in my understanding.
>>
>> No, it's basically just a number against which the other constants are
>> compared. E.g., if another bonus wants to balance out against exactly
>> one space of indentation, its constant needs to be 10. If it wants to
>> balance out against exactly 5 spaces, its constant needs to be 50. Etc.
> 
> So another interpretation is that the 10 gives the resolution for all other
> constants, i.e. if we keep 10, then we can only give weights in 1/10 of
> "one indent". But the "ideal" weight may not be a multiple of 1/10,
> so we approximate them to the nearest multiple of 1/10.
> 
> If we were to use 1000 here, we could have a higher accuracy of the
> other constants, but probably we do not care about the 3rd decimal place
> for these because they are created heuristically from a corpus that may
> not warrant a precision of constants with a 3rd decimal place.

Not only that. Since all of the inputs to the heuristic are integers, the outputs are discontinuous and can take only certain discrete values. And the outputs are only ever compared against one another. So a small adjustment to the output will only make a difference if it causes the value to become larger/smaller than another of the possible output values. So too high a resolution makes no sense at all.

That being said, I didn't actually check in any systematic way whether the resolution of 10:1 is high enough in practice. But I can say that the overall performance of the heuristic (in terms of number of errors counted) remained constant over a relatively large parameter range, so I think the resolution is sufficient.

Feel free to play with the parameters and/or other heuristics. The tools and raw data are all published in [1]. Let me know if you need help getting started.

Michael
[1] https://github.com/mhagger/diff-slider-tools
Previous: Stefan BellerNext: Jeff King
Message 42 of 57 in “Better heuristics make prettier diffs”
  1. 0/8 Better heuristics make prettier diffsMichael Haggerty, Aug 3, 2016
  2. 2/8 xdl_change_compact(): clarify codeMichael Haggerty, Aug 3, 2016
  3. Stefan BellerAug 3, 2016
  4. Michael HaggertyAug 3, 2016
  5. Stefan BellerAug 3, 2016
  6. Jeff KingAug 4, 2016
  7. Michael HaggertyAug 10, 2016
  8. Stefan BellerAug 10, 2016
  9. 5/8 xdl_change_compact(): fix compaction heuristic to adjust ioMichael Haggerty, Aug 3, 2016
  10. Jeff KingAug 4, 2016
  11. Michael HaggertyAug 10, 2016
  12. Michael HaggertyAug 10, 2016
  13. Jeff KingAug 11, 2016
  14. Junio C HamanoAug 4, 2016
  15. Michael HaggertyAug 10, 2016
  16. 7/8 is_blank_line: take a single xrecord_t as argumentMichael Haggerty, Aug 3, 2016
  17. Junio C HamanoAug 4, 2016
  18. 6/8 xdl_change_compact(): keep track of the earliest endMichael Haggerty, Aug 3, 2016
  19. Junio C HamanoAug 4, 2016
  20. Michael HaggertyAug 10, 2016
  21. 4/8 xdl_change_compact(): do one final shift or the other, not bothMichael Haggerty, Aug 3, 2016
  22. 1/8 xdl_change_compact(): rename some local variables for clarityMichael Haggerty, Aug 3, 2016
  23. Jeff KingAug 4, 2016
  24. Junio C HamanoAug 4, 2016
  25. Michael HaggertyAug 13, 2016
  26. Jeff KingAug 14, 2016
  27. Michael HaggertyAug 3, 2016
  28. 3/8 xdl_change_compact(): rename i to endMichael Haggerty, Aug 3, 2016
  29. Jeff KingAug 4, 2016
  30. 8/8 diff: improve positioning of add/delete blocks in diffsMichael Haggerty, Aug 3, 2016
  31. Jacob KellerAug 3, 2016
  32. Michael HaggertyAug 3, 2016
  33. Jacob KellerAug 4, 2016
  34. Junio C HamanoAug 4, 2016
  35. Michael HaggertyAug 10, 2016
  36. Junio C HamanoAug 10, 2016
  37. Stefan BellerAug 3, 2016
  38. Michael HaggertyAug 3, 2016
  39. Stefan BellerAug 3, 2016
  40. Michael HaggertyAug 3, 2016
  41. Stefan BellerAug 4, 2016
  42. Michael HaggertyAug 10, 2016
  43. Jeff KingAug 4, 2016
  44. Stefan BellerAug 4, 2016
  45. Junio C HamanoAug 4, 2016
  46. Michael HaggertyAug 13, 2016
  47. Michael HaggertyAug 12, 2016
  48. Jeff KingAug 13, 2016
  49. Junio C HamanoAug 13, 2016
  50. Jacob KellerAug 14, 2016
  51. Stefan BellerAug 15, 2016
  52. Junio C HamanoAug 15, 2016
  53. Junio C HamanoAug 4, 2016
  54. Michael HaggertyAug 13, 2016
  55. Jeff KingAug 4, 2016
  56. Junio C HamanoAug 4, 2016
  57. Jeff KingAug 4, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.