One oddity of forms: the result of a form POST is a page that has a location (the URL) but that cannot loaded via that location. As far as I know, the fact that the page is a POST and not a GET is not stored anywhere visible to the user or to JS. And refresh works oddly.
If method=QUERY were added, there would be a new variety of this weirdness.
At least browsers wouldn't have to warn users that they'd be resubmitting data if they reload the page after submitting a query form, since query requests are intended to be idempotent
The qwen.ai webpage should learn to deliver plain HTML with its content instead of overcomplicated JavaScript and CSS to display obnoxious pulsating rectangles where the content ought to be but hasn’t managed to load.
I wonder whether those cards ran the model that wrote the nonsense about the forces involved.
Hint: when you have a piece of metal stuck with thermal goop to a lot of components, the force doesn’t “concentrate” on one of them. You need to detach it from each one with however much force is needed to detach it from that component.
The papers suggest a plausible mechanism by which lithium orotate could have an effect that would be not present with inorganic lithium salts.
IIRC the hypothesis is that lithium orotate does not fully dissociate in water and thus can cross the blood brain barrier much more easily than plain Li+, and then the cells in your brain can take up the lithium orotate, metabolize the orotate part, and make the free Li+ available.
Therapies targeting amyloid deposits has been tested extensively in actual humans, and it indeed removes amyloid deposits. The main problem is that none of the therapies in question usefully treat Alzheimer’s disease.
Sure, maybe an eventual useful Alzheimer’s therapy will remove amyloid deposits, and maybe it won’t, but it needs to actually treat or at least meaningfully slow the actual disease.
I can imagine it working with a needle shaped nozzle that inserts into a hole and extrudes filament as it withdraws back out. This is probably much more than a software change, though.
Old computers, before double-buffering and compositing, were fast. Single-digit millisecond latency from input to output was common.
Now it’s 30-ish years later and computers have not recovered the latency increase from compositing, double-buffering, and other attempts to make every frame perfect. If you are showing a frame on the screen that has failed to react to input that already occurred, especially more than about 20ms later, that frame is not perfect. It’s extra imperfect if the user cannot easily do what they’re trying to do while waiting for the computer to catch up with them.
But yes, most of the examples in the article are surely both imperfect in the sense the author meant and pointlessly slow, so there is no dichotomy :-/
It does seem like a KP-like algorithm ought to be able to optimize the break positions without extreme algorithmic difficulty aside from the inputs being considerably more complex than for Latin block print: the cost function for a proposed line is a straightforward [0] calculable function of the contents of the line, and I think one could make a dynamic programming algorithm that tracks, for each input position, the cost of the optimal layout of all text up to that position with a break at that position. This gives an algorithm that takes cubic time. (For input length n, you need to fill in n values in the table. Each value scans the entire table before that position and does a calculation with complexity linear in the proposed line length.)
As a practical matter, there’s an input length n and there is some upper bound B on a credible line length as measured in code points, so there are only at most n*B credible proposed lines to evaluate, which also limits the useful look back on the table to B positions, so I think the time complexity could be reduced to O(n*B^2) without making the results worse on reasonable inputs, and this is probably quite tolerable.
[0] Straightforward once you’ve implemented the whole Arabic rendering stack, anyway. I am certainly not qualified to calculate this function :)
> The relevant rule, W2 of UAX #9, reclassifies a digit as an ARABIC NUMBER if any of the previous strong characters in the paragraph were Arabic letters, and as a EUROPEAN NUMBER otherwise. Both render their internal digits left-to-right, which is correct: numbers everywhere on Earth are read most-significant-first.
Does the author mean most-significant-on-the-left? The statement as written is a statement about the order in which one reads or perhaps thinks the number, whereas I think the author is discussing how numbers, including collections of numbers delimited by hyphens and such, should be laid out on the page.
This is a thing I have wondered about. are arabic numbers little endian when embeded in arabic text? The text is read right to left. But the numbers are the same as we put them in our left to right text where they are big-endian(read big to small). so are numbers in original arabic little-endian? read small to large. with the interesting side effect that numbers are universal.
I think least significant first is the most natural order for written numbers (and it makes addition easier.)
I had always assumed that was what was intended with Arabic numbers, only silly Europeans made a mistake when they borrowed the positional system and forgot Arabic is written the other way. (Or perhaps intentionally avoided mirroring the digits for ease of communication?)
But the author of this article makes it sound like even in Arabic, numbers are read out loud most significant first.
I think he's talking about the rendering algorithm with regards to the stream of text. essentially saying rendering direction should follow reading convention.
on the other hand, in formal arabic, it's not unusual that numers are read in clusters from least significant to most significant (right to left). 1984 would be read : eighty four and nine hundred and a thousand. not sure if the author is aware of this
> rendering direction should follow reading convention.
What does that even mean in this context? In a strictly LTR language, sure, you read left-to-right and the glyphs are rendered left-to-right. But the whole discussion is about bidirectional text, where the text is rendered by a complex algorithm. What is the “rendering direction”?
I know just enough about some RTL languages to know that one can absolutely intersperse RTL text with, say, and English phrase, and you still read the first (leftmost in the group) English sound first and so on :)
if you write (with a pen) text with mixed arabic, numbers, english words. then somebody else gets to read it, he will read arabic from right to left, then when when he encouters a number or an english word, he will naturally jump to the first latin letter of the word and start reading left to right, then jump back to the beginning if the next arabic word and switch back to RTL. the alogorithm should copy that behaviour.
It’s not so brilliant when you have an array of size 2^n and you append and then pop off the end in a loop and each operation takes time proportional to the length of the vector.
Usually, dynamic arrays aim for amortized constant time for append and pop. This trick loses that property.
Restoring it only needs one additional bit of storage, however (whether the buffer is currently 2⌊n/2⌋ or 4⌊n/2⌋ elements in size), which we can probably squeeze in somewhere.
More disappointing is that libc still forces us to use the free(p) API, without a length argument, meaning we are still paying to store a(n approximation of) the length somewhere in the allocation metadata.
If method=QUERY were added, there would be a new variety of this weirdness.
reply