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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,380d5dcaa525139c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.19.194 with SMTP id h2mr9946046wie.0.1356837411749; Sat, 29 Dec 2012 19:16:51 -0800 (PST) Path: i11ni337233wiw.0!nntp.google.com!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name? Date: Mon, 24 Dec 2012 14:58:12 +0200 Organization: Tidorum Ltd Message-ID: References: <871uegmmiq.fsf@katthult.thorslund.org> Mime-Version: 1.0 X-Trace: individual.net Y/i1o4Ktd3bUyCEv6lOD+w4WotMBu61ttt6ch23AZb0yBe79w8ratgY9voLZnuPlrC Cancel-Lock: sha1:lhzcQxXEBqevFPAC98j9qrE6ArI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-12-24T14:58:12+02:00 List-Id: On 12-12-24 13:50 , Simon Wright wrote: > Niklas Holsti writes: > >> Or do you mean to ask if it was a mistake in the definition of >> Ada.Numerics.Real_Arrays.Solve to give the second formal parameter the >> name "X", given that "X" is a common name in client code? > > This is certainly a style issue. The second parameter has been 'X' ever > since it was introduced in v4 of ai-00296 in June 2003[1]. I would > probably have chosen 'B', but there may well be mathematical texts that > would take the approach adopted in the ARM. There may indeed. > It's very common for mathematical code to adopt terse naming, in line > with the way mathematicians seem to work, Agreed. Writing long names in chalk on a black-board (or with ink on a white-board) is cumbersome and one quickly runs out of space. > and I find it hard to think of > sensible names for these parameters. One problem is that even the subprogram name "Solve" is not according to good practice. Firstly, an imperative verb like "Solve", should name a procedure, not a function. For a function, a noun should be used, for example "Solution". Secondly, "Solve" and "Solution" are really far too general; the name should be more specific, for example "Linear_Inverse_Image". A more specific subprogram name could in turn suggest sensible names for the parameters, for example "Map" for the matrix Solve.A, and "Value" for Solve.X. The overly general names "Solve" or "Solution" suggest parameter names like "Problem" or "Equation", which are not so good. > But it ought to be possible for > client code to be more explicit (unless, of course, the algorithm to be > implemented was specified by one of the above-referenced mathematicians!) I have had the pleasure ;-) of implementing some computations specified by mathematicians (well, control-theory specialist, really). The mathematical symbols in the given equations were (as typical) semi-fractal collections of indices and sub-indices surrounding some base symbol on all (well, most) corners, in different alphabets (latin, greek, etc.). The Ada identifiers logically became monsters like "alpha_sub_i_sub_kappa". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .