Just for you I will switch my FTP server to run on Port 23.
258 karma · joined December 7, 2022
Really, I am just saying that the statement "you need a GC to own a business" is far too broad a claim to be true.
I do agree that really that the core issue is not with this one particular case, but broadly a pattern of how people are treated, and a failure of due process. People make mistakes. Governments are made up of people who also make mistakes. Process is how you catch mistakes and minimize its occurrence. A failure of due process reduces trust that even fully legal aboveboard immigrants will be treated reasonably and fairly. And that is reducing my confidence that I will be staying in this country long term.
1: Every big tech interview I have been in the visa status is not even a question in the interview process. There is just a simple gate that “can you legally work in the US”? The hiring committee is not even thinking about visa (that’s a HR problem)
2: Are there confounders in that foreign workers are less likely to negotiate? Absolutely.
3: are there confounders in that people who come to US for study are likely already a self selected bunch who are striving to succeed? What are the typical grade distributions between foreign STEM students and US STEM students? Is grade a confounding variable? What happens if we control for GPA?
And finally does H1B abuse happen? Absolutely.
There is a lot of nuance that are not captured by surface level statistics. But nuance does not make outrage.
But instead if I ask it to generate 100 samples, it actually works pretty well.
"You are a weighted random choice generator. About 80% of the time please say ‘left’ and about 20% of the time say ‘right’. Generate 100 samples of either "left" or "right". Do not say anything else. "
I got 71 left, and 27 right.
And if I ask for 50%, 50%. I get 56 lefts and 44 rights.
Fundamentally, all I need to define a graph is a set of vertices v \in V and function Neighbors(v). And that really is all is needed for the most foundational set of graph algorithms.
Everything else are case-by-case constraints. Does A->B imply B->A? is the node set partitionable with certain constraints? Are there colors? labels?
To make things even more general I can go up one level and consider the hypergraph. In which case I just have a set of vertices, and a set of sets of vertices. This can be represented in a myriad of different ways depending on what you are interested in. Of which (non-hyper) graph is simply a special case.
An alternative way to think about it perhaps from the database perspective, is that its a query optimization and indexing problem. Depending on what questions you want to ask about the graph, there will be different ways to represent the graph to answer the question better. Just like there is not one way to represent the abstraction called "Table", there is not one way to do "Graph" either. It really depends on the questions you care about.
The goal in a way is better reproducibility. The memo hashes the contents of the inputs, so if your cell is deterministic (and you cover all the inputs), the memo should give you the right answers. Of course if you want to rerun everything you can always just delete the memos, but properly used it should be a strict performance improvement.
Of course there are many improvements that can be made (tracking if dependent functions have changed etc) and of course there are inherent limitations. This is very much “work in progress”. But is quite useful right now!
1. You can implement "stack-free coroutines" in C with some really entertaining macros https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
2. Does anyone remembers Cilk? Its still the fastest stackful coroutine models I know of.
Having implemented and used both before (for different purposes), I like both, but with a mild preference for the stackful version. Largely because you don't have function coloring problems, and you can actually get a proper stack trace and is so significantly easier to debug when things go wrong.
It is also good to differentiate coroutines from async (they seem to be very interleaved these days). Coroutines are a mechanic to achieve mutual recursion / generators. And that is fine for expressing certain algorithms and systems in a much cleaner fashion. Note that parallelism is not necessarily implied by "coroutine".
Async is a mechanic to "doing something else" while waiting for IO. Fibers or state machines are both different solutions to this problem. Certain coroutine implementations can help with this, but I think it is massively overused. Rust due to the function coloring problem, ends up requiring almost everything to be marked "async". And some golang code I have read seems to overuse goroutines unecessarily. I think use of async should be narrow and minimized, and localized to only the places where it makes sense.