That looks like the Latin ablative case, governed by the preposition "a" in the previous line. In Latin you can see many different forms of a name depending on its context in a sentence (the two most common in books' title pages being the genitive and ablative, roughly meaning 'of' and 'by').
I really enjoyed https://woebot.io/ for a few months. I was really surprised at its depth when I kept on discovering new flows after weeks of interacting with it daily.
But that kind of chatbot is surely an exception. And Andrew Ng is the chairman of WoeBot, so I expected it to be good quality.
The big difference here is that the bot is the product. (An interesting one at that!)
What I find utterly annoying is a chatbot popping on some software webpage, reducing my field of view and interrupting my progress toward the documentation/download/career/whatever section. In this case I find it an overly hyped widget that I absolutely do not need.
The hard part is not making (launching) the bot, but maintaining it and making sure it stays usable and useful. A very important piece that is missing from many open-source chatbot frameworks is some sort of web-based administration tool.
You need a tool that is capable of the following:
- Collecting analytics about each session, so that you can notice user problems early.
- Providing an interface for improving your training dataset using new data from actual user interactions.
- Evaluating the model after each update (simple accuracy metrics are not good enough; it is possible to maintain good accuracy and have one of your core flows messed up after re-training).
Even when you have an admin tool capable of these, you need one or more people (depending on the size of the bot) to review historical sessions and curate newly generated training data almost daily.
There is no incentive for a company to spend their time explaining what you did wrong at an interview if they are already sure they don't want to hire you. And if the reason for not choosing you is not very constructive, there's no point at all in sharing it.
Your best bet might be to ask about how you did at the end of the interview. I had some luck with interviewers explaining me a solution to an interview problem that they would consider perfect.
Try Intermittent Fasting. I.e. eat only during 8/6/4-hour window every day (I personally prefer 6).
I find it much easier to live with the fact that at certain times I am not allowed to eat at all, than trying to control what I eat at all times. It also forced me to be more careful about choosing the right food during the eating window; I now want to get as much nutritional value as I can from my food, since the total amount of food I manage to eat in 6 hours is not that large.
The first week might be a challenge in terms of managing your hunger, but it gets easier after that. I now see hunger not as a signal that my body is starving, but a signal that my body gets used to being fed at certain times of the day. I now feel hungry only about an hour before my eating window.
I find skipping breakfast and any meals after 6 PM the easiest; but of course this might be different for you. It's just with this schedule your colleagues won't even notice that you are fasting unless you tell them.
Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well.
After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this was one of the reasons why Twitter moved from Ruby to Scala.
I still love to use Python for hacking something quick for myself. But I also look at some popular strongly-typed languages now and hope to get better at one of them soon.
I think that example shows that Python's type system isn't the weakest out there, but it's still pretty weak.
For example, it doesn't have a built-in way to make a dictionary-whose-keys-must-be-integers (so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None).
I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
> so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None
Technically, dict.get() returns None if the item isn't found and you don't provide a different value for its default.
thedictionary[b] would throw a KeyError on the other hand.
One could always subclass dict if they wanted to ensure the keys were always integers or whatever.
> I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
Not sure if you're arguing for a stronger type system or having the language promote the string to an int as (I've heard) other scripting languages do.
Though, once you figure out the language doesn't automagically parse files for you you're well on the way to finding more fun and exciting ways to get python to throw error messages at you.
I am using the current Python version and tried type hinting. I don't see how it can help much, since types are not enforced;especially when interfacing with not-so-well-tested modules that don't use type hinting and can sometimes return values of unexpected type.
It's definitely a neat feature when writing an application from scratch that interfaces with few other modules or only the well-tested ones.
The point is that your example will not break anything until run time, unless some static analysis tools are deployed (which are much more limited compared to what a compiler can achieve).
The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file.
Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string.
In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwise the minimum expected file size is almost certainly larger than the maximum path length.
Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?
One common case where this is attractive is where you have a bunch of "public" functions built on top of each other, with the higher ones passing that parameter on and not otherwise caring what it is:
If you can make the low-level function generic one way or another, you avoid having to duplicate the higher-level functions.
Another case is where there are two or more parameters that you want to be generic in this sense: if your only option is duplicating the function you can end up having to define inconveniently many variants.
Yeah, that is convenient and I do that often. But I try to wrap the variables in different types depending on their source (e.g. whether it's a filename or file content) so that functions further down can disambiguate between variables explicitly.
Why not have clearer file, filename or data keyword arguments ? Or just file and call open or stringio if you have the file name or data ? Plenty of more explicit solutions.
You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.
MIT Technology Review published a piece on one possible CO2 extraction solution just a few days ago. Besides being somewhat expensive, it also needs to occupy substantial physical area.
