I guess we need to query your ability to add up integers and perform simple logic.bob wrote: ↑Fri Feb 21, 2020 11:53 pmAgain you miss the point. Someone says "there is no example of this... (whatever this is)." ALL it takes is one example where it does exist to make that statement false. I gave an example of a serious failure for every specific software package he mentioned. Hence NONE of the examples were valid, because ALL of them had exhibited failures.chrisw wrote: ↑Fri Feb 21, 2020 10:44 pmThose anecdotes prove nothing. One anecdote about your wife at an ATM doesn’t scale to all financial software products. Maybe there was a paper jam. Maybe the bank staff thought it better not to have an argument, so they shelled out. I got shelled out once by my bank when I told them my cash withdrawal was 20 GBP down, they didn’t count anything, they just okay, we believe you and gave me 20.bob wrote: ↑Fri Feb 21, 2020 9:38 pmLet's take a few of those.Rebel wrote: ↑Fri Feb 21, 2020 8:46 am It's all about the demand.
Compilers can't afford to produce buggy executables.
Financial programs can't afford flawed numbers.
NASA can't afford buggy software when they launch people into space.
Boeing can't afford buggy software and sometimes it happens anyway with devastating results.
Does bug free software exist? Of course. Because that's the demand. But not after tireless testing.
Bug-free chess programs is not a good example because there is no demand. Nobody gets hurt by a bug.
I had a couple of students that worked at Nasa. On the first space shuttle launch, they got down almost to liftoff but could not get the main pumps to turn on to "light the fire". The problem turned out to be a parallel program. Four separate computers had to initialize, run their sanity checks, and then the results were compared and had to match. They had matched thousands of times in testing. On the day of the first launch. They did not. And they would not through several resets. They found the bug, but it took some time. And if you know NASA, it had been tested almost exhaustively before "showtime". On Apollo 11, the flight control computer on the LEM crashed repeatedly during the descent to the moon. Neil Armstrong had the daunting task of landing with no nav computer data to help. Fortunately, he was up to the task. So NASA could not produce bug-free code.
GCC has produced buggy code many times. As has Apple's CLANG, as has microsoft's visual C++. There are plenty of publicly available bug reports for all three. I found/fixed some in gcc when I started to use long long.
My local bank, very large chain, had a software bug that hid certain transactions from the end user. They found/fixed it. There have been a few of those with credit cards, etc. Three weeks ago, my wife stopped by the bank to withdraw cash from the ATM. Thing took her card, processed the transaction, gave her a receipt and her card back. No cash. She checked the account from her phone and it showed the money had been withdrawn. She went inside, after a couple of hours where they went out and counted the cash in the machine, they verified their total was off by the amount of her withdrawal and it was fixed. No bugs?
We all know about Boeing here of late. They have found bug after bug after bug in their 737 max software. Which DID cause a crash. Which killed over 300 people. No bugs? Same in the US F35 fighter jet. Hardly a good example you chose here.
This discussion has been about the claim that bug-free complex code is doable within reasonable time-frame (IE maybe 1 month to 5 years, not 5000 years). It doesn't matter how the bug will affect end users. IE I would hope that heart pacemakers are thoroughly tested. Since they use computers, bluetooth, etc. Fortunately the code is actually small enough that it can be tested enough to be ALMOST 100% safe. That chess programs don't cause anybody to be hurt doesn't matter. The people that use it for analysis might disagree if the program gives them a bad move in a correspondence game and they lose because of it.
So again, all of your examples are bad because all are incorrect due to the examples given above. So back to square one. You keep claiming compilers are 100% correct. As someone who has worked on them many times, that is not just wrong, it is incredibly wrote. Bugzilla might open your eyes.
Banks actually seem pretty robust, clearly there are risks in the operations of capital markets, and risk is built in to fractional reserve banking, but adding up all the electrons seems the least of their problems.
Appeals to authority don’t prove anything either. Authority is often wrong, and step progress wouldn’t be possible if authority was always right, as showed Einstein and Newton before him, just for starters.
What you haven’t done is demonstrate chess engines have crossed over into a level of complexity where there will always be bugs. Squaring the number of if statements or whatever it was and generating some large number was smacks of desperation, I have to say. Chess is a small bounded system with fixed rules. You can test everything, you can do. Didn’t think I’ld be teaching an American about can do.
That your wife anecdotally had a problem at an ATM of Great Western Alabama bank (which may well not even have been a software problem as already noted) has no bearing at all on the status of the software at California National Bank, let alone any of the other hundred banks dotted atound elsewhere. Let’s put it another way, one egocentric chess programmer who runs around telling everybody how right he is about everything doesn’t mean all the other chess programmers are either egocentric or running around waving righteousness flags. Does it?
Chess engines are not banks. The level of complexity does not compare. And banks are astonishingly robust at adding up electrons and shuffling them around, btw.How many banks have had their systems hacked, account numbers and credit card numbers copied? Isn't writing software that doesn't provide the level of security claimed a software bug? Certainly seems so to me.
your engine is modular. Did you write functions that are not self contained and can cause damage to other modules, or did you make each module safe under all circumstances?
Why is it always MY responsibility to prove something I claim
when YOU provide zero proof of any kind? In the case of Crafty, with 2^543 possible paths through the main engine, I would certainly claim THAT can not be adequately tested.Oh, you poor lambkins. Such a tough life.
Is your move generator unreliable or are you 100% okay with it? I’m 100% okay with mine, I would guarantee that given a verified board it would only ever produce the full list of pseudo legal moves and not trash any other external objects. I’ll put 50,000 GBP on it, want to take the counter risk? Rhetorical question, of course you wouldn’t, you’ld be placing the bet on your own move generator. That’s one module, there aren’t many more. Care to challenge on another module? Make move and unmake move? Recursive search? Evaluation function? You can’t guarantee each of those under all board state conditions? That would be bizarre.
All your modules are guaranteed, you put them all together with recursive search, there’s some stuff to cover in hash and threading but nothing that can’t be dealt with. You already know what can go wrong.
Where’s the problem? Let’s hear some Can Do from you.
Over where? Wrong country. Look up a map. Chess engines are not airport software systems.
Software engineering 101. BTW that is not "squaring the number of if statements." This is simple math. If you have one if, there are two paths, one with c1 true and one with c1 false. If you have two if statements, you have 4 possibilities. c1 is false and c2 is false, then c1 is false, c2 is true... obviously 2 ^ number of if statements. And again, this is something discussed in ANY software engineering book. So how is quoting a specific and well-known number "desperation?" If we were discussing the area of a circle, would mentioning Pi be desperation? That statement makes absolutely zero sense.
BTW you are not "teaching an american about can-do." BTW you just had a software failure over there. Look up Heathrow software glitch for details.
You really can’t guarantee your own pseudo move generator? Bizarre.NO software is immune to bugs. None at all.
do you really have to go looking simple words up in dictionaries? Anyway, you got the wrong meaning of word as used. never mind.
Finally "anecdote": a short amusing or interesting story about a real incident or person.
desperate.
The things I quoted were ALL "real events" although I doubt any victim families of the boeing software glitch would find any of this amusing.
the wife anecdote does not travel to all other banks. You would need many wives each with a different bank account.
This is a simple concept. To prove something exists only requires ONE example that shows that. No more.
To prove something does exist you need to find it. Same argument. I’m waiting for your pseudo move generator to fall over, but I think you tested it okay already.To prove something doesn't exist requires that ALL possible things are examined and no example is found.
chess engine sub-structure can be guaranteed. So can the search algorithm (which basically repeats the same things over and over at each node).
A BIG difference in effort. Hence that testing finds bugs, but says nothing about their absence.
Where’s your problem?
the anecdotal wife story proves nothing about any other bank software, it may well prove nothing about your wife’s bank software either. You refuted nothing, other than maybe your unlimited belief in your own brilliance.
Is this REALLY that hard to understand. If the two of you give examples, that I can easily refute,
hahahahaha!! You really want an answer to that one?
am I the one that is at fault? It certainly seems so.
only that a nonsense piece of maths because your engine broken down into manageable and non interfering sub units, all of which are easy to guarantee.
I gave a formula E = 2 ^ number of if statements. I don't have any particular number about the lower bound on E that guarantees no bugs. But it would not be a very large number. Just 32 if-tests gives 4 billion possible paths. 4 billion is not doable for testing cases.
You are hopelessly over-invested into bigging up the complexity of chess engines and chess programming and subsequently engage from hopelessly biased argumentation positions. It gets pretty tedious telling you two and two makes four when you tell me that’s impossible to prove because the fp processor needs a billion transistors to get 4 and it can’t always be guaranteed that a neutrino won’t strike.
Anyway, feel free to be wronger. have a nice day.
The last SE book I used gave a pretty interesting example. IBM used Rational Rose (software development environment) to develop a software program that had an amazingly low number of bugs detected after distribution to end users. And they had stacked the deck by looking at ALL IBM employees and choosing the best of the best to work on the project. So the very best programmers, using a high quality software development environment, could NOT produce a bug-free program. If they could not, who could? The programmers you were using?Please. If there were no bugs in chess programs, all we would see would be version 10, then version 11, etc. No 10.1, 10.1.1, 10.1.2. On my apple watch we are up to 6.1.3, on my iPhone, we are up to version 13.3.1, on my MacBook, we are up to MacOS version 10.15.3. The very idea of no bugs is refuted by evidence every where you look. Just because software doesn't crash does not mean it has no bugs. Just because it doesn't produce an illegal move doesn't mean it has no bugs. Only one thing will prove the absence of bugs, complete testing of all paths with all possible data values. Computationally intractable and getting worse each year as software progresses. And even software reuse, partially the result of object oriented programming has produced its own set of amusing quotes by famous people. "For software reuse to work, the software must be usable first." I've given up on that idea. I still occasionally find a glitch in the C library, which is a sort of old version of reuse. I don't want to inhered bugs in code that I didn't write because those bugs are much harder to find and fix if I don't understand the code I didn't write.
Need I say more? Ed gives examples, I give each example of his a refutation that anyone can confirm. I gave you a formula for path testing which is getting closer to eliminating all bugs. You want some magic number N which says software below N can be bug free, software above N is not. Not exactly easy to define "n" and nobody has tried. We could probably test 4 billion test sets realistically. That will cover a program with just 32 if statements. That doesn't sound very realistic. Just my Search() code has 84 if statements. 2^84 is not possible. Evaluate() has almost 200 if statements. 2^200 is way out there.
A single day has 86,400 seconds. A year has about 32M seconds. 64 if conditions gives basically 10^19 pathways. doing 1 test per second would take 576 billion years. 1000 tests per second cuts that to 576 million years. one test per microsecond cuts that to 576 thousand years. And this is just for 64 if statements. So, how many if statements does it take for you to say "this is complex code?" 64? sounds pretty simple to me, but from the above, completely impossible to exhaustively test to prove the absence of bugs. To get reasonable time, the number of if statements probably needs to drop down to 32 or so which gives us 4 billion test cases which is doable. I am not going to try to pick a number N here because it seems completely irrelevant. Anything > 32 is computational challenging. Anything > 64 is computationally intractable. Anything > 128 is computationally impossible for all time.
All you have on your side is a feeling. On my side I have thousands of people that understand software development / engineering that are saying bug-free is only a concept that will never be reached. Backed up by billions of lines of code with plenty of bugs. A commonly used number is that there is one bug for every 1K lines of code in RELEASED software. IE it has already been tested to death. And the fly in that ointment is that is the DETECTED number of bugs, not the actual total. A serious problem exists. And it can't be waved away with "a foreign manager that waved his hands and eliminated all bugs."
