The rules for each contract are provided when you bet, but ultimately there are plenty of markets that are settled in controversial ways and users have little recourse because the sites TOS's often say their rulings are final (this is the same for many sports books as well).
To give an example, I wagered on a market a while ago that Trump would say "Mamdani" before the end of the week. He responded to a question Mamdani where the reporter asked about the mayor by name and Trump said "Mandami" instead of "Mamdani" (switched the m and n). Kalshi ruled that that didn't count as Trump having said the word.
Trump ultimately said Mamdani correctly the next day so it ended up not mattering and I think the rules have since been updated to accept obvious mispronunciations, but I think it's a good example of how much gray area some of these markets can have.
In my day job I program rigid body behaviour in real time amongst other simulations.
I think rigid body contact is hard to learn as it is inherently discontinuous.. something you discover when trying to code a solver.
As such I always use this prompt as a test:
"A video of a jenga brick tower falling over as a brick is removed. The physics of each brick must be realistic."
It gave me a video of where bricks suddenly disapper or morph into others[1]. The linked video is after 2-3 iterations of me insisting on realistic physics. If you are just glancing at this, you would believe it is realistic.
That said this is still very impressive and one more step towards .. IDK what. But I am a bit reasurred that at least my job won't be fully replaced with AI :)
My point here being that representationally, it might be possible to learn good dynamics without a radically different approach/arch. There are already models that extract 3D tracking points from videos, so they could possibly be leveraged for learning dynamics (which on its own gives precedent for end-to-end approaches also possibly working).
Thanks for the additional reading. I've often thought about LLMs and their ability to represent the physical world with its laws. And always concluded it is not really possible to do so with "just" text tokens and their relations in a latent space. It looks to me there are different approaches being taken to tackle this:
* You could instruct your LLM to interact with a simulator to run experiments and infer behaviour
* You could edit the transformer model and inject spatially relevant data rather than text as is done in above paper
* You could change the architecture to be more condusive for representating a world state. I.e., LeCun's JEPA world model.
* You could further enhance some of the above by using a differentiable physics engine (eg. NVIDIA Newton) to calculate losses directly.
But at the end of the day if a model has any hope to always produce realistic physics, it HAS to learn the laws of nature in some form or other. It looks to me that the next big leap could be achieved by combining the last two approaches.
P.S.: I like discussing such topics. If anyone knows a forum or discord with like-minded people, please let me know :)
> P.S.: I like discussing such topics. If anyone knows a forum or discord with like-minded people, please let me know :)
Unironically twitter (and only use the "Following" tab as opposed to the "For You")
Make an account that only follows university affiliated researchers with less than 1000 followers. In my experience discord servers get suffocated by beginners and crackpots because conversations don't naturally self-organize into their own threads.
I'm not sure why, especially because you're a developer... But damn, the amount of people that expect AI to just one shot stuff is hilarious. Half of the time I make a typo or something, should I be laughed out of the room?
Such videos are essentially dreams: how it feels that the planks should move, not what equations of rigid body physics would compute. And the feeling is realistic (even if overly dramatic in the end). If "stylistic transfer" works for static pictures spread out in space, why won't it work for the character of motion spread out in time?
Classic 3d simulation artifact with boundary conditions. I remember for an assignment where I had to model liquid with rigid bodies, they would suddenly gain infinite force at the corner and just disappear. It's clear that they must have used a lot of these kinds of synthetic data. But what's impressive to me, every release of these models, I am feeling less and less uncanny valley.
Totally unrelated, but what would you say the feasibility of writing simulation software for simulation of/replicating body movements during/in a martial arts technique would be?
I’ve often thought it would be very handy to have a proper simulator for being able to simulate and identify inefficiencies in one’s technique, but no idea whether it would be feasible to do.
Would be similar to the typical simulations of humanoids. If you need to model the deformations of the human body, or get a proper model of tendons that make up humans, it'll be more difficult, but possible.
Proper simulators for those exist, you essentially need an engine with a compliant contact model. MuJoCo is the goto here, see:
Indeed, it entirely depends on which axis you want to focus on. A loose trade-off chart would be speed, stability and accuracy. You can only have two of these in a simulator.
Robotics folks probably want speed and accuracy. I'm from the video game industry so I generally look for speed and stability.
Note: This is a loose analogy and recent techniques are already blurring the lines between these axis.
If you are just generating as usual with the main model then you're sequentially generating A -> AB -> ABC.
If I'm understanding correctly, what speculative decoding is doing is first (= more FLOPs) using a different small/fast (but less accurate) model to generate this ABC (you hope) sequence, then use the main model to now verify it in parallel (A + AB + ABC in parallel) rather then generate it sequentially. Assuming you had the FLOPs available to really do this in parallel, then this parallel verification vs sequential generation is what gives you the speed up.
200% agree. If you decide to use this power you must accept the tiny risk and huge consequences of it going wrong. The article seems like it was written by AI, and quoting the agent's "confession" as some sort of gotcha just demonstrates the author does not really understand how it works...
LLMs are not deterministic per my understanding. A program always produces the same output for the same input and instructions (ignore FP accuracy for now). How is determinism achieved here?
LLMs (or at least transformer-based LLMs) are effectively almost entirely deterministic, the randomness being largely only present due to (unnecessary) optimizations and other tweaks.
Temperature is not at all core to LLMs, it is something that rather makes the outputs more varied and desirable for human consumption generally. It is trivial to set to zero for applications like this.
On CPUs, the models are essentially fully deterministic, even with FP accuracy, and most common kernels have reproducible (albeit slower) variants even on GPUs. Otherwise, yes, FP non-associativity on GPUs is the only real source of randomness in inference.
The other issue arises from batch invariance, but this is a problem that occurs only at scale when serving multiple users / inputs have some randomness too. You can (usually) trivially eliminate this by controlling what goes in the batch or making the batch size be one. There are also other more clever mitigations for this, none of which are secrets.
LLMs produce a distribution of token probabilities which is then sampled. This sampling is the only random part of the system.
If you just take the most probable token every time, the system becomes fully deterministic. We don't do this as the output becomes more stiff and less creative.
LLMs may be deterministic for a subset of inputs, if one output (or intermediate layer) neuron-state probability is significantly higher than the rest. My understanding is, when probabilities are close they diverge.
I think the diagrams look very similar to what Keenan Crane uses in his papers, perhaps they used that tool. I think his students have now fleshed it out for general use.
One esoteric route would be to try and specialize in an area where talent is scarce. There's a lot of gameplay programmers, few engine programmers, fewer graphics programmers, and very few physics programmers (in my experience at least).
As such you could try to specialize in this area (collision detection, ray queries, rigid body simulation, constraints, solvers, softbody sim, fluid sim etc.). Of course this isn't for everyone as it requires skills and interest in: low level concurrent programming, maths/linear algebra and physical behavior intuition.
If you do find these topics fascinating and can demonstrate some ability in them, your skills will certainly be in demand.
I've always observed a curious thing within India regarding the Devnagari (Hindi) and Latin (English) scripts. Essentially all English words are always written in Devnagari, but it's rarely the other way around. For example it is much more likely to see इंग्लिश टू हिंदी than "angrezi se hindi".
My personal theory is that this is because you can make every sound you hear in English using the Devnagari script, but not the other way around.
> My personal theory is that this is because you can make every sound you hear in English using the Devnagari script, but not the other way around.
This is not very close to true. English (even a given accent) has a rather high number of phonemes, and they don’t overlap very closely with Hindi. What is probably more relevant here is that Devanagari is relatively phonetic so writing in it is useful to describe English pronunciations, more so than the English script is for Hindi (or English, for most unfamiliar words).
I think both you and GP are correct, but in different ways.
It's true that the English language has a very large number of phonemes... but accents tend to regularize/restrict these phonemes. For example, a typical bilingual speaker of Indian English and Hindi will replace instances of the /æ/ phoneme (as in "blast" or "fast") with another phoneme like /a:/ (as in "father"). Which isn't that unusual since /æ/ is pretty uncommon among languages.
Other rare English phonemes include the dental fricatives, i.e. the "th" sounds in "ether" (voiceless) and "either" (voiced). Speakers of Indian English often replace this with a dental stop, a "t" sound (voiceless) or "d" sound (voiced). (Note that Devanagari has a _lot_ of stops, so this is one place where it cannot be cleanly encoded into the Latin alphabet without diacritics.)
So overall: while I think Devanagari can't encode e.g. American English, it can actually do a pretty solid job of encoding Indian English, but not the other way around.
Sounds like a reasonable theory but do you have an actual example? The one you gave:
> For example, a typical bilingual speaker of Indian English and Hindi will replace instances of the /æ/ phoneme (as in "blast" or "fast") with another phoneme like /a:/ (as in "father"). Which isn't that unusual since /æ/ is pretty uncommon among languages.
does not apply to Indian languages because most of them have daily-use-words with the /æ/ sound.
Hindi written in Devanagari is highly phonetic (not perfect but near perfect). However, English is not phonetic at all. E.g., "Th" in Then is different from the "Th" sound in Father.
Devanagari has much more phonetic structure than English spelling.
The English Latin letter arrangement holds a tenuous phonetic connection to pronunciation half the time, whereas the devanagari usually indicates exactly how you say it.
Perhaps explains why Indian accent is the way it is - most of the time it's a literal phonetic translation. Words like "champagne" are source of joke for any English learner, but even a simple word like "nature" has a phonetic translation of "Na two rae".
As a Bollywood superstar famously quotes: English is a funny language.
It's that plus the fact that half of spoken Hindi is actually English words cobbled into the language similar to how English was latinized due to the normans and french
I'm not sure if I don't understand, or completely disagree, but if you look anywhere 'digital' like Reddit for example, a lot of Hindi is written in Latin script. WhatsApp too in private communication, where people don't have or haven't understood how to use a devanagari (or transliterating) keyboard on their phone.
As a Britisher learner it's frustrating¹ actually, because there is a standard for how to do this - IAST, for Sanskrit/derived generally - but of course that's not what native speakers use casually. E.g. your 'angrezi se hindi' would be 'añgrezī se hiñdī' but anyone writing Hindi with those accents is foreign or an academic. (Also people will casually write 'ay' instead of 'e' ए or 'ee' for 'ī' ई, etc. cf. 'paneer'.)
[1: The frustration is because it leads to ambiguity, whereas IAST is 1:1 and so preserves the phonetic nature of devanāgarī, and tells me exactly which t/d/r sound, if it's aspirated, etc. which a fluent native layperson's anglicised interpretation really doesn't. They might write gora & gora and know from context if that's gora or ghoṛā, but if I don't already know the word a gora like me is stuck.]
Many foreign learners have written about it.
Essentially, one can follow conventions around oneself or try to write and get an English spelling that sounds closest to Hindi pronunciation. And there are no academic rules around it that one is taught in schools in India.
I learnt about IAST only after seeing how foreigners transcribe Sanskrit texts in Latin.
Thanks, I'm slack on that because I can't type it!
(I also am often unsure which is correct, since as you no doubt know it's so common to drop the चंद्र and write हूं for example where it's properly हूँ )
In a lot of "technical" situations, people tend to opt for the well established English counter parts for nouns or concepts. eg even a native Hindi speaker will use कंप्यूटर / computer over संगणक / Sanganak
Given the name I was also expecting some clever SQL-like data structure/query for fast spatial lookup but I digress.
Game physics involves a lot of things (solvers, collision detection, numerical stability, etc.).
I am skeptical of their claims of being able to run physics in what I understand are stored procedures for their database.
I looked at their docs for physics https://spacetimedb.com/docs/unity/part-4
where they demonstrate the simplest form of collision check (sphere overlap). I fail to see how that is an improvement or speedup over existing methods. Some quotes:
"This may not be the most efficient way to do collision checking (building a quad tree or doing spatial hashing might be better), but SpacetimeDB is very fast so for this number of entities it'll be a breeze for SpacetimeDB."
>> Nothing is quantified with numbers.
"For every circle, we look at all other entities."
>> This is the most inefficient N^2 way you could do collision detection.
And not to mention networked physics is a whole additional layer of complexity, where you have to use some form of prediction techniques and very likely end up changing your core physics code to accommodate this.
All of this suggests to me much thought has not been put into the claim "you can also do physics with it!" and its implications. Perhaps it is enough for extremely simple physics, as demonstrated with their demo game. If the author is reading this, I suggest spending some time understanding what this claim implies and qualifying it better.
However I must mention that I applaud their courage to try something so outlandish. If you truly believe your claims are possible, I encourage you to keep working on it.
But I'll be convinced when extraordinary evidence backs extraordinary claims.
Source: I work on a commercial game physics engine and related netcode.
I believe they've done more complicated physics in their game bitcraft, but that code hasn't been released yet (no idea if it will be.) But there has been work in the discord recently and 2 member have individually implemented rapier[1] at this point. I can't say anything about the related netcode however as I don't know how much they've focused on it. At the very least work has been done.
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
Nice, that's very interesting and a commendable achievement!
If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.
For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.
On of the people who implemented it is from unity, from my understanding he can't actually release the code. For the other guy, this was his last comment on the matter
> Sure, my plan was to write a readme and share the code with my colleagues anyway. It should be ready by the weekend because I'm in the middle of a refactoring right now.
> The gist of it: each time a System adds a "movable" component to a StDb table, it also adds the rigid body and collider in Rapier. Then, a scheduled reducers updates the simulation then fetches resulting positions and velocities from Rapier and updates the "movable" components. I have no client prediction at this time.
So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.
Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.
I see, that's extremely interesting. As mentioned earlier, I do respect efforts to push on something new, especially if it's against conventional wisdom and would be interested in poking around with an open mind. I'll join the Discord.
Thank you!
Then again looking at the FAQ for Bitcraft, we have this:
"What engine does BitCraft use?
The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "
Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.
I didn't truly know and I didn't want to just throw out a guess so I just asked. They mentioned they have a basic hand rolled system for their physics. So not using unity physics.
I guess making the claim that is was more complicated might have not been right for me to do, but it would be hard to believe that they did the degenerate case of O(n^2).
Speculation: I have only written a physics engine once during college (so please excuse my ignorance), but I think for a basic mmo a simple chunk and AABB approach would work. It would be easy to query for the surrounding chunks and just run the collision on that subset. I know one of the team members was working on porting a minecraft 1.7.3 server at one point, but I don't know if they got up to the point of moving collision off of the server and into the database.
Thank you for asking and forwarding the answer. I appreciate your comments.
Speculation as well: Looking at the trailer for Bitcraft, it looks like they have articulated characters and cloth physics. This raises more questions for me.
I am contributing to a project by a SpacetimeDB community member to get Rapier running within Unity. Instead of trying to get Unity PhyX running on the server, we just use a deterministic Rust physics engine on both client and server. It is a mostly complete drop in replacement as it stands and is deterministic (Unity's PhyX is not). We'll keep improving it!
We rely on the guarantees of Rapier's determinism. I haven't done extensive testing on the determinism claim yet, but it has held up so far.
https://rapier.rs/
