You made me comment again, very well explained why can't we do certain things with logic, most of the youtubers only focusing what can we do in this problem.
What is this code below purpose in remove method? Entry<K, V> prev = e; e = e.next; while (e != null) { if (e.getKey() == key) { prev.next = e.next; e.next = null; return e; } prev = e; e = e.next; } I delete this code, and turn out fine without it. I can still remove data on the middle.
Thanks man for uploading this, Nobody has explained this much in detail, I have to fiddle around my filter to find your videos, all other top videos are shit.
Great series! Would you also consider making a video about different subjects such as parser combinators or foldable and traversable containers or even optics!
A couple of questions: How big is the array in the standard HashMap class provided in Java? I would think that 8 is rather small and you are just using 8 as a simple example. Can the standard array size be changed? Thanks for the video!
docs.oracle.com/javase/8/docs/api/java/util/HashMap.html HashMap() Constructs an empty HashMap with the default initial capacity (16) and the default load factor (0.75). you dont have to worry about changing the side, it happens automatically in the class
in the while in the put fonction we can do this to no ? while (current != null) { if (current.key.equals(key)) { current.value = value; return; } if (current.next == null){ break; } current = current.next; } current.next = entry;
thanks, sorry about that. you can turn on CC . but anyways what i said was that after the if invalid call, we should just continue to next iteration. we should not be checking s[l].lower() == s[r].lower()
Again thank you very much for your effort to make these three videos, it helps tremendously for people like me who are struggling with these difficult terms.
That's not quite correct. We can wrap functions using a functor. With access to the structure, e.g. "Just (const 5)" is a wrapped function in the Maybe functor. But that's "cheating"… using only fmap and an existing functor value v, this is also possible though, e.g. let's say v is "Just 5", then "fmap const v" creates a functor value containing a (trivial) function. These examples aren't really interesting, sure. And indeed Applicative is more interesting because it crucially allows going beyond wrapping a function. It allows *applying* this wrapped function to a wrapped value, yielding another wrapped value. Without understanding the functor structurally (e.g. using fromJust for the Maybe functor), this cannot be done using the functor alone. In your definition of (<*>) for Applicative Maybe2, you had to access the wrapped function using the internal knowledge of the Maybe2 data type. This is true in general, it is not possible to write a generic Applicative instance using only Functor (and it's equally impossible to write a generic Monad instance using only Applicative). Ok, to be exact, you didn't have to know the structure of the wrapped function but you did have to know the structure of *at least one* of function and value. This is because we can use fmap on a function too, supplying a parameter. fmap (+3) (Just2 5) = Just2 8 but equivalently fmap (\f -> f 5) (Just2 (+3)) = Just2 8 Haskell programmers being as lazy as the language (😉) would probably write the latter as fmap ($ 5) (Just2 (+3)) though. What this means in practice is that the difference between Functor and Applicative is that the former only allows lifting unary functions while the latter allows lifting binary functions (as is easily seen by the fact that, instead of pure and <*>, it's also permitted to define pure and liftA2). And this is a huge difference because not only are binary functions more powerful than unary functions but, using binary functions, we can also implement ternary functions and so on. I.e. Applicative allows combining wrapped values to produce another wrapped value, using only type class functions, which Functor does not allow.
I might be wrong, but pure for tree shoud be implemented as infinite recurrent in order to meet the identity rule of Applicative typeclass: pure id <*> v = v
