Even if the translation is perfect and "real-time", it comes with a significant latency that will make any conversation less natural. Good for some situations while traveling, not something you would want to rely on for everyday life.
HN user
wibr
The API would provide pseudoranges and also the carrier phase on some phones, so it should be possible to calculate a solution with corrections.
Here's my list, the three stars indicate the rating on douban.com: https://www.jiong3.com/gradedwatching/
I would personally recommend: Secret, On Children, A Sun, Light the Night, Office Girls, Scissor Seven, Ancient Detective, Back to 1989
It depends. Sometimes I really learn all the words before watching, sometimes I just watch something without any preparation.
Adding too many words to Pleco SRS over a short time doesn't work well, you will get overwhelmed with reviews quickly. So if I decide to study the words for a tv show I take some time between the episodes to prepare for the next ones, depending on how many words I have to learn it could be days or weeks.
Which searches are you referring to?
Thanks! I've actually watched that one a while ago but it's not available on Netflix in my region so couldn't get the subtitles to add it to the list. The version on youtube only has hardsubs, unfortunately.
What's the name of the Taiwanese workplace drama?
For people learning Mandarin I provide some information including word lists for a lot of shows on Netflix here:
I'm also guilty of this. Related to this thread, some years ago I made a puzzle game with Chinese characters where you get a bunch of components and try to combine them to as many characters as possible: http://www.jiong3.com/pinzi/
It's not just yak shaving though, some programming skills can be really useful when dealing with vocab lists etc..
Not a structured method like Heisig but a dictionary for Pleco which uses actual etymology to explain characters:
I've also learned the first 1500 characters using this book, not in one month though.
The method works but has some problems. Maybe the biggest problem is that it completely ignores pronunciation. It does not help you remember the pronunciation and it does not make use of the sound components of the characters. Most characters are composed of one component which hints at the meaning and another which hints at the sound, e.g. 青 is the sound component in 情清輕請, all of those are pronounced qing (with different tones). Usually it's not that obvious, this is just a good example. The left component in those characters would hint at the meaning.
The Heisig method instead creates a mapping between a keyword, which is derived from a single meaning of the character or invented for components which don't have a meaning, to the written form of the character using mnemonics. This works well in the beginning but once you reach a more advanced stage where you know how to say something in Chinese but maybe forgot how to write the characters this doesn't help you much since the pronunciation is not incorporated into the mnemonics.
When you are just starting out and learning all those characters seems like an unmanagable task, the Heisig method can provide a good structure to quickly "learn" many characters (keyword<>writing). It's also fun to come up with stories and images. But in the end it can only provide a basic scaffold for learning more meanings, pronunciation, words etc.
I even made a small game once using those character decompositions: http://www.jiong3.com/pinzi/
The note for your employer does not contain any information about the reason for the sick leave in Germany, the one for your health insurance does.
The big advantage of flashcards in Pleco is the integration with the whole app. If you use the Pleco Reader, you can add new cards directly from the Reader. You can also create cards from dictionary entries and during studying check other dictionaries for each card, play the audio etc.. Some people prefer Anki, but personally I would recommend the Pleco Flashcards for learning Chinese.
This is neat!
Also useful for this kind of analysis: https://www.chinesetextanalyser.com/
I'm doing something similar but instead of reading native books I'm still sticking to readers with increasing difficulty so that I don't have to look too many words up while reading. Since the readers also include word lists I can learn almost all of the words beforehand.
My reading list (traditional characters) is here: https://www.chinese-forums.com/forums/topic/44336-graded-rea...
The website displays search results from several dictionaries: https://www.moedict.tw/about.html
I learned a lot about aviation as a kid/teenager playing the Microsoft Flight Simulator. All the important instruments, flight control, radio navigation, flight patterns etc. Good times on Meigs Field.
My personal copy-paste summary of a similar topic on HN some time ago (https://news.ycombinator.com/item?id=9784008):
# Getting familiar with a new codebase
### Use the right tools
- grep, ack, ag, global search (Visual Assist)
- doxygen, javadocs
- sourcegraph, pfff (facebook), open-grok, SourceInsight
- Proper IDE, REPL
- chronon (dvr for java)
- SWAG (Software Architecture Group)
- Static code analysis
### Use the repository
- Find most relevant (frequently, recently edited) files
- Find dependancy graphs
- Get basic information like which languages are used for what
- Use good source control so that you don't have to worry about breaking things
- Look at commits, in general or for specific issues
- Browse the directory structure, packages, modules, namespaces etc.
- Use "blame" to see when things changed
### Ask questions
- Talk to the customer, find out the purpose of the application
- Pair up with another developer who is more familiar with the code
### Read the documentation
- Look at use cases, diagrams describing architecture, call graphs, user docs
- Understand the problem domain
- Add more documentation as your knowledge grows
- Comments and docs might be wrong!
### Browse the code
- Skim around to get a general idea and a feeling for where things are
- Look at public interfaces, header files first
- Find out which libraries are used
- Take some important public API or function in the UI and follow the code from there. Find implementations of functions, dive into related functions and data structures until you understand how the it's done. Then work your way back out.
- Use tools to quickly find declarations, definitions, references and calls of variables/functions/etc., usage patterns
- Find the entry point of the program
- Figure out the state machine of the program
- Focus on your particular issue
- Use a large, vertical screen with small font size with a pane to show file/class structure
### Take notes
- Use pencil and paper to write down summaries, relationships between classes, record definitions, core functions and methods
- Write a glossary: Function names, Datatypes, prefixes, filenames
- Document everything you understand and don't understand
- Use drawings to create a mental model
### Look at the data
- Find out how the data is stored in the database
### Build the project
- First make sure you can build it and run it
### Use the debugger, profiler and logging
- Set breakpoints, poke around the code, change variables, inspect local variables, stack traces, ...
- Watch the initialization process
- Start from main() and see where it goes
- Find hotspots with the profiler
- Set logging level to max/add logging and use the output to go through the code
### Edit the code
- Adopt the existing coding style
- Try to recreate and fix small bugs, make sure you understand the implications of the fix to the rest of the program first
- Tidy up the code according to the common standard after talking with the team
- Make the code clearer (best with tests)
- Add TODO comments
- Add comments describing what you think the code does
- Hack some feature into the code, then try to not break other stuff, build up a mental model over time, re-write the feature properly
### Use Tests
- Run the tests, make sure they are all passing
- Create new tests
- Browse the tests as an examples reference
Not a parking lot, but a park:
https://www.visitberlin.de/en/tempelhofer-feld-tempelhof-fie...
I was only referring to the time. "halb drei" is two thirty, which usually means 14:30 unless you specifically say "in the morning". The action in [2] would probably be added if you add a full stop.
For DeepL:
-> À trois heures et demie
-> 14 h 30 du soir,
-> À 14 h 30,
-> On va au cinéma à 14h30.
Correct for everything but the first, not sure why it added "du soir". For the a complete sentence "Um halb drei gehen wir." it's also correct ("On part à 14h30.").
Um halb drei -> À trois heures et demie
Um halb drei gehen -> Aller à deux heures et demie
Um halb drei gehen wir -> A quatre heures et demie nous partons
Um halb drei gehen wir ins Kino. -> A trois heures et demie nous allons au cinéma.
How useful are visualizations like this for improving the performance of the model?
Unfortunately they don't provide any details about the model or the training. Would be nice to have an example as a baseline for real-time performance on iOS devices.
I tried it with a German poem (Erlkönig) and it seems like Shakespeare is in the training data... at least it's not regular English:
"And if thou wilt not, I shall need violence."
You could also do that with inkscape on the commandline, not sure if it's faster, though...
I agree that it works well in the Espace, however my impression is that while in the Model 3 the display is in the center like in the Espace it's also closer to the driver, making the viewing angle larger...
This comes up basically everytime the Tesla Autopilot is discussed on HN since they rely mostly on cameras, except that they also have a front radar. In the end, we want self-driving cars to be better than human drivers, so they should also handle situations that humans are struggling with and additionally have some redundancy. Some things which are difficult to do for CV, detecting things in the dark for example, are trivial for Lidar. Radar on the other hand can provide accurate measurements for distance and speed of other vehicles, also independent of lighting conditions.
I don't really believe that the hardware is enough for what they are trying to achieve. There is almost no redundancy e.g. on sensor level except for the front radar supporting the front cameras and ultrasound for close distances, however if one of those rear-facing cameras fails due to a defect or dirt on the lens the vehicle would have to stop because it wouldn't be able to detect oncoming cars. I am also not sure about the processing power, handling video streams and doing deep learning for up to eight cameras in real time seems a little too much for a current gpu?
Tesla uses the same Tier 1 suppliers as any other automaker, so I don't really see why the Tesla production would be more vertically integrated. They have their own batteries but so do traditional automakers have their own ICEs and other key technologies.
The evolution of the pug: https://youtu.be/iHPozu1raQo?t=2m12s
http://www.steffengerlach.de/freeware/ the scanner tool is also quite neat and freeware