Re: "RESET"

On 5/25/2025 12:18 PM, Carlos E. R. wrote:

On 2025-05-25 04:01, Don Y wrote:

On 5/24/2025 5:37 PM, Carlos E. R. wrote:

 ...
 

Then, there are many designs where you can not pull power, because there is an unreachable battery.

>
So, the battery is inaccessible but a reset button wouldn't be?
All the more reason NOT to need a reset button!

 Think phones.

Does "reset" actually reset the phone's CPU?  Or, just reset the *settings*
in the phone?  That's the difference I'm trying to highlight.  Reseting
*settings* is just a UI capability.

Then, it is impossible to guarantee that the device will never find itself in a pickle. No matter how fantastic the designers are.

>
Barring hardware failures, software should be able to sort itself out,

 Should.
 Actually, nobody warranties this. Oh, wait, I remember a company that did warranty it, for limited sized code, and hugely expensive. They did the core software on ATMs or the servers behind them, I don't remember.

There are lots of industries that expect devices to perform as specified.
(The trick is finding competent people to write and review the specifications).
You don't need to test every combination ox X and Y to verify multiply(X,Y)
is implemented correctly; that would be a foolish approach to the problem.
You craft software so you can identify the "corner cases" of interest to
a particular algorithm/implementation and test THOSE.  Then, expect everything
"in the middle" to behave.  I.e., why *should* mul(3,Y) be any different
than mul(5,Y) -- in the GENERAL case?
[This is where you engineer your algorithm and test cases accordingly.  E.g.,
if I perform mul(3,Y) as add(Y, 2Y) then it would likely require separate
testing from mul(5,Y) as add(Y, 4Y).  But, otherwise, the only interesting
cases are mul(0,Y), mul(X,0), mul(X,-Y), mul(-X,Y) and variations on "big"
arguments (i.e., to verify overflow is handled appropriately:  which would
differ based on how overflow is SUPPOSED to be handled -- saturated
arithmetic, etc.)]