Pradnaya/add lsm feature

[pradnayapathak]

Pull Request Template:
If you are merging in a feature or other major change, use this template to check your pull request!

Basic Info

What's this pull request about?

This PR adds a new feature for calculating Language Style Matching (LSM) scores. The calculate_lsm function processes conversation data to compute LSM scores for various function word categories, offering insights into linguistic alignment within conversations.

My PR is About Adding a New Feature to the Code Repository

Adding Feature to the Feature Dictionary

• I have edited the feature_dictionary.py file with an appropriate entry for my feature. Below is a sample entry; I confirm that all fields are accurately filled out.

  "Function Word Accommodation": {
    "columns": ["function_word_accommodation"],
    "file": "./features/word_mimicry.py",
    "level": "Chat",
    "semantic_grouping": "Variance",
    "description": "The total number of function words used in a given turn that were also used in the previous turn. Function words are defined as a list of 190 words from the source paper.",
    "references": "(Ranganath et al., 2013)",
    "wiki_link": "https://github.com/Watts-Lab/team-process-map/wiki/C.9-Mimicry:-Function-word,-Content-word,-BERT,-Moving",
    "function": ChatLevelFeaturesCalculator.calculate_word_mimicry,
    "dependencies": [],
    "preprocess": [],
    "vect_data": False,
    "bert_sentiment_data": False
  }

• If my feature is at the chat level, my dictionary entry is in the top half of the file; if my feature is at the conversation level, my dictionary entry is in the bottom half of the file (below the comment that says, ### Conversation Level).

Documentation

Did you document your feature? You should follow the same requirements as above:

• Docstrings: I have followed the proper documentation format (https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html; Google Format recommended).
• Docstrings: Every function in the file has a block quote comment with a description of the feature.
• Docstrings: Every input argument is documented.
• Docstrings: The output type is documented, along with a description of what the output is for.
• Docstrings: I have linked the feature under the Table of Contents (docs/source/features/index.rst)

Code Basics

• My feature is a .py file.
• My feature uses snake case in the name. That means the name of the format is my_feature, NOT myFeature (camel case).
• My feature has the name, NAME_features.py, where NAME is the name of my feature.
• My feature is located in src/features/.

Testing

• I have thought about test cases for my features, with inputs and expected outputs.
• I have added test cases for my feature under the tests/ folder.
• My feature passes the automated testing suite.

The location of my tests are here:

N/A but will send test message to Emily and Shruti

If you check all the boxes above, then you ready to merge!

[xehu]

At a quick glance, this PR is a great start but is missing two pieces:

1. The Feature isn't called: The LSM feature needs to be called in the ConversationLevelFeaturesCalculator (this file: https://github.com/Watts-Lab/team_comm_tools/blob/pradnaya/add_lsm_feature/src/team_comm_tools/utils/calculate_conversation_level_features.py). Otherwise, the FeatureBuilder won't generate the feature.

2. There are no tests: @pradnayapathak, can you attach a CSV with a "worked" example that you've tested locally, in which you've computed the LSM manually for a given conversation, and for which you know the "expected value?" We can add it to our test file here: https://github.com/Watts-Lab/team_comm_tools/blob/pradnaya/add_lsm_feature/tests/data/cleaned_data/test_conv_level.csv; basically, all you need to do is provide a sample conversation and the value we expect, and when we run the feature, we will assert that the value we get is the value we want (so that we know the feature works!).