add xraydb function to compute muD

[yucongalicechen]

closes #9

I have added optional arguments (mu, d, sample, energy, density) that can be used with the xraydb function to compute muD. I didn't put any error messages for invalid inputs, because I think both the input function and xraydb give clear enough error messages (e.g. for invalid float number or incorrect sample names), but I can add some if needed.

@sbillinge ready for review

[yucongalicechen]

@till-schertenleib I could use some advice on this implementation, if you find other user-friendly muD functions or have any suggestions for improving the instructions!

[sbillinge]

When we add user functionality like this it is important to get it right, which includes users. Let's discuss first what use-case we want to code up before coding anything or we risk making the code worse. @yucongalicechen do you remember how to do a Use case? It is a list of actions that begins with an actor, something like

1. visitor wants to greet colleague politely
2. visitor holds out flat palm and approaches colleague
3. visitor stops 3 feet away and awaits response
4. colleague reaches and and grasps visitor hand
5. visitor makes firm but not too firm grip
6. visitor moves hand up and down four times and then lets go, making eye contact and smiling
7. visitor takes a step back and starts converation.

Use your judgement, but talk to people who might use the code. Don't start from the code. e.g., don't say things like "user enters density" because you are then writing the UC to the code, not the code to the UC. For example, a good UC would be

1. user places sample on diffractometer
2. diffractometer determines weight and dimensions of the sample
3. diffractometer shares this information with labpdfproc
4. labpdfproc computes muD

would be a great UC! It may be too difficult for us to engineer right now, so we save it for later and write another UC. In the end we impement the one that is the best balance between what is desirable and what is possible.

[yucongalicechen]

When we add user functionality like this it is important to get it right, which includes users. Let's discuss first what use-case we want to code up before coding anything or we risk making the code worse. @yucongalicechen do you remember how to do a Use case? It is a list of actions that begins with an actor, something like

1. visitor wants to greet colleague politely
2. visitor holds out flat palm and approaches colleague
3. visitor stops 3 feet away and awaits response
4. colleague reaches and and grasps visitor hand
5. visitor makes firm but not too firm grip
6. visitor moves hand up and down four times and then lets go, making eye contact and smiling
7. visitor takes a step back and starts converation.

Use your judgement, but talk to people who might use the code. Don't start from the code. e.g., don't say things like "user enters density" because you are then writing the UC to the code, not the code to the UC. For example, a good UC would be

1. user places sample on diffractometer
2. diffractometer determines weight and dimensions of the sample
3. diffractometer shares this information with labpdfproc
4. labpdfproc computes muD

would be a great UC! It may be too difficult for us to engineer right now, so we save it for later and write another UC. In the end we impement the one that is the best balance between what is desirable and what is possible.

Yes, I remember the UC. Thanks for the suggestions, I will talk to people and work on the UCs first!