Editing Module talk:TableTools (section)

== Improved NaN handling ==

{{edit template-protected|Module:TableTools|answered=y}}
Please pull in [[Special:Diff/1048120640/1060800426|my changes from the sandbox]] that correct issues with NaN handling. I already [[Special:Diff/1060767140/prev|updated the testcases]] (I first made them fail and then fixed the issue in the sandbox). I considered further simplifying {{code|isNaN|lua}} since I believe NaNs are the only values in Lua that fail the not equal to self test but it might be possible with external code, e.g., userdata (but I believe Scribunto uses none of that). That said, anything not equal to itself probably should not be considered for removal in {{code|removeDuplicates|lua}}. In Lua, NaNs are always an issue when attempting to use arbitrary table values as table keys (unlike {{code|nil|lua}} which cannot be used as a table value or key and mostly come into play when dealing with sparse tables or arbitrary expression lists). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:37, 17 December 2021 (UTC)

{{ping|Verdy p|Johnuniq|Anomie}} It should be noted that both {{code|nil|lua}} and NaN values cannot be table keys, however, it is not an error to attempt to index a table with such values. Lua will throw errors preventing these values from being used as actual keys (i.e., {{code|rawset(tableX, nil, true)|lua}} and {{code|rawset(tableX, 0/0, true)|lua}} are guaranteed to error) but these values can be handled in index and newindex events (via {{code|__index|lua}} and {{code|__newindex|lua}} metamethods) without issue. As an example, I [[Special:Diff/1060785316/prev|initially modified]] {{code|listToSet|lua}} to consider all NaN values as if they were the same (i.e., if there is at least one NaN in the input array, indexing the returned set with any NaN yeilds {{code|true|lua}}) but decided that was not particularly useful, given Lua considers them never equal to any value (including other NaNs or even themselves). If that is considered valuable we could revert to such. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:37, 17 December 2021 (UTC)
:Thanks but the sandbox p.listToSet has a typo due to use of <code>v</code> in p.invert and <code>item</code> in p.listToSet. It's probably best to use <code>v</code> in both of them. By the way, the ping did not work because it was added in an edit of the comment. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 00:50, 18 December 2021 (UTC)
::{{re|Johnuniq}} the mispaste was easily fixed but I cleaned up the variables across the functions anyway. Thanks. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 22:43, 30 December 2021 (UTC)
:::I'm not going to think about anything remotely tricky for at least a week. Someone else might want to action this but I'm posting to let you know that if nothing happens you might ping me in ten days. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 23:30, 30 December 2021 (UTC)
:{{re|Uzume|Johnuniq}} is this still being worked on, or is there an agreeable version ready to go? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 15:29, 10 January 2022 (UTC)
::{{re|Xaosflux}} As far as I am concerned the version in the current sandbox is "ready to go". I have rectified the one issue {{U|Johnuniq}} found since I originally made the request. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:10, 10 January 2022 (UTC)
:::I looked at the new code. There is another problem at line 67 due to replacement of <code>t</code> with <code>arr</code> in <code>p.removeDuplicates</code> in two of the three places where <code>t</code> was used. I will have a look at what should be done but introducing <code>arr</code> when the rest of the module uses <code>t</code> is not desirable and I suspect the new <code>arr</code> should go. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 02:47, 11 January 2022 (UTC)
::::{{re|Johnuniq|Xaosflux}} That too was easily rectified. Please find the fixes in the current sandbox. Thank you, —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:10, 27 January 2022 (UTC)
:::::That looks good. However now we need to think about whether a module used on 4.9 million pages should be updated with some nice-to-have improvements that are very unlikely to make a practical difference. I'm happy either way but will wait in the hope that someone else makes that decision. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 02:20, 28 January 2022 (UTC)
::::::{{re|Johnuniq}} I find it amusing you consider correcting a bug in the NaN handling "some nice-to-have improvements that are very unlikely to make a practical difference". Such is certainly true if one never has any NaN values anywhere but clearly it has (broken) NaN support so apparently someone needed that. This was the main reason for updating the testcases first (to demonstrate the brokenness and subsequently rectify such). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:12, 30 January 2022 (UTC)
::::::I've made the changes. Thanks for working on this and Johnuniq for checking code &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 13:10, 31 January 2022 (UTC)