to some degree this alphabet soup brands are a direct consequence of well intended but not well working Amazon policies :/
Not only did Amazone more or less force all the OEM/White label seller to pretend to be "proper brands" instead of just being honest, it also made them realize that they can use this to doge all responsibility and most reviews and has not done anything (working) to fix that situation (or other problematic situations on it's side). To make that worse even if you search for "<brand> <product>" the first results might be from random cheap copies of companies which branding is all just a hollow make pretend, further pushing off brand clones. Amazone really does a bunch of harm in not so obvious ways in addition to all the more obvious issues :/
--------
Some clarifications:
- I'm not speaking about brands which pretend to create their own product but sell OEM, I mean companies which very obviously sell OEM
- I also don't have an issue that when searching for "<brand> <product>" I also get off brand alternatives, I have an issue with this alternatives being multiple of the first search results in combination with the intentional UI design of all sellers "looking the same" (as in you have product images but no seller theming/branding on product pages), in combination with the oft not so grate product "sheet" etc. That lead to Amazon effectively deceiving people (especially older ones) into buying products they do not want to buy. (E.g. a cheaper but very unreliable clone of a product instead of the more expensive but for the customer very affordable original product, and yes, sometimes the clones are better then the original, most times not).
To add to this, this is probably due to Amazon Brand Registry which promotes products from brands with a trademarked name. The sellers only care about the brand so far as it's trademarkable. Mashing on the keyboard is the simplest and quickest way to make that happen.
I bought a unique product that didn't have any branding in the pictures, but when I got it, it had their brand on it. The seller said that is due to Amazon's branding policy. Stupid policy.
> but you can't find any meaningful review because they are white labels
Which is one of the reasons they exist. You fortunately for more commons stuff have the original manufacturer+product name which gets rebranded into alphabetsoup as soon as it get's popular. If you can figure out the original name, or if it's advertised as, you can maybe lookup some reviews. Otherwise: stay away, but normal consumers tend no to know that because "it's on amazon" (or equivalent).
When LLMs try to do the wrong thing, don't correct it with new instruction. Instead, edit your last prompt and give more details there.
LLM have limited context length, and they love stuck to their previous error.
Just edit the previous prompt. Don't let the failed attempt pollute your context.
> The article doesn't show any function lifetime annotations, only @safe and @unsafe.
It does, but it's under the "External Annotations" section:
// External annotations go in a header file
// @external: {
// strlen: [safe, (const char* str) -> owned]
// strcpy: [unsafe, (char* dest, const char* src) -> char*]
// strchr: [safe, (const char* str, int c) -> const char* where str: 'a, return: 'a]
//
// // Third-party libraries work the same way
// sqlite3_column_text: [safe, (sqlite3_stmt* stmt, int col) -> const char* where stmt: 'a, return: 'a]
// nlohmann::json::parse: [safe, (const string& s) -> owned json]
// }
> The where clause specifies lifetime relationships—like where stmt: 'a, return: 'a means the returned pointer lives as long as the statement handle. This lets the analyzer catch dangling pointers from external APIs.
The GitHub repo also has an annotations guide with some more info [0]. The general syntax appears to be:
// @lifetime: (parameters) -> return_type where constraints
> The frustration, for Hamkins, goes beyond mere incorrectness—it’s the nature of the interaction itself that proves problematic.
I would assume pairing LLMs with a formal proof system would help a lot. At the very least, the system can know what is incorrect, without lengthy debates, which frustrate him most.
This won't help the system discover or solve new math, but it make the experience far more endurable.
That itself may be tricky. Suppose you proof system tells that the proof is correct — how do you verify it is proof of the assertion you want, unless you have beforehand written the "test harness" by hand?
At least in programming, formally checking that the code does exactly what is required is orders of magnitude harder than simply writing code that compiles.
reply