Jump to content

Talk:Price fraction: Difference between revisions

Line 76:
: The issues raised are certainly interesting. However after the discussion of the merits of two alternative forms for specifying the table data, it seems to me that the data format chosen by the J implementation (and others) is a nice compromise between them - easily understandable/editable by the "casual maintainer" (especially when the values are lined up) and not bulky or misleading.
:While I think the idea of standardizing on CSV for presenting tablular (and list?) data to be used in a task has some merit, I'm not sure that adding routines to all such tasks for reading/parsing it from a CSV file is desirable. I'm pretty sure there are already tasks for reading and writing files in CSV format.--[[User:Tikkanz|Tikkanz]] 22:48, 18 March 2010 (UTC)
 
:If the government supplied data then I would copy their description into the program and add a link to the original source too. When things change, the maintainer would have both before and after sources to decide on what has changed and then to implement that change. on how the routine is coded: after learning about bisect it seems right for the job and leaves the raw range and output price data in a nicely displayed way. A competent maintainer who didn't know the bisect model should be able to learn to use it from the Python documentation and a little experimentation as its use in the Python example is straight-forward. <br>
:CSV has its uses but this table of regions I find OK for this task, but see no need to parse it as part of performing the task. --[[User:Paddy3118|Paddy3118]] 09:42, 19 March 2010 (UTC)
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.