smiths
commented
6 years ago You should identify the variabilities for the family of ODE solvers. You will document this in your commonality analysis. You should focus on the build time variabilities. Run time variabilities, where the executable program at the end is itself a family, aren't necessary. You specify the parameters for your family member and then generate the code for the family member.
The obvious variability for your generator is the order of the RK method and the value of the parameters. For instance, you should be able to generate a 2nd order or a 4th order solver. You specify these parameters for the generator and it gives you the appropriate code.
I'm not sure what your comment about metaprogramming introducing the only variability. There will be more than one variability as you make different decisions for the inputs to the "meta progam." Dr. Carette may have been confused about the notion of run time binding. I'm not asking you to do that.
For the commonality analysis document you do not need to worry about how you are going to implement the family. I'm hoping that you will be able to use metaprogramming, but this isn't a decision that technically needs to be made at this time.
Going by your suggestions and example from class about a word processor being a family of programs due to turning off spell-checking yielding a new member of this family, I assumed that generating different code for every ODE would count as a program family. However, it seems Dr. Carette disagrees, due to metaprogramming introducing the only variability. Did I misunderstand or not understand completely?
Thank you!