Village Pump/Approximate fit solutions: Difference between revisions
Content added Content deleted
(Consensus.) |
(+1) |
||
| Line 21: | Line 21: | ||
We could just have a policy that allows approximations, if an exact fit is not available, providing that the solution states the limitations and any differences in behaviour from the task requirements. [[User:Markhobley|Markhobley]] 16:49, 24 July 2011 (UTC) |
We could just have a policy that allows approximations, if an exact fit is not available, providing that the solution states the limitations and any differences in behaviour from the task requirements. [[User:Markhobley|Markhobley]] 16:49, 24 July 2011 (UTC) |
||
:Hi Mark, we have such a policy. It is explained above. It may rely on discussion in the talk pages but has worked in the past, and should work in the future. How about listening to the emerging [[wp:Consensus decision-making|consensus]]? --[[User:Paddy3118|Paddy3118]] 19:11, 26 July 2011 (UTC) |
:Hi Mark, we have such a policy. It is explained above. It may rely on discussion in the talk pages but has worked in the past, and should work in the future. How about listening to the emerging [[wp:Consensus decision-making|consensus]]? --[[User:Paddy3118|Paddy3118]] 19:11, 26 July 2011 (UTC) |
||
:: I like the idea of tagging what we're so far calling "approximate" solutions: solutions to problems similar in spirit to the task, when the task itself cannot be solved by the language in question. For example, if your language is sandboxed, you're not going to be able to solve a task that requires you to save a file in an arbitrary location. But rather than ignoring the task, it would be useful to write a quasi-solution that puts the data into local storage, if you have that ability. |
|||
:: This is a different situation from incorrect programs or "the language can do the task, but it's difficult and I'm lazy". |
|||
:: [[User:CRGreathouse|CRGreathouse]] 18:51, 1 August 2011 (UTC) |
|||