Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 12:26:20 +0300
Organization: Tidorum Ltd
Lines: 69
Message-ID: <lkqbtsFlkbfU1@mid.individual.net>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vbcob9$dvp4$1@dont-email.me> <vbd6ia$e0ld$2@dont-email.me>
 <UxpCO.174965$Hld5.7714@fx15.iad> <vc41rl$1fhjd$1@dont-email.me>
 <86jzfccri4.fsf@linuxsc.com> <vc8mhi$2n382$3@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net J0e1g4mqIVE73pbWi8+8egImDXP7RINKWbDhtBHQuKWvrRk5eC
Cancel-Lock: sha1:9RTQCrR4dMg+1gwQ/68L18xbbzI= sha256:LPN4GbcnGRIsdxkvJ3tJ1bW+TrgnvLBmCREu9tK+waI=
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vc8mhi$2n382$3@dont-email.me>
Bytes: 3385

On 2024-09-16 10:25, Thomas Koenig wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>> If the loop variable
>> represents degrees C or F, or some other naturally signed measure it
>> should be signed (or maybe floating point).
> 
> The first one is a bad idea because temperature is a continuous
> physical quantity.
> 
> The second has bad implications for constructs like
> 
>        DO R = 0.0, 1.0, 0.1
> 
> where it will depend on details floating point arithmetic if the
> number of loop trips is 10 or 11.
> 
> You can argue that people can write
> 
>        DO R=0.0, 1.05, 0.1
> 
> but this construct was error-prone enough that it was deleted
> from the Fortran standards.
> 
>> What kind of loop it
>> is, whether ascending or descending, or what the increment is, etc,
>> is secondary;  a more important factor is what sort of value is
>> being represented, and in almost all cases that is what should
>> determine the type used.
> 
> Not for floating point numbers.  For that, you should simply do
> 
>        DO I=0,10
>          R = I * 0.1
> 
> or
> 
>        R = 0.0
>        DO I=0,10
> ...
>          R = R + 0.1
>        END DO
> 
> whichever rounding error you prefer.
> 
>>> Bringing it back to "architecture" Like Anton Ertl has said, LP64 for
>>> C/C++ is a mistake.  It should always have been ILP64, and this nonsense
>>> would go away.  Any new architecture should make C ILP64 (looking at you
>>> RISC-V, missing yet another opportunity to not make the same mistakes as
>>> everyone else).
>>
>> I believe this view is shortsighted.  The big mistake is developers
>> hardcoding types everywhere - especially int, but also long, and
>> their unsigned variants.  It's almost never a good idea to hardcode
>> a specific width (eg, uint32_t) in a type name used for parameters
>> or local variables, but that is by far a very common practice.


I agree. This issue guided the design of the scalar type system in Ada.

C programmers can use typedef to get part way there, but not all the way 
because typedefs are still weakly typed.


> Hence Fortran's SELECTED_REAL_KIND and SELECTED_INT_KIND...


And the way Ada programmers can define application-specific types with 
the ranges and precisions the application needs.