462 karma · joined May 6, 2010
Cool project!
I don't think that necessarily negates any conclusions, but, it doesn't help the author's case.
1. Do piddly algorithm type stuff that I've done 1000x times and isn't complicated. (Could take or leave this, often more work than just doing it from scratch)
2. Pasting in gigantic error messages or log files to help diagnose what's going wrong. (HIGHLY recommend.)
3. Give it high level general requirements for a problem, and discuss POTENTIAL strategies instead of actually asking it to solve the problem. This usually allows me to dig down and come up with a good plan for whatever I'm doing quickly. (This is where real value is for me, personally.)
This allows me to quickly zero in on a solution, but more importantly, it helps me zero in strategically too with less trial and error. It let's me have an in-person whiteboard meeting (as I can paste images/text to discuss too) where I've got someone else to bounce ideas off of.
I love it.
I prefer forgiveness over permission ...
I think a consciousness with access to a stream of information tends to drown out the noise to see signal, so in those terms, being able to "experience" real-time climate data and "instinctively know" what variable is headed in what direction by filtering out the noise would come naturally.
So, personally, I think the answer is yes. :)
To elaborate a little more - when you think of a typical LLM the answer is definitely no. But, if an AGI is likely comprised of something akin to "many component LLMs", then one part might very well likely have no idea how the information it is receiving was actually determined.
Our brains have MANY substructures in between neuron -> "I", and I think we're going to start seeing/studying a lot of similarities with how our brains are structured at a higher level and where we get real value out of multiple LLM systems working in concert.
https://en.wikipedia.org/wiki/Kolmogorov_complexity
https://en.wikipedia.org/wiki/Solomonoff%27s_theory_of_induc...
https://en.wikipedia.org/wiki/Minimum_description_length
Seems like these could be related, going to dive into this more! :)
Kurt Godel (or maybe Douglas Hofstadter, rather) would raise an eyebrow. :)
After you fix a lock-related bug for example, how do you deal with an open tab running a different version of your code that is erroneously misusing a lock?
You need to account for that when you release new code, yeah? Rename the lock maybe? Some other logic?
At least the Sudafed has acetaminophen in it ...
Alas, I do not. :(
How are they supposed to deliberately train on synthetic data when they don't know whether it is (synthetic) or not?
Also, do you not feel that it is presumptuous to dismiss a body of work in a few sentences with a "seems fine to me"?
Maybe you should calm down.
I wonder how those charts compare with the rest of the world?
One affects the entire environment with air pollution, and the other affects a localized area by modifying terrain.
Is it really true on the internet though? omg.lol could presumably stay "small-appearing" and "quaint" and have millions of users. How could you really tell the difference?
If it were all indexed you could drill down and find people who share your interests, that doesn't necessarily ruin the website, yeah?
I really miss that feeling, it's a rarity nowadays.
That being said, after reading this stuff, I may start using it on my local branches to clean up multiple commits into one tidy one, but that's about it.
The architect wanted to break everything up into extremely small pieces, small enough pieces that many were dependent on each other for every single call. Think "a unified address service" to provide an physical address via an identifier for anything that had an address (customers, businesses, delivery locations, etc).
The problem was that it turns out when you're looking up a customer or business, you always need an address, so the customer service needed to hit the address service every time.
Disregarding the fact that this whole thing was a stupid design, the plan was that when you hit the customer api, the customer code would make internal http calls to the address service, etc.
I pointed out that this was a ton of unnecessary network overhead, when all of this information was sitting in a single database.
The whole team's argument was effectively - "it's 2015, computers and networks are fast now, we don't need to worry about efficiency, we'll just throw more hardware at it".
The whole thing ended up being scrapped, because it was crippled by performance issues. I ended up rewriting the whole thing as a "macroservice" which was 60000% faster for some particularly critical backend processes.
Anyway ... I think that mentality is prevalent in a lot of people involved in technology creation, technology has improved so much, moore's law etc etc etc.
So let's not worry about how much memory this thing takes, or how much disk space this uses, or how much processing power this takes, or how many network calls. Don't worry about optimization, it's no big deal, look at how fast everything is now.