On Sun, Feb 10, 2013 at 9:49 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Sun, Feb 10, 2013 at 8:40 AM, Matthew Knepley <knepley at gmail.com>wrote: > >> The phrase "may as well" is very slippery. Python arrays are just [x, y, >> z], whereas JSON needs a library. >> However, the format is is now way crucial to the scheme. I want to get >> the workflow up an running with >> the simplest format. We will inevitably tweak it was we add tons of crap >> on top if it works. >> > > The syntax for plain arrays is identical. I was suggesting JSON to manage > recursive data structures (nested solvers, perhaps monitoring different > things). So it becomes a dict of arrays or a dict of dicts of arrays. Also, > we could spit out -snes_view in machine-readable form, we could have nicer > diagnostics on the GUI side. It is because of these extensions that I think > it's worth starting with something that will extend gracefully rather than > a hack that is only intended for arrays of numbers. > Don't disagree with any of your reasons, however, there is very little work wasted here. Most of the coding is adding new methods, hooking up Python, etc. and not writing the two lines for output. Thus, adding JSON later will be all new work, and will invalid hardly anything. This is modularity :) Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130210/c30b4579/attachment.html>
