Finally a coherent (well hopefully) draft of my MIS

[PeaWagon]

Thank you for your patience with me finishing this. I anticipate that there will be some muddlement with how the math is presented - please let me know if I need to fix it. 867af31

[smiths]

Thank you Jen. I look forward to looking over you MIS.

[smiths]

Comments are provided in c60d32b. You will see that I am confused by the design, while at the same time recognizing that real thinking and design has taken place. I've made a suggestion that you replace your dictionaries with tuples.

[PeaWagon]

@smiths the main reason I am using a dictionary is to accommodate my non-functional requirement ("NFR4: The program should be easy to use and quick to explain to chemists."). I do not want the user to have to provide the inputs in a certain order in the input files. Especially after having parsed/generated input files for other chemistry programs, this issue of formatting is a real gripe of mine. If I have a dictionary, then the key is the name of the input variable (example "num_slots") and the value is the value of that variable (example 20 slots). The program has to simply read in the file, line by line, and assign the inputs.

I am not worried that the user might change the inputs during the program's execution, since they would have to modify the gac source code (and if they are already doing that then they probably have other requirements than what I intended). As it is, the only interaction that the user has is to run the gac module with two input files. If I was worried that the inputs could get changed during execution, I could write the mol input module as a singleton object (there are a few ways to do that in python - essentially by making an object and forcing all of the attributes to be private using underscores). I think this would be unnecessary and a bit complicated for my program. Also it would be ugly code. Besides, maybe the user should change those inputs half way anyway. It is not a requirement that the inputs don't change (just a suggestion that they shouldn't).

Hopefully these comment address your issue sufficiently.

tldr I want to use dictionaries to allow my users to specify their input in whatever order they please. I don't want to constrain the program such that you cannot make changes to the input during execution.

[PeaWagon]

I am also leaving this issue open as a reminder to fix my MIS state variables. I ended up putting random stuff in those sections, since I obviously didn't understand what was meant to go there 😛

[smiths]

@PeaWagon, I think there is a misunderstanding in your interpretation of my advice. I am all for dictionaries in your implementation. What I am talking about is making your specification more language agnostic. My suggestion was to use tuples in the mathematical sense, but I think you interpreted that as advice to use Python tuples in your implementation. Python tuples and mathematical tuples are (confusingly!) not the same things.

On page 32 of Hoffman and Strooper you will see an overview of the date type for tuples. "Tuples consist of collections of elements of different types. Each tuple has one or more fields associated with it, and each field has a unique identifier called the field name." This definition of tuple is the mathematical abstraction of what you are looking for. My advice is to use (mathematical) tuples in the specification, and dicts for the implementation.

On the subject of Python implementation of (mathematical) tuples, I found a good web-page:

https://dbader.org/blog/records-structs-and-data-transfer-objects-in-python

I'm fine with you using dicts, but one thing that has bothered me about them is the reliance on typing the field name as a string. What if someone types the string name wrong? The dicts don't really define a new type either. You have to enforce that yourself with careful programming. An option I really like is the NamedTuple. This is a more true translation of the mathematical concept of tuple to Python code. You might want to think about using this in the future instead of dicts.