w-m

The $285k was not an estimation of what it costs to run a ship per day. They merely divided $4M by 14. So it was an estimation of how much saving two weeks to go around is worth to the highest bidder, per day.

What makes you think the LLM couldn’t run a debugging session from the content of a JIRA ticket and the whole code base + documentation?

ESTA costs $21 since May 2022, before it was $14.

- Pancake optics (0 to -5.75 diopter adjustable)

- Interpupillary Distance (IPD) adjustment range of 58 to 72mm

- E Ink 1.3” displays

- 256x256 per eye resolution

- Side-lit with 3000K LEDs

- Circular polarizers and transflective films

https://solreader.com/technical-specs

In Germany, trucks are going at 89 km/h (officiall 80 km/h) and the driver has to take a mandatory break, which is electronically tracked, every 4.5 hours. They have to take a 45 minute break, and the truck charges from 20 to 80 % in 30 minutes. So in theory, the 500 km range is sufficient, at least when it's moderately warm out.

In practice, there's already a shortage of simple parking space for trucks on break along motorways. It'll be quite difficult to quickly build out a network of chargers that supply > 1 MW per truck, for many trucks at a time, all over the place.

They say it can be charged from 20 to 80 % in 30 minutes. As it has a 600 kWh pack, it must charge at > 720 kW (given the megawatt charging system, which has not been finalized).

I learned from a German hands-on video [0] on the Mercedes truck that there’s already a law that allows for up to 90 cm long noses for aerodynamic design [1]. But it seems no manufacturer has a model making use of that yet. I don’t think we will see a US style truck design though. If you want to deliver to any European city, the US it’s simply not feasible to go longer.

[0]: https://youtu.be/AdgcShJJaBc

[1]: https://trans.info/en/more-aerodynamic-truck-cabins-come-to-...

That seems to be for the previous version, not the announced 600 kWh one.

edit: information on the new one can be found in the press release [0]:

- 600 kWh LFP battery

- 500 km range

- 400 kW CCS charging

- later: megawatt charging, 20 to 80 % in 30 minutes

[0]: https://media.daimlertruck.com/marsMediaSite/en/instance/ko/...

Earlier today, ChatGPT/DALL·E 3 refused to draw the bat sign (from batman) for me, due to content policy. When I asked it to rephrase the prompt to circumvent any copyright issues, it came up with "an emblem featuring a nocturnal flying creature silhouette", which made me chuckle quite a bit.

Playing the game where you have to convince the LLM to spit out the secret password[0] was great training for this content policy dance with DALL·E. Isn't it great - even though the machine is now performing the handicraft, you can still feel creative. Not by creating art yourself, but by finding new workarounds around the man-made content policy limitations.

[0] https://gandalf.lakera.ai

Earlier this year we built a live depth estimation system in our research lab. It uses a small laser projector with visible light and an event camera to estimate the depth of the projected points. You get a point cloud of whatever surface or object you’re projecting on, while being free to project any content [0]. Also it’s fast enough to process 1280x720 points at 60 Hz with a laptop CPU.

Explaining this work and use cases can sometimes be a bit of a struggle. Maybe if “ambient computing” is established as a widely known buzzword, imma have to steal it to make that part of the job a little easier. Until now I was mostly going with mixed reality.

[0]: https://fraunhoferhhi.github.io/X-maps/

Reading this, I realized that a similar thing developed in German, my native tongue, but from a different root. As a noun, capital Paar refers to a pair of exactly two, like “ein Paar Schuhe”, or a couple (n.), like “das Paar”. As a pronoun, lowercase paar refers to a few or a couple of.

This leads to this weird situation where “ein Paar Socken” is exactly two socks, but “ein paar Socken” can be a few socks, like 2-7. The pronunciation is exactly the same, and both versions are in common use.

It's a little quirky indeed, as the newer version completely shuts out part of the player base: If you try to launch CS:GO on Mac, it automatically deletes itself and updates to CS2. Then it tells you that it can't run, because cs2.exe can't be found.

I don't think anybody following OpenAI's feature releases will be caught off guard by ChatGPT becoming multi-modal. The app already features voice input. That still translates voice into text before sending, but it works so well that you basically never need to check or correct anything. Rather, you might have already been asking yourself why it doesn't reply back with a voice already.

And the ability ingest images was a highlight and all the hype of the GPT-4 announcement back in March: https://openai.com/research/gpt-4

Re garbage performance on stacking: I had tried interleaving the values (creating a 56x28 img), it dropped one percentage point of accuracy when using gzip.

VW opened a car factory / exhibition space in the city center of Dresden 20 years ago [0]. It was already connected with tram tracks, so they built a freight tram that would run through the city to deliver parts to the factory [1]. It was always quite a sight to behold when they passed in front of the baroque architecture of the Zwinger.

[0]: https://en.wikipedia.org/wiki/Transparent_Factory

[1]: https://en.wikipedia.org/wiki/CarGoTram

Best one I found is Normalized Mutual Information at 95%. It's a little more complex, but you could still compute it relatively quickly on binarized images.

    NMI skimage: ~30 seconds, 95% accuracy
    NMI numba *: ~0.6 seconds, 95% accuracy

Here's the code, courtesy of ChatGPT:

    @njit(cache=True)
    def compute_joint(img1, img2):
        stacked = 2 * img1.ravel() + img2.ravel()
        return np.bincount(stacked, minlength=4).reshape(2, 2)

    @njit(cache=True)
    def entropy(counts, total):
        # Convert counts to probabilities
        p = counts / total
        # Only calculate for non-zero entries to avoid log(0)
        return -np.sum(p[p > 0] * np.log2(p[p > 0]))

    @njit(cache=True)
    def normalized_mutual_information(img1, img2):
        joint_counts = compute_joint(img1, img2)
        total_pixels = 28*28
        
        # Marginal counts
        c1 = np.sum(joint_counts, axis=1)
        c2 = np.sum(joint_counts, axis=0)
        
        # Compute entropies directly from counts
        h1 = entropy(c1, total_pixels)
        h2 = entropy(c2, total_pixels)
        joint_entropy = entropy(joint_counts.flatten(), total_pixels)
        
        mutual_info = h1 + h2 - joint_entropy
        return 2 * mutual_info / (h1 + h2)

While screens of earlier MacBooks could be turned off with a single magnet, my 2020 Intel MBP requires both the left and the right sensor (around the tab and the enter key) to trigger at the same time to consider it closed. It would be nearly impossible to trigger that accidentally. For starters, you'd need to wear two watches..

Trying to come to this discussion I accidentally misclicked and ended up in OPs profile, to learn that he’s a cofounder of Overleaf (hi John, big fan of the product). Overleaf, which has the purpose of turning markup language into PDFs, whereas Nougat turns PDFs into markup language. Made me wonder how many of these inverse/symmetrical/twin products there are, where one turns foos into bars and the other turning bars back into foos.

Studio Babelsberg in Potsdam has four "metropolitan" (Berlin/Paris/New York/London) streets: https://www.studiobabelsberg.com/en/backlots/metropolitan-ba...

That's a really nice idea. Have you thought about making it a product?

Last week I helped someone organizing and analyzing their data in Excel. As I'm using Excel only once every couple of years, I had to rewatch the wonderful "You Suck at Excel with Joel Spolsky" to be productive again. Now seeing this announcement page, I was immediately reminded of the mini-rant towards the end of the video [0]:

> On average, once every three months, there's a startup that makes a thing that they say is going to be amazing, and it's just PivotTables. They're like, "It works with Excel, and it does this amazing consolidation, and slicing and dicing of all your data, and it's amazing, and we're going to make a startup. I'm going to sell this for four hundred ninety-five dollars." And that happens at least once every three months. The trouble is, the VCs usually know about PivotTables.

Of course this product goes a little further, making suggestions what columns to analyze and chart with an LLM. But it's quite funny to me that this Microsoft Research product is reinventing the PivotTable (+PivotChart) part with Python and Pandas.

[0]: https://youtu.be/0nbkaYsR94c?si=kkfFHZ_fyGmG3Lnj&t=2988

I'm not sure there are people who are buying new phones every 8 years. But buying a used 2-3 year old iPhone, using it for 3 years and then handing it down to be used another 3 years by someone else is very common around here (Germany).

GGUF support was merged in llama.cpp three days ago: https://github.com/ggerganov/llama.cpp/pull/2398

I’ve often done that in Paris, absolutely enjoyable. Through the city proper you only walk a little over two hours north-south or east-west. With a few detours to points if interest and breaks for coffee it’s one of my favorite ways to spend a half day.

I think you are missing that the world is a little messy. You are correct that native extensions can and do drop the GIL. But data needs to be loaded, it needs to be preprocessed (does your image downsampling library drop the GIL? Does the video decoder drop the GIL? How do you find out? You need to do a little string processing on your data, well then you're out of luck.). Hardware devices need to be managed. Progress needs to be logged, and operations need to be debugged. There isn't a perfect kernel that can be run for every operation, you may have to run a little Python code before calling into your native code.

Again, I would encourage you to read the motivation section of the PEP, which shows a multitude of frustrations with the current state. The issue is subtle enough that I'm struggling to summarize it in a single sentence.

It's exactly the high-performance native extensions that require the GIL removal to allow for a full utilization of the machine. Although already successful as glue for these libraries, Python is ultimately hamstrung by the GIL on many-core machines. Using the GIL removal to start writing algorithms in interpreted Python is not the intention.

I warmly recommend reading the motivation section of the PEP. It is incredibly well written, quoting issues from PyTorch, scikit and NumPy:

https://peps.python.org/pep-0703/

Every time the GIL removal is discussed, I notice a tidal wave of negativity in the comments, which is completely surprising to me. I suspect some critics primarily deal with thread-parallel programs that focus on asynchronous data sharing and task signaling. In languages like C++, handling these with threads and locks is tricky, and you're all but guaranteed to produce subtle race conditions. I'm totally with you on this – I wouldn't want to manage this in Python either.

However, consider parallel data processing, a task I face so often in computer vision. In C++, I can slap a `pragma omp parallel for` onto a for loop processing a list of images/videos/meshes/csvs, increasing the speed of this section of the program by the number of CPU cores. I do this when the problem is well defined (one input, one output each), and it hasn't blown up in my face once. In Python, on the other hand, it feels cumbersome when spinning up worker processes for such tasks, not to mention harder to debug. For this kind of work, removing the GIL would be a massive relief.

It's good that people are highlighting the issues. But to add my weight to the scale, the GIL is the main barrier in Python to stand in my way to speed up my programs. So I'm very happy that they're investing their resources to build a proper way of doing thread-parallelism.

Does anybody have an idea on how to get in to Metal programming (as in Apple Metal)? I'd love to mess around a little with this on iOS and macOS while learning about tile-based rendering, but I have trouble locating educational written material.

There's a book (https://metalbyexample.com/the-book/), but the author has put up a note that it's quite out of date. It seems the most up-to-date information is available in the WWDC videos (regarding e.g. Metal 3), but I'd really prefer something written. And Apple's documentation reads more like a reference material and is quite confusing when starting out.

I think Hammock Driven Development[0] deserves a spot in the classics!

[0]: https://www.youtube.com/watch?v=f84n5oFoZBc

I wrote about my motivations in a different comment. To be honest, I didn't harbor any particular expectations. Maybe a flicker of hope for a bit of feedback or interaction from someone who'd given it a go, be it results, queries, or issues.

Maybe I should have kept my expectations in check, considering not many labs will have the setup ready to go, let alone have the inclination to dabble with it. But that was a step I didn't consciously take.

There's an uncanny silence from the world when you've thrown so much of yourself into a project, and you're the only one to care about it. It really shouldn't catch you off guard if you're thinking about it rationally, especially if you're not regularly communicating about the project for more people to notice it. But it still doesn't feel great.