X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Gustaf Thorslund]

-- why_x.adb by confused Gustaf Thorslund

with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
with Ada.Text_IO; use Ada.Text_IO;

procedure Why_X is
   -- Let's say we have an equation Ax = b according to the notation
   from
   -- http://en.wikipedia.org/wiki/Matrix_(mathematics)#Linear_equations
   -- where A and b are known while x is unknown.
   
   A : Real_Matrix(1..1, 1..1) := (others => (others => 2.0));
   B : Real_Vector(1..1) := (others => 12.0);
   
   -- x is found using 
   -- function Solve (A : Real_Matrix; X : Real_Vector) return
   -- Real_Vector;
   X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?
   
begin
   for I in X'Range loop
      Put_Line(Float'Image(X(I)));
   end loop;
end Why_X;

-- Executing the program gives
-- $ ./why_x 
--  6.00000E+00
-- So we found the expected value of x.
-- Was it a misstake to use X as argument name in Solve?

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Niklas Holsti]

On 12-12-24 00:28 , Gustaf Thorslund wrote:
> -- why_x.adb by confused Gustaf Thorslund
> 
> with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Why_X is
>    -- Let's say we have an equation Ax = b according to the notation
>    from
>    -- http://en.wikipedia.org/wiki/Matrix_(mathematics)#Linear_equations
>    -- where A and b are known while x is unknown.
>    
>    A : Real_Matrix(1..1, 1..1) := (others => (others => 2.0));
>    B : Real_Vector(1..1) := (others => 12.0);
>    
>    -- x is found using 
>    -- function Solve (A : Real_Matrix; X : Real_Vector) return
>    -- Real_Vector;
>    X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?


Or you could ask, why use "X" as the name of a local variable?

>    
> begin
>    for I in X'Range loop
>       Put_Line(Float'Image(X(I)));
>    end loop;
> end Why_X;
> 
> -- Executing the program gives
> -- $ ./why_x 
> --  6.00000E+00
> -- So we found the expected value of x.

Do you see that as a problem? :-)

> -- Was it a misstake to use X as argument name in Solve?

Do you mean, is it an error that your program uses "X" as the name of a
local variable, when it also calls a function that has a formal
parameter called "X"?

No, it is not an error and is quite legal. The compiler knows from the
named-association syntax ("X => ...") that "X" refers to the name of a
formal parameter.

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?

That is a matter of coding style and habit. (I would probably have
chosen the name "B" for the second parameter, since "X" suggests
"unknowns" to me, while "A" and "B" suggest "knowns".) And most coding
style guidelines recommend against single-letter names like "X" in
application programs, so "X" should not really be a common name.

Or do you mean to ask if it is mistake that your program uses the name
"X" for a local variable, which the reader can confuse with the formal
parameter "X"?

If you have no important reason to call your local variable "X", it
would be slightly clearer to choose a different name, at least for
readers not yet familiar with Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> 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.

It's very common for mathematical code to adopt terse naming, in line
with the way mathematicians seem to work, and I find it hard to think of
sensible names for these parameters. 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!)

[1] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00296.txt?diffbase=1.3&rev=1.4

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Niklas Holsti]

On 12-12-24 13:50 , Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> 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
      .      @       .

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[jpwoodruff]

I would agree that calling the formal parameter "x" is
infelicitous. But it's been that way for a long time, so we live with
it.  The important thing is that the originators made the decision and
moved on.

I'm glad the topic came up.  I like to engage the people who think
this subject is interesting.  I'm going to reopen the topic of Ada
bindings to Lapack, and the subject of parameter names looms in that
discussion.  I'll put something up a couple days after Christmas.  

Ho Ho Ho.  

John



On Sunday, December 23, 2012 3:28:13 PM UTC-7, Gustaf Thorslund wrote:
> -- why_x.adb by confused Gustaf Thorslund
> 
> 
> 
> with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
<...>
> 
>    -- x is found using 
> 
>    -- function Solve (A : Real_Matrix; X : Real_Vector) return
> 
>    -- Real_Vector;
> 
>    X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?
> 

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Gustaf Thorslund]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Or you could ask, why use "X" as the name of a local variable?

Since it's a common name of an unknown in the context of linear
equations.

>
>>    
>> begin
>>    for I in X'Range loop
>>       Put_Line(Float'Image(X(I)));
>>    end loop;
>> end Why_X;
>> 
>> -- Executing the program gives
>> -- $ ./why_x 
>> --  6.00000E+00
>> -- So we found the expected value of x.
>
> Do you see that as a problem? :-)

No :-) But someone reading
  http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-7-6.html#I1361

without a knowing what linear equations are could get a bit confused.

(in the middle of the page there is an equation "Ax = y")

>> -- Was it a misstake to use X as argument name in Solve?
>
> Do you mean, is it an error that your program uses "X" as the name of a
> local variable, when it also calls a function that has a formal
> parameter called "X"?
>
> No, it is not an error and is quite legal. The compiler knows from the
> named-association syntax ("X => ...") that "X" refers to the name of a
> formal parameter.

No, I used X intentionally to show the why it can be confusing.

> 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?

Right!

> That is a matter of coding style and habit. (I would probably have
> chosen the name "B" for the second parameter, since "X" suggests
> "unknowns" to me, while "A" and "B" suggest "knowns".) And most coding
> style guidelines recommend against single-letter names like "X" in
> application programs, so "X" should not really be a common name.

"X" could be a common name in short examples or even a local
variable. Just like "I" and "J" in loops.

> Or do you mean to ask if it is mistake that your program uses the name
> "X" for a local variable, which the reader can confuse with the formal
> parameter "X"?

No.

> If you have no important reason to call your local variable "X", it
> would be slightly clearer to choose a different name, at least for
> readers not yet familiar with Ada.

For readers not familiar with Ada but familiar with linear equations one
might as well write:

  X := Solve (A, B);

From what I see the argument name "X" doesn't really add any value
anyway.

/Gustaf

Re: X : Real_Vector := Solve(A => A, X => B); -- Why X as argument name?

[Gustaf Thorslund]

Simon Wright <simon@pushface.org> writes:

> Niklas Holsti <niklas.holsti@tidorum.invalid> 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.

Thanks for the link! So then we are three who would have chosen 'B' over
'X'. I'm curious why 'X' was chosen. But whatever the reason was it's
already done.

> It's very common for mathematical code to adopt terse naming, in line
> with the way mathematicians seem to work, and I find it hard to think of
> sensible names for these parameters. 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!)

When it comes to an abstract generic level it may be hard to come up
with more explicit names. A queue will have a head and tail (or some
other names). Depending on application it may be good or bad to be
first.

/Gustaf