use of 'Base to compensate for the lack of information

use of 'Base to compensate for the lack of information

[Mehdi Saada]

To compensate for the lack of exercices, I rewrote part of the package provided by the teacher. It sure allows a better understanding of what's going on. And I purged the errors much faster than the first time.

There are the p_poly package, who elaborate the operations on polynome, without knowing about the internal structure of the coefficients, whose type is defined is another generic package.

P_poly is generic too, and take the needed methods of a private "ELEMENT" representing the coefficient as parameters, along with ELEMENT itself, who could be a scalar, modular or whatever type instead of a record modelling rationals.

It seems good and practical, but at one time, I need the coefficient to be multiplied by the coefficients' array index, which is a Natural.

So, I wrote
    with function "*" (E1: in ELEMENT; E2: in NATURAL'Base) return ELEMENT is <>;

But since X'Base meant the unconstrained subtype of X, any type defined as "type T is range ..." won't fit in. Yet I don't want any assumption on the nature of ELEMENT. It could be defined as Integer, Natural, modular types, or be rational made of modular types in case of FINITE FIELDS.

How do I do while keeping that generic design ?

Re: use of 'Base to compensate for the lack of information

[Dmitry A. Kazakov]

On 2017-12-27 13:29, Mehdi Saada wrote:

> It seems good and practical, but at one time, I need the coefficient 
> to be multiplied by the coefficients' array index, which is a
> Natural.

Does not make sense, but ...

> So, I wrote
>      with function "*" (E1: in ELEMENT; E2: in NATURAL'Base) return ELEMENT is <>;
> 
> But since X'Base meant the unconstrained subtype of X, any type
> defined as "type T is range ..." won't fit in.

Since it is not Integer, yes.

> Yet I don't want any
> assumption on the nature of ELEMENT. It could be defined as Integer,
> Natural, modular types, or be rational made of modular types in case of
> FINITE FIELDS.

Array index of a rational type? That makes any array except empty and 
singleton countably infinite, well, well.

> How do I do while keeping that generic design ?

    type Index is range <>;
    with function "*" (Left : Element; Right : Index)
       return Element is <>;

  [ with function "*" (Left, Right : Element) return Element is <>; ]

If you want it be any copyable type, then

    type Bandersnatch is private;
    with function "*" (Left : Element; Right : Bandersnatch)
       return Element is <>;

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

Re: use of 'Base to compensate for the lack of information

[Mehdi Saada]

Le mercredi 27 décembre 2017 14:28:22 UTC+1, Dmitry A. Kazakov a écrit :
> On 2017-12-27 13:29, Mehdi Saada wrote:
> 
> > It seems good and practical, but at one time, I need the coefficient 
> > to be multiplied by the coefficients' array index, which is a
> > Natural.
> 
> Does not make sense, but ...

Ahahah... Now I read myself, I think the same: utter nonsense.
I mean "array of ELEMENT (which should be rational coefficients, but can be integer or modular), indexed by signed integers".

Hence, that should be ok, and the user should only need to provide ELEMENT, T_DEGRE and NULL_ELEMENT. No need for a maximum degre anymore, by the way.
generic
    type T_DEGRE is range <>;
    type Element is private;
    with function "+" (E1,E2: in ELEMENT) return ELEMENT is <>;
    with function "-" (E1,E2: in ELEMENT) return ELEMENT is <>;
    with function "-" (E1: in ELEMENT) return ELEMENT is <>;
    with function "*" (E1: in ELEMENT; E2: in T_DEGRE) return ELEMENT is <>;
    with function "/" (E1,E2: in ELEMENT) return ELEMENT is <>;
    with procedure ECRIRE(E1: in ELEMENT) is <>;
    NULL_ELEMENT: in ELEMENT;

Re: use of 'Base to compensate for the lack of information

[Jeffrey R. Carter]

On 12/27/2017 01:29 PM, Mehdi Saada wrote:
> To compensate for the lack of exercices, I rewrote part of the package provided by the teacher. It sure allows a better understanding of what's going on.

It can be an instructive exercise to take an existing library and write (some 
of) the pkg bodies from scratch, without referring to the existing implementation.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51