51–60 of 107 posts
Earlier quoted context omitted.
The difference might be people are actually held accountable for the results.
Why is that better if in aggregate, the people who can be held accountable are worse anyway? We are killing thousands on the road to be sure we can blame a driver instead of a computer as one example.
Earlier quoted context omitted.
> It's not a coincidence that I train a model on healthcare regulations and it answers a question about healthcare regulations If you train a model on only healthcare regulations it wont answer questions about healthcare regulation, it will produce text that looks like healthcare regulations.
And that's not a coincidence. That's not what the word "coincidence" means. It's a complete misunderstanding of how these tools works.
> I think it comes down to how familiar you are with the domain and its constraints. When I watch a medical drama, I have no idea if they're using realistic language. It sounds good, but real doctors probably cringe at the inaccuracies. By now, numerous notable programmers have reported positive experiences with all forms of AI-assisted coding, which this conclusion arrogantly fails to account for.
I wanted to check the prime factors of 1966 the other day so I googled it and it led me to https://brightchamps.com/en-us/math/numbers/factors-of-1966 , a site that seems focussed on number facts. It confidently states that prime factors of 1966 are 2, 3, 11, and 17. For fun I tried to multiply these numbers back in my head and concluded there's no way that 6 * 187 could reach 1966. That's when I realized this site w…
> A factor of 1966 is a number that divides the number without remainder.
>The factors of 1966 are 1, 2, 3, 6, 11, 17, 22, 33, 34, 51, 66, 102, 187, 374, 589, 1178, 1966.
If I google for the factors of 1966 the Google AI gives the same wrong factors.
https://chatgpt.com/share/68cffaab-4c14-8006-89a2-1818172e4d... Tried on ChatGPT, seems fine.
https://chatgpt.com/s/t_68cffbc05ef48191996ffbaa3c6e55a7 same with non pro.
It's consistently missing `search` for all of us.
They are very good at some tasks and terrible at others. I use LLMs for language-related work (translations, grammatical explanations etc) and they are top notch in that as long as you do not ask for references to particular grammar rules. In that case they will invent non-existent references. They are also good for tutor personas: give me jj/git/emacs commands for this situation. But they are bad in other cases. I s…
Don't use a microwave to fry a steak then. This is an irritating post and I have plenty of skepticism towards AI. LLMs were always bad at this kind of task, simple to us humans as it may be. This post proves nothing that wasn't known for two years. However, I do superficially agree with some of the links at the end. LLMs as they have been so far are confirmation machines and it does take skill to use them effectively…
Except this microwave is advertised as also for steaks. And sometimes it works, and sometimes you cannot even warm milk in it. It's totally not reliable.
Once again an example of "anti-ai people are those who treat LLMs as oracles, not the pro-ai people."
Of course there is valuable knowledge in understanding limitations but that is not the approach the author is taking here, imo the author seems disingenuous.
sure, but when I expect this [1] from _any_ full time hire, my "expectations are too high from people" and "everybody has their strengths"
[1] find a list of valid html5 elements, find a list of TLDs, have an understanding of ccTLDs and gTLDs
uint16_t ea_indexed(void)
{
uint8_t post = *PC++;
uint16_t base, off = 0;
/* 1. pick base register */
static const uint16_t *const base_tbl[4] = { &X, &Y, &U, &S };
base = *base_tbl[(post >> 5) & 3];
/* 2. work out the effective address */
if ((post & 0x80) == 0) { /* 5-bit signed offset */
off = (int8_t)(post > 3;
} else if ((post & 0x60) == 0x20) { /* 8- or 16-bit offset */
if (post & 0x10) { /* 16-bit */
off = (int16_t)fetch_be16(PC);
PC += 2;
} else { /* 8-bit */
off = (int8_t)*PC++;
}
} else if ((post & 0x60) == 0x40) { /* auto inc/dec */
int8_t step = ((post & 0x0F) == 0x0) ? 1 :
((post & 0x0F) == 0x1) ? 2 :
((post & 0x0F) == 0x2) ? -1 :
((post & 0x0F) == 0x3) ? -2 : 0;
if (step > 0) base += step; /* post-increment */
off = step > 3) & 3;
if (acc == 0) off = A;
else if (acc == 1) off = B;
else if (acc == 2) off = (AFrom looking at Page 150 of https://colorcomputerarchive.com/repo/Documents/Books/Motoro... it looked pretty much perfect except for the accumulator addressing. That's impressive...
Then in another chat I asked it "give a technical description of how the 6809 indexed operands are decoded" and it just can't do it. It always gets the fundamentals wrong and makes pretty much everything up. Try it yourself, doesn't have to be Kimi most other AIs get it wrong too.
My assumption is that it's learned to how to represent it in code from reading emulator sources, but hasn't quite mapped it well enough to be able to explain it in English.. or something like that.*