I'm curious about it and your thinking on how to track things over time and see what has surprised us since we got started. It is useful to note down every time you (or your team) sets an expectation with someone (or another team) and then make sure you don't forget about that. It's also useful to be deliberate when setting expectations.
Having a public journal could well work for noting down when expectations are set and whenever there is a meeting of minds. I've found when tracking things like this that the amount of data can quickly grow to the point where you can no longer quickly and easily reason about it. The success seems to live and die on the data visualization or UI/UX.
Ok, I'll bite. From the article I can't really figure out what collaborating by contract (CBC) is, how it works in practice or how to introduce it to an organization.
A search in Google for "Collaborate by contract" gives three results, all from the same person, all in the last few weeks. Including this new article it's 1776 words in total on CBC. It doesn't seem to be real or something that has been tried out in an organization. It appears to be Al Newkirk's idea for a system that could work, but has not been tried.
Specifically, I'd like to see an example of a contract and who agrees to it; what the journal of contracts looks like; what happens when after an agreement everyone learns something that they didn't know when the agreements were made; what are the leaders committing to and what happens when they fail to deliver that?
It sounds like you've got something specific in mind when you say, "modeling". The term modeling is used in a lot of different situations to mean different things. For example, it could mean to make a 3d model in Blender, it could mean to pose for someone to paint you or to take a photo, with databases it's used to mean modeling the data, with statistics it's used to mean finding a way to simply represent and reason about the data (create a model of it).
The things you've listed out make me guess you want to write 2d or 3d image rendering software. Is that right?
If that's the case, there's no substitute for trying to recreate certain algorithms or curves using a language or tool that you're comfortable with. It'll help you build an intuition about how the mathematical object behaves and what problems it solves (and doesn't). All of these approaches were created to solve problems, understanding the theory of it doesn't quite get you there. If you don't have a good place to try out functions, I recommend https://thebookofshaders.com/05/ , https://www.desmos.com/calculator , or https://www.geogebra.org/calculator .
A good place to start is linear interpolation (lerp). It seems dead simple, but it's used extensively to blend two things together (say positions or colors) and the other things you listed are mostly fancier things built on top of linear interpolation.
A final note: a lot of graphics math involves algebra. Algebra can be fun, but it also can be frustrating and tedious, particularly when you're working through something large and make a silly mistake and the result doesn't work. I suggest using sympy to rearrange equations or do substitutions and so on. It can seem like overkill but as soon as you save a few hours debugging it's worth it. It also does differentiation and integration for you along with simplifying equations.
Thanks for that! Here is a longer video about the scanimate, including demos of a currently working machine and an interview with an operator and an engineer.
Yes and no. The H-1B visa is "dual intent" [1] and you are allowed to apply for and receive a green card (permanent resident card) while on an H-1B. After 5 years with permanent residence you can apply for citizenship. It is a common path, and the intention for the majority of people on an H-1B visa.
It's a trick I stole from ext2, and simplified. In that filesystem there are three bitsets: one for reading, one for writing, one for fsck. If you don't understand a bit you can't do that action.
For most protocols there's only reading and writing, so you can use odd bits to mean "backwards compatible features, you can read even if you don't understand" and even for "stop, we broke compat".
That's a good idea for filesystems. But OpenTimestamps Proofs aren't really "written to". They're created, and then later validated. Also, being cryptographic proofs, my philosophy is the validator should almost always understand them 100%, or not at all, to avoid any false proofs.
That's also why I picked a binary encoding: it's difficult to parse an OTS proof incorrectly. An incorrect implementation will almost always fail to parse the proof at all, with a clear error, rather than silently parse the proof incorrectly.
Motion sickness in Far Cry is why I stopped playing first person or any 3D games. It has taken about 20 years before I seriously tried again and figured out that with higher frame rates and wide enough FoV I could actually play them again.
I have a DM42 and have had it a few years. I haven’t had to replace the battery yet. There are times when I used it everyday, and times I leave it sitting on the shelf for months. I also have an HP42, and it eats batteries. I assume it has a fault.
Wouldn’t two symbols with a 1:1 ratio have four possible bit patterns for two bits? (00,01,10,11) With the ratio only happening on average over a large number of bits?
Id there really could only be 01 or 10, then those are the two symbols in the alphabet, and you only need one bit to pick the next symbol (two bits of output).
I'm curious about it and your thinking on how to track things over time and see what has surprised us since we got started. It is useful to note down every time you (or your team) sets an expectation with someone (or another team) and then make sure you don't forget about that. It's also useful to be deliberate when setting expectations.
Having a public journal could well work for noting down when expectations are set and whenever there is a meeting of minds. I've found when tracking things like this that the amount of data can quickly grow to the point where you can no longer quickly and easily reason about it. The success seems to live and die on the data visualization or UI/UX.
reply