Inferring array index type from array object

Inferring array index type from array object

[Maciej Sobczak]

Consider this:

S : String := "Hello";

It is possible to iterate over all indices of this array with this
construct:

for I in S'Range loop ...

I would like to declare I as a free variable instead and I would
expect some symmetry in the language by doing this:

I : S'Range := S'First;

But it does not work. Of course, one can do:

I : Positive := S'First;

But it has the disadvantage of hardcoding the index type and
introducing unnecessary coupling in the code.
(hint: the problem is not really about Strings, it is a general array
question)

I have two questions:

1. What is the standard justification for this assymetry? What exactly
makes S'Range "work" in a for loop?

2. Is it possible to declare the index variable without hardcoding the
index type (that is, to infer it from the array object)?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Inferring array index type from array object

[Dmitry A. Kazakov]

On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:

> Consider this:
> 
> S : String := "Hello";
> 
> It is possible to iterate over all indices of this array with this
> construct:
> 
> for I in S'Range loop ...
> 
> I would like to declare I as a free variable instead and I would
> expect some symmetry in the language by doing this:
> 
> I : S'Range := S'First;

subtype Index_Span is Integer range S'Range;
I : Index_Span := S'First;

> I have two questions:
> 
> 1. What is the standard justification for this assymetry?

"We don't want to do anything [useful]." (:-))

> What exactly
> makes S'Range "work" in a for loop?

It is hard wired, since ranges are not first class citizens.

> 2. Is it possible to declare the index variable without hardcoding the
> index type (that is, to infer it from the array object)?

No, without improving the type system. E.g. introducing abstract index
types, and abstract range types (or more general sets of index types), and
abstract composite types like arrays.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Inferring array index type from array object

[J-P. Rosen]

Dmitry A. Kazakov a �crit :
>> I would like to declare I as a free variable instead and I would
>> expect some symmetry in the language by doing this:
>>
>> I : S'Range := S'First;
> 
> subtype Index_Span is Integer range S'Range;
> I : Index_Span := S'First;
Or simply:
I : Positive range S'Range;

>> 1. What is the standard justification for this assymetry?
This is a simplification of loops, to avoid some typing to the user.
Think of it the other way round: since a for loop involves the
declaration of an object, the type should always be explicitely declared
(a coding rule that I apply - of course checkable by AdaControl):

for I in positive range 1..10 loop ...
for I in positive range S'Range loop ...

So it is really symetrical, except that in the case of a loop, you  are
allowed to "simplify" by omitting the "<type> range" part - forcing the
compiler to deduce the type from the range, which is not a good idea IMHO.

>> 2. Is it possible to declare the index variable without hardcoding the
>> index type (that is, to infer it from the array object)?
> 
There is no point in doing this, since the type of the array /is/
hardcoded anyway. You could allow the same "simplification" as for
loops, but as mentionned above, I prefer the other way round: always
explicitely give the type name.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Inferring array index type from array object

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
> 
>> Consider this:
>>
>> S : String := "Hello";
>>
>> It is possible to iterate over all indices of this array with this
>> construct:
>>
>> for I in S'Range loop ...
>>
>> I would like to declare I as a free variable instead and I would
>> expect some symmetry in the language by doing this:
>>
>> I : S'Range := S'First;
> 
> subtype Index_Span is Integer range S'Range;
> I : Index_Span := S'First;
> 
>> I have two questions:
>>
>> 1. What is the standard justification for this assymetry?
> 
> "We don't want to do anything [useful]." (:-))
> 
>> What exactly
>> makes S'Range "work" in a for loop?
> 
> It is hard wired, since ranges are not first class citizens.
> 
>> 2. Is it possible to declare the index variable without hardcoding the
>> index type (that is, to infer it from the array object)?
> 
> No, without improving the type system. E.g. introducing abstract index
> types, and abstract range types (or more general sets of index types), and
> abstract composite types like arrays.

I don't think such large language changes would be necessary. The 
expression S'Range gives the compiler all the information about the type 
and its constraints, so I see no reason why Ada could not be extended 
simply to allow S'Range in a variable declaration, as in the above 
quoted "I : S'Range". The declared variable "I" would have the same 
(sub)type as the loop counter in "for I in S'Range loop ...".

On the other hand, I haven't really felt the need for this extension in 
my programs. Whenever I declare an array type, either the index type has 
no meaning for the application, and I use a subtype of Integer (eg. the 
array just represents a sequence or set of objects), or I also define an 
index type (eg. an object identifier) that is associated with the array 
type. So I have not felt a need for using S'Range in a variabnle 
declaration.

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

Re: Inferring array index type from array object

[Georg Bauhaus]

On 23.06.10 11:03, J-P. Rosen wrote:

>>> 2. Is it possible to declare the index variable without hardcoding the
>>> index type (that is, to infer it from the array object)?
>>
> There is no point in doing this, since the type of the array /is/
> hardcoded anyway. You could allow the same "simplification" as for
> loops, but as mentionned above, I prefer the other way round: always
> explicitely give the type name.

Is the required name somehow related to why the Ada.Container generics
do not re-export the formal types?


But anyway, without Dmitry's abstractions, a partial
solution should work along these lines, I think,

generic
   type Index_Type is (<>);
   type Component_Type is private;
package GA is

   type Array_Type is array (Index_Type range <>) of Component_Type;

   generic
      with function "+" (Left, Right: Component_Type)
                         return Component_Type is <>;
      Zero: in Component_Type;
   package Algorithms is

      function Sum (A: Array_Type) return Component_Type ;

   end Algorithms;

end GA;

Re: Inferring array index type from array object

[J-P. Rosen]

Georg Bauhaus a �crit :
> Is the required name somehow related to why the Ada.Container generics
> do not re-export the formal types?
> 
 Not sure what you meant by this, but outside the instantiation, you are
supposed to know how it was instantiated, therefore you have access to
the actuals. Why would you need to reexport the formals?

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Inferring array index type from array object

[Gautier write-only]

Perhaps empty ranges have played a role for designers not going too
far into defining what you would like (some "subtype S_range is
S'Range", or "type S_range is new S'Range" ?) ?

procedure String_range is
  subtype Index_empty is Positive range 1..0;
  I1: Index_empty:= Index_empty'First;
  --
  S: constant String:= "";
  I2 : Positive range S'Range:= S'First;
begin
  null;
end;

There, GNAT produces a Constraint_Error for any of I1 or I2, on the :=
lines.

G.

Re: Inferring array index type from array object

[Peter C. Chapin]

Niklas Holsti wrote:

> I don't think such large language changes would be necessary. The 
> expression S'Range gives the compiler all the information about the type 
> and its constraints, so I see no reason why Ada could not be extended 
> simply to allow S'Range in a variable declaration, as in the above 
> quoted "I : S'Range". The declared variable "I" would have the same 
> (sub)type as the loop counter in "for I in S'Range loop ...".

This seems weird to me. S'Range is a range, not a type. I agree that it
includes type information, but then so does an object.

X : Integer;
Y : X;       -- Let Y have the same type as X. Weird.

Type inference is a big subject and while it can be very nice in languages
that support it comprehensively, type inference doesn't really seem like
the "Ada way" to me. In any case, once you start supporting type inference in
any form you have to wonder just how far down that road you want to go. Right
now Ada only infers types in one very limited case (right?)... that is in
support of implicitly declared loop index variables.

Peter

Re: Inferring array index type from array object

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Dmitry A. Kazakov a �crit :
>>> I would like to declare I as a free variable instead and I would
>>> expect some symmetry in the language by doing this:
>>>
>>> I : S'Range := S'First;
>> 
>> subtype Index_Span is Integer range S'Range;
>> I : Index_Span := S'First;
> Or simply:
> I : Positive range S'Range;

Right.  And as others have noted, beware null ranges.

>>> 1. What is the standard justification for this assymetry?
> This is a simplification of loops, to avoid some typing to the user.
> Think of it the other way round: since a for loop involves the
> declaration of an object, the type should always be explicitely declared
> (a coding rule that I apply - of course checkable by AdaControl):
>
> for I in positive range 1..10 loop ...
> for I in positive range S'Range loop ...

I see those two lines as very different.

I agree with you on the first line.  In "for I in 1..10",
Ada takes a "wild guess", and says the type is Integer.
That's a language design mistake, and I always like
to make the type explicit, as shown above.  Well,
almost always -- I might leave it implicit if I is never
mentioned, as in:

    -- Print "Hello" ten times:
    for I in 1..10 loop
        Put_Line ("Hello");
    end loop;

But in the second example, I'm perfectly happy with leaving
the type implicit:

    for I in S'Range loop
        ... S(I) ...

because this code really doesn't care what the index type is.
We're saying "the type of I is whatever the index type of S
is, and we don't need to name it here".

Can AdaControl check my style rule -- complain if I depend
on the default-to-integer rule, but not complain if the
type of the loop index is properly deducible from the
stuff between "in" and "loop"?

Note that Ada 2012 will (probably) eliminate the need for
I altogether, which is a good thing, since I is just an
extraneous thing -- we really want to talk about the
components of S here, not their index values.

> So it is really symetrical, except that in the case of a loop, you  are
> allowed to "simplify" by omitting the "<type> range" part - forcing the
> compiler to deduce the type from the range, which is not a good idea IMHO.

Why is that a bad idea (in the second case)?

- Bob

Re: Inferring array index type from array object

[J-P. Rosen]

Robert A Duff a �crit :
>> for I in positive range 1..10 loop ...
>> for I in positive range S'Range loop ...
> [...] 
> 
> But in the second example, I'm perfectly happy with leaving
> the type implicit:
> 
>     for I in S'Range loop
>         ... S(I) ...
> 
> because this code really doesn't care what the index type is.
Yes, but OTOH it is nice to say that werever an object is declared, its
type appears on the same line. And if you want to make a rule, it is
always simpler to say "do that" than "do that, except when..."

> Can AdaControl check my style rule -- complain if I depend
> on the default-to-integer rule, but not complain if the
> type of the loop index is properly deducible from the
> stuff between "in" and "loop"?
Not yet, although it would be a very simple addition. The hardest part
would be to find an acceptable name for the rule. The current one is:

check declarations (anonymous_subtype_for);

and I wouldn't like:
check declarations (anonymous_subtype_except_range_for);
;-)


>> So it is really symetrical, except that in the case of a loop, you  are
>> allowed to "simplify" by omitting the "<type> range" part - forcing the
>> compiler to deduce the type from the range, which is not a good idea IMHO.
> 
> Why is that a bad idea (in the second case)?
> 
As noted before, it would be so simpler to say "no type inference". In
general, in the rare cases where Ada tried to save some typing, it was a
bad idea...
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Inferring array index type from array object

[Warren]

Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
> Dmitry A. Kazakov wrote:
>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
..
>>> 2. Is it possible to declare the index variable without hardcoding
>>> the index type (that is, to infer it from the array object)?
>> 
>> No, without improving the type system. E.g. introducing abstract
>> index types, and abstract range types (or more general sets of index
>> types), and abstract composite types like arrays.
> 
> I don't think such large language changes would be necessary. The 
> expression S'Range gives the compiler all the information about the
> type and its constraints, so I see no reason why Ada could not be
> extended simply to allow S'Range in a variable declaration, as in the
> above quoted "I : S'Range". The declared variable "I" would have the
> same (sub)type as the loop counter in "for I in S'Range loop ...".

I think most would agree that this is a "convenience" feature.
I think the language (and its compiler) is probably complicated
enough for these types of additions. Don't forget each new feature
requires a "test suite" and validation, in addition to the 
compiler itself.

Warren

Re: Inferring array index type from array object

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Not yet, although it would be a very simple addition. The hardest part
> would be to find an acceptable name for the rule. The current one is:
>
> check declarations (anonymous_subtype_for);
>
> and I wouldn't like:
> check declarations (anonymous_subtype_except_range_for);
> ;-)

I'd suggest something like "default_integer_range".  It's not just
for 'for' loops -- the same language malfeature occurs for array
type decls, for example.

- Bob

Re: Inferring array index type from array object

[Dmitry A. Kazakov]

On Wed, 23 Jun 2010 16:33:43 +0000 (UTC), Warren wrote:

> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>> Dmitry A. Kazakov wrote:
>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
> ..
>>>> 2. Is it possible to declare the index variable without hardcoding
>>>> the index type (that is, to infer it from the array object)?
>>> 
>>> No, without improving the type system. E.g. introducing abstract
>>> index types, and abstract range types (or more general sets of index
>>> types), and abstract composite types like arrays.
>> 
>> I don't think such large language changes would be necessary. The 
>> expression S'Range gives the compiler all the information about the
>> type and its constraints, so I see no reason why Ada could not be
>> extended simply to allow S'Range in a variable declaration, as in the
>> above quoted "I : S'Range". The declared variable "I" would have the
>> same (sub)type as the loop counter in "for I in S'Range loop ...".
> 
> I think most would agree that this is a "convenience" feature.
> I think the language (and its compiler) is probably complicated
> enough for these types of additions.

On the contrary, it is complicated because ranges and indices are irregular
types. Hard coded special cases make language more complex for both
programmer and compiler developer.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Inferring array index type from array object

[Warren]

Dmitry A. Kazakov expounded in
news:xhhsthd26ppk$.1iukhhnnqoq42$.dlg@40tude.net: 

> On Wed, 23 Jun 2010 16:33:43 +0000 (UTC), Warren wrote:
> 
>> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>>> Dmitry A. Kazakov wrote:
>>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
>> ..
>>>>> 2. Is it possible to declare the index variable without hardcoding
>>>>> the index type (that is, to infer it from the array object)?
>>>> 
>>>> No, without improving the type system. E.g. introducing abstract
>>>> index types, and abstract range types (or more general sets of
>>>> index types), and abstract composite types like arrays.
>>> 
>>> I don't think such large language changes would be necessary. The 
>>> expression S'Range gives the compiler all the information about the
>>> type and its constraints, so I see no reason why Ada could not be
>>> extended simply to allow S'Range in a variable declaration, as in
>>> the above quoted "I : S'Range". The declared variable "I" would have
>>> the same (sub)type as the loop counter in "for I in S'Range loop
>>> ...". 
>> 
>> I think most would agree that this is a "convenience" feature.
>> I think the language (and its compiler) is probably complicated
>> enough for these types of additions.
> 
> On the contrary, it is complicated because ranges and indices are
> irregular types. Hard coded special cases make language more complex
> for both programmer and compiler developer.

"On the contrary" to what?  I already said things were
"probably complicated enough".

Warren

Re: Inferring array index type from array object

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> outside the instantiation, you are supposed to know how it was
> instantiated, therefore you have access to the actuals. Why would you
> need to reexport the formals?

Formal types, yes, not so sure about formal objects. Consider eg a
generic signature package ..

   generic

      type Severity_Code is (<>);
      --  Messages are logged with this indication of severity.

      Error : Severity_Code;
      --  This value is used for error messages.

      Informational : Severity_Code;
      --  This value is used for informational messages.

      with procedure Log (Severity : Severity_Code; Message : String);

   package Logging_Signature is

      --  Make the actual instantiation parameters visible.
      package Exported is
         Error : Severity_Code renames Logging_Signature.Error;
         Informational : Severity_Code renames Logging_Signature.Informational;
         procedure Log (Severity : Severity_Code; Message : String)
           renames Logging_Signature.Log;
      end Exported;

Re: Inferring array index type from array object

[Niklas Holsti]

Peter C. Chapin wrote:
> Niklas Holsti wrote:
> 
>> I don't think such large language changes would be necessary. The 
>> expression S'Range gives the compiler all the information about the type 
>> and its constraints, so I see no reason why Ada could not be extended 
>> simply to allow S'Range in a variable declaration, as in the above 
>> quoted "I : S'Range". The declared variable "I" would have the same 
>> (sub)type as the loop counter in "for I in S'Range loop ...".
> 
> This seems weird to me. S'Range is a range, not a type. I agree that it
> includes type information, but then so does an object.
> 
> X : Integer;
> Y : X;       -- Let Y have the same type as X. Weird.

Another, perhaps more readable way would be to introduce some attributes 
that return types:

   I : S'Index_Type;

   Y : X'Type;

> Type inference is a big subject and while it can be very nice in languages
> that support it comprehensively, type inference doesn't really seem like
> the "Ada way" to me.

I would not call these examples "type inference", as they require no 
global or even subprogram-wide analysis. The desired type can be derived 
directly from what is written locally (and, of course, from the meaning 
of the identifiers).

> In any case, once you start supporting type inference in
> any form you have to wonder just how far down that road you want to go. Right
> now Ada only infers types in one very limited case (right?)... that is in
> support of implicitly declared loop index variables.

The type of implicitly declared loop index variables (for I in S'Range 
loop) needs only local analysis, so I would not call it type inference.

Resolution of overloaded subprogram and operator names is much more 
complex and could deserve to be called type inference. But even that 
requires only local analysis, although (I believe) it needs more than 
one traversal of the syntactic structure of the (nested) call.

"Real" type inference would be needed if these suggestions were extended 
to let variables be declared using the return type of an overloaded 
function call, with the overload resolution extended to take constraints 
from the use-sites of the variable. I won't try to give an example of 
that, as I agree with Peter that such non-local type inference would be 
against the Ada way.

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

Re: Inferring array index type from array object

[Niklas Holsti]

Warren wrote:
> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>> Dmitry A. Kazakov wrote:
>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
> ..
>>>> 2. Is it possible to declare the index variable without hardcoding
>>>> the index type (that is, to infer it from the array object)?
>>> No, without improving the type system. E.g. introducing abstract
>>> index types, and abstract range types (or more general sets of index
>>> types), and abstract composite types like arrays.
>> I don't think such large language changes would be necessary. The 
>> expression S'Range gives the compiler all the information about the
>> type and its constraints, so I see no reason why Ada could not be
>> extended simply to allow S'Range in a variable declaration, as in the
>> above quoted "I : S'Range". The declared variable "I" would have the
>> same (sub)type as the loop counter in "for I in S'Range loop ...".
> 
> I think most would agree that this is a "convenience" feature.

Yes, but in other contexts, when we advocate Ada, we often make a big 
point of the "convenience" of the 'Range attribute for arrays, such as 
"No need to pass extra parameters for array index bounds, just use 
'Range". The suggestion to let variables be declared by the "type" 
S'Range (or, if desired, a new attribute S'Index_Type) has a similar 
advantage (but a weaker one, I admit).

> I think the language (and its compiler) is probably complicated
> enough for these types of additions. Don't forget each new feature
> requires a "test suite" and validation, in addition to the 
> compiler itself.

Yes, of course. But as time goes on, and as long as the extensions are 
backwards compatible, I think the compiler writers and validators could 
live with a growing test and validation suite. But then I am not one of 
those guys...

On the other hand, I do worry about language and compiler complexity. If 
the creation and maintenance of Ada compilers is very costly and 
difficult, it creates a risk for the survival of Ada, as well as a brake 
on the evolution of Ada. When we talk about "the Ada way", it seems to 
me that we have in mind a simpler and more elegant and uniform thing 
than the current Ada language -- some "core of Ada" that perhaps could 
be defined and implemented in an easier way. I suspect that Dmitry has 
the same feeling, which is why he keeps suggesting (or dreaming about) 
such large and fundamental changes to Ada.

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

Re: Inferring array index type from array object

[J-P. Rosen]

Robert A Duff a �crit :

> I'd suggest something like "default_integer_range".  It's not just
> for 'for' loops -- the same language malfeature occurs for array
> type decls, for example.
> 
The "_for" is because I have separate rules for loops, indexing, case
statements...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Inferring array index type from array object

[Georg Bauhaus]

On 6/23/10 9:09 PM, Simon Wright wrote:
> "J-P. Rosen"<rosen@adalog.fr>  writes:
>
>> outside the instantiation, you are supposed to know how it was
>> instantiated, therefore you have access to the actuals. Why would you
>> need to reexport the formals?
>
> Formal types, yes, not so sure about formal objects. Consider eg a
> generic signature package ..
>
>     generic
>
>        type Severity_Code is (<>);
>        --  Messages are logged with this indication of severity.
>
>        Error : Severity_Code;
>        --  This value is used for error messages.
>
>        Informational : Severity_Code;
>        --  This value is used for informational messages.
>
>        with procedure Log (Severity : Severity_Code; Message : String);
>
>     package Logging_Signature is
>
>        --  Make the actual instantiation parameters visible.
>        package Exported is
>           Error : Severity_Code renames Logging_Signature.Error;
>           Informational : Severity_Code renames Logging_Signature.Informational;
>           procedure Log (Severity : Severity_Code; Message : String)
>             renames Logging_Signature.Log;
>        end Exported;
>

Similarly, without reference to names outside the generic,
at least as a temptation: If some container has a "regular
interface", one can think of an algorithm in terms of names
that from the container only.

with Some_Container;
generic
   with package Collection is new Some_Container (<>);
procedure Copy (input: Collection.T; output: in out Collection.T);
   -- copies objects of type Collection.E,
   -- from and to objects of type Collection.T,
   -- pointed to by objects of type Collection.Cursor.

generic
    type Element_Type is private;
package Some_Container is
    subtype E is Element_Type;
    type ... Set, List, Map, ... is private;
    subtype T is ... Set, List, Map, ...;
    ...
    type Cursor is private;
    ...
private
    ...
end Some_Container;

OTOH, it might be OK to make the Copy procedure from above
a child of Some_Container.  Since everything needed by Copy
is then "exported" by Some_Container to children, this might
do.

(It is not a solution to Simon's case, though, I guess.)

Re: Inferring array index type from array object

[Warren]

Niklas Holsti expounded in news:88f9osFmcmU1@mid.individual.net:

> Warren wrote:
>> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>>> Dmitry A. Kazakov wrote:
>>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
>> ..
>>>>> 2. Is it possible to declare the index variable without hardcoding
>>>>> the index type (that is, to infer it from the array object)?
>>>> No, without improving the type system. E.g. introducing abstract
>>>> index types, and abstract range types (or more general sets of index
>>>> types), and abstract composite types like arrays.
>>> I don't think such large language changes would be necessary. The 
>>> expression S'Range gives the compiler all the information about the
>>> type and its constraints, so I see no reason why Ada could not be
>>> extended simply to allow S'Range in a variable declaration, as in the
>>> above quoted "I : S'Range". The declared variable "I" would have the
>>> same (sub)type as the loop counter in "for I in S'Range loop ...".
>> 
>> I think most would agree that this is a "convenience" feature.
> 
> Yes, but in other contexts, when we advocate Ada, we often make a big 
> point of the "convenience" of the 'Range attribute for arrays, such as 
> "No need to pass extra parameters for array index bounds, just use 
> 'Range". The suggestion to let variables be declared by the "type" 
> S'Range (or, if desired, a new attribute S'Index_Type) has a similar 
> advantage (but a weaker one, I admit).

But how far down that road do you want to go? This is
the crux of the issue. 

I'd find ++X or X += n convenient. But should that be 
implemented in Ada?  I'm ok with leaving it out.

At some point, you have to draw a line in the sand.

Warren

Re: Inferring array index type from array object

[Niklas Holsti]

Warren wrote:
> Niklas Holsti expounded in news:88f9osFmcmU1@mid.individual.net:
> 
>> Warren wrote:
>>> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>>>> Dmitry A. Kazakov wrote:
>>>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
>>> ..
>>>>>> 2. Is it possible to declare the index variable without hardcoding
>>>>>> the index type (that is, to infer it from the array object)?
>>>>> No, without improving the type system. E.g. introducing abstract
>>>>> index types, and abstract range types (or more general sets of index
>>>>> types), and abstract composite types like arrays.
>>>> I don't think such large language changes would be necessary. The 
>>>> expression S'Range gives the compiler all the information about the
>>>> type and its constraints, so I see no reason why Ada could not be
>>>> extended simply to allow S'Range in a variable declaration, as in the
>>>> above quoted "I : S'Range". The declared variable "I" would have the
>>>> same (sub)type as the loop counter in "for I in S'Range loop ...".
>>> I think most would agree that this is a "convenience" feature.
>> Yes, but in other contexts, when we advocate Ada, we often make a big 
>> point of the "convenience" of the 'Range attribute for arrays, such as 
>> "No need to pass extra parameters for array index bounds, just use 
>> 'Range". The suggestion to let variables be declared by the "type" 
>> S'Range (or, if desired, a new attribute S'Index_Type) has a similar 
>> advantage (but a weaker one, I admit).
> 
> But how far down that road do you want to go? This is
> the crux of the issue. 
> 
> I'd find ++X or X += n convenient. But should that be 
> implemented in Ada?  I'm ok with leaving it out.
> 
> At some point, you have to draw a line in the sand.

"Convenience" is not always opposed to "the Ada way". Ada strives to be 
readable and correctness-prone (that is, the opposite of error-prone). I 
thnk that there are features that could be added to Ada that favour 
these goals but also increase convenience.

I think Ada could well support an add-and-assign syntax, for example in 
the syntax X +:= 1 (or X := * + 1 as it was written IIRC in Burroughs 
Extended Algol). It seems to me that if "X" is a longish name, perhaps 
with indexing and component selection, having it appear only once is 
both more readable and less error-prone than forcing it to be written 
and read twice, as in the standard X := X + 1. But the new syntax should 
be defined as an abbreviation for the standard form (albeit with only 
one evaluation of the name X), not as a new operator.

In C/C++, these updating assignment operators cause problems when they 
are used as (parts of) expressions, which I would not want to see in Ada.

To return to the case of using S'Range or S'Index_Type to declare 
variables, assume that we have

    S : array (Framp_Number) of Neighness_Value;

The question is then to compare the readability and error-proneness of 
the current standard form

    I : Framp_Number;
    ...
    ... S(I) ...

with the proposed alternative

    I : S'Range;  -- or S'Index_Type;
    ...
    ... S(I) ...

I don't see any general reason to prefer one or the other. The former 
style emphasises that "I" holds a Framp_Number value, with less emphasis 
on "I" being a valid index for S, while the latter style has the 
opposite emphasis. I would favour the latter style if the main or only 
role of "I" is to index S. This could avoid errors if the index type of 
S is later changed, and such a change would also be easier (less editing 
of text).

Of course, even if such features agree with the Ada way, it may not be 
worth-while to add them to Ada. That is a cost-benefit trade-off where 
the "cost" is in definition, implementation, testing, and maintenance of 
standards and compilers, but not a "cost" as some kind of "degradation" 
of the qualities of the Ada language. At most, there may be some "cost" 
in fully learning the (now larger) language.

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

Re: Inferring array index type from array object

[Adam Beneschan]

On Jun 28, 3:18 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:

> "Convenience" is not always opposed to "the Ada way". Ada strives to be
> readable and correctness-prone (that is, the opposite of error-prone). I
> thnk that there are features that could be added to Ada that favour
> these goals but also increase convenience.
>
> I think Ada could well support an add-and-assign syntax, for example in
> the syntax X +:= 1

see http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0187-1.txt?rev=1.6

                         -- Adam

Re: Inferring array index type from array object

[(see below)]

On 29/06/2010 02:49, in article
73ee19f6-1591-47ba-9dd0-3932935422f7@v13g2000prn.googlegroups.com, "Adam
Beneschan" <adam@irvine.com> wrote:

> On Jun 28, 3:18�pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
> wrote:
> 
>> "Convenience" is not always opposed to "the Ada way". Ada strives to be
>> readable and correctness-prone (that is, the opposite of error-prone). I
>> thnk that there are features that could be added to Ada that favour
>> these goals but also increase convenience.
>> 
>> I think Ada could well support an add-and-assign syntax, for example in
>> the syntax X +:= 1
> 
> see http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0187-1.txt?rev=1.6

Sigh!

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Inferring array index type from array object

[Warren]

Niklas Holsti expounded in news:88sld2F9m8U1@mid.individual.net:

> Warren wrote:
>> Niklas Holsti expounded in news:88f9osFmcmU1@mid.individual.net:
>>> Warren wrote:
>>>> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>>>>> Dmitry A. Kazakov wrote:
>>>>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
>>>> ..
>>>>>>> 2. Is it possible to declare the index variable without
>>>>>>> hardcoding the index type (that is, to infer it from the array
>>>>>>> object)? 
...
>>>>> same (sub)type as the loop counter in "for I in S'Range loop ...".
>>>> I think most would agree that this is a "convenience" feature.
>>> Yes, but in other contexts, when we advocate Ada, we often make a
>>> big point of the "convenience" of the 'Range attribute for arrays,
>>> such as "No need to pass extra parameters for array index bounds,
>>> just use 'Range". The suggestion to let variables be declared by the
>>> "type" S'Range (or, if desired, a new attribute S'Index_Type) has a
>>> similar advantage (but a weaker one, I admit).
...
>> At some point, you have to draw a line in the sand.
> 
> "Convenience" is not always opposed to "the Ada way". Ada strives to
> be readable and correctness-prone (that is, the opposite of
> error-prone). I thnk that there are features that could be added to
> Ada that favour these goals but also increase convenience.

No argument on that.

> I think Ada could well support an add-and-assign syntax, for example
> in the syntax X +:= 1 (or X := * + 1 as it was written IIRC in
> Burroughs 
..

One thing that really irks me (in lack of convenience)
is the lack of certain functions in the library support.  
For example, I was looking for the inverse of a complex 
number function. Did I missed it? My googling didn't 
turn up much, nor did grep on the package hdrs.

So because it is missing (AFIK), I had to google it and 
figure out how it is done and code it myself.  Wouldn't it
be safer if the function was already provided and tested?
Wouldn't it also be more accurately coded (floating
point can be tricky)? At least it would be tested.

IIRC, I ran into the similar issues with some other
functions (ATAN2??). The LOG10() issue was
resolved when I discovered there is a base argument
in LOG(), so that was just my own "user error".

But even if a function is considered "trivial", I
think it would be "safer" to include it. Additionally, 
having them provided means that they will 
be coded for the best accuracy.

Warren

Re: Inferring array index type from array object

[John B. Matthews]

In article <Xns9DA683A562C67WarrensBlatherings@81.169.183.62>,
 Warren <ve3wwg@gmail.com> wrote:

> One thing that really irks me (in lack of convenience)
> is the lack of certain functions in the library support.  
> For example, I was looking for the inverse of a complex 
> number function. Did I missed it? My googling didn't 
> turn up much, nor did grep on the package hdrs.
> 
> So because it is missing (AFIK), I had to google it and 
> figure out how it is done and code it myself.  Wouldn't it
> be safer if the function was already provided and tested?
> Wouldn't it also be more accurately coded (floating
> point can be tricky)? At least it would be tested.
> 
> IIRC, I ran into the similar issues with some other
> functions (ATAN2??). The LOG10() issue was
> resolved when I discovered there is a base argument
> in LOG(), so that was just my own "user error".
> 
> But even if a function is considered "trivial", I
> think it would be "safer" to include it. Additionally, 
> having them provided means that they will 
> be coded for the best accuracy.

So, what is the "missing" function?

<http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Inferring array index type from array object

[Warren]

John B. Matthews expounded in news:nospam-803846.13501829062010
@news.aioe.org:

> In article <Xns9DA683A562C67WarrensBlatherings@81.169.183.62>,
>  Warren <ve3wwg@gmail.com> wrote:
> 
>> One thing that really irks me (in lack of convenience)
>> is the lack of certain functions in the library support.  
>> For example, I was looking for the inverse of a complex 
>> number function. Did I missed it? My googling didn't 
>> turn up much, nor did grep on the package hdrs.
>> 
>> So because it is missing (AFIK), I had to google it and 
>> figure out how it is done and code it myself.  Wouldn't it
>> be safer if the function was already provided and tested?
>> Wouldn't it also be more accurately coded (floating
>> point can be tricky)? At least it would be tested.
>> 
>> IIRC, I ran into the similar issues with some other
>> functions (ATAN2??). The LOG10() issue was
>> resolved when I discovered there is a base argument
>> in LOG(), so that was just my own "user error".
>> 
>> But even if a function is considered "trivial", I
>> think it would be "safer" to include it. Additionally, 
>> having them provided means that they will 
>> be coded for the best accuracy.
> 
> So, what is the "missing" function?
> 
> <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>

1) The "inverse" of a complex number. 

2) Also, math libraries usually include atan2(y,x),
since the error can be large with certain ranges
of x in the tan(x) form:

#include <math.h>

double atan2(double y, double x);
float atan2f(float y, float x);
long double atan2l(long double y, long double x);

Warren

Re: Inferring array index type from array object

[Jeffrey R. Carter]

On 06/29/2010 12:31 PM, Warren wrote:
>
> 2) Also, math libraries usually include atan2(y,x),
> since the error can be large with certain ranges
> of x in the tan(x) form:

Ada.Numerics.Generic_Elementary_Functions defines

    function Arctan  (Y           : Float_Type'Base;
                      X           : Float_Type'Base := 1.0)
                                                     return Float_Type'Base;
    function Arctan  (Y           : Float_Type'Base;
                      X           : Float_Type'Base := 1.0;
                      Cycle       : Float_Type'Base) return Float_Type'Base;

-- 
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

Re: Inferring array index type from array object

[Warren]

Jeffrey R. Carter expounded in news:i0djsr$632$1@tornado.tornevall.net:

> On 06/29/2010 12:31 PM, Warren wrote:
>>
>> 2) Also, math libraries usually include atan2(y,x),
>> since the error can be large with certain ranges
>> of x in the tan(x) form:
> 
> Ada.Numerics.Generic_Elementary_Functions defines
> 
>     function Arctan  (Y           : Float_Type'Base;
>                       X           : Float_Type'Base := 1.0)
>                                                      return
>                               Float_Type'Base; 
>     function Arctan  (Y           : Float_Type'Base;
>                       X           : Float_Type'Base := 1.0;
>                       Cycle       : Float_Type'Base) return
>                       Float_Type'Base; 

Ok my bad, like the LOG10(), it is covered.  But
I see no inverse of a complex number yet. ;-)

Warren

Re: Inferring array index type from array object

[Adam Beneschan]

On Jun 29, 12:31 pm, Warren <ve3...@gmail.com> wrote:
>
> > So, what is the "missing" function?
>
> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
>
> 1) The "inverse" of a complex number.

Isn't that just 1.0 / X?  The division operator is defined in
Generic_Complex_Types and Complex_Types (G.1.1), and there is a
definition with a real left operand and complex right operand.  If
there's a different kind of inverse, I'm not familiar with it.  If
this is the same thing you're looking for, however, I don't see any
gain in providing a separate "Inverse" function.  1.0/X or X**(-1) are
readable enough for me.


> 2) Also, math libraries usually include atan2(y,x),
> since the error can be large with certain ranges
> of x in the tan(x) form:

As Jeffrey pointed out, Ada does have that.  Since Ada allows
overloaded function names, we can still call it Arctan instead of
having to invent a name like atan2 (or three names as they do in C).
By the way, I'm not sure that the error is the main reason for having
this function.  The result of the two-argument arctan function is in
the range -pi .. +pi, as opposed to -pi/2 .. +pi/2 for the one-
argument variation; this allows you to get a result in any of the four
quadrants (instead of just two), giving you the correct result when
you want to compute the angle corresponding to a point (x, y) on a
Cartesian graph.

                                -- Adam



> #include <math.h>
>
> double atan2(double y, double x);
> float atan2f(float y, float x);
> long double atan2l(long double y, long double x);
>
> Warren

Re: Inferring array index type from array object

[Damien Carbonne]

Le 29/06/2010 21:31, Warren a �crit :
> 1) The "inverse" of a complex number.

Why don't you use 1.0 / Z ?
It is defined in Ada.Numerics.Generic_Complex_Types:

    function "/" (Left : Real'Base; Right : Complex) return Complex;

Damien

Re: Inferring array index type from array object

[Dmitry A. Kazakov]

On Tue, 29 Jun 2010 13:22:55 -0700 (PDT), Adam Beneschan wrote:

> On Jun 29, 12:31�pm, Warren <ve3...@gmail.com> wrote:
>>
>>> So, what is the "missing" function?
>>
>>> <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
>>
>> 1) The "inverse" of a complex number.
> 
> Isn't that just 1.0 / X?

-X ? (additive inverse)

Re - j Im ? (complex conjugate)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Inferring array index type from array object

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

Adam Beneschan expounded in news:73a0af1d-7213-44af-90fa-ed6de4c64ce8
@b4g2000pra.googlegroups.com:

> On Jun 29, 12:31�pm, Warren <ve3...@gmail.com> wrote:
>>
>> > So, what is the "missing" function?
>>
>> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
>>
>> 1) The "inverse" of a complex number.
> 
> Isn't that just 1.0 / X?  

Ok, it seems to be, as the GSL (Gnu Scientific Library)
defines it as:

gsl_complex
gsl_complex_inverse (gsl_complex a)
{                               /* z=1/a */
  double s = 1.0 / gsl_complex_abs (a);

  gsl_complex z;
  GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) * s);
  return z;
}

But is this (GSL code) computationally more accurate 
than a simple 1/Z? Faster? I don't know, as I am currently
porting to Ada and avoiding analysis at this point (a huge 
task). But I do know that accuracy can be a good reason to 
implement something as a specialized function (like ATAN2
for example).

Warren

Re: Inferring array index type from array object

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Warren expounded in news:Xns9DA6AC2A2C8BWarrensBlatherings@81.169.183.62:

> Adam Beneschan expounded in news:73a0af1d-7213-44af-90fa-ed6de4c64ce8
> @b4g2000pra.googlegroups.com:
> 
>> On Jun 29, 12:31�pm, Warren <ve3...@gmail.com> wrote:
>>>
>>> > So, what is the "missing" function?
>>>
>>> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
>>>
>>> 1) The "inverse" of a complex number.
>> 
>> Isn't that just 1.0 / X?  
> 
> Ok, it seems to be, as the GSL (Gnu Scientific Library)
> defines it as:
> 
> gsl_complex
> gsl_complex_inverse (gsl_complex a)
> {                               /* z=1/a */
>   double s = 1.0 / gsl_complex_abs (a);
> 
>   gsl_complex z;
>   GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) * 
s);
>   return z;
> }

Apologies for following up my own post, but
looking at the GSL implementation of complex 
division:

gsl_complex
gsl_complex_div (gsl_complex a, gsl_complex b)
{                               /* z=a/b */
  double ar = GSL_REAL (a), ai = GSL_IMAG (a);
  double br = GSL_REAL (b), bi = GSL_IMAG (b);
   
  double s = 1.0 / gsl_complex_abs (b);

  double sbr = s * br;
  double sbi = s * bi;
 
  double zr = (ar * sbr + ai * sbi) * s;
  double zi = (ai * sbr - ar * sbi) * s;

  gsl_complex z;
  GSL_SET_COMPLEX (&z, zr, zi);
  return z;
}

Given a=1.0, the inverse function is definitely
higher performance.  It's simpler calculation 
probably implies more accuracy as well.

Warren

Re: Inferring array index type from array object

[Jeffrey R. Carter]

On 06/29/2010 01:55 PM, Warren wrote:
>
> gsl_complex
> gsl_complex_inverse (gsl_complex a)
> {                               /* z=1/a */
>    double s = 1.0 / gsl_complex_abs (a);
>
>    gsl_complex z;
>    GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) * s);
>    return z;
> }

IIUC, the multiplicative inverse of z is

(z*)/(|z|**2)

where z* is the conjugate of z. Maybe this is the same thing.

-- 
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

Re: Inferring array index type from array object

[John B. Matthews]

In article <Xns9DA69DDA9F2AWarrensBlatherings@81.169.183.62>,
 Warren <ve3wwg@gmail.com> wrote:

> >> I was looking for the inverse of a complex  number function.
[...]
> > So, what is the "missing" function?
> > 
> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
> 
> 1) The "inverse" of a complex number. 

Ah, the multiplicative inverse. I thought you meant inverse of a 
complex valued function, such as Exp/Log or Sin/Arcsin. As Adam 
and Damien suggested, 1.0 / Z looks right:

function "/" (Left : Real'Base; Right : Complex) return Complex;

<http://www.adaic.com/standards/05rm/html/RM-G-1-1.html>

> 2) Also, math libraries usually include atan2(y,x),
> since the error can be large with certain ranges
> of x in the tan(x) form:
> 
> #include <math.h>
> 
> double atan2(double y, double x);
> float atan2f(float y, float x);
> long double atan2l(long double y, long double x);

Adam also mentioned Arctan for real values:

<http://www.adaic.com/standards/05rm/html/RM-A-5-1.html>

For complex values, you may want "the principal value of the 
argument of the complex number x + iy."

<http://en.wikipedia.org/wiki/Inverse_trigonometric_functions>

function Argument (X : Complex) return Real'Base;

<http://www.adaic.com/standards/05rm/html/RM-G-1-1.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Inferring array index type from array object

[John B. Matthews]

In article <Xns9DA6ACEFDCF8BWarrensBlatherings@81.169.183.62>,
 Warren <ve3wwg@gmail.com> wrote:

> Warren expounded in news:Xns9DA6AC2A2C8BWarrensBlatherings@81.169.183.62:
> 
> > Adam Beneschan expounded in news:73a0af1d-7213-44af-90fa-ed6de4c64ce8
> > @b4g2000pra.googlegroups.com:
> > 
> >> On Jun 29, 12:31 pm, Warren <ve3...@gmail.com> wrote:
> >>>
> >>> > So, what is the "missing" function?
> >>>
> >>> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
> >>>
> >>> 1) The "inverse" of a complex number.
> >> 
> >> Isn't that just 1.0 / X?  
> > 
> > Ok, it seems to be, as the GSL (Gnu Scientific Library)
> > defines it as:
> > 
> > gsl_complex
> > gsl_complex_inverse (gsl_complex a)
> > {                               /* z=1/a */
> >   double s = 1.0 / gsl_complex_abs (a);
> > 
> >   gsl_complex z;
> >   GSL_SET_COMPLEX (
> >     &z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) * s);
> >   return z;
> > }
> 
> Apologies for following up my own post, but
> looking at the GSL implementation of complex 
> division:
> [...]
> Given a=1.0, the inverse function is definitely
> higher performance.  It's simpler calculation 
> probably implies more accuracy as well.

The more comparable Ada implementation (from GNAT) would be

function "/" (Left : Real'Base; Right : Complex) return Complex is
    a : constant R := Left;
    c : constant R := Right.Re;
    d : constant R := Right.Im;
begin
    return Complex'(Re =>   (a * c) / (c ** 2 + d ** 2),
                    Im => -((a * d) / (c ** 2 + d ** 2)));
end "/";

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Inferring array index type from array object

[Damien Carbonne]

Le 29/06/2010 23:00, Warren a �crit :
> Warren expounded in news:Xns9DA6AC2A2C8BWarrensBlatherings@81.169.183.62:
>>>>
>>>> 1) The "inverse" of a complex number.
>>>
>>> Isn't that just 1.0 / X?
>>
<snip>
>
> Given a=1.0, the inverse function is definitely
> higher performance.  It's simpler calculation
> probably implies more accuracy as well.
>
> Warren

Ada has several overloaded versions of "/".
GNAT seems to implement "/" (Real, Complex) using a simplified version 
of "/" (Complex, Complex).
It looks (almost) like the example you gave.

    function "/" (Left : Real'Base; Right : Complex) return Complex is
       a : constant R := Left;
       c : constant R := Right.Re;
       d : constant R := Right.Im;
    begin
       return Complex'(Re =>   (a * c) / (c ** 2 + d ** 2),
                       Im => -((a * d) / (c ** 2 + d ** 2)));
    end "/";

There are differences that may have an impact on speed.
But the above version is simpler than this one:

    function "/" (Left, Right : Complex) return Complex is
       a : constant R := Left.Re;
       b : constant R := Left.Im;
       c : constant R := Right.Re;
       d : constant R := Right.Im;

    begin
       if c = 0.0 and then d = 0.0 then
          raise Constraint_Error;
       else
          return Complex'(Re => ((a * c) + (b * d)) / (c ** 2 + d ** 2),
                          Im => ((b * c) - (a * d)) / (c ** 2 + d ** 2));
       end if;
    end "/";

Damien

Re: Inferring array index type from array object

[Adam Beneschan]

On Jun 29, 2:00 pm, Warren <ve3...@gmail.com> wrote:
> Warren expounded innews:Xns9DA6AC2A2C8BWarrensBlatherings@81.169.183.62:
>
>
>
>
>
>
>
> > Adam Beneschan expounded in news:73a0af1d-7213-44af-90fa-ed6de4c64ce8
> > @b4g2000pra.googlegroups.com:
>
> >> On Jun 29, 12:31 pm, Warren <ve3...@gmail.com> wrote:
>
> >>> > So, what is the "missing" function?
>
> >>> > <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html>
>
> >>> 1) The "inverse" of a complex number.
>
> >> Isn't that just 1.0 / X?  
>
> > Ok, it seems to be, as the GSL (Gnu Scientific Library)
> > defines it as:
>
> > gsl_complex
> > gsl_complex_inverse (gsl_complex a)
> > {                               /* z=1/a */
> >   double s = 1.0 / gsl_complex_abs (a);
>
> >   gsl_complex z;
> >   GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) *
> s);
> >   return z;
> > }
>
> Apologies for following up my own post, but
> looking at the GSL implementation of complex
> division:
>
> gsl_complex
> gsl_complex_div (gsl_complex a, gsl_complex b)
> {                               /* z=a/b */
>   double ar = GSL_REAL (a), ai = GSL_IMAG (a);
>   double br = GSL_REAL (b), bi = GSL_IMAG (b);
>
>   double s = 1.0 / gsl_complex_abs (b);
>
>   double sbr = s * br;
>   double sbi = s * bi;
>
>   double zr = (ar * sbr + ai * sbi) * s;
>   double zi = (ai * sbr - ar * sbi) * s;
>
>   gsl_complex z;
>   GSL_SET_COMPLEX (&z, zr, zi);
>   return z;
>
> }
>
> Given a=1.0, the inverse function is definitely
> higher performance.  It's simpler calculation
> probably implies more accuracy as well.

That last makes no sense to me.  The code to compute A / Z for real A
has got to be essentially the same as computing 1.0 / Z and then
multiplying the real and imaginary parts of the result by A---how else
would it be done?  So while you might gain slightly in efficiency by
not performing an extra step, I don't see how you can gain in
accuracy---I've never heard of accuracy ever getting lost by
multiplying a floating-point number by 1.0.  Not according to
everything I know about how floating-point arithmetic works.

Even if you implement A / Z by converting A to a complex number A+0i
and then performing a complex division, I still don't see any way to
do this except by computing 1.0/Z and performing a complex
multiplication; again, while there will be some wasted processor
cycles, you're still going to be multiplying numbers by 1.0 and then
adding 0.0, which again is not going to result in any lost accuracy.

                                  -- Adam

Re: Inferring array index type from array object

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> By the way, I'm not sure that the error is the main reason for having
> this function.  The result of the two-argument arctan function is in
> the range -pi .. +pi, as opposed to -pi/2 .. +pi/2 for the one-
> argument variation; this allows you to get a result in any of the four
> quadrants (instead of just two), giving you the correct result when
> you want to compute the angle corresponding to a point (x, y) on a
> Cartesian graph.

And avoiding problems with the extremes; arctan (y / x) is a Bad Idea!

Re: Inferring array index type from array object

[Adam Beneschan]

On Jun 29, 10:01 pm, Simon Wright <si...@pushface.org> wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > By the way, I'm not sure that the error is the main reason for having
> > this function.  The result of the two-argument arctan function is in
> > the range -pi .. +pi, as opposed to -pi/2 .. +pi/2 for the one-
> > argument variation; this allows you to get a result in any of the four
> > quadrants (instead of just two), giving you the correct result when
> > you want to compute the angle corresponding to a point (x, y) on a
> > Cartesian graph.
>
> And avoiding problems with the extremes; arctan (y / x) is a Bad Idea!

I assume you mean because x could be 0.0 (or close to it)?  Yes,
that's another case where the two-argument arctan will give you the
result you probably want (i.e. +pi/2 or -pi/2).

                           -- Adam

Re: Inferring array index type from array object

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

Adam Beneschan expounded in news:102a43e8-21ea-4606-8b0d-6d492f9e07f8
@v13g2000prn.googlegroups.com:

> On Jun 29, 2:00�pm, Warren <ve3...@gmail.com> wrote:
>> Warren expounded 
>> > Adam Beneschan expounded 
>> > @b4g2000pra.googlegroups.com:
..
>> >> Isn't that just 1.0 / X? �
>>
>> > Ok, it seems to be, as the GSL (Gnu Scientific Library)
>> > defines it as:
>>
>> > gsl_complex
>> > gsl_complex_inverse (gsl_complex a)
>> > { � � � � � � � � � � � � � � � /* z=1/
> a */
>> > � double s = 1.0 / gsl_complex_abs (a);
>>
>> > � gsl_complex z;
>> > � GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) *
>> s);
>> > � return z;
>> > }
>>
>> gsl_complex
>> gsl_complex_div (gsl_complex a, gsl_complex b)
>> { � � � � � � � � � � � � � � � /* z=a/b 
> */
>> � double ar = GSL_REAL (a), ai = GSL_IMAG (a);
>> � double br = GSL_REAL (b), bi = GSL_IMAG (b);
>>
>> � double s = 1.0 / gsl_complex_abs (b);
>>
>> � double sbr = s * br;
>> � double sbi = s * bi;
>>
>> � double zr = (ar * sbr + ai * sbi) * s;
>> � double zi = (ai * sbr - ar * sbi) * s;
>>
>> � gsl_complex z;
>> � GSL_SET_COMPLEX (&z, zr, zi);
>> � return z;
>>
>> }
>>
>> Given a=1.0, the inverse function is definitely
>> higher performance. �It's simpler calculation
>> probably implies more accuracy as well.
> 
> That last makes no sense to me.  The code to compute A / Z for real A
> has got to be essentially the same as computing 1.0 / Z and then
> multiplying the real and imaginary parts of the result by A---how else
> would it be done?  So while you might gain slightly in efficiency by
> not performing an extra step, I don't see how you can gain in
> accuracy---I've never heard of accuracy ever getting lost by
> multiplying a floating-point number by 1.0.  

I'll concede your accuracy point. Efficiency however is 
still important for some applications, like realtime signal 
processing.

Warren