Hot answers tagged

9

It's something you overlooked. Your hash function determines the hash value by adding the ASCII values of every letter in the word. The problem is that an upper case letter won't produce the same hash as the same letter in lower case. Since you don't convert the word being checked to lower case before hashing it, you get the wrong hash number and search ...


3

The problem is bad structuring of the chain of ifs and else ifs. Look at the following: if(...) { ... } else if (isupper((char)*(word + i))) { else if (cursor -> children[(int)*(word + i) - 64] == NULL) { The first else if follows from the first if statement. There is an if statement, a block of code to execute when it is true, ...


3

The reason why your check function is slow is because of how the dictionary is loaded into memory. There are two things to do to right this: 1.) Find a good hash function online like this one I found on a Reddit post that performs pretty close to the staff's solution: // Ref: https://www.reddit.com/r/cs50/comments/1x6vc8/pset6_trie_vs_hashtable/ inline int ...


3

This is an ineffective use of a hash function. In essence, your load function simply inserts each word sequentially into an array, along with a hash number, and the check function is doing a linear search. It might as well be implemented without the hashing, at least it would be a little faster. Bottom line is this is incredibly inefficient. The purpose of ...


2

print thisNode->word $2 = "elephant\n" Looks like you are including the new line char in your word. This will cause all of the words to be misspelled, as the word sent to check will, of course, not include the newline. Revisit your load function and make sure you don't include the newline.


2

The second version looks cleaner so let's go with that. Without seeing the rest of the check function, or the load function, I think I still found your problem. Assuming that pointer->children[] is a 27 element array and is indexed from 0 to 26, then look at how you're trying to traverse down the tree. int l = toupper(word[i]); pointer = pointer-&...


2

buffer is an array of ints. on the appliance, an int is 4 bytes long. this means that the total size of your array is 512 * 4 = 2048 bytes not 512 (which you want) but that's not the actual problem. the problem is that the 512 bytes that you're reading are not stored byte by byte into each element of the array. instead, the first 4 bytes are stored into the ...


2

The hash table that you've loaded the words into should be globally accessible since many functions will use it and a direct access would make things way easier. Also, you're not supposed to alter the declaration of load and since it returns bool, you have to return a bool value. The value true should be returned in case the loading process ended with a ...


2

Well, it seems to me that if you want to free that particular malloc, you need to have two free() statements, one immediately before each return so that no matter how you exit, it gets freed. For the return true, it would have to look something like this: if (strcmp (s, head->word) == 0) { free(s); return true; } If you ...


2

So that error was being caused because the function getNode() was being used outside another function. Turns out, clang doesn't like that. So I did the following: node root_node; node* root = &root_node; That fixed it!


2

TL; DR: This looks like a memory leak. Remove: node *tableindex = malloc(sizeof(node)); tableindex = hashtable[ind]; ... free(tableindex); Add: node *tableindex = hashtable[ind]; comparison of the original and updated code (I took some guesses at your hash function etc..) Why: It seems the main problem is how the node pointer tableindex is ...


2

Actually, your problem is a lot more severe than it appears. You are getting a massive number of false positives. I say that they're false because you're not actually checking the words correctly. So let's start with that. But first, some good news. Load is working correctly. At the bottom of your search function, you have a catch-all statement, return ...


2

OK, after careful debugging I have discovered and fixed the issue. It doesn't have to do with malloc/calloc. Even though my forward declaration of the struct/root node was properly placed outside of any function, ie globally, in the load function, I was writing struct node* root = malloc(.......) instead of root = malloc(.....) This erased the global ...


2

Simply put, the while loop in check() never starts. Look at the following code: unsigned int c =0; unsigned int i = 0; while(c != '\0') int 0 is the same as \0 in their binary representation. Because of this, the test condition for the while loop will always be false when it is executed, so none of the code inside of the loop ever executes. ...


2

I just figured out the answer (in case anyone has a similar issue). And actually the error was in Load so apologies for not including that (I didn't want to paste too much of the pset in). I declared root globally but in load I'd calloc'd the memory using *node root = calloc rather than just root = calloc which meant that there was a new local instance with ...


2

As usual, Cliff B has explained things very well in his answer. I'd just like to add a more succinct explanation. Your problem is that you want to keep the dictionary sorted alphabetically and also use a hash table. But if you use a hash table, you can safely let go of the alphabetization. A hash map is a different way of sorting the words -- one that is ...


2

When you declare node* you are not declaring a variable of type struct node. Rather, you are declaring a pointer-to-node. A pointer is just a memory address. This is why, when you check the sizeof() your pointer, you're seeing 8 bytes instead of 224. By the way, if this answers your question, please let me know by clicking the green check mark. Otherwise, ...


2

The second one is incorrect and it only passes check50 because of the very small dictionaries that check50 uses. In your original version, you create a pointer that points to the hashtable, and you traverse the linked lists by modifying that pointer. The reason the second is wrong is that you are changing the values in the hashtable itself as you check ...


2

You have: else if (l == '\'' && trav->children[26] == NULL) { trav->children[26] = calloc(1, sizeof(node)); } So, what if you do have an apostrophe but trav->children[26] is not NULL? I suggest you add another condition like: else if (l == '\'' && trav->children[26] != NULL) { trav = trav->children[26]; }


2

You can jump to SUGGESTION for quick answer. I plugged your check() function on my dictionary.c program. I also have a trie in my dictionary.c. I don't know what is causing the segmentation fault. However, I found a behaviour that might be of your interest. I ran the program with both my check() function and yours against alice.txt. I found that among the ...


2

Can't tell you exactly what's happening without seeing your entire code, but one thing I can tell you right away is that you're forgetting to allocate space for the null terminator when you only malloc the strlen, like this hash_word = malloc(sizeof(word_length));. You should malloc strlen + 1. And note that sizeof(word_length) will give you back the size ...


2

It's a common problem. The problem lies in load(), where you have created a "shadow variable." A shadow variable happens this way: First, the original variable is created, either earlier in main or a function, or as a global variable. Then a second variable is created with the same name, but will have local scope because it's within a set of curly braces ...


2

You have to stop the submission now (in the submit event listener), and in case of success submit in the AJAX callback. Submitting via JavaScript will not trigger another submit event.


2

You need to determine the user name within the submit callback, not at the time of installing the callback. You are passing an empty value, not using Javascript variable username at all. Use "/check?username=" + username, or more correctly "/check?username=" + encodeURIComponent(username) (in case user name contains special characters), or maybe "/check", {...


2

So, as it turns out - the error was in the Python code. I used "request.form.get()" when I should have used "request.args.get()" since its a GET request not a POST request. Using "request.args.get()" fixed it and it is now working as expected. Thank you @Blauelf!


1

Without seeing the load and hash functions, it's almost impossible to know what's wrong. It could be that the hash function isn't giving the same result for the same word each time, or the word that is being processed has some stray characters or non-alphas attached, which could change the hash. Or, there's a problem with how the load is being done. You ...


1

Having seen your load function, I don't think it's working correctly. If you get a word that hashes to the same value as a previous word, the code will drop into the else clause and will try to place the word in the linked list, but the value loaded into head is based on a different key value from a previous word! The result is that any given word may or ...


1

I suspect that you have more than one problem in your code, but can't be sure without seeing all of it. However, I think I located one significant issue. Look at the code near the end of your load function: while (!feof(fp)) { node* new_node = malloc(sizeof(node)); fscanf(fp, "%s", new_node-> word); //run through hash function hash = ...


1

Supposing that before the loop you declare the file where you will write data FILE *jpgfile = NULL; You can use if (jpgfile != NULL) to check if you have an already open file.


1

while (cursor is not NULL) //here is where the infinite loop begins { if( cursor->word = new_node->word) //this is using strcmp { return true make cursor = cursor->next; } } What if cursor->word is NOT equal to new_node->word? cursor will never become cursor->next and thus it's never becoming NULL, right?


Only top voted, non community-wiki answers of a minimum length are eligible