From MAILER-DAEMON Mon May 04 11:24:15 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVcx5-0003gm-Lu for mharc-gforth@gnu.org; Mon, 04 May 2020 11:24:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVcx4-0003eu-A9 for gforth@gnu.org; Mon, 04 May 2020 11:24:14 -0400 Received: from a4.complang.tuwien.ac.at ([128.130.173.65]:57790) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVcx2-0002S4-Tx for gforth@gnu.org; Mon, 04 May 2020 11:24:13 -0400 Received: from anton by a4 with local (Exim 4.89) (envelope-from ) id 1jVcwx-0000pw-BV for gforth@gnu.org; Mon, 04 May 2020 17:24:07 +0200 Date: Mon, 4 May 2020 17:24:07 +0200 From: Anton Ertl To: gforth@gnu.org Subject: -infinity and REPRESENT Message-ID: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> Reply-To: anton@mips.complang.tuwien.ac.at MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: none client-ip=128.130.173.65; envelope-from=anton@mips.complang.tuwien.ac.at; helo=a4.complang.tuwien.ac.at X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/04 11:24:07 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 15:24:14 -0000 I just re-implemented REPRESENT. One issue is how to deal with -infinity (e.g., the result of -1e 0e f/). Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), f2=0 (not valid); other libc implementations might lead to different results. gforth 0.7.9_20200423 uses an ecvt_r supplied by us and produces "-inf" and f1=-1 (negative), f2=0 (not valid); the new REPRESENT currently works in the same way (except that it gives you "-infinity", space permitting). In both systems F. and FS. outputs -in. iForth behaves like gforth 0.7.2. VFX produces "Inf" and f1=-1, f2=0. The VFX behaviour looks like the most sensible one to me, but it might affect code that uses REPRESENT; we can change our own code accordingly, but what about your code? Do you have code that uses REPRESENT and that has been designed for a specific behaviour when getting -infinity? - anton From MAILER-DAEMON Mon May 04 14:54:28 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVgEV-0005RE-Un for mharc-gforth@gnu.org; Mon, 04 May 2020 14:54:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVgEU-0005R4-Qt; Mon, 04 May 2020 14:54:26 -0400 Received: from claranetnl-outbound-smtp03.mail.eu.clara.net ([195.8.64.68]:36984) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1jVgET-0005V7-Ii; Mon, 04 May 2020 14:54:26 -0400 Received: from webmail02.mail.eu.clara.net ([81.171.239.72]:53308 helo=webmail-vh.nl.clara.net) by relay03.mail.eu.clara.net (smtp-vh.nl.clara.net [81.171.239.33]:2025) with esmtpa (authdaemon_login:mhx@iae.nl) id 1jVgEM-0005oh-9i (return-path ); Mon, 04 May 2020 18:54:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 May 2020 20:54:17 +0200 From: mhx@iae.nl To: anton@mips.complang.tuwien.ac.at Cc: gforth@gnu.org, Gforth Subject: Re: -infinity and REPRESENT In-Reply-To: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> References: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> Message-ID: <886d9f266b95c42b9a7e987f9bd3b532@iae.nl> X-Sender: mhx@iae.nl User-Agent: Roundcube Webmail/1.2.4 ClaraMail2-Webmail-AuthUser: mhx@iae.nl Received-SPF: none client-ip=195.8.64.68; envelope-from=mhx@iae.nl; helo=claranetnl-outbound-smtp03.mail.eu.clara.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/04 14:54:21 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:54:27 -0000 On 2020-05-04 17:24, Anton Ertl wrote: > I just re-implemented REPRESENT. > > One issue is how to deal with -infinity (e.g., the result of -1e 0e > f/). > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), > f2=0 (not valid); other libc implementations might lead to different > results. Sorry, what are f1 and f2? -marcel From MAILER-DAEMON Mon May 04 15:54:14 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVhAM-0001e6-4f for mharc-gforth@gnu.org; Mon, 04 May 2020 15:54:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVhAJ-0001cU-QM; Mon, 04 May 2020 15:54:11 -0400 Received: from mail.net2o.de ([2a03:4000:1d:bf::11e7:20]:52562) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVhAH-0002wz-Ru; Mon, 04 May 2020 15:54:11 -0400 Received: from daiyu.localnet (200116b82666000034fdc7db497d5c40.dip.versatel-1u1.de [IPv6:2001:16b8:2666:0:34fd:c7db:497d:5c40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.net2o.de (Postfix) with ESMTPSA id 97E9B4024E; Mon, 4 May 2020 21:54:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=net2o.de; s=mail; t=1588622044; bh=GcprCsEG70ItMllU5WVJrZQrQzIB2gkGMrDCPBOS4F8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bSxmZFoR+yjLldudJbwyqqFCSCR0IUAqjk6315eyvRBZyz12eZm6qcOnCqo6gCS3n vTGbx90aiIQp9XkmVoTPM0xiuuaqDNp39N+JjIWXTkbOqSdfiZ4GTLwXoDGcAdNuaZ CgvTwhe0avrmu/TbqSPehvIfkXuiaau3UYDfgTaw= From: Bernd Paysan To: anton@mips.complang.tuwien.ac.at, gforth@gnu.org Cc: Gforth , gforth@gnu.org, mhx@iae.nl Subject: Re: -infinity and REPRESENT Date: Mon, 04 May 2020 21:53:59 +0200 Message-ID: <16381941.F3y2CZnWt1@daiyu> In-Reply-To: <886d9f266b95c42b9a7e987f9bd3b532@iae.nl> References: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> <886d9f266b95c42b9a7e987f9bd3b532@iae.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4405010.g6YqyTpg5p"; micalg="pgp-sha256"; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a03:4000:1d:bf::11e7:20; envelope-from=bernd@net2o.de; helo=mail.net2o.de X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 19:54:12 -0000 --nextPart4405010.g6YqyTpg5p Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Am Montag, 4. Mai 2020, 20:54:17 CEST schrieb mhx@iae.nl: > On 2020-05-04 17:24, Anton Ertl wrote: > > I just re-implemented REPRESENT. > > > > One issue is how to deal with -infinity (e.g., the result of -1e 0e > > f/). > > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), > > f2=0 (not valid); other libc implementations might lead to different > > results. > > Sorry, what are f1 and f2? flag1 is sign (-1 when negative), flag2 is valid (0 when invalid). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* https://net2o.de/ --nextPart4405010.g6YqyTpg5p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEERJ1NDqPQRwYnwBjr9y2Uk5MtoGcFAl6wctcACgkQ9y2Uk5Mt oGdcAw//Ut/5YnYC/L23aHYH1x4OlKdLuOsp0sH4le1smxzqAtOTNhLKmR+gD19A 7Smz+SslAt2quVqtkN56DCzKOybmGVnhlLJjdF512QuFIZtK1w707DWh0E9xGr5J iGMcCn+1CHCtXN6mtXTMaZSgCXxMsZH6TCS/M5M1OQ94dwxCFvN62X+yq5YqJKQB hPvehTPsheSd9LTUymfT8u9fABCLMsi0TSbasszHCz2ITiS0gYmYBQT7ICwSJ5WK ON+6eEiaPjhNYnA5sjD46NUvu+2wXNrXn0Sa8bOuk4a6VAzJbw+jcs2/76wqI+iq DP8bw9bTPa+13YhtUyVCeuDCX2lzkAqCoJQ4smC1gLIASw7vTBXUOqACp+8Tl8KK L+cuwlSuDcZkrxorbtdR5JTC+1bXoo7OzmGmYi2SLI6GMRt8MtTZFmhc5h6KiM0D NKJbjcUiVVCXUEZTZsgmQju2SjWKVvExHHGWIVxPQTv86+DSYiH82v7wUcFzDmeF DnC31SoFhG7nDQ0jpywoUVECbppiMCYyOQ2shTS7Sa3dK5su0jPsPA16LHoz2VaO ODvB2IC5ajYhuDhFStMmPxZb/oXOr9ivgkmYxRte4cffkha8bT63Geq69m6qvUfr hDUF81Mp2Cz8NGs90ecXx8enanDPdh1dAxCdpSq+CD5We4NGGzo= =ByS8 -----END PGP SIGNATURE----- --nextPart4405010.g6YqyTpg5p-- From MAILER-DAEMON Mon May 04 19:03:43 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVk7j-0005fQ-3K for mharc-gforth@gnu.org; Mon, 04 May 2020 19:03:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVk7h-0005fD-Ep; Mon, 04 May 2020 19:03:41 -0400 Received: from claranetnl-outbound-smtp06.mail.eu.clara.net ([195.8.64.71]:49348) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1jVk7f-0000Kk-Uu; Mon, 04 May 2020 19:03:41 -0400 Received: from webmail02.mail.eu.clara.net ([81.171.239.72]:56208 helo=webmail-vh.nl.clara.net) by relay06.mail.eu.clara.net (smtp-vh.nl.clara.net [81.171.239.36]:2025) with esmtpa (authdaemon_login:mhx@iae.nl) id 1jVk7X-0003To-LE (return-path ); Mon, 04 May 2020 23:03:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2020 01:03:31 +0200 From: mhx@iae.nl To: anton@mips.complang.tuwien.ac.at Cc: gforth@gnu.org, Gforth Subject: Re: -infinity and REPRESENT In-Reply-To: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> References: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> Message-ID: <1683b2aa4825f595eadd5824f5919069@iae.nl> X-Sender: mhx@iae.nl User-Agent: Roundcube Webmail/1.2.4 ClaraMail2-Webmail-AuthUser: mhx@iae.nl Received-SPF: none client-ip=195.8.64.71; envelope-from=mhx@iae.nl; helo=claranetnl-outbound-smtp06.mail.eu.clara.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/04 19:03:35 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 23:03:41 -0000 On 2020-05-04 17:24, Anton Ertl wrote: > I just re-implemented REPRESENT. > > One issue is how to deal with -infinity (e.g., the result of -1e 0e > f/). > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), > f2=0 (not valid); other libc implementations might lead to different > results. > > gforth 0.7.9_20200423 uses an ecvt_r supplied by us and produces > "-inf" and f1=-1 (negative), f2=0 (not valid); the new REPRESENT > currently works in the same way (except that it gives you "-infinity", > space permitting). > > In both systems F. and FS. outputs -in. > > iForth behaves like gforth 0.7.2. > > VFX produces "Inf" and f1=-1, f2=0. > > The VFX behaviour looks like the most sensible one to me, but it might > affect code that uses REPRESENT; we can change our own code > accordingly, but what about your code? Do you have code that uses > REPRESENT and that has been designed for a specific behaviour when > getting -infinity? ( Bernd clarified f1 and f2. ) > VFX produces "Inf" and f1=-1, f2=0. I think I will fix iForth (in due time) to give "-INF", f1=-1 f2=-1. It does not make sense to me to claim f2=0 when the item has a sign and gives valid output for many operations. I have used REPRESENT exactly once in a program, in 1997. However, it is used in a lib that I use almost daily to print scaled strings ( 1k 1.23u 7.12G etc. ). I have never seen it return +/-INF there. -marcel From MAILER-DAEMON Tue May 05 02:48:37 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVrNd-000868-5P for mharc-gforth@gnu.org; Tue, 05 May 2020 02:48:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVrNb-00083b-3j for gforth@gnu.org; Tue, 05 May 2020 02:48:35 -0400 Received: from a4.complang.tuwien.ac.at ([128.130.173.65]:58026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVrNZ-0004gP-NZ for gforth@gnu.org; Tue, 05 May 2020 02:48:34 -0400 Received: from anton by a4 with local (Exim 4.89) (envelope-from ) id 1jVrNV-0006mD-SB for gforth@gnu.org; Tue, 05 May 2020 08:48:29 +0200 Date: Tue, 5 May 2020 08:48:29 +0200 From: Anton Ertl To: gforth@gnu.org Subject: Re: -infinity and REPRESENT Message-ID: <20200505064829.gfd2k6m2led37wmb@a4.complang.tuwien.ac.at> Reply-To: anton@mips.complang.tuwien.ac.at References: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> <1683b2aa4825f595eadd5824f5919069@iae.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1683b2aa4825f595eadd5824f5919069@iae.nl> User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: none client-ip=128.130.173.65; envelope-from=anton@mips.complang.tuwien.ac.at; helo=a4.complang.tuwien.ac.at X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/05 02:48:30 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 06:48:35 -0000 On Tue, May 05, 2020 at 01:03:31AM +0200, mhx@iae.nl wrote: > On 2020-05-04 17:24, Anton Ertl wrote: > > One issue is how to deal with -infinity (e.g., the result of -1e 0e f/). > > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), > > f2=0 (not valid); other libc implementations might lead to different > > results. > > > > gforth 0.7.9_20200423 uses an ecvt_r supplied by us and produces > > "-inf" and f1=-1 (negative), f2=0 (not valid); the new REPRESENT > > currently works in the same way (except that it gives you "-infinity", > > space permitting). > > > > In both systems F. and FS. outputs -in. > > > > iForth behaves like gforth 0.7.2. > > > > VFX produces "Inf" and f1=-1, f2=0. > > > > The VFX behaviour looks like the most sensible one to me, but it might > > affect code that uses REPRESENT; we can change our own code > > accordingly, but what about your code? Do you have code that uses > > REPRESENT and that has been designed for a specific behaviour when > > getting -infinity? > > ( Bernd clarified f1 and f2. ) > > > VFX produces "Inf" and f1=-1, f2=0. > > I think I will fix iForth (in due time) to give "-INF", f1=-1 f2=-1. > It does not make sense to me to claim f2=0 when the item has a sign and > gives valid output for many operations. I think that putting the sign in f1, not in the string is most appropriate, because that's the same as for finite numbers (-1e produces "10..." and f1=-1). As for f2, with IEEE arithmetic there is no number that's strictly invalid; IEEE 754 defines a meaning for every bit pattern. So what should we return as f2? 1) Always return -1? That's not useful, and contrary to existing practice. 2) Return -1 for finite and infinite numbers, and 0 for NaNs. That's arguable, but contrary to existing practice. Moreover, what would be the use of this behaviour? 3) Return -1 for finite numbers, and 0 for infinities and NaNs. That's existing practice, and is useful for indicating that the that the string result consists of digits and that the n (exponent) result of REPRESENT is actually meaningful. - anton From MAILER-DAEMON Tue May 05 03:55:53 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jVsQj-00015f-97 for mharc-gforth@gnu.org; Tue, 05 May 2020 03:55:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVsQi-00015W-EU; Tue, 05 May 2020 03:55:52 -0400 Received: from claranetnl-outbound-smtp03.mail.eu.clara.net ([195.8.64.68]:32909) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1jVsQh-0005oJ-6C; Tue, 05 May 2020 03:55:52 -0400 Received: from webmail02.mail.eu.clara.net ([81.171.239.72]:51385 helo=webmail-vh.nl.clara.net) by relay03.mail.eu.clara.net (smtp-vh.nl.clara.net [81.171.239.33]:2025) with esmtpa (authdaemon_login:mhx@iae.nl) id 1jVsQb-0006Ph-AJ (return-path ); Tue, 05 May 2020 07:55:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2020 09:55:45 +0200 From: mhx@iae.nl To: anton@mips.complang.tuwien.ac.at Cc: gforth@gnu.org, Gforth Subject: Re: -infinity and REPRESENT In-Reply-To: <20200505064829.gfd2k6m2led37wmb@a4.complang.tuwien.ac.at> References: <20200504152407.7b3fxp77rf5uipqu@a4.complang.tuwien.ac.at> <1683b2aa4825f595eadd5824f5919069@iae.nl> <20200505064829.gfd2k6m2led37wmb@a4.complang.tuwien.ac.at> Message-ID: X-Sender: mhx@iae.nl User-Agent: Roundcube Webmail/1.2.4 ClaraMail2-Webmail-AuthUser: mhx@iae.nl Received-SPF: none client-ip=195.8.64.68; envelope-from=mhx@iae.nl; helo=claranetnl-outbound-smtp03.mail.eu.clara.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/05 03:55:48 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: gforth@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gforth discussion and announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 07:55:52 -0000 On 2020-05-05 08:48, Anton Ertl wrote: > On Tue, May 05, 2020 at 01:03:31AM +0200, mhx@iae.nl wrote: >> On 2020-05-04 17:24, Anton Ertl wrote: >> > One issue is how to deal with -infinity (e.g., the result of -1e 0e f/). >> > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), >> > f2=0 (not valid); other libc implementations might lead to different >> > results. >> > >> > gforth 0.7.9_20200423 uses an ecvt_r supplied by us and produces >> > "-inf" and f1=-1 (negative), f2=0 (not valid); the new REPRESENT >> > currently works in the same way (except that it gives you "-infinity", >> > space permitting). >> > >> > In both systems F. and FS. outputs -in. >> > >> > iForth behaves like gforth 0.7.2. >> > >> > VFX produces "Inf" and f1=-1, f2=0. >> > >> > The VFX behaviour looks like the most sensible one to me, but it might >> > affect code that uses REPRESENT; we can change our own code >> > accordingly, but what about your code? Do you have code that uses >> > REPRESENT and that has been designed for a specific behaviour when >> > getting -infinity? >> >> ( Bernd clarified f1 and f2. ) >> >> > VFX produces "Inf" and f1=-1, f2=0. >> >> I think I will fix iForth (in due time) to give "-INF", f1=-1 f2=-1. >> It does not make sense to me to claim f2=0 when the item has a sign >> and >> gives valid output for many operations. > > I think that putting the sign in f1, not in the string is most > appropriate, because that's the same as for finite numbers (-1e > produces "10..." and f1=-1). > > As for f2, with IEEE arithmetic there is no number that's strictly > invalid; IEEE 754 defines a meaning for every bit pattern. So what > should we return as f2? > > 1) Always return -1? That's not useful, and contrary to existing > practice. > > 2) Return -1 for finite and infinite numbers, and 0 for NaNs. That's > arguable, but contrary to existing practice. Moreover, what would be > the use of this behaviour? > > 3) Return -1 for finite numbers, and 0 for infinities and NaNs. > That's existing practice, and is useful for indicating that the that > the string result consists of digits and that the n (exponent) result > of REPRESENT is actually meaningful. Good points. I see now that iForth does not handle +/-0 correctly, and that the fpout 1.4 discussion is still relevant. When considering to be non-standard, I'd better take that into account. -marcel