Something like below. Play with it more!

var a = [1, 34, 53, 7, 100];
// this function takes in a number array
// it returns the maximum and the minimum of the array
function linearTraversal(a, check) {
    var n = a.length;
    if (n === 0) {
        return undefined;
    }
    var m = a[0];
    for (var i = 1; i < n; i++) {
        var e = a[i];
        if (check(e, m))
            m = e
    }
    return m
}
var max = linearTraversal(a, function (e1, e2) {
    return e1 > e2;
});
var min = linearTraversal(a, function (e1, e2) {
    return e1 < e2;
})
console.log(max);
console.log(min);

See Line 2. You should write this cryptarithm column-wise, the way you were told:

  AB
- CD
-----
  EF
+ GH
------
 PPP

Remember, stating requirements clearly is key.

I like the algorithm that you have implemented. You sort both the strings and then see if the sorted sequences are same. This is fair enough!

Looking at the details, one figures out that you take both strings (say s1 and s2) and then save their characters in two separate arrays (say a1 and a2). Then you sort a1 and a2 and check if the length of the arrays and all characters in the arrays are the same. There is nothing wrong with this, it is just that it is a bit slow. The "slowness" of this method is not immediately evident because you perhaps have tested this with short strings and because computers are fast and efficient these days for such tasks, you would not have noticed any slowness. But this might get perceivably slow if the strings are long enough.

Is it possible for you to think of an alternate way of determining if two strings are anagrams of each other that addresses the above concern?

One hint: Although there could be any number of characters in a string, the number of unique characters in a given string are not too many. In fact, if a string are made of ASCII characters alone, even if there are a million characters in a string, it could have at the most 26 (or 40 including numbers and punctuation marks) unique characters!

Read the password function assignment again. It asks "How many such passwords are there?"

Do you think there is any other way of finding an answer for it? Remember, computer science is applied mathematics and as such many programming problems are mathematical in nature. This means that you can use (perhaps mathematical, or non programmatic) ways to determine the answer.

In short, if the length of the password is n and each character is one of the 70 allowed characters (a-zA-Z0-9 and 8 symbols: 26+26+10+8 = 70),

• What is the total number of passwords possible if there were no restrictions?
• What is the total number of passwords possible with the given restrictions that there is at least a character of each kind (lower case letter, upper case letter, decimal digit, and a symbol)?

You might be thinking that this is boring, but it is required: Make sure all problems, applications etc. have proper introductory blurbs about what the current program is supposed to do.

Remember:

“Without requirements or design, programming is the art of adding bugs to an empty text file.” - Louis Srygley

I wanted to introduce you to "GitHub Issues". This is a significant part of development life cycle of any software project. Since software is inherently complex, when a particular implementation is released, there are, potentially, many problems with it. The problem could be in the form of a misalignment with respect to its specifications or simply a logical error. A logical error, as you may know, is called a "bug". GitHub Issues product lets us "file" and "fix" bugs.

I am creating this issue so that you understand the life cycle of creating an issue. Next, I will file another issue that solicits your opinion (and perhaps action).

I like what you are doing in the unit converter assignment, but I also have a comment.

This is the right time to pay attention to this comment because, like in life, in software one should be aware of the future value of one's code.

Right now, unit converter program is a "command-line" program and all its logic is part of one big, monolithic JS file. But we have always had an idea of creating an HTML page (a la Google search page) where a simple set of text-boxes or drop-downs along with embedded JavaScript would make the user interaction of unit conversion much easier than command-line.

So, if you "migrated" your converter to an HTML page, would you have to rewrite major parts of it? If it were so, it would be a lot of repetition, won't it?

What can you do about that? For instance, when I first thought about it, I thought of writing simple function whose signature is like this:

// convertMass converts the given quantity (default: 1) of mass between the given units
function convertMass(from, to, quantity) {
}

This way, you can reuse parts of your program and it will become much more maintainable.

Yes, this means iterating the program. It is true with everything in life, one has got to revisit a piece of writing, a mathematical program, a decision one took, and, of course, a computer program. Why don't you find the avenues of making your program "modular"?

The book, Mastering Algorithms with Perl (let's call it MAwP) discusses this aspect well. We are going to analyze the space-time tradeoff while implementing algorithms.

• Start with writing three functions with the following signatures
  • getBrightnessCalculate(r, g, b): Calculates the brightness every time by performing three FP multiplications and two additions: r*0.118 + g * 0.231 + b * 0.043.
  • getBrightnessPartialLookup(r, g, b): Maintain three lookup tables of 256 entries each and then do three lookups and two additions.
  • getBrightnessFullLookup(r, g, b): Maintain one lookup table of 16777216 entries and then perform one lookup.
• Write three separate programs (one for each of the functions above) each of which
  • Sets up whatever the respective function needs (e.g. creating lookup tables).
  • Calls each of the functions a million times with random values for red, green, and blue.
  • Measures the time it takes over those million calls and then get a rough value for an average time required by each function (simulating one call).

At line 18, you see if a[check] is less than the target. And then on the next line, you set low to check. Will it be better to set low to check + 1? Similarly for the check for high.

Also, you seem to be setting check to Math.floor(...) one time too many. Can you think of ways to improve that?

Add documentation and make it so that it actually runs

I am looking at SHA 1f4e085.

It seems that this version is still incorrect. You are going through the entire string (str2) even when you have run out of the possible subseq (str1). What if str2 has 10 characters that have matched in the first 100 characters of a 1-million character string? This function will end up traversing all the million characters of str1 unnecessarily before continuing.

Another problem: JavaScript may be forgiving in that it allows you to take the character of a string at an index that is greater than or equal to the length of the string, but that does not mean you should do it. When i equals length(str2) (because of i++), you will access a character that is just out of bounds and you should be careful with that (although JavaScript allows you to do it)!

See:

Here, you use a combination of both camel-casing and snake-casing (look up what these mean) while naming your function. Whereas it is a matter of style and a style-checking tool (sometimes called a linter, look up JSLint, or JSHint) will flag this inconsistency, it is a good idea to be consistent to begin with. I guess in JavaScript the incumbent style for function names is CamelCase. While it is more significant in case of naming functions and modules, it is also important while naming variables and properties. Look at your variables low and high. It is fine to have some convention here too. The convention you have followed is that low is the inclusive index, whereas high is an exclusive index (meaning a[high] does not exist and will be returning as undefined in a forgiving language like JavaScript). By making this convention or a programming assumption more explicit in the form of a documenting comment makes the code more readable.

Programming is hard. Look at the above line which you think to be correct. And after you have convinced yourself that it is, read this article and reconsider. (Let me know if you don't understand something from it).

A (life) lesson here is that always be smart, but seldom be certain.

The maze program currently cannot be retried. Add a reset button to do so and make it smoother by adding directions, it isn't really easy to understand what to do.

See the telephone keypad problem as coded as of 18 Nov 2018.

There are multiple issues with your implementation. But here I will ask that you convert this into a real "app". Remember that an "app" contains an HTML that determines the "structure" of your document and JavaScript that determines its behavior. So, maybe you should provide a textbox where the user enters a telephone number and you provide all the strings (even those that have no dictionary equivalents) and then those that have words from dictionary.

Every function you write should have a preamble that consists of

• a simple one or two line description of what it does,
• list of name and type of its arguments,
• necessary details of its return values.

This is important especially for a dynamic language like JavaScript.

Here's an example:

// Partitions the given array around an element and returns the index of the partition element.
// input: an array of numbers.
// output: the index i of the element such that a[j] <= a[i] for all j < i and a[i] < a[j] for all j > i. 
// note: the given array may be modified after the function returns.
function partition(array) {
// ...
}

Add such a description to your password functions.

This is an issue of a different kind. We call it an app. This issue calls for developing an app and clearly describes what that app should do.

Prerequisite: The Stroop Effect

Following things should be accomplished as a prerequisite to the development of this app. I know it is somewhat time consuming, but believe me, this is both interesting and useful.

• Read up Stroop Effect.
• Discuss the effect with someone. Refer to more references on the topic.
• Take the test yourself. The test measures the strength of Stroop Effect in the individual taking the test.
• Look at the homework ideas.

Your App Details

The code for the demo is here.
Study that code. Then start with the design and implementation of the same idea. How would you implement this "app" in JavaScript? How would you add the language support? How would you deploy the app to an instance on AWS so that it available for anyone to take?

Conclusion

Develop the app and deploy it. There is no deadline, although you should try to accomplish this by the end of summer 2020 (Aug/Sept 2020).