Trolling, flicking - I never heard anyone say these, but had heard they were used in the past. Along those lines, flaming or flaming out was used for failing out or needing to take terms off.
A few people still did 3AM Tommy's. Negative time Tommy's was a significant event in at least a few houses.
The Ride tradition was definitely around, with the only sanctioned playing on mornings of finals
I never heard anyone say finesse, brute force, or ignorance
> Intel keeps getting it right with numerical libraries. They're open. They work well. They work on AMD.
What Intel numerical libraries are you thinking of? When I think of Intel numerical libraries, the first that comes to mind is MKL. MKL is neither open-source nor does it work well on AMD without some fragile hacks [0].
The nvidia pgi compiler compiles CUDA to multi-core x86-64. There are other third-party compilers for CUDA->x86-64 (one LLVM-based one from Intel).
There is a "library replacement" for CUDA from AMD called HIP, that you can use to map CUDA programs to ROCm. But... it doesn't work very well.
NVIDIA also open-sourced CUDA support for Clang and LLVM. So anybody can extend clang to map CUDA to any hardware supported by LLVM, including SPIRV. The only company that would benefit from doing this would be AMD, but AMD doesn't have many LLVM contributors.
Intel drives clang and LLVM development for x86_64, paying a lot of people to work on that.
You aren't seriously implying than any bystander is capable of extending LLVM to map CUDA to SPIR-V? What percentage of present day gainfully employed software engineers do you suppose even has the background knowledge? How many hours do you suppose the work would require?
If LLVM has a SPIRV backend, probably very little. For a proof of concept, a bachelor CS thesis would probably do.
Clang already has a CUDA parser, and all the code to lower CUDA specific constructs to LLVM-IR, some of which are specific for the PTX backend. If you try to compile CUDA code for a different target, like SPIRV, you'll probably get some errors saying that some of the LLVM-IR instructions generated by clang are not available in that backend, and you'll need to generate the proper SPIRV calls in clang instead.
Its probably a great beginner task to get started with clang and LLVM. You don't need to worry about the C++ frontend side of things because that's already done, and can focus on understanding the LLVM-IR and how to emit it from clang when you already have a proper AST.
Late response I know, but I would say anyone who needs that feature could learn to do it, at least if they are on Hacker News. Maybe bystander isn't the most accurate term, but certainly anyone with criticism could take the gauntlet.
LLVM is very well documented and so are these standards. The open source community is also huge and full of talented contributors and more are always welcome to join. I think there's a reason why Linux and GitHub exist.
So in short, if it's a question of motivation and it's something you need, then become motivated to make it happen. That's more likely to happen then convincing a company to invest in supporting a competitor.
CUDA appears to have come out well before even OpenCL. I don't see why there would be expectation that nVidia would design their framework to work on a competitors product.
ATI came out with CTM, which was just an assembler. CUDA was released a month or so after that. It was a full C compiler and already had a pretty large set of examples and library functions.
I downloaded CUDA about the day it was released, and used it for real some months later when I bought a 8600 GT GPU.
To call CUDA a response to CTM is too much praise for Nvidia, because it suggests that their response included cobbling a compiler and SDK in just a month. :-)
Not on ARM, or POWER, you can't. Why you'd want to run it on AMD, I don't understand. I don't know what fraction of peak BLIS and OpenBLAS get, but it will be high.
I believe there's work to be done for each new CPU architecture (Broadwell, Skylake (AVX-512), Cascade Lake, let alone ARM or other architectures). The code needs to be updated for things like L1 cache size, number of registers per core, and number of adders per core. So there will likely continue to be frequent work on BLAS implementations until there's some very smart optimizing and profiling compiler (which is related to what ATLAS does I think).
> It feels as if the point that I'm trying to make is that mindful archiving is a better solution than to just 'keep all the things'
On the topic of plain text things (such as text messages) - how much data are you actually hoarding?
Let's say you type 100 words per minute for the next 40 years (and each word is 10 bytes). No sleep, no breaks, just 40 years of typing. Congratulations, you just produced 21GB of data. This fits on an SD card (<$30) or in the cheapest tier of cloud backup like Dropbox or Google Drive.
You can search your 40 years of typing in well under a minute. If you remember the year you typed in, you can grep the data from that year in under a second.
I don't like the term "hoarding" for this. Hoarding has a negative connotation. Storage of plaintext is so incredibly cheap (and search so fast) that I feel that option value of retaining the text is almost always greater than the miniscule cost of storage and slower retrieval.
I don't think are any valid analogies between storing physical items and digital items, as digital storage and search is orders of magnitude cheaper. Consider the same experiment where one writes with pen and paper for 40 years, and then wishes to search for the name "George".
Making a decision of what to keep must be more expensive and time-consuming than just keeping everything.
There is no way to move messages from one iOS device to another (such as a new phone). My girlfriend recently got a new iPhone and wanted to transfer our Signal message history from her old iPhone onto the new one. She said it wasn't possible, and then I spent an hour or two reading about it figuring there must be some hacky awful way to accomplish it. I couldn't find one. This has been an open issue for years [0][1].
Android has an inconvenient backup flow (that involves randomly generated 30 digit PIN and manual transfer of file), but that's infinitely better than the total lack of options on iOS. I do wish Android (and iOS) had a method to download all message history to decrypted plaintext (or JSON) for use with other apps. If I own my data, decrypting it should be my choice.
I regret recommending to my girlfriend that we use Signal, and won't recommend Signal to more people after this.
Agreed! I'm on an eastern edge of a timezone and DST ending moves sunset forward from 6PM to 5PM (and up to around 4:20PM during winter solstice).
This feels like doubling down on how much winter sucks: not only is it cold, but it's now not possible for me to exercise outside in daylight after work
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then <10 people. (I'm surprised to see anything from my first professional software experience on top of HN!)
My recollection of events (of 8 years ago):
The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebase. Eventually, it became painful to debug or add features to this endpoint because no one was particularly proficient in Erlang. Ankur (author of the post, intern) then rewrote it in Python.
I wouldn't read this as a negative about Erlang or a positive article about Python. I'd instead read it as "use a language that makes sense for your organization and already existing codebase".
From the company's perspective, you'd need at least 2 people doing that, preferably everybody. Bus factor of 1 isn't great, and when the rest of the team already knows Python, the benefits of switching to a language everyone knows is huge.
You're also presupposing Python is inferior to Erlang, which I'm not really going to argue about here, but I think we can all agree that Python isn't so bad that the decision to continue to use Python substantially and negatively impacted the org's ability to succeed.
Thanks for this comment, gives context and explains "why we switched from X to Y", answer: I did not know X, or it didn't make sense at the time. It does not mean X is bad, or Y > X (as usually suggested in this kind of articles)
In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit.
If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care.
Some dev: "Hey, I noticed one of our more complex API endpoints had some pretty bad response latency, so I dug into it a bit. It turns out our PHP/Symfony/Doctrine stack was generating over a hundred SQL queries, all of which were being performed sequentially because we don't have a good per-request concurrency story in this tech stack. So I wrote an alternate implementation in Clojure which has a great concurrency story and cut the latency by 75%."
Another developer: "...our stack was generating over a hundred SQL queries, all of which were being performed sequentially because we don't have a good per-request concurrency story in this tech stack. I just bypassed the ORM and wrote a slightly more complex SQL query, so that there is no more N+1 query problem in the backend. The latency of this end point was cut by several orders of magnitude, and our database is not overloaded by parallel inefficient queries, run by clients with 'great concurrency stories'."
Or, "here's a completely supported not-well-enough-known ORM feature that does that, that I learned about when it looked like I wasn't doing any work".
From a technical perspective, bypassing the ORM is a great solution (and if you can get the number of queries down to one, there’s no longer any need for concurrency).
Unfortunately, politically, the kind of shop which fires a dev for choosing another platform is unlikely to approve a PR which bypasses the ORM (maybe also a fireable offense!)
A dev ran up against the limitations of one platform and solved the problem by choosing a platform which didn't have those limitations. And management responded by banning the new platform.
How long do you think that dev is going to stick around in an environment like that?
Ultimately this comes down to what sort of environment you want to foster. One approach leads to an environment where devs have lots of freedom, and that creates certain problems. The other approach eventually leads to an environment where even the choice of editor / IDE is dictated, and that creates a different set of problems.
I'd favor attracting a bunch of smart folks and give them as much freedom as possible. I'd much rather deal with the kind of problems which that sort of environment creates.
I am not sure why you think it is "management responded" -- it is all about other people on the team.
Right now, I am responsible for maintaining one of our internal services. If someone tries to rewrite part of it in Clojure without extensive internal discussion first, I'll do all I can to stop it (and I am not "management" at all). And most people on the team will agree with me.
If the original dev would not want to stick around after that, good for them. If they do not care about teammates at all, they would likely be happier working alone anyway.
After all, single-handedly moving to a new technology and then forcing everyone else on the team to support it is impolite and annoying. Clojure is nice, but I don't want to be forced to learn it because the server went down on my shift.
(this is different if the service does not need to be up all the time, or the company is very small. But if you are talking about API endpoint being overloaded, the chances are, neither of this is true)
“If someone tries to rewrite part of it in Clojure without extensive internal discussion first”
“single-handedly moving to a new technology and then forcing everyone else on the team to support it is impolite and annoying”
The dev you’re describing has indeed made some bad choices and I wouldn’t want to work with that guy either.
What I had in mind was more along the lines of “check out this thing I made, what do you think?”
Totally ok responses would include: “let’s just bypass the ORM here instead”, “let’s divert 5% of traffic to it and see what happens”, “this stays a prototype until you reach a bus factor of 2”, etc.
A lot of these objections depend on context, though. The culture at large organisations taking on large and/or long-running projects is necessarily different to the culture at small organisations that can't afford the same overheads and wouldn't enjoy the advantages of greater redundancy or interchangeability anyway.
The problem here is not understanding your database not about making a system in an unsupported and probably undeployable thing to prove how clever you are...
I see this a lot and I just don't get it. Is a mechanic who uses air tools trying to "prove how clever he is"?
Knowing more than one tool allows you to choose the right tool for the job. Assuming arrogance and a motive of "proving cleverness" sounds like a great way to pick a fight.
Air tools are fine -- after the car left mechanic's garage, I cannot tell if air, electric or manual tools are used.
But if I give my car to mechanic for carb cleaning and tune-up, and get it back with fuel injection system and explanation "it is better anyway", I would be very unhappy.
Yeah, introducing a new ecosystem to mask bad DB design or bad queries because she is lacking basic SQL and relational foundations is how I envision the typical 10x programmer.
Maybe not. But if the alternative was spend one tenth of the time to cut the redundant sql queries down a bit and cut latency 50% - leaving a codebase that anyone on the team could further develop and debug... Then "that guy" might stil be in the wrong...
Language diversity is a pragmatic balance. Sometimes a language offers superior abstraction or some guarantees that eliminate a whole host of bugs and manual effort.
It’s always worth trying a hypothesis in a small spike and reliably proving whether it will scale to the rest of the org and the impact will be worth the effort.
But you’re right, there should be one official supported way of doing some kind of thing at a company.
I think of it as a trade-off between the tool perfectly designed for the job and the tool that can be used for the job of which I'm already an expert user.
As an example, my current team's codebase is Python and C++. When we need to do some basic Linux scripting (check if this file exists, if not send an error email), the two prime candidates are Bash and Python. Bash might be exactly designed for this type of thing, but a lot of the team would need to Google stuff like "bash logical and of two booleans" for Bash where they already know the Python syntax. My current rule of thumb here is "<10 lines of code: use Bash. else use Python". More generally, I often try to err on the side of using the tool I know than the unknown tool that might be perfect for the problem.
If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care.
What if it has the potential to be a much better tool for the job than the mainstream options, and your developer thinks it's worth trying it to find out?
I've seen this situation with adopting a relatively unusual language for a task that needed particularly high reliability. Yes, it was a concern that only one person currently working in the organisation knew much about it and that it might be harder to hire help if more developers were required later. On the other hand, that software was developed faster than the similar system it was due to supersede, and it had a much lower rate of reported bugs once deployed.
Of course you don't want to hire people who intend to pad their resumes with extra buzzwords on your dollar when it has no business benefit, but equally, if you never use tools that aren't chosen from among a small set of mainstream options, you'll never outperform what you can do with mainstream tools.
Software development is much more than just programming languages, I have seen teams outperform with lousy languages thanks to a great team spirit and understanding of customer needs.
I guess my answer would be that this is the kind of decision that requires being able to see the big picture. Is an individual developer in a position to weigh future recruitment challenges?
My remark about firing a person merely wanting to write something in a different language was off base and end up derailing the discussion. But the point I should have made, and stick by, is that this decision is properly made at either the company wide level, or for large companies at the level several rungs up the ladder. It isn't at all, like someone suggested above, equivalent to picking a personal IDE.
Is an individual developer in a position to weigh future recruitment challenges?
Maybe, particularly if it's a smaller organisation.
In any case, it's obviously a management decision at some point, as all things are. However, it seems quite reasonable for me for a developer to advocate using a more suitable tool even if it's not an existing choice/standard within the organisation, and if they make a good case, it seems quite reasonable to me that management might then back them despite the downsides if the upsides appear greater.
Fair. That part was over the top. But I do think employees pushing their own intellectual passions or resume building pursuits over the interests of their employer are pernicious.
If it’s out of ignorance, then sure by all means educate.
It's a two way street. Employers always want the most up to date trendy frameworks on their employees CV's. I imagine someone that has been working on a legacy VB6 app for the last few years will struggle to get his CV looked at.
Also, I worked for many shops that had a two language policy, one for development speed and one for performance.
For example, PHP and C or something.
They had many PHP devs and a few C devs and would write anything new in PHP and then later replace the few performance critical parts with C implementations.
I thought about doing this with JavaScript and Rust in my projects, but somehow I never got to the point that JavaScript became the bottle-neck.
My company is an example of this, and in a way that is quite different from that laid out in the article. We actually began with a Python implementation for our integration / API server. But this was well before asyncio and eventlet and kestral. It didn't scale well, and we quickly outgrew it.
We implemented its replacement in Elixir, a solution we are still running. It is written by a developer we still have, is well organized, follows proper functional paradigms, and fully leverages OTP/Genserver. It is resilient, and so far as the one two developers we have working in it at present, easy to maintain. We love it.
But we also are switching back to Python. The reason is simple: We only have two Elixir developers (really only 1.5), and we have far more work than they can complete. And when something breaks (usually because something changed in the various systems being integrated), we have one guy who can fix it, and get our production queues flowing again.
We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. And now that we have asyncio/eventlet/etc., the landscape has drastically changed. In Python, the various teams can create their own worker modules, and do so more efficiently because they know their own workloads far better.
Language diversity IS a problem when it impedes development and puts production at risk.
That's the 0.5 Elixir developer. Let's face it: It's easy to become a poor Elixir developer, but those capable of becoming a good Elixir developer such that it's worth the cost of effort to train them, are uncommon.
As the CIO, where the buck stops, I learned Elixir well enough to write my own Genserver-like implementation from scratch, and thoroughly enjoyed it. I wanted to be able to understand the code base. But I am still a far better Python developer than I will ever be an Elixir developer. It's all a question of time utilization.
Due to the modular nature of our integration, it's relatively easy to move from one platform to the other, one module-at-a-time. And in the end, the cost of getting a new Python-based platform up-and-running far outweighed the cost of trying to retrain Python devs.
We have three approved languages - C#, JavaScript and Python.
Of course C# you get all of the advantages of statically typed languages, so for major programs where you wil have multiple developers, it’s the go to language. But for smaller scripts like event based lambdas and scripting type scenarios, C# is overkill. Besides, each piece of AWS functionality is in its own NuGet package as opposed to one package for everything for JavaScript (Node) and Python.
JavaScript - our product is web based. Every developer is expected to know JS. So if someone decides to do a simple Microservice or lambda in C# or JS, it’s okay. Whichever they feel like doing, it’s okay.
We have another team that does a lot of ETL type processing. I doubt that many people would argue that JS is a better language for it than Python. If you are on that team and need to write something, you can choose whichever of the three languages you wish.
> In general language diversity at a company is a big negative
I agree. It really increases the difficulty of understanding the whole system. But it's a negative that has to be considered alongside potential benefits.
> If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy.
I get what you're saying; resume-driven development can ruin your systems. But at some point between "we wrote this new banking system in COBOL" and "every developer who knows COBOL and could maintain our old system is now dead", there needs to be an accepted way to experiment.
Depends. If it's a internal, innersourced, tool for everyone. Have at it, use another language. If it's my critical application, explain why we use only one language for it and don't fire them.
I think Facebook chat had a very similar experience. The first version was written by someone who liked Erlang. Later on, when some performance issues came up (probably related to GC), no one knew Erlang, and all the high performance backend code in the company was in C++. So it made sense to rewrite the thing.
And I think I had read that Whatsapp used Erlang because Facebook Chat was using Erlang and they thought Facebook knew what they were doing and decided to use the same tech. What a twist
Where did you read that? I believe Whatsapp used erlang because they leveraged ejabberd [0] for XMPP. Wouldn't surprise me if this is why FB originally used Erlang for the chat servers too.
[0] https://en.wikipedia.org/wiki/Ejabberd
Your recollection is valuable, and thank you - but contra a large chunk of the rest of this thread, the article was very clear to me that it was "our erlang was crap erlang and we didn't know how to make it not crap so we switched" which is totally reasonable and didn't seem like a negative towards erlang at all. I've supported rewrites from a language I liked more to a language I liked less for similar reasons, and what Ankur did seems like an entirely sane decision.
But even if I didn't need the clarification, the additional data was awesome, so my thank you remain sincere :)
So, in a Python-only org, someone with no Erlang experience decided to ship his first ever server to production, thinking Erlang would be a magic bullet to “scalability issues”. Obviously, there were maintainability issues and the org, blaming the language, decided to switch back to python.
To me, the fact that a novice was able to deploy production code that went on unmaintained for months, running a crucial part of the operation, speaks positively about Erlang.
I didn't see anywhere in the article blaming the language - can you find a quote to support your assertion?
From the article: "After two years of iteration, the code has become difficult to maintain. No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems. So, we decided to rewrite it in Python, the de-facto language at Mixpanel."
Yeah; it’s actually pretty easy work. Interns have a lot of uncommitted time, and they’re going to leave soon so you don’t want to integrate them into the team too much. It’s also way easier to build to a well-defined spec (which an in-production endpoint would likely have).
So you let them rewrite something that already works. If what they build is good, you‘ve just knocked out a good chunk of technical debt and found someone you probably want to hire. If not, they don’t get an offer. Either way you probably didn’t pay them much to begin with so there’s a lot of upside and not much downside.
The question isn't whether or not the work is easy for the intern, it's whether or not it's appropriate. And this cuts both ways: a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way. If it's in fact an unpaid internship, then they're straight up in violation of the Fair Labor Standards Act.
And, of course, a company that puts this kind of work on the back of a temporary worker is not treating its own codebase with the respect it deserves. This is rolling the dice with your expertise store -- you have to hope they did it well, because they aren't going to be around to answer questions if they didn't.
If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test.
The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or business requirements. You build this, and if we like it, we use it and may give you a job offer.
Unless given other information, you can assume the company complied with the law with respect to paying the intern and the intern accepted the internship offer, and it sounds like he got a great experience out of it.
> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test.
Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much they are supervised by the people who are supposed to be teaching them.
Handing out throwaway projects like you posit is an easy trip to a class action suit.
I think you may be mistaken about this. If it helps any, I wasn't one of your downvoters; I upvote comments that may be incorrect but lead to an interesting and informative discussion.
I live with an HR exec and read some of this thread to her while she was cutting rhubarb for something she's baking.
She said (paraphrased), "Are you kidding? This is a perfect project for a summer intern. They won't have to take three months to get up to speed with all your internal systems, and of course there is educational value - they will get to see how some talented developers tackled the problem in one language while they translate it to another."
There is immense value to the intern just for being around; the biggest things software dev interns learn isn’t how to code: it’s how to code as part of a team. So check-ins, CI/CD, automated testing, daily meeting cadence, architecture discussions, backlog grooming, code reviews... all things they don’t teach you in school, and all things that you need to know to develop software in the real world.
Most kids right out of school are honestly pretty decent coders. The internship is more about the professional skills than the technical ones.
> a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way
> Handing out throwaway projects like you posit is an easy trip to a class action suit.
So if an intern shouldn't do work on the core product but also shouldn't do throwaway projects, what do you suggest an intern should do?
What do you consider an "underpaid" intern? Would you consider 75% salary of campus new hire as underpaid?
Most real internships pay under market rate, but not insanely low. A few years back, going rate for an undergrad CS internship was ~$25/hr or so.
If you’re recruiting on campus, you’re competing with other companies for the most promising candidates. If you come in with an unpaid internship, you’re going to get the leftovers.
Even ten years ago, I doubt it was an unpaid internship. They weren’t common in tech going all the way back to dotcom. And if it was a paid internship, labor law doesn’t care. As far as it’s concerned that’s a job like any other.
As far as I know, unpaid internships have not really been a thing in software development.
I was an intern back in 1995 and they paid us $10/hour ($16.88 inflation adjusted) and they provided housing on a college dorm. To put that in perspective, the $650 I made after taxes every two weeks was the cost of tuition every quarter at the state school I attended. I made enough that summer to cover my entire senior year including books.
No idea, but that seems like a reasonable choice in that case.
Yes the project was impactful, but there already was a reference implementation with a reference performance target. Worst case scenario, they would have been back to using the old implementation.
Depends on the intern, and the component. If the intern is talented, the component is well-tested and the mentor or supervisor can do an effective code-review - then why not?
Deep learning mostly uses matrices with largest dimension <1000. The size of the matrix directly corresponds to the number of input and output units to to a fully connected layer.
Even a 2000x2000 matrix is relatively small as far as non O(N^3) matrix multiplication algorithms go. The faster asymptotic algorithms have larger fixed costs and do not map as nicely to current CPU/GPU architectures. Additionally, the people capable of writing high performance matrix multiplication mostly haven't spent time on the non-N^3 algorithms. I believe every common implementation (MKL, cuBLAS, Eigen, and various other BLAS's) all use the N^3 algorithm with optimizations more focused on computer architecture (cache and register blocking, limiting instruction dependencies, SIMD) than on algorithmic cleverness.
The only attempt that I know of to use a non-N^3 algorithm for practical matrix multiplication is this 2016 paper[0] called Strassens' reloaded. Figure 5 shows that their implementation of Strassen's outperforms MKL on a single core on about a (2K, 2K, 2K) matrix multiplication problem (look at upper right part of figure). However, you're rarely multiplying on a single core. Figure 6 shows that for a 10 core system, Strassen's becomes marginally faster with square matrices of size 4K, and only becomes significantly faster at size 8K. Although these results are super cool in my opinion, they're mostly not applicable to deep learning in it's current incarnation.
Finally, Strassen's algorithm is one of the simplest non-N^3 matmul algorithms (known since 1969, complexity O(n^2.8)) and I believe it has much lower fixed costs than something more recent that has complexity more like O(n^2.37).
Thanks for the links! I had never actually seen it quantified for the size matrix you needed. Just "large" which is always relative. :)
And I also hadn't looked closely enough to see if amount of training data influenced matrix size. Makes sense that it would only influence a single dimension.
The typical neural net matrix multiplication is N_EXAMPLES X N_FEATURES_IN multiplied with N_FEATURES_IN X N_FEATURES_OUT.
The output feature count is completely independent of the data size, and input feature count is only dependent on the dimensionality of the data (not the number of points), and that's only in the first layer of the network.
Even with datasets with huge number of examples, the net usually only trains on a small "minibatch" of examples at a time, typically somewhere between 16 and 1024. This minibatch size is the algorithmic N_EXAMPLES. Given these numbers, the typical neural net matrix multiplication is probably something like (32, 256) x (256, 128). This is not nearly large enough for non-N^3 tmatmul algorithms o accelerate things.
Chicago definitely does not "absolutely require" a car. I've lived here for a few years without one, and 80-90% of my friends in the city don't own one.
The trains don't go everywhere, but train + bus + bike share + Lyft make it very easy (and probably more convenient) to not own a car.
Trolling, flicking - I never heard anyone say these, but had heard they were used in the past. Along those lines, flaming or flaming out was used for failing out or needing to take terms off.
A few people still did 3AM Tommy's. Negative time Tommy's was a significant event in at least a few houses.
The Ride tradition was definitely around, with the only sanctioned playing on mornings of finals
I never heard anyone say finesse, brute force, or ignorance