For fast updates / high frame rate, especially also smooth fade from previous to next page, those displays only do black/white.
They can typically modulate about 14 levels of gray in-between but reliably (without really bad ghosting, due to strong temperature sensitivity of the pixel's transition response and the display being static so all gray has to be done by carefully interrupting a transition part way through) only from a nice flash-to-black -> flash-to-white -> fade-to-target-greyscale (sometimes one or two alternating full contrast flashes prepended to more intensely equalize the pixels/erase ghosting, but should only be needed every couple dozen page flips in grayscale mode).
I think the nice b/w no-flicker fade transitions chop the transitioning of all changing pixels into small burst/chunks and interleave/alternate the chunks of white-to-black with the chunks of black-to-white, so it's perceptually simultaneous.
Or it's actually pulling off some kind of tri-state driving leaving unchanging pixels alone and pulling those that change to either plus or minus polarity depending on what transition direction they are supposed to go in...
Sadly IIRC all quite proprietary-gated :(
What that means for djvu is that at least for text-only content on those readers that manage the 300 dpi "threshold" you'd just rasterize to pure 300dpi black/white (1 bit per pixel) comparable to a 300dpi "don't skimp on toner but don't you dare take half a second longer than you must in order to make the text crisp enough for $reader to have no good reason to whine about it being not crisp enough" laser printer job.
Djvu is particularly for displays with more than about 5bits of grayscale as well as for lossy compression of grayscale/color scans. And maybe also some efficiency gains on 1-bit-per-pixel quantized scans, but those aren't usually the target content for these readers, IMO.
Might want to try for them, though!
Hm.. I just tried on my Google pixel 7 Pro (obviously very different display - OLED) - and certainly seems like the result of a test conversion pdf2djvu should be at home on an eink screen. Not sure if there's a simple way to test on the only eink I have to hand; a Remarkable.
Fwiw google Gemini cane up with the following to convert pdfs on device in termux after some prodding (koreader can display DjVu):
You'll need access to storage:
termux-setup-storage
Then pipe/paste this to a script:
(Sorry for the verbose slop)
You can just render to the 1bpp text/4bpp images monochrome 300dpi target; perhaps some tone mapping due to the limited contrast ratio of the eink vs. your OLED should be done at rasterization time.
Then just map the resulting 16 brightness levels according to the contrast ratios/progression they have on your eink. Use phone camera and adjust whole image contrast/brightness/black-intensity sliders holding them side by side until the grayscale matches.
Then just pick pixel RGBs from a gray-bars test image you have opened on the remarkable before you took the picture with your pixel 7 pro. Might not easily be done on the phone but can let a python using AI grab those for you. (If it's wrong it'll be obvious or so harmless it doesn't matter anyways.)
Then you take that rasterized-to-1/4-bpp-djvu apply the color palette you just built yourself, and zoom to 300dpi.
Other than the screen backlight which you've taken care of when you held both devices side-by-side and played with the sliders, there's no substantial difference left.
Should be pretty representative.
Don't look with too much of a magnifying glass though the phone doesn't have exactly the same dpi so there are resampling artifacts your eyes resolve if you're too close to it.
I think it's more about guaranteeing the whole sequence, rather than who goes first?
At least for two players, if you use a two sided die (a coin), have player one win ties on ones, player two win ties of twos - and otherwise highest wins - then that is trivially done?
I would have to do a little more math to see if it generalizes by induction... I'm not sure you would get a guaranteed sequence - but I think at least guaranteed fair winner works by just increasing the die (7, 9 and 11 would be tricky because if physics again... I suppose. Unless you just ignore highest tie for missing player (reroll on extremely rare 9 9s on a d10 for nine players)?
Ed: I suppose we break smaller ties, by letting closest and highest win (for ten players, 4, 6 and 7 roll 5 - 6 is closest and over/highest of the close players to 5, then come 7?)
Ed2: nevermind we end up biased towards "high" players that often win on "high" ties, like 5 or 6.
> I think it's more about guaranteeing the whole sequence, rather than who goes first?
What do you mean? The question is who goes first.
As a matter of practice, what happens in a board game is that everyone takes a position around the board before choosing who goes first. If turns proceed in a fixed sequence, that position will determine the sequence. If the order of turns is specified by the game (for example, many feature a turn order track), then that order will be used. You never need to decide on a sequence longer than one person.
But even if that wasn't the case, the article couldn't be more explicit:
> Eric Harshbarger was asked by a board game designer if he could come up with dice that would determine who goes first — without the possibility of a tie.
> The idea was simple: settle the first turn quickly and get on with the game.
This from the article appears somewhat questionable:
>> “It was a question that did not have an obvious answer and that's something that a mathematician will often jump at.”
The problem they're bragging about solving is using dice to quickly and unambiguously select one of five options with equal probability.
The obvious answer should be that you roll a single 10- or 20-sided die, divide by 2 or 4, round up, and there you have it.
From a site selling the dice: "With these dice all players will have an equal chance of ranking first, second, third and fourth. And only one roll is required."
Wikipedia distinguishes between "go first fair" and "permutation fair". I believe Harshbarger wanted to find permutation fair dice.
Pretty sure he means this:
- assume heads beats tails
- if both players get opposite results (HT, TH) then the winner is obvious
- if both players get heads, player A is the winner
- if both players get tails, player B is the winner.
Except that as a sibling comment mentions; that generalizes to any size of group - for six players you could roll one d6, and have "that" player go first.
But apparently the constraints are: every player rolls one die once.
> But apparently the constraints are: every player rolls one die once.
That doesn't eliminate the natural scheme, it just adds some useless die rolls. You can have each of two players flip a coin and choose player A when player A flips heads or player B when player A flips tails.
Useless depends on context here; I believe the idea is that each player gets a feeling of agency (they go in the order dictated by "their" luck, not leaving the decision to someone elses roll).
The most pragmatic would probably be to shuffle N cards from ace(one) through N - and let everyone draw).
If not, someone is a native in LLMese. Conveys little about what it actually is, or connected to how Delta works and is mostly talking about some abstract metaphoric relation. I remember some article on how LLMs throw in identifiers without much understanding of the indetified, other than its similiarity to another thing in text (methaphoric speech).
Interesting. This and the other posts I've seen about Delta seems to exist in that liminal space, were it's difficult to tell if the author has had a brilliant insight, that they struggle to convey to anyone who's not yet had the same insight; or if they've simply gone slightly mad.
It's a similar sense I get with reading Nelson (after being able to think about his ideas for a while, I'm quite certain it was mostly genius and only a little bit of lunacy).
It remains to see how Delta will turn out.
On a side-note; my initial reaction to the headline was; no. Xanadu wasn't missing agents.
I do think I see where the author is going, though; and I think I agree that agents might be a new tool that might facilitate some hypertext ideas. Not Xanadu perhaps. But some other, more pragmatic and less magic place - but a place that is a little more magical than where we are now.
And it intersects a bit with an experiment we started at work; migrating our modest web site from WordPress to a static site combining 11ty (https://11ty.dev) (we already lean heavily on typescript for our application development) and visual studio code with frontmatter cms (https://frontmatter.codes) - and AI/LLMs.
AI helps with making a static page version of our site, and adopting to 11ty.
The idea is that with trivial push-to-deploy setup, our business people, with the help of AI in vs code, will be able to work directly with 11ty and git to make changes, do reviews and publish changes.
A hill that would probably have been too steep for them to climb just six months ago.
So in reference to the theme of realizing a better hypertext system with the help of AI, we're sort of doing the same thing, it turns out: mix solid, boring tools (static site gen, typescript, editor, version control, CI, static hosting) and some AI - to hopefully allow more users leverage both tooling and AI in an empowering way.
We've just stated the experiment - we may yet fly too close to the sun, and end up falling back to a traditional CMS.
I think not are the same the only thing that differentiates them is adoption. If people show interest in the thing you are a genius if they don't you are mad/crazy.
The madman and the genius are similar in that they disagree with the world at large/prevailing wisdom. Where they differ is that the madman loses the fight while the genius (eventually) wins.
One reason I have some hope for this approach is that we start by removing complexity by going to a static web site first.
We remove WordPress, database, configuration, templates - a lot of cruft.
Then we can add it back as needed for keeping edits and publishing simple. It might turn out we hardly need anything from 11ty, thanks to AI making editing more automatic.
I think (the collective) we, are (mostly by accident) building systems that are at least one dimension or level of higher abstraction than before AI.
Unfortunately with AI, higher abstraction doesn't automatically mean less complexity, or better managed complexity.
I think 95% of systems being built now with Al and on top of - or including Al - will turn out to be highly complected mountains of madness.
Complexity in itself is not an interesting measure but it's a proxy for an interesting measure: time and cost to build/maintain.
A more complicated program that is built and maintained with LLM assistance is cheaper and faster to build and fix than even a less complicated program built without. It's even the same without LLMs: once React achieved critical density and "won" the JS framework wars, building React apps became cheaper and faster even than building plain HTML/JS apps.
I strongly disagree. Incidental complexity is the enemy good emergent properties of a system; security, auditability, stability, testability, maintainability...
See:
https://zodb.org
https://gemtalksystems.com/products/gs64/
reply