I get this error on my program from the menu build => check semantic
exponent must be of type Natural, found type "Standard.Float".

Should not 10 ** (log10 a + log10 b) = a*b?

This is my compiler build:

GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32
GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32
SPARK Community 2020 (20200429)

Here is the relevant part of program:

with Ada.Numerics.Elementary_Functions;
use Ada.Numerics;

Counter : Integer := 1;
Logs : Float := 0.0;
Multiples : Float;

inside some loop:

Logs := Elementary_Functions.Log (Float(Counter), 10.0) + Logs;
Multiples := 10.0 ** Logs; => this is where it fails

I checked the Ada.Numerics.Generic_Elementary_Functions specifications
(since Ada.Numerics.Elementary_Functions is just an instance of the generics)
and it said:

function "**" (Left, Right : Float_Type'Base) return Float_Type'Base with
Pre => (if Left = 0.0 then Right > 0.0) and Left >= 0.0,
Post => "**"'Result >= 0.0
and then (if Right = 0.0 then "**"'Result = 1.0)
and then (if Right = 1.0 then "**"'Result = Left)
and then (if Left = 1.0 then "**"'Result = 1.0)
and then (if Left = 0.0 then "**"'Result = 0.0);

So the question is this a Gnat bug, wrong function used, faulty logic on me or
I am declaring it wrong?

On 2021-07-20 15:02, Richard Iswara wrote:
> I get this error on my program from the menu build => check semantic
> exponent must be of type Natural, found type "Standard.Float".
>
> Should not 10 ** (log10 a + log10 b) = a*b?
>
> This is my compiler build:
>
> GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32
> GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32
> SPARK Community 2020 (20200429)
>
> Here is the relevant part of program:
>
> with Ada.Numerics.Elementary_Functions;
> use Ada.Numerics;

To make Ada.Numerics.Elementary_Functions."**" visible without
qualification, you should also do "use Ada.Numerics.Elementary_Functions".

Otherwise the compiler will see only the predefined operator:

function "**"(Left : Float; Right : Integer'Base) return Float

(see RM 4.5.6(9 and 10)) which explains why the compiler does not accept
a floating-point value as the Right operand to "**".

> Logs : Float := 0.0;
> Multiples : Float;
...> Multiples := 10.0 ** Logs; => this is where it fails

It fails because the compiler sees only the predefined "**" operator
which has an integral right operand.

On 20/07/2021 21.09, Niklas Holsti wrote:
> On 2021-07-20 15:02, Richard Iswara wrote:
>> I get this error on my program from the menu build => check semantic
>> exponent must be of type Natural, found type "Standard.Float".
>>
>> Should not 10 ** (log10 a + log10 b) = a*b?
>>
>> This is my compiler build:
>>
>> GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32
>> GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32
>> SPARK Community 2020 (20200429)
>>
>> Here is the relevant part of program:
>>
>> with Ada.Numerics.Elementary_Functions;
>> use Ada.Numerics;
>
>
> To make Ada.Numerics.Elementary_Functions."**" visible without
> qualification, you should also do "use Ada.Numerics.Elementary_Functions".
>
> Otherwise the compiler will see only the predefined operator:
>
>    function "**"(Left : Float; Right : Integer'Base) return Float
>
> (see RM 4.5.6(9 and 10)) which explains why the compiler does not accept
> a floating-point value as the Right operand to "**".
>
>
>> Logs : Float := 0.0;
>> Multiples : Float;
>    ...> Multiples := 10.0 ** Logs;  => this is where it fails
>
>
> It fails because the compiler sees only the predefined "**" operator
> which has an integral right operand.

Thank you. So it is a visibility problem.

On 7/21/21 4:23 AM, Richard Iswara wrote:
> On 20/07/2021 21.09, Niklas Holsti wrote:
>> On 2021-07-20 15:02, Richard Iswara wrote:
>>> I get this error on my program from the menu build => check semantic
>>> exponent must be of type Natural, found type "Standard.Float".
>>>
>>> Should not 10 ** (log10 a + log10 b) = a*b?
>>>
>>> This is my compiler build:
>>>
>>> GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32
>>> GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32
>>> SPARK Community 2020 (20200429)
>>>
>>> Here is the relevant part of program:
>>>
>>> with Ada.Numerics.Elementary_Functions;
>>> use Ada.Numerics;
>>
>>
>> To make Ada.Numerics.Elementary_Functions."**" visible without qualification,
>> you should also do "use Ada.Numerics.Elementary_Functions".
>>
>> Otherwise the compiler will see only the predefined operator:
>>
>>     function "**"(Left : Float; Right : Integer'Base) return Float
>>
>> (see RM 4.5.6(9 and 10)) which explains why the compiler does not accept a
>> floating-point value as the Right operand to "**".
>>
>>
>>> Logs : Float := 0.0;
>>> Multiples : Float;
>>     ...> Multiples := 10.0 ** Logs;  => this is where it fails
>>
>>
>> It fails because the compiler sees only the predefined "**" operator which has
>> an integral right operand.
>
> Thank you. So it is a visibility problem.

"Understanding visibility is the key to understanding Ada." -- /Ada Distilled/

Recommending the use package clause as a solution to a misunderstanding of
visibility is a disservice to a beginning user. Widespread application of use
pkg clauses is a crutch to avoid understanding visibility. I recommend that
those who do not understand visibility avoid the use clause altogether, as this
forces them to learn about visibility. When one understands visibility, one can
then make reasoned decisions about whether and when to add use clauses.

In decreasing order of specificity, the ways to call an operation in a pkg are

* Use the full name: Ada.Numerics.Elementary_Functions."**" (10.0, Logs)
This calls the operation once without changing its visibility
* Rename the operation:
function "**" (Left : Float; Right : Float) return Float renames
Ada.Numerics.Elementary_Functions."**";
This makes the specific operation visible
* Use type: this makes all operators of the type visible (not applicable
in this case)
* Use all type: this makes all operations of the type visible (not
applicable in this case)
* Use package: this makes everything in the package visible

Use pkg is clearly overkill for this case, and overuse of it can have negative
consequences.

--
Jeff Carter
"Choose a data representation that
makes the program simple."
Elements of Programming Style
188

On Wednesday, July 21, 2021 at 2:29:22 AM UTC-6, Jeffrey R. Carter wrote:
> > Thank you. So it is a visibility problem.
> "Understanding visibility is the key to understanding Ada." -- /Ada Distilled/
>
> Recommending the use package clause as a solution to a misunderstanding of
> visibility is a disservice to a beginning user. Widespread application of use
> pkg clauses is a crutch to avoid understanding visibility. I recommend that
> those who do not understand visibility avoid the use clause altogether, as this
> forces them to learn about visibility. When one understands visibility, one can
> then make reasoned decisions about whether and when to add use clauses.
>
> In decreasing order of specificity, the ways to call an operation in a pkg are
>
> * Use the full name: Ada.Numerics.Elementary_Functions."**" (10.0, Logs)
> This calls the operation once without changing its visibility
> * Rename the operation:
> function "**" (Left : Float; Right : Float) return Float renames
> Ada.Numerics.Elementary_Functions."**";
> This makes the specific operation visible
> * Use type: this makes all operators of the type visible (not applicable
> in this case)
> * Use all type: this makes all operations of the type visible (not
> applicable in this case)
> * Use package: this makes everything in the package visible
>
> Use pkg is clearly overkill for this case, and overuse of it can have negative
> consequences.
>
> --
> Jeff Carter
> "Choose a data representation that
> makes the program simple."
> Elements of Programming Style
> 188

This is excellent advice and an good list, though the last element should be two or three:
* Local, via declare-region/-scope; and
* ["local" via usage inside the spec, (perhaps in the public portion, perhaps in the private); and]
* Global (top of the file context-clauses).

On 21/07/2021 23.56, Shark8 wrote:
> On Wednesday, July 21, 2021 at 2:29:22 AM UTC-6, Jeffrey R. Carter wrote:
>>> Thank you. So it is a visibility problem.
>> "Understanding visibility is the key to understanding Ada." -- /Ada Distilled/
>>
>> Recommending the use package clause as a solution to a misunderstanding of
>> visibility is a disservice to a beginning user. Widespread application of use
>> pkg clauses is a crutch to avoid understanding visibility. I recommend that
>> those who do not understand visibility avoid the use clause altogether, as this
>> forces them to learn about visibility. When one understands visibility, one can
>> then make reasoned decisions about whether and when to add use clauses.
>>
>> In decreasing order of specificity, the ways to call an operation in a pkg are
>>
>> * Use the full name: Ada.Numerics.Elementary_Functions."**" (10.0, Logs)
>> This calls the operation once without changing its visibility
>> * Rename the operation:
>> function "**" (Left : Float; Right : Float) return Float renames
>> Ada.Numerics.Elementary_Functions."**";
>> This makes the specific operation visible
>> * Use type: this makes all operators of the type visible (not applicable
>> in this case)
>> * Use all type: this makes all operations of the type visible (not
>> applicable in this case)
>> * Use package: this makes everything in the package visible
>>
>> Use pkg is clearly overkill for this case, and overuse of it can have negative
>> consequences.
>>
>> --
>> Jeff Carter
>> "Choose a data representation that
>> makes the program simple."
>> Elements of Programming Style
>> 188
>
> This is excellent advice and an good list, though the last element should be two or three:
> * Local, via declare-region/-scope; and
> * ["local" via usage inside the spec, (perhaps in the public portion, perhaps in the private); and]
> * Global (top of the file context-clauses).
>

Thank you all for your tips and explanations.

I disagree with Jeffrey's opinion on what is a reasonable solution here.
More in-line below.

On 2021-07-21 11:29, Jeffrey R. Carter wrote:
> On 7/21/21 4:23 AM, Richard Iswara wrote:
>> On 20/07/2021 21.09, Niklas Holsti wrote:
>>> On 2021-07-20 15:02, Richard Iswara wrote:
>>>> I get this error on my program from the menu build => check semantic
>>>> exponent must be of type Natural, found type "Standard.Float".
>>>>
>>>> Should not 10 ** (log10 a + log10 b) = a*b?
>>>>
>>>> This is my compiler build:
>>>>
>>>> GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32
>>>> GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32
>>>> SPARK Community 2020 (20200429)
>>>>
>>>> Here is the relevant part of program:
>>>>
>>>> with Ada.Numerics.Elementary_Functions;
>>>> use Ada.Numerics;
>>>
>>>
>>> To make Ada.Numerics.Elementary_Functions."**" visible without
>>> qualification, you should also do "use
>>> Ada.Numerics.Elementary_Functions".
>>>
>>> Otherwise the compiler will see only the predefined operator:
>>>
>>>     function "**"(Left : Float; Right : Integer'Base) return Float
>>>
>>> (see RM 4.5.6(9 and 10)) which explains why the compiler does not
>>> accept a floating-point value as the Right operand to "**".
>>>
>>>
>>>> Logs : Float := 0.0;
>>>> Multiples : Float;
>>>     ...> Multiples := 10.0 ** Logs;  => this is where it fails
>>>
>>>
>>> It fails because the compiler sees only the predefined "**" operator
>>> which has an integral right operand.
>>
>> Thank you. So it is a visibility problem.
>
> "Understanding visibility is the key to understanding Ada." -- /Ada
> Distilled/

Hm. I agree visibility is important, but it is hardly the only important
Ada concept.

> Recommending the use package clause as a solution to a misunderstanding
> of visibility is a disservice to a beginning user.

Yes, unless the recommendation also includes explaining what the "use
package" does, thus increasing the user's understanding of visibility.

> In decreasing order of specificity, the ways to call an operation in a
> pkg are
>
> * Use the full name: Ada.Numerics.Elementary_Functions."**" (10.0, Logs)
>   This calls the operation once without changing its visibility

An application that needs "**" is likely to need other operators. Using
the fully qualified names makes non-trivial expressions much harder to
read and write. In the special case of a very few uses of very few
operators, I agree that this is a workable solution.

> * Rename the operation:
>   function "**" (Left : Float; Right : Float) return Float renames
>      Ada.Numerics.Elementary_Functions."**";
>   This makes the specific operation visible

Before Ada got "use type", such renaming declarations were the only
alternative to "use package", but they are verbose and proved (in my
experience, and that of others too) to be very error-prone, mainly when
renaming many operators -- copy-paste errors were rampant and hard to
find by reading. Interesting effects occur when "-" is renamed as "+" or
vice versa. I consider this solution to be the last (worst) choice.

> * Use type: this makes all operators of the type visible (not applicable
>   in this case)
> * Use all type: this makes all operations of the type visible (not
>   applicable in this case)

These are IMO usually the best methods but, as you say, not applicable here.

> * Use package: this makes everything in the package visible
>
> Use pkg is clearly overkill for this case,

I disagree. If the code uses several operators from the package, a "use
package" is apt (because "use type" does not apply here), but should of
course be as local as possible.

> and overuse of it can have negative consequences.

Agreed.

Le 27/07/2021 à 18:00, Niklas Holsti a écrit :
>> * Rename the operation:
>>    function "**" (Left : Float; Right : Float) return Float renames
>>       Ada.Numerics.Elementary_Functions."**";
>>    This makes the specific operation visible
>
>
> Before Ada got "use type", such renaming declarations were the only
> alternative to "use package", but they are verbose and proved (in my
> experience, and that of others too) to be very error-prone, mainly when
> renaming many operators -- copy-paste errors were rampant and hard to
> find by reading. Interesting effects occur when "-" is renamed as "+" or
> vice versa. I consider this solution to be the last (worst) choice.

With AdaControl, you can check that operators that are renamed as a
different operator:
check renaming_declarations
(not identical operator as_operator function);

(This syntax is from the soon-to-be-released new version of AdaControl -
wavefront available from GitHub: github.adalog.fr)

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:imaos8Fii64U1@mid.individual.net...
>I disagree with Jeffrey's opinion on what is a reasonable solution here.
>More in-line below.

You're being too hard on Jeff. See below.

.....
>> * Use package: this makes everything in the package visible
>>
>> Use pkg is clearly overkill for this case,
>
> I disagree. If the code uses several operators from the package, a "use
> package" is apt (because "use type" does not apply here), but should of
> course be as local as possible.

For general advice, this makes some sense, but in this specific case, there
is only one operator in this package so one of the other options makes more
sense than dragging in several dozen other names. Indeed, if there are
multiple uses of the operator, I'd probably use an expression function to
make the operator locally visible (this is similar to renames, using the
fullly qualified name). I'd only use a use package if there are many
routines in the package that are commonly used and well-understood from the
prespective of the system (GEF may be that for some systems, so perhaps I'm
being too hard on you. :-).

Side-issue: declaring operators that aren't primitive (so use-type doesn't
work) is suspicious. In most cases, operators belong with the type so that
they have the same visibility. The "**" for floats doesn't really belong in
GEF, it was put there for practical reasons (rather than good design) -- as
it is rather complex to describe and implement and isn't commonly used.

Randy.