This category needs an editor. We encourage you to help if you are qualified.
Volunteer, or read more about what this involves.
Related categories
6 found
Search inside:
(import / add options)   Order:
  1. Nicola Angius (2013). Abstraction and Idealization in the Formal Verification of Software Systems. Minds and Machines 23 (2):211-226.
    Questions concerning the epistemological status of computer science are, in this paper, answered from the point of view of the formal verification framework. State space reduction techniques adopted to simplify computational models in model checking are analysed in terms of Aristotelian abstractions and Galilean idealizations characterizing the inquiry of empirical systems. Methodological considerations drawn here are employed to argue in favour of the scientific understanding of computer science as a discipline. Specifically, reduced models gained by Dataion are acknowledged as Aristotelian (...)
    Remove from this list   Direct download (15 more)  
    Export citation  
    My bibliography   2 citations  
  2. Stephen Bush, Moitra F., Crapo Abha, Barnett Andrew, Dill Bruce & J. Stephen, A Quantitative Approach to Measuring Assurance with Uncertainty in Data Provenance.
    A data provenance framework is subject to security threats and risks, which increase the uncertainty, or lack of trust, in provenance information. Information assurance is challenged by incomplete information; one cannot exhaustively characterize all threats or all vulnerabilities. One technique that specifically incorporates a probabilistic notion of uncertainty is subjective logic. Subjective logic allows belief and uncertainty, due to incomplete information, to be specified and operated upon in a coherent manner. A mapping from the standard definition of information assurance to (...)
    Remove from this list  
    Export citation  
    My bibliography  
  3. James H. Fetzer (1991). Philosophical Aspects of Program Verification. Minds and Machines 1 (2):197-216.
    A debate over the theoretical capabilities of formal methods in computer science has raged for more than two years now. The function of this paper is to summarize the key elements of this debate and to respond to important criticisms others have advanced by placing these issues within a broader context of philosophical considerations about the nature of hardware and of software and about the kinds of knowledge that we have the capacity to acquire concerning their performance.
    Remove from this list   Direct download (4 more)  
    Export citation  
    My bibliography   1 citation  
  4. James H. Fetzer (1988). Program Verification: The Very Idea. Communications of the Acm 31 (9):1048--1063.
    The notion of program verification appears to trade upon an equivocation. Algorithms, as logical structures, are appropriate subjects for deductive verification. Programs, as causal models of those structures, are not. The success of program verification as a generally applicable and completely reliable method for guaranteeing program performance is not even a theoretical possibility.
    Remove from this list  
      Direct download  
    Export citation  
    My bibliography   13 citations  
  5. Nicolas Fillion & Robert M. Corless (2014). On the Epistemological Analysis of Modeling and Computational Error in the Mathematical Sciences. Synthese 191 (7):1451-1467.
    Interest in the computational aspects of modeling has been steadily growing in philosophy of science. This paper aims to advance the discussion by articulating the way in which modeling and computational errors are related and by explaining the significance of error management strategies for the rational reconstruction of scientific practice. To this end, we first characterize the role and nature of modeling error in relation to a recipe for model construction known as Euler’s recipe. We then describe a general model (...)
    Remove from this list   Direct download (6 more)  
    Export citation  
    My bibliography  
  6. Giuseppe Primiero, Nir Fresco & Luciano Floridi (2015). On Malfunctioning Software. Synthese 192 (4):1199-1220.
    Artefacts do not always do what they are supposed to, due to a variety of reasons, including manufacturing problems, poor maintenance, and normal wear-and-tear. Since software is an artefact, it should be subject to malfunctioning in the same sense in which other artefacts can malfunction. Yet, whether software is on a par with other artefacts when it comes to malfunctioning crucially depends on the abstraction used in the analysis. We distinguish between “negative” and “positive” notions of malfunction. A negative malfunction, (...)
    Remove from this list   Direct download (2 more)  
    Export citation  
    My bibliography   3 citations