Hacker Newsnew | past | comments | ask | show | jobs | submit | GolDDranks's commentslogin

What I usually do to share code, is send a link to GitHub or whatever VCS portal we are using. Of course, this doesn't work with local, new code, but that's why we also use liberally draft pull requests to share unfinished code.

I also grew up where 90% of TV was subtitled (Finland, where, incidentally, the author of the article is from too), but I find the "good" anime subtitles better – for the simple reason that they make it easier to see which translation corresponds to which text.

Note that anime has generally more text on the screen that many western shows, so I think subtitling practices of some subtitle-heavy western countries, while informed and proven by time, don't necessarily represent optimal practices for anime.

But I think you are correct about the subtitle preferences of anime fans. The "general wisdom" of audiovisual translations is that great translations manage to convey the important point very succinctly, and a professional translator knows how to shave off the fluff to achieve subtitles that are quick to read and "fade in the background" in the sense that you don't even realize that you are reading them.

However, many anime fans actually LIKE so-called foreignizing translations ( https://en.wikipedia.org/wiki/Domestication_and_foreignizati... ). I think this plays into the fancier subtitle preferences too.


The difference is that when there is text on the original video material, in the good examples the translations are positioned in the proximity of the original texts, and styled similarly, which makes it easier to understand what is translation of what, and generally improves immersion.

In the bad examples, the translations for the texts are mixed with the lines the characters are speaking, which makes it harder to follow.


That makes sense. Thanks very much for the clarification.


Note that Turing test allows a lot leeway for the test settings, i.e. who interrogates it, how much they know about the weakness of current SOA models, are they allowed to use tools (I'm thinking of something like ARC-AGI but in a format that allows chat-based testing), and how long a chat is allowed etc. Therefore there can be multiple interpretations of whether the current models pass the test or not.

One could say that if there is maximally hard Turing test, and a "sloppy" Turing test, we are somewhere where the current models pass the sloppy version but not the maximally hard version.


Hah, tools-or-no does make things interesting, since this opens up the robot tactic of "use this discord API to poll some humans about appropriate response". And yet if you're suspiciously good at cube roots, then you might out yourself as robot right away. Doing any math at all in fact is probably suspect. Outside of a classroom humans tend to answer questions like "multiply 34 x 91" with "go fuck yourself", and personally I usually start closing browser tabs when asked to identify motorcycles


Also, Rust is not going to have it for the long run that pointers can be, in fact, disguised as integers. There is this thing called pointer provenance, and some day, all pointers are required to have provenance (i.e. a proof where they did come from) OR they are required to admit that POOF this is a pointer out of thin air, you can't assume anything about the pointee. As long as there are no POOF magicians, the GC can assume that it knows every reference!


> As long as there are no POOF magicians, the GC can assume that it knows every reference!

creating pointers without provenance is safe, so the GC can’t assume that a program won’t have them also be sound. This always be an issue.


I wouldn't say always: https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...

I don't know what the plan is but I wouldn't be surprised if there's a breaking change (maybe in an edition) to remove exposed provenance from Rust entirely.


The mechanisms that Rust provide for memory management are various. Having a GC as a library for usecases with shared ownership / handles-to-resources is not out of question. The problem is that they have been hard to integrate with the language.


While you're of course correct, there's just something that feels off. I'd love if we kept niche, focused-purpose languages once in a while, instead of having every language do everything. If you prioritize everything you prioritize nothing.


I agree specifically with regards to GC; I think that focusing on being an excellent language for low-level programming (linkable language-agnostic libraries, embedded systems, performance-sensitive systems, high-assurance systems etc.) should continue being the focus.

However, this is 3rd party research. Let all flowers bloom!


> If you prioritize everything you prioritize nothing

Well...

If you prioritize everything you prioritize generalism.

(the "nothing" part comes from our natural limitation to pay enough multidisciplinary attention to details but that psychological impression is being nuked with AI as we speak and the efforts to get to AGI are an attempt to make synthetic "intelligence" be able to gain dominion over this spirit before us)


No, they are quite identical. Both cases logically lead to "now everything has the same priority". There's nothing about generalism in there.


Just like when hiring developers, there's an advantage in choosing "jack of all trades, master of some".


That depends on the intent of the sentence, and the intent was only a guess of the GP. But you can analyze だけに in two ways:

英語に吹き替える to dub in English (the base case of 吹き替える)

英語だけに吹き替える to dub just in English (だけ + に)

アメリカだけに吹き替える to dub, just because it's America / as you'd expect of America (だけに grammar https://tanosuke.com/n2-dakeni)


Oooh I see, thanks!


Not the GP, but I watch all my anime raw (often enabling Japanese closed captions), and I struggle to understand the above...


Well, it's not really Japanese. It reminds me of myself as a doe-eyed freshman who took Japanese 101 and thought I was hot shit.


Those were the days.


There is something off with the explanation.

At first, there is 16 fetches per row x column, 1024 in total. Then, it is observed that an input row needs to be fetched only once per output row, reducing the amount to 8 fetches per row, plus 8 per row x column, 8 * 8 + 8 * 64 = 576 in total. This requires the same amount of 16 numbers to be kept in registers.

But then it is claimed that by doing one quadrant at a time, all that is needed is 64 fetches per quadrant or 256 fetches in total. But that assumes we can keep 4 rows and 4 columns, 8 numbers per row or column = 64 numbers in registers! If we can only keep 16 numbers like above, each row of the quadrant is going to take 40 fetches, and we get 160 fetches per quadrant or 640 fetches in total, a pessimization from 576 fetches!


That’s a valid point - I’m assuming infinite register capacity at that point in the post.

The next section discusses what you’re talking about eg, how to deal with finite register/shared capacity by splitting the k dimension. I’ll mention the shared/register memory limitation sooner to clarify confusion.


The overall problem with your blog post is that it is beating around the bush rather than getting to the point. Overall, it feels like the blog post is explaining tiling in reverse order of what is needed to understand it.

"How effective is tiling?" and "Why tiling tiling is so fast" should be at the end, while the key section "Why there's a limit to tiling" which should be front and center is in the middle, followed by a subversion of the entire concept in "How to sidestep tiling limits"

It's also incredibly jarring to read this:

"Wondering how we were able to reduce memory usage "for free"? Indeed, the reduction wasn't free. In fact, we paid for this reduction a different way — by incurring more writes."

This is again, completely backwards. Let's assume you don't have a cache at all, you'll have to write out everything to DRAM every single time. The opposite is also true. Imagine you had an infinite number of registers. Every addition operation will accumulate into a register, which is a write operation. Hence, the number of write operations doesn't change.

Really the main points should be in this order: 1. matrix multiplication works best with square or almost square matrices. 2. registers and SRAM (including caches) is limited, forcing you to process matrices of finite size (aka tiles) 3. memory hierarchy means that the biggest matrix you can store at a given hierarchy gets bigger. 4. you can split matrix multiplication using inner and outer products 5. outer products take few inputs and have many outputs/accumulators, inner products take many inputs and have few outputs/accumulators. 6. You want to calculate the biggest outer product you can get away with, since this significantly reduces the memory needed to store inputs and maximizes number of cycles doing calculations, once you hit the limit, you want to reuse the accumulator, so you calculate inner products of outer products.


I see, thanks for the feedback - the current blog post’s flow certainly isn’t optimal. I’ll try reordering to eliminate jarring bits and see how it flows.


It gets even worse, when the original mangaka typoes the name, and people follow a single typo like a religion. This happened with Kaoru Mori's "Emma", where a common English surname "Jones" was accidentally spelled "Jounse" by the author, and used in translations without questioning it too much, only later found to be written correctly "Jones" in a later chapter by the author herself.


I see this a lot, and it is a mild pet peeve of mine as well. Along the same lines, since I’m using Gundam as an example in this thread, I’ll point to a technology in the franchise called “psycommu” (pronounced in dubs as psy-com-moo) which is clearly transliterated from how it’s spelled in the original script without taking a second look at it. I can’t imagine why they wouldn’t have just localized it to “psy-com,” But here we are still calling it “psycommu” in recent series


Somewhat related is the situation with Shingeki no Kyojin / Attack on Titan. "Attack on Titan" was the manga author's chosen English title, except the story does not take place on the moon of Titan but is instead about giants attacking a human settlement. The Japanese title could be interpreted as "Attack of Titans" so everyone assumed "Attack on Titan" was just Engrish for that, and why CommieSubs' fan translation for example went with "The Eotena Onslaught". [1]

Years later it turned out some of the giants had classes / types and the title was a reference to the Attack type of giant. Thus the English title would've been better as "The Attack Titan", and indeed the Japanese title could also have been interpreted as that, though it's only obvious in hindsight. The Japanese title was likely deliberately intended to have the double-meaning "Attack of Titans" and "The Attack Titan", though this double-meaning cannot be conveyed in English, and in fact we're now stuck due to inertia with a third English rendering that is completely disconnected from either meaning.

[1]: https://commiesubs.com/shingeki-no-kyojin-01/


Most fans I saw called it by the Japanese title, Shingeki no Kyojin. You could almost tell whether someone watched the official licensed translation or not, based on what they called the series.

Actually, another quirk is the German lyric in the first season's opening theme. Crunchyroll doesn't usually translate opening or ending lyrics, but translating the lyrics was standard practice in the fansub era, so the. However, they misheard the lyric as "Sie sind das Essen und wir sind die Jäger" - "You are the food and we are the hunters" - as if the line is spoken by the Titans (perhaps the English-speaking audience is primed to the Germans being the bad guys in movies). The actual lyric was revealed in official Japanese sources as spoken from the perspective of the humans: "Seid ihr das Essen? Nein, wir sind die Jäger!" - "Are we the food? No, we are the hunters!" However, the incorrect lyric persists among fans because the second opening theme superceded the first before the error was widely noted in the English speaking anime community.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: