There's hardly a standard for a 'quality' contribution to discussion. Many styles, many opinions, many ways to react and support one's statements.
If anything, it had been quite customary to supply references for some important facts. Thus letting readers to explore further and interpret the facts.
With AI in the mix the references become even more important, in the view of hallucinations and fact poisoning.
Otherwise, it's a forum. Voting, flagging, ignoring are the usual tools.
"...C is my favorite language and I love the freedom and exploration it allows me. I also love that it is so close to Assembly and I love writing assembly for much of the same reasons!"
I wonder what is author's view about user's reasons to choose a C API?
What I mean is users may want exactly the same freedom and immediacy of C that the author embraces. However, the very approach to encapsulation by hiding the layout of the memory, the use of accessor functions limits the user's freedom and robs them of performance too.
In my view, the choice of using C in projects comes with certain responsibilities and expectations from the user. Thus higher degree of trust to the API user is due.
I always thought that the functions did not need a call keyword, as they normally would return a value, so that functions would appear in an assignment. So one just uses the function.
What needed a CALL was a subroutine, which effectively was a named address/label.
Indeed it would be just as possible to GOTO the address/label and then GOTO back. CALL keyword made the whole transaction more comprehensive.
So in a sense it was similar to calling up someplace using the address number. Often times this would change some shared state so that the caller would then proceed after the call. Think of it as if a 'boss' first calls Sam to calculate the figures, then calls Bill to nicely print the TPS report.
Eventually everything became a function and subroutines were associated with spaghetti...
Now, why is that it's called routine (aka program) and subroutine?
Well, apparently [0],
in a 1947 document "Planning and Coding Problems for an Electronic Computing Instrument, Part 1" by H. Goldstine and J. von Neumann it is stated:
"We call the coded sequence of a problem a routine"
I thought a prime time for contacting the parents is right after school when picking up the kid. Everyone is there waiting, so it's just natural to chit chat, esp when the kids are friends.
I'd count also those memorable school talent shows/performances and events. Another reach out avenue is volunteering, these have a higher chance to match parents with similar availability at least.
Does HFSS visualize the field in real-time or a user needs to set the geometry/parameters then precalculate the field and only then be able to explore the visualization?
Say, if I wanted to see immediate effects of changing an incidence angle, could I just "scroll" the incidence parameter?
HFSS does a typical FEM matrix solve then displays the results. It is often used for very complex or large problems, so as far as I know it isn’t set up for instant display of results. That would be a neat feature for small problems.
I've never tried running for a really long time but when I was doing testing I would not recharged the batteries for days. I would say an easy 15 to 30 minute. But like I say, I'e never tested. Now I think I will. Thanks
We live in a world full of uncertainty. When someone you know is in a current need, helping that person is one way to hedge against the uncertainty of the future. Who knows, one day you may need such help too...
That's why this advice is common. It's important to be clear about the reasons for reaching out.
If anything, it had been quite customary to supply references for some important facts. Thus letting readers to explore further and interpret the facts.
With AI in the mix the references become even more important, in the view of hallucinations and fact poisoning.
Otherwise, it's a forum. Voting, flagging, ignoring are the usual tools.