"too few element" in an unconstrained array, given as litteral ?

"too few element" in an unconstrained array, given as litteral ?

[Mehdi Saada]

The definitions for polynoms I slightly modified, don't fit anymore wit the test program:

 28   Set(Poly3,(2/1, 5/8)); -- but every call on Set does the same
ts_poly1.adb:28:14: warning: too few elements for type "T_Liste_Coef" defined at p_poly_v1_g.ads:48, instance at line 20
ts_poly1.adb:28:14: warning: "Constraint_Error" will be raised at run time

 18    package PRat is new P_Rationnels_G(T_Entier);                        
 19    package PRatIO is new PRat.IO;                                       
 20    package PPoly is new P_Poly_V1_G(PRat, PRatIO, 40);               
_____________________________________
generic
   with package P_Rationnels is new P_Rationnels_G(<>);
   with package P_Rationnels_io is new P_Rationnels.Io(<>);
   Max : Positive;
package PPoly is
_____________________________________

subtype T_Degre is T_Entier range 0..T_Entier(Max); -- I found this phrasing ugly as hell, but I don't know how to make T_Entier visible in the "generic" part since p_rationnels is yet to be instanciated... But I guess it's not the cause of the exception here.

In the test program: Set(Poly3,(2/11)); -- any call of Set raises constraint_error

The current definitions:
type T_Liste_Coef is array (T_Degre range 1..T_Degre'Last) of T_Rationnel;
type T_Vect_Coef is array (T_Degre range <>) of T_Rationnel;
type T_Polynome (Degre : T_Degre := 0) is -- type mutant
record
   Coef : T_Vect_Coef (0..Degre) := (others => Nulle);
end record;

And the constructor method: :
procedure Set (
         Poly :    out T_Polynome;
         Vect : in     T_Liste_Coef ) is
      V_Coef : T_Vect_Coef (0 .. Vect'Last - 1);
   begin
      for I in Vect'range loop
      V_Coef (I - 1) := Vect (I);
   end loop;
   Poly := (Vect'Length - 1, V_Coef);
end Set;

How can an object of an UNCONSTAINED array type, given as a litteral, have "too few elements ?", though sometime I saw "too few" means "too much", but it wouldn't make more sense to me either.

Re: "too few element" in an unconstrained array, given as litteral ?

[Niklas Holsti]

On 18-01-20 12:55 , Mehdi Saada wrote:
> The definitions for polynoms I slightly modified, don't fit anymore wit the test program:
>
>  28   Set(Poly3,(2/1, 5/8)); -- but every call on Set does the same
> ts_poly1.adb:28:14: warning: too few elements for type "T_Liste_Coef" defined
>    at p_poly_v1_g.ads:48, instance at line 20
> ts_poly1.adb:28:14: warning: "Constraint_Error" will be raised at run time
   ...
> The current definitions:
> type T_Liste_Coef is array (T_Degre range 1..T_Degre'Last) of T_Rationnel;
    ...
> How can an object of an UNCONSTAINED array type, given as a litteral, have
> "too few elements ?"

T_Liste_Coef is not unconstrained; there is no "range <>" in its 
declaration. It is constrained and any object of this subtype needs 
T_Degre'Last elements.

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

Re: "too few element" in an unconstrained array, given as litteral ?

[Mehdi Saada]

That's what I confused then ! How do I say then, "between A and C elements" ? That what's I intended.
I suppose I need to define another subtype before the array,
subtype T_Indice is T_Degre range then 1..T_Degre'Last, to convey what I want.

Re: "too few element" in an unconstrained array, given as litteral ?

[Niklas Holsti]

On 18-01-20 15:21 , Mehdi Saada wrote:
> That's what I confused then ! How do I say then, "between A and C elements" ? That what's I intended.
> I suppose I need to define another subtype before the array,
> subtype T_Indice is T_Degre range then 1..T_Degre'Last, to convey what I want.

Yep. And then define the array as ... array (T_Indice range <>) of ...

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

Re: "too few element" in an unconstrained array, given as litteral ?

[Mehdi Saada]

We discussed it some weeks ago,
but how do I write:
Temp := (Poly_B.Degre + Ind - 1, (Poly_B.Degre + Ind - 1 => (1/1)), others => <>);
Ind is the index of a for loop, hence there's a dynamic choice, hence ... No other choices possible. So the above is illegal. I want the nicest expression, because the algo part was already hard on me, so I need to find convoluted ways to counter my less that optimal syntaxical knowledge, it's too much.
I need that to implement multiplying a polynom with x, or x**2, and so forth, with a bunch of zero to the left.
That done, I saw all others primitives work... and I'll be in heaven. For a brief moment, though.

Why in (array) aggregate, no more component allowed after a dynamic choice ?

[Mehdi Saada]

I had to write
declare
   Temp: T_Polynome (Poly_B.Degre + Ind -1);
begin
   Temp.Coef(Poly_B.Degre + Ind -1) :=              
   Poly_A.Coef(Poly_B.Degre+Ind)/Poly_B.Coef(Poly_B.Degre);
end;

Ind being a loop indice.

whereas I would have prefered:
Temp: T_polynome :=  (Poly_B.Degre + Ind - 1,(Poly_B.Degre + Ind - 1 => Poly_A.Coef (Poly_B.Degre+Ind)/Poly_B.Coef(Poly_B.Degre), others => <>));

What's the reason behind this limitation, whereas in one more sentence, the same effect is achieved ?

Re: "too few element" in an unconstrained array, given as litteral ?

[Niklas Holsti]

On 18-01-20 18:52 , Mehdi Saada wrote:
> We discussed it some weeks ago,
> but how do I write:
> Temp := (Poly_B.Degre + Ind - 1, (Poly_B.Degre + Ind - 1 => (1/1)), others => <>);

(There seems to be a typo in the above: the second ')' should be at the 
end.)

> Ind is the index of a for loop, hence there's a dynamic choice, hence ...
> No other choices possible. So the above is illegal.

Yes.

> I want the nicest expression, because the algo part was already hard

Assuming that Poly_B.Degre + Ind - 1 is the highest index ('Last) in the 
aggregate, you could concatenate two aggregates (the index used in the 
second, one-element concatenand is irrelevant, I chose 1 for brevity, 
see RM 4.5.3):

Temp := (
    Poly_B.Degre + Ind - 1,
    (0 .. Poly_B.Degre + Ind - 2 => <>) & (1 => (1/1)));

That assumes also that the first index is zero.

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

Re: Why in (array) aggregate, no more component allowed after a dynamic choice ?

[Randy Brukardt]

It's complicated both for the reader and the compiler to ensure that an 
aggregate with multiple dynamic components in fact covers all of the 
components of the target type. (And that check is a hallmark of Ada, one 
cannot accidentally forget to specify a component and still have a working 
program.) It also gets very complicated to generate an others clause if a 
number of components at unknown locations are previously initialized.

Ada probably could have allowed two such components or maybe even three 
without the complexity growing too much. But there is a standard language 
design axiom that one should allow either zero, one, or unlimited/many of 
any thing. Allowing more than one dynamic component would violate this 
axiom, and the limit it is rarely encountered (you seem to have a knack for 
running into language corner-cases :-).

                                Randy.

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:aa4f3429-4bfd-44ac-a817-9fd0dd187841@googlegroups.com...
>I had to write
> declare
>   Temp: T_Polynome (Poly_B.Degre + Ind -1);
> begin
>   Temp.Coef(Poly_B.Degre + Ind -1) :=
>   Poly_A.Coef(Poly_B.Degre+Ind)/Poly_B.Coef(Poly_B.Degre);
> end;
>
> Ind being a loop indice.
>
> whereas I would have prefered:
> Temp: T_polynome :=  (Poly_B.Degre + Ind - 1,(Poly_B.Degre + Ind - 1 => 
> Poly_A.Coef (Poly_B.Degre+Ind)/Poly_B.Coef(Poly_B.Degre), others => <>));
>
> What's the reason behind this limitation, whereas in one more sentence, 
> the same effect is achieved ?