comp.lang.ada
 help / color / mirror / Atom feed
From: Mehdi Saada <00120260a@gmail.com>
Subject: use of 'Base to compensate for the lack of information
Date: Wed, 27 Dec 2017 04:29:44 -0800 (PST)
Date: 2017-12-27T04:29:44-08:00	[thread overview]
Message-ID: <dc81f170-1442-48d8-af5d-a929cfabfdcb@googlegroups.com> (raw)

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 ?


             reply	other threads:[~2017-12-27 12:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-27 12:29 Mehdi Saada [this message]
2017-12-27 13:28 ` use of 'Base to compensate for the lack of information Dmitry A. Kazakov
2017-12-27 13:53   ` Mehdi Saada
2017-12-27 16:10 ` Jeffrey R. Carter
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox