> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…
StableCode
101–109 of 109 posts
Re: StableCode
#102> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…
The reason that people need to gather precise requirements that are precise is because the specifications -> product loop is long. Imprecision results in lots of wasted effort. If that loop is shortened drastically, then trying, checking and tweaking is suddenly a much more viable design method. That doesn’t require a precise set of requirements.
Re: StableCode
#103> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…
It’s about giving the domain experts who understand what the requirements should be a way to build something without having to have the domain knowledge of code.
Re: StableCode
#104Earlier quoted context omitted.
There's also just far more tokens to train on if you do multi-language. I'd guess only the most popular languages would even have enough training data to get a specialized version - but it would still be an interesting trade off for certain use cases. Being able to run a local code assistant on a typescript-only project for example, with a 32k context window would really come in handy for a lot of people. I don't kno…
Its worth noting that from what I can tell - A model well trained in most languages would be able to learn the niche ones much more easily. The vocab size of llama2 is 32,000. I guess I personally don't think that there's enough difference in programming languages to actually save any meaningful number of tokens considering the magnitude of the current vocab.
https://huggingface.co/mlc-ai/mlc-chat-Llama-2-7b-chat-hf-q4...
it looks like if you just limit it to English it'd cut the count almost by half - further limiting the vocab to a specific programming language could cut it down even more. Pure armchair theory-crafting on my part, no idea if limiting vocab is even a reasonable way to improve context handling. But it's an interesting idea - build on a base then specialize as needed and let the user swap out the LLM on an as-needed bases (or the front-end tool could simply detect the language of the project). 3B or smaller models with very long context which excel at one specific thing could be really useful (e.g. local code completer for English typescript projects)
Re: StableCode
#105If I’m reading this correctly this could be an open source model that may compete with the likes of copilot? That is something I’d be very interested in if they can get the compute requirements down to those of say a standard 13B model. Then I could fine tune (correct term?) it on my offline data and hook it into something like fauxpilot and my IDE. I had a look at some of the recent code models (wizardcoder,strider…
Re: StableCode
#106Earlier quoted context omitted.
in what world is a hashtable lookup worst case O(1)? Your own solution doesn't match your requirements. If you want amortized complexity then a simple vector suffices.
1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…
To be actually toxic for a moment, you do know that amortized and average are different right?
There is an easy solution to get O(1) for all operations too by allowing them to throw an exception: a simple array. There is no other O(1) solution for all operations that I am aware. In fact it is probably not too difficult to prove that such a solution does not exist.
Re: StableCode
#107> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…
You're missing the point: Natural language can be much a higher layer of abstraction than the programming languages we currently have. It's much faster to say "Add a button to download the output as a PDF" than write JS directly. You'd be surprised by what regular people can build when you give them the power to create software. Here are a bunch of apps created using my tool/GPT-4: https://showcase.picoapps.xyz Most…
Re: StableCode
#108Earlier quoted context omitted.
1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…
Average and big-O notation don't go together... Yes, it works 99% of the time, but parent explained to you why you won't get that 1% of the offers. That, plus taking offence by his comment, which makes you not pass behavioral part of the interview.
I'm okay not getting 1% of the offers. I'm not $100 bill so everyone likes me.
I appreciate an attempt to educate me though, I wanted to make clear that any discussion like that is useless without solution to a problem. Post your solution, we'll discuss downsides. You can see it from my side, and I have another one. The parent commenter ain't got no solution, but keeps insisting he can implement that easily with this and that...
Good luck passing interviews with that attitude...
Re: StableCode
#109Earlier quoted context omitted.
1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…
Pointing out a mistake is toxicity? Your ego is off the charts. Also, I gave you a solution that would probably be _better_ than yours in 99% of scenarios, a simple vector from any standard library, std::vector in C++, and Vec in Rust. This solution gives you O(1) worst case for peek, and amortized worst case O(1) for the other operations. To be actually toxic for a moment, you do know that amortized and average are…