807 karma · joined April 20, 2012
I think you should look more into Ada. The only "runtime" is for the exception handling and bounds checking, both of which can be turned off if needed.
And I don't know where you got that "3 times" figure from? Do you have an example you are referring to?
If what you are getting at is that it is not widely used/not used in anything “successful” and thus just a pipe dream, then I understand your concern. But that doesn’t mean it can’t be a useful strategy for some fields nor that it couldn’t produce more reliable systems.
One illuminating example was a calculator application which had numerous errors and crashes which stemmed from intricacies of the UI implementation. By designing it as a statechart transitions are made visible and relationships are clear. The book provides three more examples.
In addition to the posted blog post, there are two more concepts in statecharts that I think are important: history and concurrency. They are not easy to explain in this comment, but the gist is that “history” allows for a simpler expression of returning to a previous state and “concurrency” formalizes the behavior of having concurrent states.
I’d recommend anyone to take a look at the book and I’d especially recommended to anyone who is a little skeptical of the idea of statecharts. I think the biggest argument against statecharts is that it requires you to specify your actual design, instead of just hacking on the code.
You don’t need anything fancy – but you do need to understand your requirements and thoroughly simulate and verify the intended behavior.
Package names are, in some fashion, marketing and branding. The manufacturers publish their own specs and do adhere to them. There are also standards (mentioned in other comments), but they are typically more general.
I’m not saying this is ideal – but that is simply the reality.
A lot of good stuff has begun to happen in this regard. At least KiCad has a large and pretty decent quality collection of footprints; I think other tools are making similar efforts.
However, I wish they would make it easy to adjust these footprints or make derivatives of them, without having to essentially redraw them.
For a looong time I’ve wanted to apply geometric constraint solving to drawing footprints. This would allow for having a base footprint which defines the constraints and then parameter files could introduce the specific dimensions needed. I’ve been working on it at https://github.com/henrikh/footwork-ecad and the parts are there, but I’d love to collaborate on it with someone :-)
Furthermore, there aren’t really any standards for packages and hence it is difficult to trust foorprints. A TSOP package from one manufacturer manufacturer is not necessarily the same as a TSOP package from another. This is not a hypothetical — I’ve been bitten by this.
There are tools to assist in and automate a lot of this, but since most of the time is spend on other parts of a product it simply isn’t very critical.
Overall if you don’t know Ada I’d recommend that you take a look at the features of it. It has very similar design goals as your V.
Second, you might (will) not be able to completely compress the data. A picture might be worth a thousand words, but they still take out a megabyte or so on disk. That makes for about 1000 bytes per word ;) So the entropy/information of a picture might be very small ("A dog jumping into water"), but we have no chance of truly understanding a general source (reality) and expressing its full machinery.
Think about the difference between JPEG and PNG (or GZIP and a JavaScript minifier). They are designed for completely different assumptions about the source and even receiver. JPEG assumes that the most important part of an image is the human-visual understand; PNG is lossless, but assumes high inter-pixel dependence. GZIP assumes general bytes (I think); JS minification assumes that a there is a more fundamental representation of the source without noise (formatting, comments, reasonable names, dead functions).
It is actually a very reasonable assumption for almost all kinds of data -- given that suitable compression is applied. Data, which is well-compressed, is essentially uniformly random.
When p('a') = p and p('b') = 1 - p, it means that the probability of 'a' and 'b' do not depend on anything. The probabilities must sum to 1, since it is the certain event, so p('a') + p('b') = p('a' + 'b') = p + 1 - p = 1. That is when we assume that only the symbols 'a' and 'b' are possible.
If there was a relationship between 'a' and 'b', say that 'b' always occurs after every 'aaa', then the when we receive 'aaa', we know that the next symbol is 'b' -- always.
So in this case the probability of 'b' has a relationship, a condition on the history, which would be written as p('b' | hist = 'aaa') = 1. A much more useful framework for this is a Markov process the a history/memory of 3. A graph for such a process can be seen here: https://mermaidjs.github.io/mermaid-live-editor/#/view/eyJjb...
Each node is a state and the edges represent the possible outputs. The rul for such a graph is that the probabilities of the "leaving" edges must sum to 1 -- we must of course always leave the current state we are in. Notice that it takes a sequence of 'aaa' to enter node "D", afterwhich we _must_ output a 'b'. Using some matrix formulations it is possible to calculate the probabilities of 'a' and 'b' (the stationary distribution I think it is called).
And to return to the first point, why is independence a reasonable assumption. In the Markov process, in node D, we known that we must always output a 'b'. In terms of information theory, if we receive 'aaa' then the 'b' is given and provides no new information. There we can perfectly predict it and we could also remove it (compress the data), without _losing_ information.
'abaabbaaab'
contains the same information as
'abaabbaaa'
since we _know_ that there must be a 'b'.
I hope that explains why independence is reasonable.
A bit challenge, I think, is that the current list is overwhelmingly big and it would really benefit from being more digestible/navigable. But there is only so much time in the world...
If you find something which is unclear or could be better, then please tell.
For electronics there are a lot of small things which should be considered in each design. The must-haves are covered by standards and regulation, but there are many many other considerations which makes life easier or catches errors: checklists are an obvious choice.
So to make it easy for myself I bought http://pcbchecklist.com
It is mostly focused on being comprehensive, but every now and then I have some free time to expand on it.
The original article even includes an example of using Cube to configure the clocks and then use those configurations together with Rust.
I agree that it isn’t ideal at all and kinda wonky. But more links in the datasheets would be nice.
CAD packages ship with or have collections of common footprints, but be aware that there aren’t truly standards and two footprints might be named the same but have quite different dimensions (even within a single manufacturer). It is rare but it happens and thus it is worth checking.
KiCAD has a large repository of common footprint layouts which I believe is of a reasonable quality, but I have never used them myself.
However, Allen recommends finding a thresholds which fits your situation.
Right now it is a tool for myself and my work, which puts a priority on being comprehensive; but the licensing is liberal and I’m open to input.
Yet, I'm genuinely curious, why isn't GCC up to snuff?
* Edit: Which of course limits general adoption.
If anything, I can take solace in the fact that it is very much alive despite the exaggerated rumors of its death. I'd encourage everyone to try it out and steal all the ideas.
Is it purely a matter of what is well-branded?
He kind of touches upon it in the talk with the TV-SAt 1 situation where operations really got to be creative and find some solution to learn about the problem. Other great examples of this mindset are the quite successful Mars rovers, the Voyager spacecrafts and the Huygens probe.
It is well established that “knowing more” is not really a thing; we just learn to further understand relations and distinctions, feeding our ability to know of more things we have yet to learn.
I recently completed a biography[0] and the subject in question lost all his responsibility, in turn it let him suddenly have the time to pay attention to the small details relating to his former work. Now, I’m not interested in loosing my responsibilities, but I do want to give them the attention they deserve.
[0]: The Power Broker, Robert Caro