Gnat bug or mistaken program?

Gnat bug or mistaken program?

[Richard Iswara]

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?

Re: Gnat bug or mistaken program?

[Niklas Holsti]

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.

Re: Gnat bug or mistaken program?

[Richard Iswara]

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.

Re: Gnat bug or mistaken program?

[Jeffrey R. Carter]

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

Re: Gnat bug or mistaken program?

[Shark8]

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).

Re: Gnat bug or mistaken program?

[Richard Iswara]

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.

Re: Gnat bug or mistaken program?

[Niklas Holsti]

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.

Re: Gnat bug or mistaken program?

[J-P. Rosen]

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

Re: Gnat bug or mistaken program?

[Randy Brukardt]

"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.