Fun fact: his original concept needed 9 pins and therefore was going be forced to have a 14 pin package. A late epiphany got it down to the 8 pin version we know today.
It's not that there is zero applicable knowledge transfer, but there are definitely some fundamental differences between digital components and analog power devices, in particular.
For digital, the transistor are CMOS, optimized to be as tiny as possible, running at < 1V, and with individual devices mostly driving microamps, going up to milliamps in some particular areas of the chip.
For power, we're talking about IGBTs, optimized to handle as much power as possible with maximum efficiency, at hundreds of volts.
They are both semiconductor devices, but they are about as similar as the engine for a sports car vs. for a panamax cargo ship.
He was saying that the III of C major is the V of A minor, and so if you are planning to play in A minor using a set of chords pulled from C major, you may want to add a III alongside the iii.
The skills needed to create a chip and the skills needed to create chip design software are fundamentally different. Of all the engineers I've met who work on the physical implementation and timing closure of digital chips, only a very limited number would have any hope of creating some sort of place and route tool, and it would be rudimentary and inefficient. They are not expert programmers.
Mario Kart on Wii was released in 2008, when the oldest of Gen-Z would have been 11 years old. I'm pretty sure that's too young to be setting design trends.
I have no idea if there are systems on a submarine that might experience extreme temperatures. But for the hull, since it is constantly surrounded by liquid water, I would expect that it does not regularly experience temperatures less than ~0C. Maybe there's a concern when surfacing in the arctic? That said she obviously shouldn't have faked data whether it was stupid or not.
This may not be the level of detail you are looking for, but I found this short tutorial to be effective at explaining the basics: https://learningsynths.ableton.com/
Ultimately, I think using synthesizers does entail a lot of exploratory knob turning, even if understanding the effect of different components can help guide you to the sound you are looking for.
Maybe I can try to explain the parent comment's point a different way. When saying that rust works on types and not on arbitrary specifications, I think he is saying that rust is more limited than languages that support arbitrary specifications. However, by making this tradeoff it achieves a reasonable degree of safety without incurring a ton of overhead.
I believe the comment that types are aligned with the syntax is meant as a contrast to other languages which include specifications written in a format substantially different from or fully removed from the implementation. This can reduce the friction of using type-based verification when compared to formal verification capable of describing an arbitrarily complicated spec.
When discussing the scalability of types, I think he is saying that because types are coupled to the implementation, and don't support non-local reasoning, it is less likely that you will run into issues with type checking as you try to compose many small components into a larger program. In contrast, my impression is that with full formal verification, it can become extremely difficult to properly verify a large system.
Regarding your comparison to C and python, I think it's clear that the parent was comparing the specific type system and borrow checker that Rust provides vs. formal verification, not making a statement about the general concept of a type system. In particular, I don't think it's reasonable to assume he was saying the existence of types provides any sort of safety. Rather, it's clear he was saying the use of a powerful type system (such as that found in Rust or Haskell) to implement a limited specification of the program functionality can provide a degree of safety.
In the original naming scheme, 2nm would be the length of the transistor gate, which is the smallest feature on the device, not a dimension of the whole transistor. It's not meaningful to compare 2nm to the area numbers given above.
Exactly this. It may be useful for OP to consider what the hypothetical opposite of significant digits would be: insignificant digits, ie. digits that tell you nothing. A leading zero can be omitted from a number without any loss of information. A trailing zero, when correctly used in a position that is not below the tolerance, gives you significant information. On the other hand, if you start combine numbers with different tolerances, but do not truncate the result, you will have a bunch of trailing digits that are meaningless in practice because they are below the combined tolerance.
Conceptually HDL is actually very similar to those cases, but with an important difference: simulated time. In an HDL simulator, the simulator starts executing by running code designated to run at time 0 (in Verilog, this is specified using an "initial" block).
Looking first at combinational logic: As the simulator goes through the "initial" code, it will set variables to new values. These value changes will activate event listeners throughout the code ("always @ *" or "assign" in Verilog), which represent combinational logic. So if variable "myvar" is updated, and it is an input to an adder in some other module, the always statement which updates the adder output will be triggered. Whenever a combinational event is triggered here at time 0, it is "scheduled" to be resolved at time 0 + delta, where delta just represents a time after time 0, but before time 0.000...01.
Alternatively, you can schedule events with a specific delay, such as setting up a clock signal to wait 0.5ns and then toggle. You can then setup event listeners to react to the rising edge of this clock signal ("always @ posedge" in Verilog), giving you synchronous logic.
Typically, a simulation will involve a bunch of setup a time 0, combinationally getting every variable to its initial condition. Then there will be no more events scheduled at the current simulator time, so the simulator advances until the next time it has an event scheduled (such as the clock edge at 0.5ns). That value changes from that event will likely trigger many more combinational events that will be resolved before moving onto the next clock edge.
So, all of the scheduling basically works the same as event driven javascript, the big difference from what I can tell is that events are scheduled relative to simulator time, rather than real world time, and the time doesn't advance until everything scheduled for the current time has resolved. This lets us simulate the massively concurrent nature of hardware even using a single simulator thread.
When considering how this looks in actual hardware, you can still consider clocked elements as being event driven, but it's not obvious that it makes sense to think of combinational gates that way. Still, the tools are designed to construct a circuit that gives you the same result as the event driven semantics, as long as you meet timing constraints.
I'm not a simulator expert, so I may be slightly off in my explanation, but hopefully that gives you the general idea!
A typical way to handle this in a functional language would be to create a datatype with a name like "PositiveInt", which just contains an Int inside it. However, in a language like OCaml, you can make it so that users of this type cannot directly create it, and instead must use a function like "makePosInt", which would check that its argument is positive, then give you back a value of type PositiveInt containing your data.
I'm not too experienced with this though, so this is pretty much the extent of my knowledge on this topic.
"Is there any evidence that tweets have meaning? I could easily imagine a world where posters fool themselves into thinking the words they wrote contained their intentions, while readers fooled themselves into thinking they had uncovered those intentions."
As with all natural language, production and interpretation of poems is subjective. Poetry is just an attempt to use natural language without the constraints of prose, in order to accomplish things that are not possible with prose.
Some poets may have a goal to convey a particular idea or emotion. Others may just want to create something moves the reader. Still others may not care about the reader at all. All of these things are okay.
I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call
report_timing -from ... -to ...
When the commands have 50 optional parameters, this method of calling is convenient.
However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.
Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.
Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
There are many effects that contribute to semiconductor aging. Thermal stress and diffusion, as you and the child comment suggested, are definitely part of it. There is also electromigration, which can cause the interconnect to fail. In advanced nodes there are effects related to the magnitude of the electric field and the various material interfaceds, such as hot-carrier injection (HCI). Here's an article which gives explanation of a few aging effects:
Following this logic, if a popular rust crate doesn't prioritize security, it can potentially change people's risk assessment of the rust ecosystem as a whole. So this maintainer's actions could have negative effects on other rust projects with no relation to his. He may not have an obligation to do anything about it, but it's kind of "not cool".
> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything.
I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.
I'm pretty sure the effect you are discussing has to do with the uncertainty relationship inherent to the Fourier Transform [0]. This is very closely related to the Heisenberg uncertainty principle, and states you cannot simultaneously constrain time and frequency, which are the values you need to measure for position and velocity, respectively. In the context of signal processing applications, I don't think the particle nature of light is typically considered, which is why it may not be exactly correct to refer to it as the Heisenberg uncertainty principle in this context. This is a bit outside my domain though, so take it with a grain of salt.
Fun fact: his original concept needed 9 pins and therefore was going be forced to have a 14 pin package. A late epiphany got it down to the 8 pin version we know today.