Village Pump/Approximate fit solutions: Difference between revisions

'approximate' template, 'approxiate' policy, pi#guiss.
(We do allow examples which don't match exactly, but they usually match the core goal of the task)
('approximate' template, 'approxiate' policy, pi#guiss.)
Line 12:
::It's nothing to do with that. I am trying to make the documents as good as they can be, and I think being relaxed and inclusive is the best way forward. I don't think we need to be quite so strict with an "this is not an exact match, so it must be deleted" type of approach. After all, the solution was valid, whether it gets published here or not. I can always publish it on another website. That is not a problem. It's just convenient to work with Rosetta Code, because it has similar goals to a project that I have been developing, and the infrasture is already in place here, and I quite like how the project is evolving. FWIW, a policy would alleviate the need for the tag, or it is easy to add "If your language cannot achieve this task exactly, then make an approximate implementation, and state divergencies and limitations in the provided solution" to every task. But I think this is extreme. A policy would be sufficient (if only really for the purpose of clarification of conflict between different developers ideas). [[User:Markhobley|Markhobley]] 20:47, 24 July 2011 (UTC)
:::We do include examples which aren't exact matches. Usually they are discussed in the talk pages and annotated properly (or changed/replaced) if there is a problem. The problem with the one in [[pi]] is that it doesn't seem to match any part of the task except displaying part of the value of pi. It does not calculate, and it doesn't continuously show digits except to the extent of a stored number. It's understandable to add a solution for a task which has (for example) 5 requirements and the solution meets 4 of them as long, as the one requirement it misses isn't the real point of the task (like a display issue on a calculation task) and as long as it's noted. It is not acceptable to add a solution to a task which does not fit "the spirit of the task" (like using a completely different type of algorithm than what the task asks for). In short, the policy is implicitly in place and no template is needed. Any disputes should be taken to their talk pages, and both sides should try to keep an open mind (and please keep it nice...don't attack). --[[User:Mwn3d|Mwn3d]] 21:06, 24 July 2011 (UTC)
 
We do (or, rather, I do, and others tend to follow my lead) have a policy of allowing approximate-fit solutions. I do like the idea of a {{tmpl|approximate}} as a "subclass" of {{tmpl|incorrect}}, which is used to enumerate acknowledged deviations from the task description. Pages with {{tmpl|approximate}} can be listed on the "unimplemented in X" pages, to draw attention to them and allow them to be fixed, where possible. --[[User:Short Circuit|Michael Mol]] 12:02, 26 July 2011 (UTC)
 
This is not a good place to continue the discussion about [[Pi#GUISS]]. --[[User:Short Circuit|Michael Mol]] 12:02, 26 July 2011 (UTC)
==Policy==