Hashes (25) Considering the following actual monster structure, implicit linked list structure, and list functions pre-defined for you: struct monster_struct { char name [64]; char type [64]; unsigned short int weight; unsigned short int monsteriness; }; typedef struct monster_struct monster; monster_linked_list *mll_new(); void mll_add (monster_linked_list *l, monster *m); void mll_remove(monster_linked_list *l, monster *m); monster *mll_find (monster_linked_list *l, char *name);

Hashes (25) Considering the following actual monster structure, implicit linked list structure, and list functions pre-defined for you: struct monster_struct { char name [64]; char type [64]; unsigned short int weight; unsigned short int monsteriness; }; typedef struct monster_struct monster; monster_linked_list *mll_new(); void mll_add (monster_linked_list *l, monster *m); void mll_remove(monster_linked_list *l, monster *m); monster *mll_find (monster_linked_list *l, char *name); ...implement an open-hashed hashtable by defining an mhash structure, and implementing the following functions: mhash *mhash_new(); unsigned short int mhash_hashvalue(char *name); void mhash_add(mhash *h, monster *m); void mhash_remove (mhash *h, monster *m); monster *mhash_find (mhash *h, char *name); Notes: . . You may assume an unsigned short int is 16 bits. Your hashing function should return the product of the ASCII value of the first and last character of the name. Your mhash table should be large enough to hold the entire range of the hashing function. For this question don't worry about disposal. . Reflection (5) What are the worst-case big-0 times of your add, remove and find functions? When are those times reflective of real- world performance, and when is real-world performance better? HA: 10/25 (did not implement hash function as required, did not use given linked list prototypes)