convore.json/groups/pyne/am-i-too-old-fashioned-if-i-want-compiled-language-tools-as-well/messages.json

[{"user_id": 30471, "stars": [], "topic_id": 33293, "date_created": 1304434368.6263411, "message": "Of course, we'll still have to do some of that if we want to process and run existing codes like MCNP, but we want to abstract it away from the user so that, perhaps, at some point in the future we can interface on the back end with APIs rather than text files.", "group_id": 9127, "id": 898721}, {"user_id": 30471, "stars": [], "topic_id": 33293, "date_created": 1304434436.0822279, "message": "So what we really want is, if we're writing our own methods, fast kernels (written in compiled languages) with a Python API that provides flexibility to the user at a negligible performance penalty. That's been the philosophy behind \"Python in scientific computing\" since the beginning, if I'm not mistaken.", "group_id": 9127, "id": 898729}, {"user_id": 30471, "stars": [], "topic_id": 33293, "date_created": 1304434300.922734, "message": "I don't think compiled tools are old-fashioned at all, if you're looking for faster execution times. What we want is fast code with an extensible Python interface, obviating all the nasty \"read ouput file, write input file, call process\" cycling that couples all of the legacy codes still in use.", "group_id": 9127, "id": 898712}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304437055.826355, "message": "The compile/JIT'd/interpreted space is becoming more confused by the day.  So the question as posed is really about which languages you want an interface for.", "group_id": 9127, "id": 899238}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304436896.1783271, "message": "Tools like Cython make Python compile-able.  Tools like V8 make interpreted JavaScript faster than C for many operations.", "group_id": 9127, "id": 899201}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304436794.534344, "message": "I know this sounds pedantic, but I think the distinction here is really between very high level languages (Python, Javascript), high level languages (C/C++, Fortran), and low level language (Assembler).", "group_id": 9127, "id": 899182}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304436584.397845, "message": "@gonuke Ideally, if there is a clean enough separation, this package would supply C/C++-tools as well.", "group_id": 9127, "id": 899147}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304439283.5645759, "message": "Understood, on all counts. As sethrj commented, there are existing tools in high level languages that may want to interface.", "group_id": 9127, "id": 899882}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304440860.962209, "message": "Well, in the short term, I think we will end up providing a C++ interface to many of our routines.  However, I think that we decided not to guarantee this API, at least in the short term, for simplicity.", "group_id": 9127, "id": 900166}, {"user_id": 30471, "stars": [], "topic_id": 33293, "date_created": 1304477873.2315071, "message": "So perhaps @gonuke could clarify what \"tools\" mean. Do you mean tools for the front end or the back end?", "group_id": 9127, "id": 906513}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304531398.2734561, "message": "I have long wanted to have a truly open set of subroutines (e.g. Fortran, C, C++) for reading nuclear data from standard formats (e.g. ACE, ENDF) in order to facilitate building new codes.", "group_id": 9127, "id": 916637}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304531572.7208769, "message": "My #2 wish is related.... and definitely more python relevant - methods to parse standard output file formats (MCNP, PARTISN [ascii & FORTRAN binary], etc) and put them into a data structure that is useful for high level manipulations (plotting, summing, slicing, etc)", "group_id": 9127, "id": 916672}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304531337.2285841, "message": "As I have pondered these conversations, I'm changing my view a little, but for the sake of argument...", "group_id": 9127, "id": 916631}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304531460.1137309, "message": "With nuclear transport related work, one can easily code a new method, but one hits the wall quickly and hard, when one wants real nuclear data rather than 1-group made up data to test", "group_id": 9127, "id": 916646}, {"user_id": 32023, "stars": [], "topic_id": 33293, "date_created": 1304531503.652688, "message": "This is my #1 wish.... but coming around to today's way of doing this from scratch, perhaps relying on some python glue is in fact the right way to do it", "group_id": 9127, "id": 916655}, {"user_id": 30469, "stars": [], "topic_id": 33293, "date_created": 1304567685.075331, "message": "@gonuke I've been working on exactly that- modules to read ACE and ENDF data into a high level format as well as modules to read output data from MCNP, etc. It'll take me a little while to merge my stuff into the pyne repository as I'm currently on international travel for a month.", "group_id": 9127, "id": 924021}, {"user_id": 30471, "stars": [], "topic_id": 33293, "date_created": 1304595610.141171, "message": "@gonuke I think that Python glue is definitely the best way to do it. The underlying data structures should be accessible from C++ or FORTRAN, but the input to those structures should be in Python. Because the \"reading\" will only be done once per simulation run, it doesn't have to be super-optimized, and Python with its modules and extensive built-in string objects is highly superior for text interpretation.", "group_id": 9127, "id": 927685}, {"user_id": 10411, "stars": [], "topic_id": 33293, "date_created": 1304617757.426863, "message": "@sethrj The road isn't one way either.  Say you have some pure python code that you want to access from C, you can always link against the CPython interpreter and access your Python API via C functions.  Once again, Cython makes this relatively easier.", "group_id": 9127, "id": 932218}]