From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA19708 for caml-red; Fri, 13 Oct 2000 12:04:11 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA11103 for ; Thu, 12 Oct 2000 19:02:30 +0200 (MET DST) Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9CH2SX15657 for ; Thu, 12 Oct 2000 19:02:29 +0200 (MET DST) Received: from dylan (dialup07ip083.tus.azstarnet.com [169.197.33.83]) by cepheus.azstarnet.com (8.9.3/8.9.3) with SMTP id KAA19726 for ; Thu, 12 Oct 2000 10:02:25 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <000601c0346e$b943a940$210148bf@dylan> From: "David McClain" To: Subject: Re: Undefined evaluation order Date: Thu, 12 Oct 2000 10:06:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: weis@pauillac.inria.fr ... but the same would be true the other way too... (0.0 * a * b). I am a numeric programmer and these things are unavoidable no matter how you choose to order the evaluations. If (a * b) raises a NaN then what would be the value of 0.0 times that? The IEEE spec would say the result would have to continue to be a NaN. I normally perform all arithmetic with exception processing supressed or deferred. The only time an exception is useful to me is if there is some remedial action that could be taken. I want my NaN's and INF's to appear in my answers. In particular, if something should go awry at one point out of millions I don't want that one point to hose my entire calculation. (Note that I do not look kindly at the Fortran way of aborting an entire program for one bad point...) In signal and image processing, especially in a real-time environment, you just drop the bad points on the floor and continue running. - DM -----Original Message----- From: Dave Berry To: Greg Morrisett ; caml-list@inria.fr Date: Thursday, October 12, 2000 4:53 AM Subject: RE: Undefined evaluation order >May I toss in a possible complication? I'm thinking of numeric code, and >the possibilities of optimisation. To take a simple example, (a * b * 0.0) >should always be zero. Except that (a * b) could raise an exception or >return a NaN. I imagine there exist more complex numeric optimisations that >a compiler may wish to perform. > >So my question is whether numeric operations might be hampered by requiring >a defined evaluation order, even in the case that changing the order has a >visible (and desired!) effect. I'm not a numeric programmer, and I know >there are some numeric programmers on the list, so perhaps they would care >to comment. > >Perhaps an alternative would be to specify the evaluation order, but allow >the compiler to modify the evaluation order to reduce the possibilities of >NaN results or numeric exceptions. It wouldn't be as elegant as a universal >rule, but might be more practical. > >Dave. > > >-----Original Message----- >From: Greg Morrisett [mailto:jgm@cs.cornell.edu] >Sent: Wednesday, October 11, 2000 1:23 PM >To: 'Hendrik Tews' >Cc: caml-list@inria.fr >Subject: RE: Undefined evaluation order > > >> I would like to vote for leaving the evaluation order >> unspecified (implicitly repeating all suitable arguments from >> previous postings). The specification should only regulate the >> necessary things not more. > >I don't see why. As far as I can tell, the only reason >to not specify the order is for performance. I've never >seen a systematic study that significant performance >gains are achievable across a range of applications. >Most compilers only do very local re-orderings, and >these can typically be achieved with local effects >analysis (at least for languages like ML that are >relatively effect free.) > >We've heard promises of expression-level parallelism >since the dawn of Fortran and Lisp. But for 40 years, >they speedups have yet to be realized because the granularity >is always too small to do the necessary synchronization >for multi-processors, and the granularity is too large >for instruction-level parallelism (i.e., other hazards >manifest.) If you truly believe that magic compilers >will someday come along and parallelize things, then >why are you worried that these compilers will be stopped >by a specified evaluation order? > >IMHO, there are compelling reasons to at least specify >an evaluation order, if not to standardize on left-to- >right. In spite of the fact that programmer's *should* >realize that expressions could be evaluated in any order, >they tend to assume the order that the current compiler >uses. Then when someone else ports the code, or the >compiler changes, things break. > >As I mentioned earlier, when teaching, it's nice for >a language to be simple and uniform. Explaining to >a student why: > > let x = input() in > let y = input() in > (x,y) > >is not equivalent to: > > (input(), input()) > >is one more thing that confuses them -- especially when >we emphasize that the whole point of anonymous functions >is to avoid naming things that need not be named! > >A standard trick for Scheme coders is, as someone suggested, >to randomize the order of evaluation in the hopes of >tripping across such bugs. Ugh. Maybe the type-checker >should just randomly type-check a few expressions too :-) > >If you're going to have an unspecified order of evaluation, >then I think you realistically need an effects analysis >in order to warn the programmer that what they are writing >is dependent upon the order. Unfortunately, either the >analysis would need to be global (to get rid of all the >false positives) or else you'd have to augment function >types with effects information, add in polymorphic effects, >etc. In other words, you're buying into a whole ball of wax. >Neither option seems all that wonderful. > >-Greg >