From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Thu Oct 8 19:19:06 2020 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 49DE6358986; Thu, 8 Oct 2020 19:19:06 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mr85p00im-zteg06011601.me.com (mr85p00im-zteg06011601.me.com [17.58.23.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id C1CCC3568C0 for ; Thu, 8 Oct 2020 19:19:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1602177542; bh=LRbJHeU32qO56WmuVYFrWR4khup7sM8jWpvdcZ8LPms=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=rhFMsxz8fUQj6Jsj/9j5tB0hTWJ2BgK0ytMb2dMVcvr+e7p/TY8d3VP5WHE7lTHDS HPBF2lZHTL7KyAXbs3jZIcEW0TTh+tAG6EH+/AsdEjaUNndUGVVfIMmyBXz80wYtkk Z/qStlldWOMBlj5lAqTjRHsZseaNpyFonKtWRhso0oYraXgeLRn6Yu+vjEKkvGObbG WinvT0uuVa4RCcVkE2+txGYRRtytS8Lh+VnEKS+vr6ciISCSsJLehveDC6F2+emsIk K32Cl+7JbcO7a7SWOnGp4C1xB2aoiIRBFh54Q1+YjwwZKNBR/phxdeU0hySCC/qQYO GhGgEjnxi3R4g== Received: from davids-imac.home (host86-141-29-144.range86-141.btcentralplus.com [86.141.29.144]) by mr85p00im-zteg06011601.me.com (Postfix) with ESMTPSA id 49819920A6A for ; Thu, 8 Oct 2020 17:19:02 +0000 (UTC) From: David Muxworthy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: David Muxworthy Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Fwd: BOUNCE sc22wg5@open-std.org: Non-member submission from [John Reid ] Date: Thu, 8 Oct 2020 18:18:59 +0100 References: <20201008154929.9DDD1358A0A@www.open-std.org> To: sc22wg5@open-std.org Message-Id: <3E01A106-FF2D-498C-A2F3-390A49B13738@icloud.com> X-Mailer: Apple Mail (2.3445.9.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-08_11:2020-10-08,2020-10-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=15 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=950 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2010080127 Sender: owner-sc22wg5@open-std.org Precedence: bulk > =46rom owner-sc22wg5@www.open-std.org Thu Oct 8 17:49:29 2020 > Return-Path: > Delivered-To: sc22wg5@open-std.org > X-Greylist: delayed 487 seconds by postgrey-1.34 at www5.open-std.org; = Thu, 08 Oct 2020 17:49:29 CEST > Received: from smtp-out-6.tiscali.co.uk (smtp-out-6.tiscali.co.uk = [62.24.135.134]) > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > (No client certificate requested) > by www.open-std.org (Postfix) with ESMTP id 5E8D23568C0 > for ; Thu, 8 Oct 2020 17:49:29 +0200 = (CEST) > Received: from [192.168.1.10] ([92.20.143.4]) > by smtp.talktalk.net with SMTP > id QY2ckQWIhXXMUQY2cke00l; Thu, 08 Oct 2020 16:41:14 +0100 > DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; = d=3Dtalktalk.net; > s=3Dcmr1711; t=3D1602171674; > bh=3DR7aiDEfjS+VACXYMKYlxj1JULZIprtfKtEEdnuzsO3M=3D; > h=3DTo:Cc:From:Subject:Date; > = b=3DIhH8YiKRvSKPaMTHXUsJFK5JGL95PAImNT3iC7qX+Oqm+hYqCfzXXeDhYZX+hXxOm > = AS5x68gSJBnDYBIQQ3tho5d490J1Tagxz5TH0tOJGBIYf0cvjJ8W+Y5MhG1oGMtSF/ > YadZst0cbo1f8Av+CaCkAn8BRIE0pkd/r6cqwUTA=3D > X-Originating-IP: [92.20.143.4] > To: WG5 > Cc: Nathan Weeks > From: John Reid > Subject: Vote on interps > Message-ID: <933b5c67-03a9-7f7d-299b-f0ba65f19009@talktalk.net> > Date: Thu, 8 Oct 2020 16:41:19 +0100 > User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) = Gecko/20100101 > Firefox/60.0 SeaMonkey/2.53.2 > MIME-Version: 1.0 > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8bit > X-CMAE-Envelope: = MS4wfEQTbg4AVDca63JXvAqeNan3/3x4sm0bncljWNQxZT/8jmho+B/W/TtvuWJVX7ro2SkYVk= 50SrkLfpZK3/IZEwkF1XGhCxkKpEtAt9GXT5J6bQBCdel0 > = 69XrktKfAe5V1P6dHf12UNhsF5MIVZlvaVvySIXpFb37KRPLsuc3IvMQx6AO6EzOshFN2Fm+m5= c/AFYjaVrePXRcllb0QpdXoKvnffC72kpZEMvRaq2zpH5/ >=20 >=20 > The following Fortran 2018 interpretations are being balloted: >=20 > Yes No Number Title > -Y- --- F18/001 ACOSH principal value specification is wrong > -Y- --- F18/002 Internal procedures in generic interface blocks > -Y- --- F18/003 Pointer association of component of non-definable = selector > -Y- --- F18/004 Program execution sequence with failed images > -Y- --- F18/005 Does INPUT_UNIT really identify the same unit as *? > -Y- --- F18/006 Connection of INPUT_UNIT on different images > -Y- --- F18/008 Contradictory assumed-rank requirements > -Y- --- F18/009 Bad examples in IEEE_ARITHMETIC functions > -Y- --- F18/010 Categories of pure procedures > -Y- --- F18/011 Categories of elemental procedures > -Y- --- F18/012 Internal procedure in a generic interface > -C- --- F18/013 TEAM_NUMBER arguments and intrinsic function are = ambiguous > -Y- --- F18/014 Type of OPERATION arguments to the REDUCE intrinsic > --- -N- F18/015 Example in C.6.8 is wrong > -Y- --- F18/016 Host association changes in Fortran 2018 > -Y- --- F18/017 Final subroutine invocation order > -Y- --- F18/018 Public namelist and private variable >=20 > Comment on F18/013. >=20 > Edit for [20:30] 3.145.4 team number, definition. > The edit and its expanded version are not consistent. I suggest > removing "(5.3.4)" from the expanded version. I think that this > reference is unnecessary with the term "sibling teams" defined > (see edit for [20:27+] Terms and definitions). >=20 > Reason for no vote on F18/015. >=20 > Nathan Weeks has pointed out to me that there are three problems with > the new code for C.6.8 in N2176, viz >=20 > 1. The code for choosing the number of spares does not correspond to > the comment for it. >=20 > The simplest solution is to change "10" to "9" in > the line > images_spare =3D MAX(NUM_IMAGES()/100,0,MIN(NUM_IMAGES()-10,1)) > but I prefer the suggestion of Anton Shterenlikht to replace this > line by > images_spare =3D 0 > if ( NUM_IMAGES() .GE. 10 ) images_spare =3D 1 > if ( NUM_IMAGES() .GE. 200 ) images_spare =3D NUM_IMAGES()/100 > It is absolutely clear what this does, which I see as an example of > good practice. It does not need a comment to explain what is going on. > Therefore I suggest changing the comment to > ! Choose how many images to keep as spares. >=20 > 2. The variable images_used is incremented only on image 1 but is > referenced by other images near the beginning and end of DO outer. >=20 > The statement > IF (THIS_IMAGE () > images_used) done =3D done[1] > near the end of DO outer may be replaced by > IF (team_number =3D=3D 2) done =3D done[1] > which avoids the problem here and I think it is an improvement anyway. > A simple solution for the use of images_used near the beginning > of DO outer in the statement > team_number =3D MERGE (1, 2, local_index<=3Dimages_used) > is to make images_used a coarray and replace "images_used" by > "images_used[1]" in this statement. This will need the addition of a > SYNC ALL statement just before the statement > outer : DO > to ensure that the correct value is used on all images on the > first iteration of the loop. >=20 >=20 > 3. The intention is that on each cycle of the DO iter loop, a > calculation is performed on the worker images and if any of them fail > during this, the calculation is resumed from a checkpoint with the > failed images replaced by spares. On resumption, the variable > read_checkpoint should have the value true on all the worker images > so that they access the checkpoint data. On a replacement image, > this variable will still have its initial value of false. >=20 > A simple way to fix this is to change the initial value of > read_checkpoint to true. The subroutine simulation_procedure will need > to keep track of which checkpoint data to use or that none is > available because this is an initial call. The statement > read_checkpoint =3D .FALSE. ! Initial startup, not from checkpoint. > should be replaced by the statement > read_checkpoint =3D .TRUE. > This ensures that read_checkpoint has the value true on a spare > image when it first comes into use. For clarity I also suggest > changing the declaration of read_checkpoint to > LOGICAL :: read_checkpoint ! If read_checkpoint true on entering > ! simulation_procedure, go back to previous check point if one > ! exists. >=20 >=20