From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81013 invoked by alias); 29 Jun 2017 07:53:36 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 80995 invoked by uid 89); 29 Jun 2017 07:53:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:D*lanl.gov, decades, patrick, H*p:D*edu X-HELO: NAM01-BY2-obe.outbound.protection.outlook.com Received: from mail-by2nam01on0129.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (104.47.34.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 07:53:31 +0000 Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=colorado.edu; Received: from [198.11.30.49] (198.11.30.49) by BY1PR03MB1403.namprd03.prod.outlook.com (10.162.127.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 29 Jun 2017 07:53:27 +0000 Subject: Re: sin_pi and cos_pi To: Gerard Jungman , Konrad , "gsl-discuss@sourceware.org" References: From: Patrick Alken Message-ID: <9432fc8a-1143-5fb3-77ad-07336aead332@colorado.edu> Date: Thu, 29 Jun 2017 07:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DM5PR21CA0031.namprd21.prod.outlook.com (10.172.92.145) To BY1PR03MB1403.namprd03.prod.outlook.com (10.162.127.145) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ac384437-bca0-497e-8b1d-08d4bec3ee70 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:BY1PR03MB1403; X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;3:azOMiKqHbpWionSGYStbFxgR+uSgWpf81o6hUhrE6CJMsd4e3erWRVUXjIrP7b6JpXu8sFaDufK5bzVbLcGrdiADDeYXBKOkrp5U1H/vvmOlGbSp1mvYxJDx7xXL8J0odvFkWVX05cJWD1Mgvf/WPc+acVhh/5mp6Om+fKLfDJ4tiQP1MEsmltE0XBKcBsNcI6UMGPbUAOR0FC90IarVJ776X0Q734cISuDLuZkvRhIDy2HtdkgItfCU/UaL0dinpEMyWsTgTHfx9fmP2OQakOW/1Fp8vN+gu2LtGKVmy+aOE56vBXdY3mOpft4/GNGhr+tywo4DNGkuZGkg2ml16+ht6QH91rxz3U3/rZ8lg02rnGPFDcPIHBll1sAETR0Jx+4pDU4/coTz8Ot5gLT5CfmuK7jFDpfbdp/68Pzya8y3r6mKtKISlgLSE9jUGLDnl7sTGOggzJqwY2hCVBPMJ1OecRjX0L4g2EjoU0EUvMxqw1Mr0bE3dRwWwCvDt9C32ZB1Uc9M2MjrcWNmhn8zXmahrCPo2wfjaxCwyK/ah1ZzvnvViE/jpTYSXe+sTsVkwcHu3r3IDk1+aACYAAHH7jZ2i2Sk+Yaqid5WM9H7E0hmSctrOUwGw3cD+1Ti5TTQ+A1sbt+4sHtBfYaGkLdMAveq1BU8U615CXadTx8ItMfWIeNhjMQzNoX0EUNudI1vQBySb8wcsJ5uLuk2t5hCtOex6Mg9atjjW9ZfAVvMsds= X-MS-TrafficTypeDiagnostic: BY1PR03MB1403: X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;25:Bm+FT2qwMQmnrLiZydXaTm4JkbQB3rw0qTLo3jKHWjhHamFN//+kkJuYMn8tLmFXWDiBCiRzVDiqul5375vCy2p0QssrUd28LG8EUB57eKogDU7GZtDPPGiHpzeauaVjeIXDNvdZwIxQjsl9oeHDWRUKTpcbJNrRrJJWviJSppIDHOnqFKmLxFseXxf7csvV4IFr1ljveUIH/LGojgdWUnzJMtHtxmZe/jJLwK6pqxjr6Vm2rv9OH0O33zjSqnyIRX8bVP4eR58Nw/nF5NIvZMmEIqDVURDJ2zTrf0lxG74CZ//0njlDdSv6tGKPuA4zJN2/WFFvMLnQV3NYDnTikTDrzkbIEX1sneaN6FuYsuIyu3I13fxxBfWrOyPFcB0F7DS9IiPe3B1xBeGoDhjZyyWTirgiLb7ar8rWOwNUIQaOuGrFExr6UcgZGZIPpPwKCVy/3KkLC3w1ZtWrejvrB2OdSro25hezBzKXB/4HCwqmDoTxxOZf+LdExpNSQdCtJzOXJPdPoiYNqHbpe7oDHAOuedtvNx1/I335MQSmciselKMu3wrm6JZ3L3rTgu3FoOcEAjRjdlLi/s3Pl9+omNgAFxpHgWOqUE2bKBSDUMPc+iWoAhkny4XXAURO/tkW1IXfp1RuueUm874IPnDbPJBl2GTWP/dF5/wb2m6YkXYcpGiqmpwBAwUBCiN8fQtFnthL/bc4CAlq9yPOozDV+5+fgmDTw3o7ueCK87Dk0lUbok2TKyWZUXxMcS3CagUgDRRAz8tvxRruTMV5w6ohMSv+sW3NQFO/+o96C4dKRzelWa12NTU3ZnzsvG2eZCQCHf11FenfKJmwqUvY+YZNtMsOC1eVXjDj4rIhYTw4UTp44g9II1oUn1MWh8NgfNMH1vIEl95Wr/0qAaB9r4uw2jE5cf5lVzDVXrPH+5OTKO8= X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;31:YXA+kddGbfuJnJh9+CVJtuMC81ToTXnBBFkoqydyNx5VpXW1NCbbQGrw0z/UJolAx0k8OOAd0cwwg8/n2yMgDQzelMz6YfjkyAWtuNPVAhKEUJdO+6c4dnPubyVbGRE7luqCDboDtSSLzS2PqBZYdaBtiAtV9ldKyL22ijwgYsNSyD+qLSl306nPTfjjWQuqv8xMzGoXQ1hodfDPBDVwvqMgV0YynrT50AUspi/uoe812vrJHylQQQraJy6UgmpxIEdAcirjqhHXNwNC0YnGVjCVOiABvilZ4PeOWuKayOGs7KGvg74Uf1FGdYWbjUApWCuvdLUsIOhAddeyOQafgp6itGo6Hzc9r3LnVp7CpGfZK9P4uKYBjcTvkpmynDX0OHDOkfC52gOU0q3IRrV6tWEvgQN2RTCg32d6Yk5gj02+Au6I3XYXSeHUczUfkrwdoUOcWcrCmOULEXeG7StWT0h/WpXukcGskSGXaYC3x3k9cDuv6uZwEs1HEwNU6r7FtUiF55t8+3+Y9vrs9uvZ6QF99HyF6rEoU7W2QOD3VkULccc1d7Fvg4mEtwFlGUVDFoyPtI9OBnh48l6fVZKozN7TcoEVCtJW/sxxbvofvlO9Vxfwxt6WRyFVn1g4FTQ3fDdrp07o9I/uOMxsavWiaKY/PfVLHCx34WvxXolEsY5ArUlV3cY2lURdrXgeeWdx4bjpXXKyAO9yIOoCPmmSuw== X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;20:E9ms2V2aPD+RrRi7UkeuExJDjUfdKsdJIcmMW+A2BoD6HzhMI4P2SPaTz8+8GuIDpyHzrGbCcAwE6/ymMZlTW7Ou2JMRdORxPSwaZTpFi1+bKIscurUaITbVBsqjxAdFFA2BiHxLo5QtcBt3FHERnsSVYckohDQ5c6iYx4ubu0IX7bobQPbeC7gIvQY7hKYS2MtzKTy8HPhOk6gGXy55otp6zkaa4Gw3HaLLxH56Ea9IqX3w6c9BS6CLUnPLb8vwDb4NFmBg9rGqopV3EOsGJqxUE0DlwH/weyTi+dmKnG92RjHbtY3ddC5HssNflNtxnfwEuYYbuuX1XwfKvGktmxsPvDhHF5slX2jr/semyM7jVLPOs7G7rvVyMp1vMW9xU2ysqf7wnZp3XXrFInph3T9oXX4TSuYHLnWG7QOdYAnWhXWfu5NNDsJR8sztHqPwIoAA873AmPbXlkbB4l91RRufhGvhOgJLkBfSAENCtlK/QAN8oRLJhOB8u6dItZI5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(22074186197030)(236129657087228)(788757137089)(48057245064654)(92977632026198)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:BY1PR03MB1403;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:BY1PR03MB1403; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAzTUIxNDAzOzQ6Q24vYVRyeE1DVTdoL1hzM0VvSHJQTVVub3Fo?= =?utf-8?B?RjBlUVA2QXp3bzBlNk41cWw1Um8wTXhUK1FvUnJRNzA5M3dxL1ZvYmFyaU5T?= =?utf-8?B?NU9nZjYxUVd4K0ZCOFFtdWNoeXpkaWhRWjRVSGYwdlVuNXFTT2hHL1ZLTmx6?= =?utf-8?B?aUhDSzRSNTRWUEtoaXlsVlM5WjlNUjM4OVRtT0x6dzVTVjBzbkpGUmNaYmxI?= =?utf-8?B?Vk5GVlFlWlVYaFl4ejVTZ1VmeXNqZjRqcHc5a2J4ZHR6RzRMNXg0SXV1ak4r?= =?utf-8?B?eHpNY3BpNnRtcHZvZWN1Q25sOXBzQWc2cnlSaFQ3VUNtMzBScUpva3lDTWxN?= =?utf-8?B?UnlaRTZWanI4L3N1M09wNlpVMmwvQlNCbythWEJMdjFkNXJzUldjOVdOaUNO?= =?utf-8?B?L3lmYXA4cDRxRzI1eEg0cmtXMkJvNFkwRGdMTDdNZkVEUGdzUGtuZFB4MXhJ?= =?utf-8?B?VTQzcGt3UGo1dGxqUVN1eG5qTVZxMG5Ia3ZaQVdjZXp0MVFLRWU2d2dVVG81?= =?utf-8?B?NzFQTzgyczRKbFk4N3hhVXFDSFZLcTVOT3ZVRkQ1a08zQlFKVjdvMEdjVFJl?= =?utf-8?B?SFVCS05tN0dQd2w0NVdzckpSTlN3aEg2MkxwbXNvWFBMSFR6OFlYZHN1M1JB?= =?utf-8?B?anNhYUFXQ2tlSlZaOFYxQXozY0M5aGtzZm01RlE3QlNKMU5oNmxvaElJeEpi?= =?utf-8?B?M3ptZXNGSmRhVHpnRVZKQlU2Y1RvMkJROXo1UEdkNmtPTU1GNXMxT056cFAr?= =?utf-8?B?Q1R4RG9uSVMxeVIyMXovNmZnejhvZUdYUEtCbW91eXN3L0ZlZHFoMWpPUDkr?= =?utf-8?B?TWdwL1A5TVFsNDBZZWNPenlvbElQcmYrcUNTbGF3cXJnM3R4YThKLy9Janlo?= =?utf-8?B?Q2xrUnUzMWJHT0M5aG5IK3FjbTJoSHBOQy9SeWxkV3lkV0cyT2draWlhS0oy?= =?utf-8?B?YzVDUUhzdU9CTVlRMXBldFdJVEU3czJxK09WZ1EwRTQyQlAvZm1vZkFHMjVT?= =?utf-8?B?SkxUTDRMdlZXSTEvN0l1WnNVYVFsRmdIYzU5RDZ5cEkrMHFsSVZnWnJIbW56?= =?utf-8?B?cHRkS3lxQXJGRnZMVTlvZDZmaGR5QzM4dUM3aFpra1NqdnhXM0JmNUNNdk5N?= =?utf-8?B?ak5DWTJaRUg0WVEwSElTVWs4U1JmRlVUYmZ4SUNmK2VUUi9PQnQwM21Lampx?= =?utf-8?B?MVo0Z3NhT0h3K29tSkVqTy8xZlNEM1k1Qk50Z2IxdDd2YlYwM1dTa0NDM281?= =?utf-8?B?Z2kzNkhYc0ViSURwaU1wazVBbVNoT0tJR0VpdUxwYSsvNE0rQ01qc1VyQUdS?= =?utf-8?B?SERVd0dYTjg0dHBTeFZSell6ZWNiZnpzM0UvNjJ3OVE3NmVFQWFwNzdZRmU5?= =?utf-8?B?LzNsNHVkbTgzdUp2MmpINnFWRFNHaHZ0d1VxbjBZdEY4anZMcEU1eWk2OVNL?= =?utf-8?B?WENXVks5akRaQmZhLzczanNJQVJoU3Nqazh6eTZqMENXY1JneXNvWklNRTVU?= =?utf-8?B?SERwY04vOHYydjVIMG1QVGYrR1ErT3dRRDVDTFZLNzBYMnh1d2tLWVh2SmU0?= =?utf-8?B?V2ttL1E5YUN0dFVKQTVaaXhBdWVpR1Q4WEMyNTVFS2NSOXdQZmhuZXdxdmJN?= =?utf-8?B?ZHpKeW1uYzNQSmZka1d4YUVuWmJnb2cwOUdiSzQrRGhKV0xZMHZhOGIxNXlN?= =?utf-8?B?Y0RCaVZRUHhMQ3NtYk9mSTZUS3Z5Wi9BdnB5RHZHdy9FNTBML3J1Vng0UVIx?= =?utf-8?B?N0FkZVdKZjdNcWlCclJLODVZeUtEdzZtUkFmSGtXaXFxTFR3amJtQVhyL3pv?= =?utf-8?B?NDdWRDJwaGNodUxlMk1vOGVsWTlPbDdOeFY4UlFGSURXMHhDNXdZNDNIenpJ?= =?utf-8?Q?VTxyctK4xX4hggB7eXo+Jej9pxOdnXL?= X-Forefront-PRVS: 0353563E2B X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39850400002)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(54094003)(76104003)(377454003)(42186005)(31686004)(53546010)(2501003)(966005)(25786009)(305945005)(65826007)(6666003)(50986999)(4001350100001)(5660300001)(7116003)(54356999)(76176999)(2950100002)(347745004)(16799955002)(49976008)(64126003)(2906002)(229853002)(50466002)(88552002)(36756003)(230700001)(23676002)(33646002)(3846002)(6116002)(75432002)(478600001)(189998001)(31696002)(90366009)(47776003)(7736002)(83506001)(66066001)(65806001)(38730400002)(81166006)(65956001)(6246003)(8676002)(53936002)(6306002)(6486002)(51014002)(3940600001);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR03MB1403;H:[198.11.30.49];FPR:;SPF:None;MLV:nov;PTR:InfoNoRecords;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAzTUIxNDAzOzIzOkpobi9UK2RIUnAxaloreUVmdWliZ1ZUVGJy?= =?utf-8?B?eFJDT2cwcXUzckUxMERJZS9nTmp5KzlmK0QvYzI4bElsYTBuM3RoRkRReTdG?= =?utf-8?B?S21SMnRTNnAzZUtmblMvVUo3RVdLV0JIOXdvZVZwVFNmTmFlTXFnWGhiWmtM?= =?utf-8?B?eDd4ZzJ3ZkVucEtEV0pFTzVDVi9XVTJHcWdLbk1ZeEN1UFFrV01iT3lieEU3?= =?utf-8?B?R0ptMjNHZEVHTFV0SXd0Vk1YSU8wUFhuSG5zUkhENm05RjNvV0NVRFNYK1FY?= =?utf-8?B?UVNWN1JDdlZRQlVpVkF4ZHlDYW5ycFVZSEc5a1dBSmliQ0lCTWUrVWRpUkpO?= =?utf-8?B?bzd1ZmJkMWkyWmt2Y2N4TWlkL0xjcU1JVnFWZERvbjBSc1lkbVNqRVk2ZUpB?= =?utf-8?B?eDVyb3orQnRSRTVxZ0JlYWliQUhOYnJLbXVHMGRZN1JwdGdrUThlbTJsSDF1?= =?utf-8?B?T1pMd0FMQ0E3aEU0aXVFOVJKOXBCMGtnSEw2a2p1aksweFNhY3F6UG5NdTdJ?= =?utf-8?B?eVB3L2tGUitGQjIxdFFObEUzSjlHTjU3SHcyQUdmenNnSW1ZUWlVQW4xZkdv?= =?utf-8?B?RWR2UUFCQzh4T0tXT2Jrb2VrQmk5TmlmTXZOTDVwMFdvSHRIZUswS2NxVU1M?= =?utf-8?B?bFlSZkJMQlBIQ015ZFN5TFRtSE5YVldsR0R4aUtUWHpqWmJoWU5wTTIvMlVP?= =?utf-8?B?Q01ENTV3cEVLaDk0NzdNeUM2NEIyeEpTeko1TmZpNVgwOVNvaXQxNitxcmRZ?= =?utf-8?B?amFWd05BZ2d2S3lubXI3Sm9icG1YRGNWck9qY2F0VUo1ZU40RWZCcXVXVytm?= =?utf-8?B?bDMyQ1FhRXhCMmFCQlhsQVJLcFZZQlRUeUVoWFd1V1ZyazJ0d25iRUlkOHlY?= =?utf-8?B?aHJQajZvb1FJemJrMlpZNXQwdFVZWlNVSDZxRVZyd2xqZHpHeDA0cXkrNG5h?= =?utf-8?B?QnRCaU13dkEwbmg1dG9BZUdtV3BwYnBsY29SRmxURFhQQVdDZytOcWk3a2NS?= =?utf-8?B?NUlnb1Fja3kwSHRWWllBZmtMRXJURldmSnFLQVdwRzU2SWIvWXJSaWJ2WTJO?= =?utf-8?B?cDR3eEkxeEZqSHRxYkhycWxUZG9neUtTck9ZR0JjSEMzSW9rUFpUeCtNNEl2?= =?utf-8?B?am9aSUpwT3QvOVdPRXlZL3dnNFRmeUdJRjdvUmNnalJJcVYvWG80aGxWNVNO?= =?utf-8?B?M0kwN25DQkR2dUlYYVJpNEU5TVNiQlF2bGNRS3JtR2NNUHlyZjhDOEs4S2dY?= =?utf-8?B?YVA1U0tQRm9zbS9QY0ZYMGNoZFlRRk03NHJjR2VWVFJITUR5cHRJTCtvRkNG?= =?utf-8?B?b3lIVW95ZFczRWkzVEVkcFdFcm8xc0RNa1ZjTlFuaEhCTHRzOW1LSEw0Uklk?= =?utf-8?B?bVBNUHFoRXM2ZEJsWjVxb3lRYUpVNlUzSXphN0ppYndFODFZZFlCK05Pczh3?= =?utf-8?B?d3UxK2dkd3dRVDRuQW5pM09JUk40dXh4VENnQXZCZXRIRi9WTDZqTVdPSnJ5?= =?utf-8?B?U1gzNkpUV29YQ1Bpb3hIQVdXUlZDUURzL29KNldmeU5TVUE2WjU4WW1TaUxP?= =?utf-8?B?Y1FlbDQrdUZ5MjAyMVhtVFlWTlJxd3ViRmtCNmJiMmUrd2NoYlpQOEtqdFMw?= =?utf-8?B?ck9yQnRTemZoVnFGWmlLVGFpdXkvZzNmZUdmSkE5WXE0ZmVmYVAzVWdtT0k0?= =?utf-8?B?dERtWmRaeVNpOHp6VVcweHV3bzJaR1RQOEovcUtUcjNGVC9SN2MvbklOMnQ5?= =?utf-8?B?ZWVxOHZmbmF1QVJtWVJKQms4ZlJhV08yQ3lwdXczR1B0MmJCWEYyZ3ZuNUJB?= =?utf-8?B?U3MxR3NZK2QwSUxCUnJjR0hTSjk1ZEM0S25TdG5wbmgxNmx0SStsckxkTXNx?= =?utf-8?B?NTRpSndDd0RXN2VZZG82TGw0SmxUQVRTbTdZQjNIV042cURrS29HaStIY1J6?= =?utf-8?B?RWRyelZCd29vSnljZmdGczEzWEIrOTFRME1hbDlhd3BJUHlGaStZelJmWVFt?= =?utf-8?B?RVFreG1FOTdkejEvRWlNSUgwUlhSQnVCcnVuK2ExZ1g2MFNjbng2Wll3OUl3?= =?utf-8?Q?g80M=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAzTUIxNDAzOzY6Y2Vud3NVNGg2blNITHBMYVdBb0YzWWJqZTBl?= =?utf-8?B?TitOT1o5OXpUbzBHYUtOZGFSd3Zab3hwWU1XaGE4Y1BmZUpDWDRQMHRxSEls?= =?utf-8?B?S2dhOEp1WGw4eFh1ZnlZSTQzcUtjYktvbW1wc3RPVlpVOEhRSnNFd2RKQ3Nm?= =?utf-8?B?bjQ3TElPVFlBVENUdXUxY1ZIK3BXbFJBQWJWclJtbjFabnB5RTN1ZmRXTGZl?= =?utf-8?B?TjI3VUtFTkkvQkVFWnRUVmdUT1dyNlFSY2lTT25memRVY0Z1TjlHc0hvVTJV?= =?utf-8?B?aG1TMDU0TG1PbzFLcGNTS0dXVW43NHdoajRkYzBIL3NEWkFmY2xZekRVQktB?= =?utf-8?B?UHJEZ2N3Qlh6ejJCZ0pnOGRGSExaUHJ6Zy9kcjY0U0pNVzJpNUd0b3ZWbXR3?= =?utf-8?B?QVE4dFB1UWdwZW43MVdXUzVGL1ZUMTM2WkdubllpU3JSSjdCWXY4WlJpbHZY?= =?utf-8?B?Rm5YR00rWXN6ZmYzSVBvM3hra0JNMCt0eGkxR1R4TVhlOTV3M0V5ZGFCVDBk?= =?utf-8?B?UTBReXhDM3JVUHVvMjNhWmY2MlpsTWhLUXYwem8raUgrUzJ2Rk50dHZ4NHRM?= =?utf-8?B?aDd5Y1ErYldTK2xhVEV5ZXJwcGNISEUwTndsUklXSTZoZDlpMHpOMDNZU0dG?= =?utf-8?B?eEJ5cGxQbEQ0U0JjRnJ4WXZ5dGJoTXhCbU1Hdm56NHVBRXlYRytGUHJ3SzFs?= =?utf-8?B?WmkvUUkvWmU4WVJxWUNEUTRxYnZCdDhVWkc3U2xvU2dwYzg0ekJpSVJsVTZY?= =?utf-8?B?Y1hoRG9Bc3JxSGdZVkxWVUVyc2xucjdjaGxGQTVVSXZCWnN3R1F4WjJtU0Rz?= =?utf-8?B?TUVZSmd2UWwrMVlreWgrb1pSUmVFN25QM3Z0bUliM0lVazBGc01DcVczd3lC?= =?utf-8?B?bExDR1h1R2UzWEpXYmJNT1VrSXAvREdiL09nYll0cjIzTURSUldKVEpSRDVP?= =?utf-8?B?Y2poMExUeTJ5YjM1TzdUd1NKdU01MmpkZnMzMWpIcmt4SVBFSlJmajRwUzAz?= =?utf-8?B?SGNYQVY3NDRGaW1uY0ttYk5iRk1oL0dSeWJxUDhCbWRkRldMRVN6RGIxNlVT?= =?utf-8?B?bVRoVnl2U0RNL0ZIZHFXU2lycUVhN0twejRNdXBSS0ZMZWtxYVVHY3pwN1Ry?= =?utf-8?B?NEpnSjlpVGJOVWxYckhIRW9UaWRiRkoySlpJQkI5bHJTZkpybmZyZ0s0MHhX?= =?utf-8?B?YjY3U0lHNXFHOUNQbFpFazNtUytJYytGd1E0a1NueUNHT2lJcDlOUkNGaENy?= =?utf-8?B?RExwMWdQd1ZNUTVTeERGSUY3eDVxTGpBRjR0UzJJclVNekRwZnhCemYxaHpj?= =?utf-8?Q?GH0Xftd+cXQAooyHIAUMteJ0SrtnMzI=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;5:gaTQkRZ8tfayTP/6WCHkbfjPq86EfI2ljpf9/6teeOzpTr+t+2xG1XEmP1q8BuVZLlz73gNLtuxUUyxv/rPYZzfDI6iA+zSzawgxEuIbYGk785AX/woEB8hh/9bAuPhQHzc5HdHyBFnZa5lLa+abQ5qbL43eE1ok715dLV+1/zY49Ox7WRkOFha00vmA0aPYz3HBxHArmxiWusS/BXYfCu+6BswG5XH0CdVgYd9vUQbdnKCDsZ82bhnlIdalbBpGN8WUPK6PtVaGlPMVwO6BGxzWB4Fzvzt/TtIHtsFvRZmbO7n6LeY+noP6VcCLgfDhLaXUon8wQsBtT9R+6L96Qc0UWupxWCSbe85un3VDTzLqerzihfAA/YdwqD48DEd2unv8ZnctnqIaEmswQN65RvJ7wONGYEdZ39pHz+aArQI8Y0xNFi80s+ST6ScTmtNbVvfC/xysdd728LZd5JwgMtZsPCnkmKYE3J21S6UmbpP78JkCCf96Uj9n7/yw5Y5i;24:SxrI7KLFrHakFKgp5xpMN9q9Yawb30T++xFcClFPaU6N3DBl4mflv2u3m+SbGcdUmYgBL2YBr35XEq6DvTDLWziC5SZHApGByA0pVPNI/Cc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BY1PR03MB1403;7:mq/wmqTJhC1Ci7NR8KrD1+BLeWjx/UM8fNY+Qoq5qBazFEaoZXcqCo+OfX2N0Ml9s35pGCclhTr3PtkoyNqRRXrc3vLwVscspBLgl0XLl3FrmL/8zpyDTz6cGxSBXxqTr5+wtWtwOJXBLbXAKRytQD6DGoQNeSC6D52iC/s2DpddvDuBk6rA4ypIJ5GEFwbXH5YhBucz98kPwBz5VCgVntAZD0rn08zjLJ0ylBi6lIIEcNpSfRpxAcfWDcfpWUCc4eJ2xpAy7gerpZhhMizKIAIWmAtoA2Sv1bmpS8dIyTkNXpK/O+6D9oodoCO/qHseLkuKdUPmroljiPBtmfqIIcTluZW6k2QvafXKPFwTk8DtFLskSul0lCdGZFoI2Dv9d+veovkwPxULXqZQ/750TzJchpjPsUFDAM8KhnsZmI4IlNMInObhDdrD8Fn0s+/i2bZSdOKH2j9FfRSSCmhmMXTSJLbz2ijm/K6jJKKnhFFQov8dIzyxJprZGHe10VtCNqtw4sP/QiW8xatLCKgbvzbv8lbb6yX+w1wRb7iKFeWPBI/wE3CWpLPq3CCgKRz78QZsHvDVF91FBH7tgKg+SnSn/7J5+KbQqRYzXQLOl5dYLYzE7viGnRyEWZuiRKdvAoKOUivQIsso84WJCGT+hHFlTFTYb0s+GPo1oPi4UN0c583Iq7iVb8ULTXdMp2O30zuFGuZ2rx3yRBwkUXBJb7fRfjsqIufuMja7PBJVO7yv6YoVfJm1X2DOR4CgBwYVZhfJkBvhJ8d1Rm2qoieQ5ELcK14dvekeoTedGKlGulQ= X-OriginatorOrg: colorado.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2017 07:53:27.3241 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1403 X-SW-Source: 2017-q2/txt/msg00002.txt.bz2 Hi Gerard, Interesting post. In the recent release (2.4) I had tried to fix bug #45730 (https://savannah.gnu.org/bugs/index.php?45730), where the bessel_j2 function failed for large input arguments. This was found to be due to calls to the gsl_sf_sin and gsl_sf_cos functions with large inputs, so those functions definitely have bugs for large arguments. Anyway I switched the gsl_sf_sin/cos calls to libm sin/cos which fixed the issue, however I had no clue how to assign the correct error to the sin/cos calls in the j2 function, largely because I have no idea how the SF errors work anyway. I ended up setting the error to 0, which according to your post below seems to be the correct approach. But I remember there were still some issues with the tests, since the SF test suite does some complex tests on these error values, and it didn't like the j2 error result for large inputs. After some tinkering I eventually got the tests to pass ok. I wonder if we should just replace all gsl_sf_sin/cos with sin/cos ? Also what is "ulp" ? Patrick On 06/28/2017 10:51 PM, Gerard Jungman wrote: > On 06/28/2017 04:51 AM, Konrad wrote: >> Dear Gerard and all, >> >> thanks for your comments, I wasn't aware of the caveats concerning >> round() but your implementation takes care of that. > > Like I say, I do not know if what I did was the best choice, but I > do know that round(), and friends like nearbyint(), seemed to be > problematic. > >> I'll try to combine our codes if that's ok with you > > That's fine. Whatever works. Obviously, any improvements > are welcome, since I would like to know what I missed. > >> in particular I'd like to provide the error estimate since this is >> (for me) one the main reasons to use GSL. > > I will comment about error estimates below, since that is something > that I have thought about in the intervening years. > >> There are a few questions remaining before I proceed: >> >> why are you reducing the argument to [-1,1] but not to [-0.5,0.5]? >> This would avoid one of the special cases you treat explicitly, >> parameterized by 1-z. > > That may be only a matter of style. You have an explicit test > for fabs(fracx) > 0.5 which flips it around. I like to avoid > the extra flip and treat the case directly. I find flips > like that confusing. In the end, I think we have the same > number of branches, by direct count. The branch patterns > will be different though, so it is hard to compare. Code > size is different too. > >> in the GSL implementation do we actually need the special case for >> fabs(z) around 0.5 >> As far as I know this special case is implemented reliably in >> gsl_sf_sin_e and gsl_sf_cos_e which can be used for the intermediate >> cases as well. > > It took me a while to come up with the right comment here. In the > end, I think the problem I have is with the idea of deferring to > the GSL implementations at all. There are a number of reasons > not to do this. > > First, there is logic and machinery in gsl_sf_sin_e() and > gsl_sf_cos_e() for handling large arguments. That effort is > wasted, since we know that we have a reduced argument, so > why not avoid the cost of invoking the full implementation. > You also avoid the headache of introducing some possible > problems that could be lurking in the GSL functions. > > When evaluating a function near a zero, or other special point, > I like to use a method which manifestly converges to the exact > answer, without reliance on the logic in some other function, > even if I wrote that function myself... > > If I had more patience, I would replace the invocation of the > library functions with direct evaluations, such as a rational > approximation. But I did not get around to trying that. The > series that I do use are kind of lame, but they do satisfy > the minimum guarantee of a smooth transition. I could > make some further technical comments about series, but > that would lead in another direction. > > Second, the GSL functions can never compete with the library > implementations. They were never meant to; instead they were > built to produce some kind of error estimate, under some > circumstances. I now consider that motivation to be > wrong; see the discussion below about error estimates. > > Of course, the library functions expend unnecessary effort doing > their argument reduction gymnastics too. Ideally, I would like to > have a gold-plated implementation for arguments which are already > reduced, which can be invoked in situations like this. But the > gymnastics in the library functions are highly optimized, so > they bother me less. > > >> I'll check out the glibc implementation as well, but I guess it lacks >> error estimates, so as a first step I'd like to stick with the >> reduction to our GSL-trig functions and look into optimizing it with >> the glibc methods afterwards. Let me know what you think of this >> strategy. > This leads into the discussion of error estimates. Decades ago, there > was a real concern about issues like argument reduction and the level > of precision in library functions like sin() and cos(). There may > still be some issues on weird platforms, or with certain compiler > flags on some platforms. But people who work with such things are > aware of the issues and act accordingly. > > For practical concerns, we can assume IEEE 754 or some equivalent. In > this case, the problems for most (probably all) elementary functions > were solved a long time ago. For example, the argument reduction > problem was solved at Sun in the early 1990s. You can read the > short research paper by Ng, "Argument Reduction: Good to the Last Bit". > It's all over the web. Here is one link: > > https://www.csee.umbc.edu/~phatak/645/supl/Ng-ArgReduction.pdf > > The code in glibc is precisely the code written by this group at SunPro. > It still carries the Sun copyright notice, 1993. It basically guarantees > that sin() and cos() are correct to the last bit. The error in their > private implementation of sin_pi() will be no worse. Obviously that > case is much easier than reducing mod PI; as you see for yourself, > you basically just need modf() for sin_pi(). > > So there is essentially no error in sin() and cos(), or sin_pi(). > More precisely, you can assign an error which is equivalent to one ulp. > So there is really not much point in computing an error. And certainly > not the way that the GSL implementations do it. The culture of that > implementation really stems from the funky Fortran world of the 1970s, > when carpets were orange-colored shag, and computer consoles had > built-in ashtrays. > > So my advice is to avoid the GSL trig implementations and use the > standard library. If you need an error to propagate into something, > you can assume the error on sin() and cos() is one ulp. > > In particular, since the GSL interfaces require returning an error, > I suggest just using the library sin() and cos() and returning one > ulp, basically a fractional error of DBL_EPSILON or so. > > > My general feelings about error estimation are as follows. > First, if a function is implemented in such a way as to > guarantee precision to the last bit, then error estimates > are just a waste. The elementary functions in the standard > library can be assumed to have this behavior. > > Second, if a function cannot be made this precise without > recourse to crazy machinery (like deferral to a multi-prec > implementation), then that limitation is probably just part > of the interface, and should be accepted as such, as long > as the result produced is reasonable. For example, if you > lose 10 bits in a complicated special function, I may not > cry. Of course, such limitations should be carefully > measured, circumscribed, and documented. > > This seems to be the case for some library implementations in > certain contexts. For example, the complex functions, like csin() > in the C99 standard, are not "guaranteed" to be good to the last > bit. I think some vendors could not be bothered to figure out > all the cases; there is a large range of behavior in a dopey > little function like csin(). I am not sure of the status in > glibc; I would be interested to know. > > I think there is explicit language somewhere in the glibc manual > that says something like "well, we do our best, but there are > no guarantees of bit-accuracy". Probably somewhere around the > discussion of complex-valued functions or arithmetic. Yes, > even complex arithmetic is a problem for some vendors... > > Third, if a function cannot be implemented without catastrophic > loss of precision in some regime, then it probably should not > be implemented at all. Fixing such a problem is a research > project, but it should not be inflicted on unknowing users. > > GSL suffers somewhat from this last problem. It was partly a > utility and partly a research project. As such, the quality > of the special functions varies a great deal. Some of those > functions should really not be in there at all. I can say > this, because it is my fault. > > > What I really wanted from the error estimates was a way to > characterize the behavior of the implementations. In some > sense, I wanted them to be able to cry for help when they > were stretched too far. Ideally, once you knew that everything > was ok for your application, you could then turn them off and > get bare-metal performance. That second part of the dream > never came close to realization. > > Nowadays, I think the right procedure is to characterize the > functions from outside. You want to prove that the functions > satisfy a minimum specification by a combination of scanning > values and a little theorem-proving. This is also a very > enlightening practice in general. You get to see where > all the weird jumps and hiccups are, just by staring > at a scatter plot of value scans. > > -- > G. Jungman > > > By the way, for some reason I seem to not be getting > the gsl-discuss emails anymore. Not sure why. Maybe > institutional spam filters or something. But if I > miss some of this discussion, that may be the reason. >