You’re right, this one is missing. Although I’m skeptical of the utility (and accuracy) of something as precise as “percentage of cloud cover,” compared to what is available in the app, namely “clear, cloudy, mostly sunny, etc.”
Is there a meaningful difference between 25% cloud cover and 35%? Or is it better to just give names to the “conditions” at buckets of 25%, 50%, 75%, etc?
How is that difference meaningful? What actions are you going to take differently at 95% cloud coverage vs 100%? I can't think of anything I'd do differently if I was expecting 100% cloud coverage tomorrow to wake up and find that it was actually at 95%.
Yeah, and I’d argue that if the difference is meaningful to you, then you probably want something more accurate than what a consumer-grade weather service can provide. So it would be borderline irresponsible of Apple to even give you the false confidence of some precise measurement of cloud cover.
This guys PR team has been obviously working overtime in the last few months to make him the new musk. I’m taking note of all the organizations being paid to exhaustingly fawn over the cool new kid of death technology
Ocean carriers already optimize and it’s odd to have the article suggest they don’t. The company Sofar Ocean (https://www.sofarocean.com/products/wayfinder) does it in a particularly interesting way and actually has people using it, rather than a theoretical analysis of a small number of voyages
Configuring netrw right and having my vimrc load a side pane with it on load, combined with configuring my tab key to cycle between windows... Perfect.
This is one of the better landing pages for a product I’ve seen, it’s so succinct. Nicely done. I’m going to actually evaluate your product today as a result
Conceptually, to the best of my understanding, nothing too serious; perhaps the inefficiency of processing a larger input than necessary?
Practically, a few things:
If you want to have your cake & eat it too, they recommend Enumerated Shapes[1] in their coremltools docs, where CoreML precompiles up to 128 (!) variants of input shapes, but again this is fairly limiting (1 tok, 2 tok, 3 tok... up to 128 token prompts.. maybe you enforce a minimum, say 80 tokens to account for a system prompt, so up to 200 tokens, but... still pretty short). But this is only compatible with CPU inference, so that reduces its appeal.
It seems like its current state was designed for text embedding models, where you normalize input length by chunking (often 128 or 256 tokens) and operate on the chunks — and indeed, that’s the only text-based CoreML model that Apple ships today, a Bert embedding model tuned for Q&A[2], not an LLM.
You could used a fixed input length that’s fairly large; I haven’t experimented with it once I grasped the memory requirements, but from what I gather from HuggingFace’s announcement blog post[3], it seems that is what they do with swift-transformers & their CoreML conversions, handling the details for you[4][5]. I haven’t carefully investigated the implementation, but I’m curious to learn more!
You can be sure that no one is more aware of all this than Apple — they published "Deploying Transformers on the Apple Neural Engine" in June 2022[6]. I look forward to seeing what they cook up for developers at WWDC this year!
---
[1] "Use `EnumeratedShapes` for best performance. During compilation the model can be optimized on the device for the finite set of input shapes. You can provide up to 128 different shapes." https://apple.github.io/coremltools/docs-guides/source/flexi...
[5] `use_flexible_shapes` "When True, inputs are allowed to use sequence lengths of `1` up to `maxSequenceLength`. Unfortunately, this currently prevents the model from running on GPU or the Neural Engine. We default to `False`, but this can be overridden in custom configurations." https://github.com/huggingface/exporters/pull/37/files#diff-...
