From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!news.uni-weimar.de!medsec1.medien.uni-weimar.de!lucks From: Stefan.Lucks@uni-weimar.de Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Wed, 14 Oct 2015 20:17:59 +0200 Organization: Bauhaus-Universitaet Weimar Message-ID: References: <5cb5c989-4d12-41d8-88df-ab45988ba8a1@googlegroups.com> <87mvvla5ma.fsf@bsb.me.uk> <87si5d1jiw.fsf@jester.gateway.sonic.net> NNTP-Posting-Host: medsec1.medien.uni-weimar.de Mime-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-609333674-1444845979=:8228" X-Trace: pinkpiglet.scc.uni-weimar.de 1444847336 23722 141.54.178.228 (14 Oct 2015 18:28:56 GMT) X-Complaints-To: news@pinkpiglet.scc.uni-weimar.de NNTP-Posting-Date: Wed, 14 Oct 2015 18:28:56 +0000 (UTC) X-X-Sender: lucks@debian In-Reply-To: <87si5d1jiw.fsf@jester.gateway.sonic.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Content-ID: Xref: news.eternal-september.org comp.lang.ada:27977 Date: 2015-10-14T20:17:59+02:00 List-Id: --8323329-609333674-1444845979=:8228 Content-Type: text/plain; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Wed, 14 Oct 2015, Paul Rubin wrote: > Ben Bacarisse writes: >> Do you mean that there are reasons to permit !(a =3D=3D b) and a !=3D b = to >> have different values in some cases? > > I think he meant they should both return the same value, but it is ok if > they don't use the same algorithm. Of course it may be possible for the > compiler to optimize the first into the second. The idea is just that > if (a !=3D b) { ... } can be much faster than if (a =3D=3D b) { ... } = =2E As I seem to understand, Ben questioned that either the test on equality=20 or on non-equality could be much faster than the other one. In Ada syntax: function "=3D"(A, B: T) return Boolean is begin if Hash(A) /=3D Hash(B) then return False else return Slow_Equality_Test(A, B) end "=3D"; function "/=3D"(A, B: T) return Boolean is begin if Hash(A) /=3D Hash(B) then return True else return Not Slow_Equality_Test(A, B) end "/=3D"; -- if this where allowed in Ada It seems quite clear that for any inputs X and Y, the expressions X =3D Y= =20 and X /=3D Y should evaluate at the same speed. Or what am I missing? Actually, "/=3D" could be faster than "=3D" if either where defined as=20 follows: function "=3D"(A, B: T) return Boolean renames Slow_Equality_Test; function "/=3D"(A, B: T) return Boolean is (Hash(A) /=3D Hash(B)); -- second case Redefining "=3D" this way is just missing an optimization. Redefining "/=3D" is that way is a bug. So how could "/=3D" really be faster than "=3D"? My guess is that the devil's advocate, Maciej Sobczak, assumed that "=3D" i= s=20 already in use as identifier, instead of another identifier for the=20 Slow_Equality_Test, as I call it. Which means, we cannot employ the=20 optimization for equality. An independent "/=3D" would then allow us to=20 optimize non-equality. But this would be a design flaw, and it might be easy to fix: function "=3D"(A, B: T) return Boolean is -- optimized equality begin if Hash(A) /=3D Hash(B) then return False else return Outer_Package."=3D"(A, B) end "=3D"; -------- I love the taste of Cryptanalysis in the morning! -------= - www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-luck= s ----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universit=E4t Weimar, Germany-= --- --8323329-609333674-1444845979=:8228--