From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,181acb4d59c58e23
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!news.glorb.com!news2.glorb.com!news.mv.net!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: evaluation of named numbers
Date: Sun, 17 Oct 2010 12:05:03 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wcc39s4pzyo.fsf@shell01.TheWorld.com>
References: <2304722c-027d-42f6-a45d-5a7646c35cf6@t8g2000yqk.googlegroups.com>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls6.std.com 1287331488 10407 192.74.137.71 (17 Oct 2010 16:04:48
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Sun, 17 Oct 2010 16:04:48 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:UU2DPvaSkt63tqZiTogpXs9eUyk=
Xref: g2news2.google.com comp.lang.ada:15562
Date: 2010-10-17T12:05:03-04:00
List-Id: <comp.lang.ada>

Rolf <rolf.ebert_nospam_@gmx.net> writes:

> I always thought that named numbers are fully evaluated with (almost)
> unlimited precision at compile time.

Static expressions are always evaluated exactly.  There's no "almost"
about it -- if the compiler runs out of memory trying, then it should
print an error message rather than producing an inexact result.

Named numbers are always static, so that applies to them.

>... I was quite astonished to see
>
>   Ticks : constant := 20 / 1000 * 16_000_000 / 8; -- 40_000 ticks

However, the "/" operator on integer types throws away the remainder
(whether static or at run time).  That's the "/" operator for
root_integer in this case.  20/1000 is exactly 0 in Ada, and that's what
the compiler is calculating.  That's "wrong" in the maths sense, where
20/1000 is "one fiftieth" or "zero with a remainder of 20", or various
other definitions, but never "exactly 0".

If you write it like this:

Ticks : constant := 20.0 / 1000.0 * 16_000_000.0 / 8.0;

then it will use the "/" for root_real, which will
calculate a mathematically correct answer.

It's annoying that Ada (and lots of other languages) use
a mathematically wrong definition of division, but that's
the way it is.  It's also annoying that the type of
a literal is determined by the mere presence or absence
of ".0".

By the way, if you write "-- 40_000 ticks" like this:

    pragma Assert(Ticks = 40_000);

you will be notified if it's wrong.  ;-)

> evaluated to 0 and not to the expected 40.000. It seems that the
> compiler uses integer numbers also for intermediate results and 20 /
> 1000 ends up to be 0 instead of 0.02. Any decent pocket calculator
> gets that right.

I'm no expert in pocket calculators, but I think most of them
use floating point (possibly decimal floating point?),
so they do not always calculate exactly-correct results
with arbitrary precision.  And they tend to have less
memory than is available to an Ada compiler.  ;-)

- Bob