devit

All non-toy programming languages support encapsulation, usually implemented with "private" or "public"/"export" keywords (well-designed languages make private the default), which means that unless the "thing" was marked as public/exported, in which case it's designed to be reused and stable and thus it's OK to depend on it, that will trigger a compiler or runtime error (in well-designed languages, a compiler error).

Obviously, in that case it's perfectly normal and acceptable to either export or make public the thing, if it is a good idea for it to be part of the module interface, or if that's not a good idea factor out the useful thing and make it a 3rd module that both the original and new modules depend one; this should come with some documentation about the interface if it's not obvious or fully specified by the types.

Am I missing something or this "ARC-AGI" thing is so ludicrously terrible that it seems to be completely irrelevant?

It seems that the tasks consists of giving the model examples of a transformation of an input colored grid into an output colored grid, and then asking it to provide the output for a given input.

The problem is of course that the transformation is not specified, so any answer is actually acceptable since one can always come up with a justification for it, and thus there is no reasonable way to evaluate the model (other than only accepting the arbitrary answer that the authors pulled out of who knows where).

It's like those stupid tests that tell you "1 2 3 ..." and you are supposed to complete with 4, but obviously that's absurd since any continuation is valid given that e.g. you can find a polynomial that passes for any four numbers, and the test maker didn't provide any objective criteria to determine which algorithm among multiple candidates is to be preferred.

Basically, something like this is about guessing how the test maker thinks, which is completely unrelated to the concept of AGI (i.e. the ability to provide correct answers to questions based on objectively verifiable criteria).

And if instead of AGI one is just trying to evaluate how the model predicts how the average human thinks, then it makes no sense at all to evaluate language model performance by performance on predicting colored grid transformations.

For instance, since normal LLMs are not trained on colored grids, it means that any model specifically trained on colored grid transformations as performed by humans of similar "intelligence" as the ARC-"AGI" test maker is going to outperform normal LLMs at ARC-"AGI", despite the fact that it is not really a better model in general.

Well, that's just the normal way to write software, no?

Aside from some websites and small scripts, all software is written like that.

You simply create a hierarchical directory structure where the directories correspond to modules and submodules and try to make sure that the code is well split and public interfaces are minimal.

So far no one has managed to produce a programming language with dependent types that compiles to efficient machine code with zero overhead like Rust and C do, so the reason to not have dependent types in Rust is to be able to produce efficient code (which Haskell doesn't even without dependent types).

Obviously if such a language is possible to make and gets made, it will be the strict best programming language overall and make all other languages obsolete (just like Rust obsoleted C/C++, etc.)

I think Haskell is fundamentally a bad design, because there is no reason to not have dependent types and totality checking in such a language, and also laziness is bad as it makes memory usage unpredictable and potentially asymptotically broken.

Basically Rust is much better at producing efficient code with zero abstraction cost (while still doing a decent job at controlling mutation and having an expressive non-dependent type system) and having a large package ecosystem, and Lean, Agda and Idris are much better at being theoretically perfect languages while sacrificing code efficiency, so why use Haskell?

They claim it's available in ChatGPT Plus, but for me clicking the link just gives GPT-4o Mini.

Aren't "personal carbon footprints", whether of the rich or not, insignificant compared to industrial carbon emissions?

I can find 3.7 * 10^13 kg CO2 for energy yearly worldwide.

On the other hand, there are around 25 * 10^3 private jets each emitting 4.9 CO2 kg/mile, with mach 1 being 767 miles/hour, which gives 4.9 * 25 * 10^3 * 767 * 24 * 365 kg CO2 = 8.23 * 10^11 per year assuming the jets are running all the time at the speed of sound.

8.23 * 10^11 / (3.7 * 10^13) = 2.2%, with assumptions that make this a significant overestimate. Internet sources claim 0.9% from civil aviation.

Seems like a trivial problem to me.

If the graph is directed, do an SCC decomposition in linear time using a graph library and then any SCC with size more than one has at least a loop, trivially extracted by following any edges in the SCC.

If the graph is undirected, compute a spanning tree in linear time using a graph library and then any edge outside the tree forms a loop, again trivially extractable from the edge and the paths from its endpoints to their least common ancestor in the tree.

Since those algorithms are already asymptotically optimal, it's just an engineering problem of finding the solution with the best constant factor given the precise data structures and goal in question.

This fix makes no sense:

if is_hyphen(value[0]) and value[1] == "$":

     converted_value = float(re.sub(r"[^.0-9]", "", value)) \* -1

If the strategy is to delete all non-numeric characters in re.sub, you should instead replace _all_ characters that could be a minus with '-' before doing the float(re.sub(...)) including the '-' instead of this bizarre ad-hoc code.

Also "is_hyphen" is wrong since it doesn't handle the Unicode minus sign.

Name and description are very confusing and a trademark violation since despite the claims it seems to be completely unrelated to actual Nanite in UE5, just an implementation of something similar by a person unaffiliated with UE5.

There is also Bevy's Virtual Geometry that provides similar functionality and is probably much more useful since it's written in Rust and integrated with a game engine: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...

It needs three choices, since many of the colors are blue-green and the "this is blue" or "this is green" is essentially a random choice.

I wonder what's the complexity class of the problem of deciding if it is solvable in a given number of moves?

Interactive use definitely wants the best model possible so that you have a higher chance of getting a correct and useful response.

It might be hard however to decisively convince people that one model is significantly better than another though, so branding/first mover/etc. probably plays a big role.

<<Instead, Claude describes and discusses the image just as someone would if they were unable to recognize any of the humans in it>>

Why? This seems really dumb.

Using the rocket equation, it is possible to compute the ratio between the $kg launch cost and $/kg material sell price that would make it economical.

Based on my calculations, with optimistic assumptions (including the asteroid being made solely of the desired material), you need 5 Falcon 9 launches and in-space assembly to bring back one ton of material, which would require selling the material for 350k$/kg for parity. But gold is only 80k$/kg, platinum is 30$/kg, etc.

Doesn't look feasible with current technology.

I think that in principle one could tag the training set with "source" tags and express weights as a sum of subweights for each source tag; during backpropagation, the overall weight and subweight for the training sample would be updated, and during inference linear operations would happen on the subweights as well, while nonlinear operations would scale all subweights by the ratio.

This should in principle allow to determine how much each source influenced each output token of the LLM.

The problem is that this multiplies storage and compute time for tagged inference by the number of source tags, so it may be impractical to actually tag single documents or authors, but might be useful for very broad categories like "copyrighted" vs "non-copyrighted", "synthetic" vs "human generated", "photo" vs "drawing" vs "rendering", year range of publication, etc.

Seems pretty dubious to do this without adding support for having both 4KB and 16KB processes at once to the Linux kernel, since it means all old binaries break and emulators which emulate normal systems with 4KB pages (Wine, console emulators, etc.) might dramatically lose performance if they need to emulate the MMU.

Hopefully they don't actually ship a 16KB default before supporting 4KB pages as well in the same kernel.

Also it would probably be reasonable, along with making the Linux kernel change, to design CPUs where you can configure a 16KB pagetable entry to map at 4KB granularity and pagefault after the first 4KB or 8KB (requires 3 extra bits per PTE or 2 if coalesced with the invalid bit), so that memory can be saved by allocating 4KB/8KB pages when 16KB would have wasted padding.

Very unlikely that a half page proof of P!=NP is correct.

Please provide a formalization of your argument in any widely-used theorem prover (I'd recommend Lean) configured with options widely accepted to be sound.

BTW, the argument seems trivially bullshit because you say that L is in NP, and then claim that L is not P because "there exists no algorithm that...", but if L is in NP there is of course an exponential-time algorithm for L.

It would be nice to have some competition.

Right now basically you are forced to buy a Pixel phone, because if you don't buy an iOS or Android device you don't have apps, if you buy an iOS device you lose your freedom, and if you don't buy a Pixel phone you don't have timely updates and GrapheneOS and thus don't have an open source, frequently updated and well-engineered OS.

It seems it's an invalid encoding if I understand the article correctly.

There seems to be some debugging utility in such a mechanism, e.g. you could use it to run CPU tests, benchmarks or debug code in userspace of a stock OS and then directly communicate with serial port MMIO without needing to pollute the CPU state with a system call or change the kernel to directly map the MMIO into userspace.

Could this a debugging instruction that was mistakenly left enabled in production or possibly even an intentional backdoor?

Most modern ISAs like RISC-V provide no way of directly accessing physical memory regardless of privilege (you have to either disable paging or setup page tables to point to the physical memory you want), so it seems unlikely that one could accidentally implement one.

In case of an intentional backdoor it seems surprising that it would not be authenticated with a secret key, but maybe they are very incompetent.

I think a study like this is mostly worthless.

The issue here is that humans are a combination of their natural state (how they would be if they were raised with no contact, direct or indirect, with society) and social conditioning (the system of induced emotions and mental strategies that society instills in people to sustain and propagate itself).

"Committed relationships" are in the natural state most likely naturally living in a tribe, with probably little or no pair bonding/coupling in humans, while western social conditioning is about committed relationships, marriage, etc. with several very different flavors (traditional marriage, polyginous marriage, hierarchical polyamory, etc.)

"Casual sex" in the natural state probably "just happens", while social conditioning has a whole lot of mental ideas about with whom/when/how much you should do it, what it means if you do/don't do it, etc.

The problem with studying the natural state is that there are little or no humans living in it (and certainly none accessible to most/all researchers), and the closest animals, chimpanzees and bonobos, are significantly different between them in their sociosexuality.

The problem with studying social conditioning is that it massively varies between gender, location, subculture, age, historical period, and varies randomly between individuals.

So this study at best might manage to describe the average social conditioning that currently affects Mechanical Turk users (clearly chosen because it's easy and cheap to target them, rather than any attempt at producing quality research), and thus is pretty much useless.

> But the method itself has still got a much slower throughput than a tracing GC, when used in a similar manner

That is correct, but the issue is not with reference counting, but rather with having unnecessary extremely frequent RC/GC operations.

Once frequency is reduced to only necessary operations (which could be none at all for many programs), reference counting wins since its cost is proportional to the number of operations, while GC has fixed but large costs.

That's because, unlike Rust, those languages with RC would have a lot of unnecessarily refcounted objects because they don't have value objects, do a whole lot of useless reference count updates because they don't have borrowing and always have to use atomics because they can't ensure that some objects are not shared between threads (and also would need a cycle collector in addition to the reference counting).

If you use reference counting properly in a well-designed language then it's obviously better than GC since it's rarely used, fast, simple, local and needs no arbitrary heuristics.

The destructor cascades are only a problem for latency and potential stack overflow and can be solved by having custom destructors for recursive structures that queue nodes for destruction, or using arena allocators if applicable.

What do you mean?

Assuming you use a set of slabs of fixed size objects and keep free objects in a linked list, both malloc and free are trivial O(1) operations.

Destructors with cascading deletions can take time bounded only by memory allocation, but you can solve that for instance by destroying them on a separate thread, or having a linked list of objects to be destroyed and destroying a constant number/memory size of them on each allocation.

You can, but it turns out that, as one may intuitively expect, a GC is never needed unless implementing a VM for a GC-based language or an API that required GC like fd passing on unix domain sockets, and those generally want an ad-hoc GC instead tailored to whatever you are implementing.

Since it's not needed and it's massively worse than reference counting (assuming you only change reference counts when essential and use borrowing normally) due to the absurd behavior of scanning most of the heap at arbitrary times, there is no Rust GC crate in widespread use.

Is there a reason why game developers can't just sell a key on their website using Shopify/WooCommerce/etc. and distribute the game files publicly via a CDN?

Assuming they can get their game discovered via some sort of non-store channel (e.g. Reddit, social media, YouTube, Twitch, ads, etc.), the user can simply search the web for the game, find the website, click "buy" and proceed.

Probably a bit more work than publishing on Steam but not that much. Seems worth it for large budget games or games that are very popular in a specific niche discoverable outside Steam.

You can use kexec to load a different Linux kernel from a Linux kernel.

Probably slower and perhaps less compatible than using GRUB though.

Is this actually better than just putting in dry ice?

It seems that dry ice has 571 kJ/kg latent heat at -78.5 C sublimation, while lithium batteries have around 250 Wh/kg = 900 kJ/kg, but with batteries you have the extra weight of the refrigeration system plus whatever loss of efficiency it causes, as well as the risk of mechanical/electrical failure.

It seems that charging batteries is much cheaper though, with dry ice seemingly going for 2-6$/kg and electricity 0.1688 $/kWh = 0.04$/kg to charge batteries.

Locking doesn't result in deadlocks, assuming that it's implemented properly.

If you know the set of locks ahead of time, just sort them by address and take them, which will always succeed with no deadlocks.

If the set of locks isn't known, then assign each transaction an increasing ID.

When trying to take a lock that is taken, then if the lock owner has higher ID signal it to terminate and retry after waiting for this transaction to terminate, and sleep waiting for it to release the lock.

Otherwise if it has lower ID abort the transaction, wait for the conflicting transaction to finish and then retry the transaction.

This guarantees that all transactions will terminate as long as each would terminate in isolation and that a transaction will retry at most once for each preceding running transaction.

It's also possible to detect deadlocks by keeping track of which thread every thread is waiting for and signaling the either the highest transaction ID in the cycle or the one the lowest ID is waiting for to abort, wait for ID it was waiting for terminate and retry.