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.
Actually, that speculation about tweets sounds pretty realistic to me...
But seriously, I think we can all agree that among the literary arts, poetry is the most likely to be accidentally uninterpretable. Due to its cultural context it is also the area where uninterpretability is the most likely to be accepted. This creates an environment where you run a serious risk of developing a culture of meaninglessness.
Some poetry serves the "higher" meaning of discussing political ideas like Claudia Rankine's Citizen: An American Lyric.
Some poetry is made to make you laugh like Billy Collins' Another Reason Why I Don't Keep A Gun in the House.
Some poetry is purposefully inscrutable and difficult because the author wants you to work to understand them. A good example of this might be r-p-o-p-h-e-s-s-a-g-r by E.E. Cummings.
Each of these examples is meaningful in its own different way. I think trying to decide what has meaning is hard because you might automatically discard a work of art that is "just for fun". Isn't play meaningful?
as everybody else in Italy, I had to study the Divine Comedy (which is an incredible work, and I'm glad I had to), and part of doing that is learning multiple interpretations of a single line, variations of people who have read and re-read the work over centuries. It really easily convinces you that, if the art itself can have a given meaning, still many interpretations are bonkers and there might be no hidden meaning at all.
I am sure the same applies, to e.g. William Blake.
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 don't think these are contradictory positions. It's a bit like defensive programming in social space: one can take significant responsibility for one's own work while remaining aware that others with no legal/etc compulsion to likely will not.
> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations.
almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.
> go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time
As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.
If I build something in real life, like a playground, and ask people to come use it, but then through my own negligence it falls apart and becomes a hazard, it is my fault for having created this situation in the first place.
Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.
> Idk why this keeps getting tied back to paid/unpaid
i was responding to a comment about engineering ethics. engineering is a profession. engineering ethics is taught to student engineers in the context of a job, where you're getting paid. taking the (literal classroom) lessons out of context distorts them.
if you go back to your engineering ethics professors and say "gee, but what if i do this work for fun and just stick it up on a web page on the internet", they're going to look at you like you're insane, and then not know what to say.
> If I build something in real life
the last thing this thread needs is more analogies.
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.
So your're correct that there is a Fourier Transform analogy for the uncertainty principle, but in the context of FMCW lidars (which brought up the question of velocity vs position uncertainty), the measurement of frequency actually determines both the position and the velocity. It's actually a problem for most FMCW lidars because you just get 1-2 frequency measurements and somehow need to disentangle what the range frequency is, as well as what the doppler (velocity) frequency is. A massive amount of effort has been put into developing lidar methods and architectures that solve this problem well.
But in summary, the uncertainty principle as encountered in quantum mechanics has ~nothing to do with a trade off between range accuracy and range uncertainty. It's possible that it could come into play in a very detailed treatment of FMCW lidar SNR, in the context of counting return photons, but also not generally necessary there. The time-frequency uncertainty plays a role in that the range and velocity resolution both get better the longer you stare at a signal. So for a given amount of reflected light, at a given range/velocity, there is a fundamental lower bound to how long you must integrate to a) get a signal at all and b) achieve a desired precision.
It seems to be an extract from "Foundations of Field Computation" by Bruce MacLennan, if you want to read the whole thing: http://web.eecs.utk.edu/~bmaclenn/FFC.pdf
He and Dr. Marcolli have a bunch of interesting stuff on their websites if you like this sort of stuff.
