Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Monday October 31 2016, @06:16PM   Printer-friendly
from the explosions-killing-everybody-isn't-a-choice dept.

Researchers at MIT have put together a pictorial survey http://moralmachine.mit.edu/ -- if the self-driving car loses its brakes, should it go straight or turn? Various scenarios are presented with either occupants or pedestrians dying, and there are a variety of peds in the road from strollers to thieves, even pets.

This AC found that I quickly began to develop my own simplistic criteria and the decisions got easier the further I went in the survey.

While the survey is very much idealized, it may have just enough complexity to give some useful results?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by Arik on Tuesday November 01 2016, @09:35PM

    by Arik (4543) on Tuesday November 01 2016, @09:35PM (#421412) Journal
    "I've got to disagree with your point."

    OK, that's your right. Try to do so in an interesting way, that's all I ask ;)

    "In any complex environment it's impossible to write bug-free code which will deal with it."

    Well that's a particularly strong assertion, do you have any proof for it?

    "There's a combinatorial explosion which prevents it."

    Well that's still just an assertion, and it's highly questionable. I'll try to rehabilitate it. Common methodologies do wind up hitting something that could be aptly characterized as a 'combinatorial explosion' and it does have the effect you attribute. But that is no proof that the problem is unavoidable. That doesn't mean that it cannot be avoided with good design and careful execution.

    To put this in more concrete terms, it probably is impossible to create a bug-free version of microsoft word, while sticking anywhere close to its current design. No matter how much you polish a broken design it's still broken. But there's no reason that LaTeX could not be polished into a completely bug free form given the proper investment of time and competence towards that goal. The end user, with the caveats already mentioned applying to that term of course; the end user doesn't really care which design is executing behind the scenes. They want to make a pretty document on their screen and then have it pop out of the printer. They rely on the more experienced users, or on the industry, to worry about how to best make that happen. Would they prefer to have bug-free software to use, even if it cost a little more and didn't always work in exactly the same way? Most of them in my experience will answer strongly in the affirmative, if the question is posed that way, but equally most of them are deeply convinced that bug-free software is simply impossible. This is because they do, indeed, see the computer as something that works essentially by 'magic.' We all do that, we see things we do not understand as magic.

    But they're wrong, and good sir, you are wrong as well. Computers do not work by magic. They work by logic.

    --
    If laughter is the best medicine, who are the best doctors?
  • (Score: 2) by HiThere on Wednesday November 02 2016, @06:19PM

    by HiThere (866) Subscriber Badge on Wednesday November 02 2016, @06:19PM (#421778) Journal

    Computers do not work by magic, but people are fallible. You can reduce errors by many standard deviations, but you can't eliminate them. Even formal mathematical proofs have been found in error, sometimes long after being accepted as valid. And you're talking about things that have to operate in an environment much less well defined.

    If you were to assert that it was logically possible to constrain the goals sufficiently that a sufficiently careful process would eliminate all errors, I might agree with you, but even then I'd have my doubts. Formal proof systems tend to require that the goals be stated without error, e.g., but if you're interested in what the thing does, then that it accomplished the formal goals isn't the test. Even then...there's a few craters on Mars that lead me to doubt that even the formal goals can be properly met. IIUC the recent splash was because the software caused the probe to release the parachute too soon. And I'm rather certain that they were as careful as they could figure out how to be. Another was because of incorrect conversion between measurement systems...or rather non-conversion, and assuming the units were equal when one was metric and the other imperial. The errors are often obvious AFTER you notice them. That doesn't help much ahead of time because of the combinatorial explosion of what needs to be considered. Object oriented programming was an attempt to address this, but it was insufficient. It helps. Assertions help. Unittests help. But even if you only use the Spark subset of Ada you can't eliminate all errors, since some are embedded in the specifications, and when you start making the specifications more complex, you get more errors there. (IIUC the program with the unit non-conversion error WAS written in Spark, but that's an impression from a third had report, so it may well be wrong. It could have meant that it was an error that Spark wouldn't have caught.)

    --
    Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    • (Score: 1) by Arik on Wednesday November 02 2016, @09:24PM

      by Arik (4543) on Wednesday November 02 2016, @09:24PM (#421838) Journal
      "Computers do not work by magic, but people are fallible."

      Which is why we have developed elaborate methods for double-checking ourselves.

      "You can reduce errors by many standard deviations, but you can't eliminate them."

      You know the more I re-read this the more I think we must be speaking a different language.

      Of course you can eliminate them! It's just absurd to say otherwise.

      I'm not saying it's trivial, or easy, particularly in the case of complex systems, but to say it's impossible? That makes no sense at all.

      If you truly believe this then I don't even know how you could function.

      Computing is math. And the beautiful thing about math has always been that there IS a right and wrong answer. If it's a very hard problem, it might be a very difficult answer to come to, but to say there are no answers at all? I can make no sense of that.

      "Even formal mathematical proofs have been found in error, sometimes long after being accepted as valid."

      And yet if it were impossible to eliminate error, how would this have been detected? These are errors that have been detected and eliminated - they don't prove your point they prove mine!

      "If you were to assert that it was logically possible to constrain the goals sufficiently that a sufficiently careful process would eliminate all errors"

      I believe that's exactly what I have been saying.

      "Formal proof systems tend to require that the goals be stated without error, e.g., but if you're interested in what the thing does, then that it accomplished the formal goals isn't the test."

      That's just sloppy framing. The proof that the code does what it says it does, and no more, is an entirely separate concern from the question of whether or not the goals were properly formulated. Formulating goals properly is an art of its own, of course, and if your spec is wrong then the program you get to meet it will be wrong, but that's clearly not the programmers fault, it's the fault of whatever entity determined the spec.

      "But even if you only use the Spark subset of Ada you can't eliminate all errors,"

      Again, we must be speaking a different language, because that doesn't even make enough sense to be wrong.

      "since some are embedded in the specifications,"

      Ah, there we go. No. No bugs are embedded in specifications. What you are talking about is faulty specification. Not a software bug.

      Even with specifications, sure it's hard, it's a very difficult task in fact, but do you really believe it's *impossible* to write them correctly? If so then why even bother?

      We might not, we probably shouldn't, expect to get anything beyond the trivial completely correct at the first go, but I can't see why we should believe it's impossible even in theory, as you seem to do. Aim high, see how close you can get, don't give up at the start, that's so sad.

      Unfortunately this seems to be the generally accepted meme these days - everything has bugs, they are just accepted, no one will go to any real effort to eliminate them because they don't realize it's possible. In that way it seems to have become a self-fulfilling prophecy.

      --
      If laughter is the best medicine, who are the best doctors?