ones complement

ones complement

[Richard Paladino]

Hello,

Is there an ada function for the c ~ function?

Thanks

Re: ones complement

[Samuel Tardieu]

>>>>> "Richard" == Richard Paladino <rickp@bill.com> writes:

Richard> Hello, Is there an ada function for the c ~ function?

"not" works on modular types.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: ones complement

[dennison]

In article <m3k9429xm0.fsf@zaphod.enst.fr>,
  Samuel Tardieu <sam@ada.eu.org> wrote:
> >>>>> "Richard" == Richard Paladino <rickp@bill.com> writes:
>
> Richard> Hello, Is there an ada function for the c ~ function?
>
> "not" works on modular types.

"not" works on arrays of booleans too.

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: ones complement

[Corey Ashford]

Richard Paladino wrote in message <35DD8731.F8E756AB@bill.com>...
>Hello,
>
>Is there an ada function for the c ~ function?
>
>Thanks
>

If you are using modular types, the unary operator "not" should do
the trick.

- Corey

Re: ones complement

[Jaap Douma]

Hello, i have the next two examples:

   -- image checksum is last 16 bits of ones complement of sum of 16-bit
bytes
   Srec_Image_Checksum := 16#FFFF# - Srec_Image_Checksum ;

   -- last 8 bits of ones complement of sum of bytes
   Sum := 16#Ff# - (Sum mod 16#100#) ;




 

Richard Paladino wrote:
> 
> Hello,
> 
> Is there an ada function for the c ~ function?
> 
> Thanks

Re: ones complement

[Jaap Douma]

Hello, i have the next two examples:

   -- image checksum is last 16 bits of ones complement of sum of 16-bit
bytes
   Srec_Image_Checksum := 16#FFFF# - Srec_Image_Checksum ;

   -- last 8 bits of ones complement of sum of bytes
   Sum := 16#Ff# - (Sum mod 16#100#) ;




 

Richard Paladino wrote:
> 
> Hello,
> 
> Is there an ada function for the c ~ function?
> 
> Thanks

Ada vs Fortran for scientific applications

[Nasser Abbasi]

I like to discuss the technical reasons why Ada is not used as much as 
Fortran for scientific and number crunching type applications?



To make the discussion more focused, let's assume you want to start 
developing a large scientific application in the domain where Fortran is 
commonly used. Say you want to develop a new large Finite Elements Methods 
program or large computational physics simulation system. Assume you can 
choose either Ada or Fortran.



What are the technical language specific reasons why Fortran would be 
selected over Ada?



I happened to know a little about Ada and Fortran, and from what I know, I 
think Ada would be an excellent choice due to its strong typing, good 
support for numerical types and good Math library.



I know also that Fortran is supposed to be better/faster when it comes to 
working with large Arrays (Matrices), but it is not clear to me why that is, 
and if it is still true with Ada 05. Something about arrays aliasing, but 
not sure how that is.



I am also not sure on the support of sparse matrices in both languages' 
libraries.



It is known that Ada strong domain is realtime and safety critical 
applications. I never understood why Ada never became popular in the 
scientific field in particular in areas such as computational physics or CFD 
or such similar fields.



Any thoughts?



thanks,



Nasser





 

Re: Ada vs Fortran for scientific applications

[Jean-Pierre Rosen]

Nasser Abbasi a �crit :
> What are the technical language specific reasons why Fortran would be 
> selected over Ada?
> 
Some immediate reasons:
1) Packaging. Packages allow better organization of software, which is 
good for any kind of application.

2) Strong typing. Scientific applications often deal with physical 
units, and Ada is great at supporting these.

3) User defined accuracy. Ada allows you to define the accuracy you 
need, the compiler chooses the appropriate representation. Note that you 
are not limited to only two floating point types (many machines have 
more than that).

4) Fixed points. Not available in Fortran

5) Guaranteed accuracy, not only for basic arithmetic, but for the whole 
mathematical library

6) Standardization. All compilers process exactly the same language.

7) Interfacing. Easy to call libraries in foreing languages => all 
libraries available for Fortran are available for Ada.

8) Concurrency, built into the language

9) Generics. Stop rewriting these damn sorting routines 1000 times.

10) Default parameters. Makes complex subprograms (simplex...) much 
easier to use.

11) Operators on any types, including arrays. Define a matrix product as 
"*"...

12) Bounds checking, with a very low penalty. Makes bounds checking 
really usable.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada vs Fortran for scientific applications

[Dan Nagle]

Hello,

Jean-Pierre Rosen wrote:
> Nasser Abbasi a �crit :
>> What are the technical language specific reasons why Fortran would be 
>> selected over Ada?
>>
> Some immediate reasons:
> 1) Packaging. Packages allow better organization of software, which is 
> good for any kind of application.

Can you compare and contrast Ada packages
with Fortran modules and submodules?

> 2) Strong typing. Scientific applications often deal with physical 
> units, and Ada is great at supporting these.

What specific features of Ada provide better support
than the comparable feature of Fortran?

> 3) User defined accuracy. Ada allows you to define the accuracy you 
> need, the compiler chooses the appropriate representation. Note that you 
> are not limited to only two floating point types (many machines have 
> more than that).

How is this better than Fortran's kind mechanism?

> 4) Fixed points. Not available in Fortran

Agreed.  How important is this for floating point work?
Fortran is rarely used for imbedded software (at least,
I wouldn't).

> 5) Guaranteed accuracy, not only for basic arithmetic, but for the whole 
> mathematical library

Can you compare Ada's accuracy requirements with Fortran's
support for IEEE 754?

> 6) Standardization. All compilers process exactly the same language.

Again, how is this different?  Fortran compilers are required
to be able to report use of extensions to the standard.

> 7) Interfacing. Easy to call libraries in foreing languages => all 
> libraries available for Fortran are available for Ada.

Can you compare Interfaces.C to ISO_C_BINDING?
How is one better or worse than the other?

> 8) Concurrency, built into the language

Co-arrays and concurrent loops are coming in Fortran 2008.

> 9) Generics. Stop rewriting these damn sorting routines 1000 times.

Intelligent Macros are coming in Fortran 2008.

> 10) Default parameters. Makes complex subprograms (simplex...) much 
> easier to use.

Agreed.

> 11) Operators on any types, including arrays. Define a matrix product as 
> "*"...

How is Ada's operators for types better or worse than Fortran's?
Is Ada's "*" operator better than Fortran's matmul()?

> 12) Bounds checking, with a very low penalty. Makes bounds checking 
> really usable.

How is Ada's bounds checking better or worse than Fortran's?

"Fortran" /= "FORTRAN 77"  ;-)

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Re: Ada vs Fortran for scientific applications

[Jean-Pierre Rosen]

Disclaimer:
I am an Ada guy. FORTRAN was my first programming language, but it was 
long, long ago, and I don't know about the latest improvements to the 
language. I'll answer some questions here, but I'd like to be 
enlightened on the latest trade from the FORTRAN side.

Dan Nagle a �crit :
> Hello,
> 
> Jean-Pierre Rosen wrote:
>> Nasser Abbasi a �crit :
>>> What are the technical language specific reasons why Fortran would be 
>>> selected over Ada?
>>>
>> Some immediate reasons:
>> 1) Packaging. Packages allow better organization of software, which is 
>> good for any kind of application.
> 
> Can you compare and contrast Ada packages
> with Fortran modules and submodules?
Honestly, I don't know about Fortran modules.

>> 2) Strong typing. Scientific applications often deal with physical 
>> units, and Ada is great at supporting these.
> 
> What specific features of Ada provide better support
> than the comparable feature of Fortran?
Is it possible in Fortran to define three *incompatible* types Length, 
Time, and Speed, and define a "/" operator between Length and Time that 
returns Speed?

>> 3) User defined accuracy. Ada allows you to define the accuracy you 
>> need, the compiler chooses the appropriate representation. Note that 
>> you are not limited to only two floating point types (many machines 
>> have more than that).
> 
> How is this better than Fortran's kind mechanism?
I need to be educated about Fortran's kind, but can you use it to 
specify that you want a type with guaranteed 5 digits accuracy?

>> 4) Fixed points. Not available in Fortran
> 
> Agreed.  How important is this for floating point work?
> Fortran is rarely used for imbedded software (at least,
> I wouldn't).
It's not important for floating point work, it's important for fixed 
point work :-)

Because Fortran has no fixed points, the scientific community sees 
floating point as the only way to model real numbers. Actually, fixed 
points have nothing to do with embedded software, they are a different 
way of modelling real (in the mathematical sense) numbers, with 
different numerical properties. Depending on the problem, fixed point 
may (or not) be more appropriate.

>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the 
>> whole mathematical library
> 
> Can you compare Ada's accuracy requirements with Fortran's
> support for IEEE 754?
Ada's accuracy requirement is independent from any hardware (or 
software) implementation of floating points, and are applicable even for 
non IEEE machines.

>> 6) Standardization. All compilers process exactly the same language.
> 
> Again, how is this different?  Fortran compilers are required
> to be able to report use of extensions to the standard.
AFAIK, there is a formal validation suite for Fortran, but
1) Compilers rarely report their validation result
2) A compiler is deemed "passed" if it succeeds 95% of the tests, while 
100% is required for Ada

>> 7) Interfacing. Easy to call libraries in foreing languages => all 
>> libraries available for Fortran are available for Ada.
> 
> Can you compare Interfaces.C to ISO_C_BINDING?
> How is one better or worse than the other?
Sorry, I don't know what you are refering to (except for Interfaces.C :-)

>> 8) Concurrency, built into the language
> 
> Co-arrays and concurrent loops are coming in Fortran 2008.
Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking 
model, not concurrent statements model. Both models have benefits and 
drawbacks, it depends on the needs.
> 
>> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
> 
> Intelligent Macros are coming in Fortran 2008.
I don't know what an "intelligent macro" is, but certainly generics 
(once again available since 1983"), are much more than macros, even 
intelligent ones.

For one thing, the legality of generics is checked when the generic is 
compiled. This means that, provided actual parameters meet the 
requirements of the formals, there is no neeed to recheck at 
instantiation time, and ensures that any legal instantiation will work 
as expected. AFAIK, this cannot be achieved by macros.

>> 10) Default parameters. Makes complex subprograms (simplex...) much 
>> easier to use.
> 
> Agreed.
> 
>> 11) Operators on any types, including arrays. Define a matrix product 
>> as "*"...
> 
> How is Ada's operators for types better or worse than Fortran's?
> Is Ada's "*" operator better than Fortran's matmul()?
More convenient to write:
Mat1 := Mat2 * Mat3;

>> 12) Bounds checking, with a very low penalty. Makes bounds checking 
>> really usable.
> 
> How is Ada's bounds checking better or worse than Fortran's?
I may miss something on the Fortran side, but Ada's very precise typing 
allows to define variables whose bounds are delimited. If these 
variables are later used to index an array (and if the language features 
are properly used), the compiler statically knows that no out-of-bound 
can occur. In short, most of the time, an Ada compiler is able to prove 
that bounds checking is not necessary, and corresponding checks are not 
generated.

In practice, compiling an Ada program with or without bounds checking 
shows very little difference in execution speed, because only the really 
useful checks are left, all the spurious ones have been eliminated.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada vs Fortran for scientific applications

[Dick Hendrickson]

Jean-Pierre Rosen wrote:
> Disclaimer:
> I am an Ada guy. FORTRAN was my first programming language, but it was 
> long, long ago, and I don't know about the latest improvements to the 
> language. I'll answer some questions here, but I'd like to be 
> enlightened on the latest trade from the FORTRAN side.
> 
> Dan Nagle a �crit :
> 
>> Hello,
>>
>> Jean-Pierre Rosen wrote:
>>
>>> Nasser Abbasi a �crit :
>>>
>>>> What are the technical language specific reasons why Fortran would 
>>>> be selected over Ada?
>>>>
>>> Some immediate reasons:
>>> 1) Packaging. Packages allow better organization of software, which 
>>> is good for any kind of application.
>>
>>
>> Can you compare and contrast Ada packages
>> with Fortran modules and submodules?
> 
> Honestly, I don't know about Fortran modules.

I think they're alot like packages.  They provide a scope
where you can define variables, data types, operators,
functions, etc.  They can be either PUBLIC or PRIVATE
and the USEr of the module can control which ones he
imports.  They allow for a lot of name and implementation
hiding.  Data types can have PRIVATE or PUBLIC internal
parts, independent of whether or not the data type itself
is PUBLIC or PRIVATE.

> 
>>> 2) Strong typing. Scientific applications often deal with physical 
>>> units, and Ada is great at supporting these.
>>
>>
>> What specific features of Ada provide better support
>> than the comparable feature of Fortran?
> 
> Is it possible in Fortran to define three *incompatible* types Length, 
> Time, and Speed, and define a "/" operator between Length and Time that 
> returns Speed?
Yes, it's possible.  There was a long thread inb c.l.f a
year or two ago abou this.  It's a bit of a pain in the butt
to cover all the cases.  Is E = m*c**2 the same as E=m*c*c?
Fortran 2003 has polymorphic variables which might make it
easier to write a complete set of units and operators.  That
probably would lose some compile time checking.

> 
>>> 3) User defined accuracy. Ada allows you to define the accuracy you 
>>> need, the compiler chooses the appropriate representation. Note that 
>>> you are not limited to only two floating point types (many machines 
>>> have more than that).
>>
>>
>> How is this better than Fortran's kind mechanism?
> 
> I need to be educated about Fortran's kind, but can you use it to 
> specify that you want a type with guaranteed 5 digits accuracy?
Yes, Fortran allows you to specify both decimal precision
and exponent range for variables.  The compiler must pick
the best representation it supports (where "best" is defined
in the standard).  If it doesn't support the precision or
range, it must give an error.
> 
>>> 4) Fixed points. Not available in Fortran
>>
>>
>> Agreed.  How important is this for floating point work?
>> Fortran is rarely used for imbedded software (at least,
>> I wouldn't).
> 
> It's not important for floating point work, it's important for fixed 
> point work :-)
It's not important for Fortran work ;) .

Technically, it probably could be done under the KIND
mechanism, but I don't think any compiler support it
directly.  There is enabling stuff coming in F2008.
> 
> Because Fortran has no fixed points, the scientific community sees 
> floating point as the only way to model real numbers. Actually, fixed 
> points have nothing to do with embedded software, they are a different 
> way of modelling real (in the mathematical sense) numbers, with 
> different numerical properties. Depending on the problem, fixed point 
> may (or not) be more appropriate.
> 
>>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the 
>>> whole mathematical library
>>
>>
>> Can you compare Ada's accuracy requirements with Fortran's
>> support for IEEE 754?
> 
> Ada's accuracy requirement is independent from any hardware (or 
> software) implementation of floating points, and are applicable even for 
> non IEEE machines.
Nope.  The IEEE features in Fortran 2003 encourage
processors to do the right thing, but don't mandate it.

What does Ada say about things like  COS(1.1E300)?
It's unclear to me what that could or should mean on a
machine with finite (or at least less than 300 ;) ) digits
of precision.
> 
>>> 6) Standardization. All compilers process exactly the same language.
>>
>>
>> Again, how is this different?  Fortran compilers are required
>> to be able to report use of extensions to the standard.
> 
> AFAIK, there is a formal validation suite for Fortran, but
Nope, there isn't a formal validation suite for "modern"
Fortran.  There was one for FORTRAN 77, but, realistically,
it wasn't very good.  If you need one, I know where you can
get a real good one ;).

> 1) Compilers rarely report their validation result
> 2) A compiler is deemed "passed" if it succeeds 95% of the tests, while 
> 100% is required for Ada
> 
>>> 7) Interfacing. Easy to call libraries in foreing languages => all 
>>> libraries available for Fortran are available for Ada.
>>
>>
>> Can you compare Interfaces.C to ISO_C_BINDING?
>> How is one better or worse than the other?
> 
> Sorry, I don't know what you are refering to (except for Interfaces.C :-)
The ISO_C_BINDING module specifiecs a raft of C like
things, named constants, some procedure interfaces, etc.
There is also a BIND(C) attribute for externals that
forces the compiler to use a C compatible calling
sequence.  Between that and the named constants, etc.,
you can define interfaces to just about any C function
and vice-versa.  There are some purely Fortran things,
like multi-dimensional array sections, that have no
defined passing mechanism.

> 
>>> 8) Concurrency, built into the language
>>
>>
>> Co-arrays and concurrent loops are coming in Fortran 2008.
> 
> Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking 
> model, not concurrent statements model. Both models have benefits and 
> drawbacks, it depends on the needs.
> 
>>
>>> 9) Generics. Stop rewriting these damn sorting routines 1000 times.
>>
>>
>> Intelligent Macros are coming in Fortran 2008.
> 
> I don't know what an "intelligent macro" is, but certainly generics 
> (once again available since 1983"), are much more than macros, even 
> intelligent ones.
> 
> For one thing, the legality of generics is checked when the generic is 
> compiled. This means that, provided actual parameters meet the 
> requirements of the formals, there is no neeed to recheck at 
> instantiation time, and ensures that any legal instantiation will work 
> as expected. AFAIK, this cannot be achieved by macros.

This is a flaw (or feature?) of the macro approach.  The
macro system is Fortran aware, so really stupid things
can be caught early on, but most bugs would be caught
when a version is instantiated.  Basically you define a
template-like thing, which can have embedded IF-THEN logic,
and instantiate it yourself for whatever set of conditions
you need.

There's an old joke that says "all compilers are multi-pass
optimizers, some of them require the programmer to make the
first few passes."  In that sense, Fortran's intelligent
macros are just like Ada's generics.

> 
>>> 10) Default parameters. Makes complex subprograms (simplex...) much 
>>> easier to use.
>>
>>
>> Agreed.
Agreed also.  Fortran subroutines can have optional
arguments.  However, there's no magic default.  The
subroutine programmer must check for the absence of
an optional argument and do the right thing manually.

>>
>>> 11) Operators on any types, including arrays. Define a matrix product 
>>> as "*"...
>>
>>
>> How is Ada's operators for types better or worse than Fortran's?
>> Is Ada's "*" operator better than Fortran's matmul()?
> 
> More convenient to write:
> Mat1 := Mat2 * Mat3;

There's been several comments on this one.  Basically,
Fortran went the route that all intrinsic operators
operate on an element-by-element basis.  User defined
operators can do whatever is desired.  Personally, I
think code is hard to read when * sometimes operates
one way and sometimes another.  But, that's just my
opinion.
> 
>>> 12) Bounds checking, with a very low penalty. Makes bounds checking 
>>> really usable.
>>
>>
>> How is Ada's bounds checking better or worse than Fortran's?
> 
> I may miss something on the Fortran side, but Ada's very precise typing 
> allows to define variables whose bounds are delimited. If these 
> variables are later used to index an array (and if the language features 
> are properly used), the compiler statically knows that no out-of-bound 
> can occur. In short, most of the time, an Ada compiler is able to prove 
> that bounds checking is not necessary, and corresponding checks are not 
> generated.
> 
> In practice, compiling an Ada program with or without bounds checking 
> shows very little difference in execution speed, because only the really 
> useful checks are left, all the spurious ones have been eliminated.
> 
Ada's is surely better.  Knowing that a subscript has to be
in range, because it's checked when a value is assigned to
the subscript variable, has to be more efficient than what
Fortran can do. In general, Fortran has to check the value
of the subscripts on every array reference.  In practice,
most array references take place in DO loops and compilers
can usually hoist the checks outside the loop, so they have
minimal cost at run time.

Dick Hendrickson

Re: Ada vs Fortran for scientific applications

[robin]

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net...
>
> Ada's is surely better.  Knowing that a subscript has to be
> in range, because it's checked when a value is assigned to
> the subscript variable, has to be more efficient than what
> Fortran can do. In general, Fortran has to check the value
> of the subscripts on every array reference.

It can do this only if it is a compiler option.
It is not a feature the language.

>  In practice,
> most array references take place in DO loops and compilers
> can usually hoist the checks outside the loop, so they have
> minimal cost at run time.

Re: Ada vs Fortran for scientific applications

[Dick Hendrickson]

robin wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net...
> 
>>Ada's is surely better.  Knowing that a subscript has to be
>>in range, because it's checked when a value is assigned to
>>the subscript variable, has to be more efficient than what
>>Fortran can do. In general, Fortran has to check the value
>>of the subscripts on every array reference.
> 
> 
> It can do this only if it is a compiler option.
> It is not a feature the language.

There's a ambiguous "it" in those sentences. ;)

But, if "it" refers to Fortran, subscript bounds rules
ARE a feature of the language.  You are NEVER allowed to
execute an out-of-bounds array reference in a Fortran
program.  In practice, the historical run-time cost of
checking bounds was [thought to be] too high, so compilers
either didn't do it, or did it under some sort of command
line option control.

Dick Hendrickson

> 
> 
>> In practice,
>>most array references take place in DO loops and compilers
>>can usually hoist the checks outside the loop, so they have
>>minimal cost at run time.
> 
> 
> 

Re: Ada vs Fortran for scientific applications

[robin]

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net...

> robin wrote:
> > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> > news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net...
> >
> >>Ada's is surely better.  Knowing that a subscript has to be
> >>in range, because it's checked when a value is assigned to
> >>the subscript variable, has to be more efficient than what
> >>Fortran can do. In general, Fortran has to check the value
> >>of the subscripts on every array reference.
>
> > It can do this only if it is a compiler option.
> > It is not a feature the language.
>
> There's a ambiguous "it" in those sentences. ;)
>
> But, if "it" refers to Fortran, subscript bounds rules
> ARE a feature of the language.

Subscript bounds checking is not part of the Fortran language.

>  You are NEVER allowed to
> execute an out-of-bounds array reference in a Fortran
> program.  In practice, the historical run-time cost of
> checking bounds was [thought to be] too high, so compilers
> either didn't do it, or did it under some sort of command
> line option control.

But in some languages [PL/I included] bounds checking
is part of the language, and can be controlled by the programmer.

Subscript checking is an important part of any program.

> Dick Hendrickson

Re: Ada vs Fortran for scientific applications

[Nasser Abbasi]

"robin" <robin_v@bigpond.com> wrote in message 
news:6H9dg.10258$S7.9150@news-server.bigpond.net.au...
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net...
>
>> robin wrote:
>> > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
>> > news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net...
>> >
>> >>Ada's is surely better.  Knowing that a subscript has to be
>> >>in range, because it's checked when a value is assigned to
>> >>the subscript variable, has to be more efficient than what
>> >>Fortran can do. In general, Fortran has to check the value
>> >>of the subscripts on every array reference.
>>
>> > It can do this only if it is a compiler option.
>> > It is not a feature the language.
>>
>> There's a ambiguous "it" in those sentences. ;)
>>

>> But, if "it" refers to Fortran, subscript bounds rules
>> ARE a feature of the language.
>

> Subscript bounds checking is not part of the Fortran language.
>

I just did this simple test, declare an array and go overbound and see if we 
get a run-time error:

----------------- FORTRAN 95 ------

$ g95 --version
G95 (GCC 4.0.2 (g95!) Mar  3 2006)
Copyright (C) 2002-2005 Free Software Foundation, Inc.

$ cat f.f90

PROGRAM MAIN
INTEGER A(10)
DO I=1,11
   A(I)=0
END DO
END PROGRAM

$ g95 f.f90
$ ./a.exe

$   <------------------- NO runtime ERROR


---------------- ADA gnat2005 ----------

$ cat main.adb
procedure Main is
    A : array( INTEGER RANGE 1..10) OF INTEGER;

BEGIN
   FOR I IN 1..11 LOOP
       A(I):=0;
   END LOOP;

END Main;


gnatmake  etc.....

successful compilation/build

$ ./main.exe

raised CONSTRAINT_ERROR : main.adb:6 index check failed   <---- ERROR


Nasser

Re: Ada vs Fortran for scientific applications

[Richard Maine]

Nasser Abbasi <nma@12000.org> wrote:

> I just did this simple test, declare an array and go overbound and see if we
> get a run-time error:
...
> $ g95 f.f90
...
> $   <------------------- NO runtime ERROR

This part of the thread has started drifting away from relevance to much
of anything, but that particular sample is just drifting yet further. It
illustrates neither much about subscript bounds rules being part of the
language nor about bounds checking being part of the language, which
were the two topics mentioned earlier in the subthread.

Instead, the example illustrates only that g95 does not have the bounds
check option enabled by default, which is yet a third question (and one
mentioned in more generality earlier).

As with most compilers, g95 does have a bounds check option; it just
isn't enabled by default. Compiling your same example, but asking for
bounds checking, gets it. In particular, compiling and running your
example code on my Mac here with

  g95 -fbounds-check clf.f90
  ./a.out

Gives me:

At line 4 of file clf.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1

which is, in fact, more detailed than the message you showed from gnat.
(Turning on the trace options gets rid of the message about not having
one, but it is trivial and adds nothing else useful for this example.)

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Re: Ada vs Fortran for scientific applications

[glen herrmannsfeldt]

Everett M. Greene wrote:
(snip)

> Doing multi-precision arithmetic on a ones complement
> machine can be a real challenge.

Well, you want unsigned arithmetic to do multiple precision,
which is harder if a machine only supplies ones complement.

-- glen

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[robin]

glen herrmannsfeldt wrote in message ...
>Everett M. Greene wrote:
>(snip)
>
>> Doing multi-precision arithmetic on a ones complement
>> machine can be a real challenge.
>
>Well, you want unsigned arithmetic to do multiple precision,
>which is harder if a machine only supplies ones complement.

In what way?
The arithmetic is done using fewer bits than word.
You have to do that with twos complement also.

The arithmetic required is addition; and all values
manipulated are positive.  Results are the same in
machines supporting ones or twos complement
representation for negative values.

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

robin wrote:
> glen herrmannsfeldt wrote in message ...

(snip)

>>Well, you want unsigned arithmetic to do multiple precision,
>>which is harder if a machine only supplies ones complement.

> In what way?
> The arithmetic is done using fewer bits than word.
> You have to do that with twos complement also.

The bits resulting in an unsigned addition or subtraction operation are 
the same as for a twos complement operation, but the detection of 
overflow (or carry/borrow) is different.  If you can properly detect
carry/borrow you can do it with all the bits in the word.

> The arithmetic required is addition; and all values
> manipulated are positive.  Results are the same in
> machines supporting ones or twos complement
> representation for negative values.

Hmm.  If you can detect the end around carry you can generate
the correct unsigned result, and so still use all the bits.
This is not usually easy in an high-level language, but should
be provided to the assembly programmer.

-- glen

Re: ONES COMPLEMENT

[robin]

glen herrmannsfeldt wrote in message ...
>robin wrote:
>> glen herrmannsfeldt wrote in message ...
>
>(snip)
>
>>>Well, you want unsigned arithmetic to do multiple precision,
>>>which is harder if a machine only supplies ones complement.
>
>> In what way?
>> The arithmetic is done using fewer bits than word.
>> You have to do that with twos complement also.
>
>The bits resulting in an unsigned addition or subtraction operation are
>the same as for a twos complement operation, but the detection of
>overflow (or carry/borrow) is different.  If you can properly detect
>carry/borrow you can do it with all the bits in the word.

The CDC cybers did not provide that.

>> The arithmetic required is addition; and all values
>> manipulated are positive.  Results are the same in
>> machines supporting ones or twos complement
>> representation for negative values.
>
>Hmm.  If you can detect the end around carry

The CDC cyber did not provide that.

>you can generate
>the correct unsigned result, and so still use all the bits.
>This is not usually easy in an high-level language,

Naturally.

> but should
>be provided to the assembly programmer.

The CDC Cyber did not provide that.

Re: ONES COMPLEMENT

[Richard Steiner]

Just a related link for interested folks (from the UNIVAC 110x world):

  http://www.fourmilab.ch/documents/univac/minuszero.html

The current Unisys Clearpath IX/Dorado mainframe line still uses the
same architecture, so it's still an issue.  :-)

-- 
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
    Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night.
       WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
                   The Theorem Theorem: If If, Then Then.

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[Shmuel (Seymour J.) Metz]

In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006
   at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
said:

>"robin" <robin_v@bigpond.com> writes:

>> Some implementations of ones complement used two forms of
>> zero 

FSVO "some" equal to "all".

>>which required two tests.

That  makes no sense.

>A properly designed 1s complement machine would not
>generate -0 in normal arithmetic operations.

0+(-0)?

>Thus, no need to perform a program check for -0.

I never saw a need to test for it regardless. Every 1s complement
machine I know of lets you test for zero in a single instruction.

>> How many machines now offer ones complement arithmetic?

Before the S/360 captured the market there were large numbers of
machines in the lines started with the CDC 160, CDC 6660 and the
UNIVAC 1107. The shift seemed to be a copycat issue more than a
technological one.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: ONES COMPLEMENT

[Peter Flass]

Shmuel (Seymour J.) Metz wrote:
> In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006
>    at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
> said:
> 
>>A properly designed 1s complement machine would not
>>generate -0 in normal arithmetic operations.
> 
> 
> 0+(-0)?
> 
> 
>>Thus, no need to perform a program check for -0.
> 
> 
> I never saw a need to test for it regardless. Every 1s complement
> machine I know of lets you test for zero in a single instruction.
> 

What happens on a test for negative?  Did the machines just test the 
sign bit, making -0 a negative number?

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

Peter Flass wrote:

> Shmuel (Seymour J.) Metz wrote:

(snip on negative zero)

>> I never saw a need to test for it regardless. Every 1s complement
>> machine I know of lets you test for zero in a single instruction.

> What happens on a test for negative?  Did the machines just test the 
> sign bit, making -0 a negative number?

Well, consider the 704, which is actually sign magnitude but has the
same problem.  (The easiest way to do sign magnitude arithmetic is
to convert to ones complement first, and convert back later.)

The 704 has a three way test instruction recently discussed in some
newsgroup, with branch destinations for negative, zero, and positive.
Any questions about the origin of the arithmetic IF statement?

-- glen

Re: ONES COMPLEMENT

[robin]

glen herrmannsfeldt wrote in message <5qednejm5MHL9SPZnZ2dnUVZ_oSdnZ2d@comcast.com>...
>Peter Flass wrote:
>
>> Shmuel (Seymour J.) Metz wrote:
>
>(snip on negative zero)
>
>>> I never saw a need to test for it regardless. Every 1s complement
>>> machine I know of lets you test for zero in a single instruction.
>
>> What happens on a test for negative?  Did the machines just test the
>> sign bit, making -0 a negative number?
>
>Well, consider the 704, which is actually sign magnitude but has the
>same problem.  (The easiest way to do sign magnitude arithmetic is
>to convert to ones complement first, and convert back later.)

It doesn't follow.
Twos complement for neg. values is just as easy.
In fact, for a serial machine, not only it [twos complement] easier,
it is done in less time! when consideration of the ensuing arithmetic
is considered.

>The 704 has a three way test instruction recently discussed in some
>newsgroup, with branch destinations for negative, zero, and positive.
>Any questions about the origin of the arithmetic IF statement?

This is off-topic, and completely irrelevant.
It has nothing to do with ones complement.

Re: ONES COMPLEMENT

[robin]

Shmuel (Seymour J.) Metz wrote in message <44bceab6$29$fuzhry+tra$mr2ice@news.patriot.net>...
>In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006
>   at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
>said:
>
>>"robin" <robin_v@bigpond.com> writes:
>
>>> Some implementations of ones complement used two forms of
>>> zero
>
>FSVO "some" equal to "all".

Not all.

>>>which required two tests.
>
>That  makes no sense.

One test for all bits zero, the other required for all ones.

>>A properly designed 1s complement machine would not
>>generate -0 in normal arithmetic operations.
>
>0+(-0)?
>
>>Thus, no need to perform a program check for -0.
>
>I never saw a need to test for it regardless. Every 1s complement
>machine I know of lets you test for zero in a single instruction.

(-0) looked like a negative value on some machines.

>>> How many machines now offer ones complement arithmetic?
>
>Before the S/360 captured the market there were large numbers of
>machines in the lines started with the CDC 160, CDC 6660 and the
>UNIVAC 1107. The shift seemed to be a copycat issue more than a
>technological one.

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[Everett M. Greene]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> writes:
> mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said:
> >"robin" <robin_v@bigpond.com> writes:
> 
> >> Some implementations of ones complement used two forms of
> >> zero 
> 
> FSVO "some" equal to "all".
> 
> >>which required two tests.
> 
> That  makes no sense.
> 
> >A properly designed 1s complement machine would not
> >generate -0 in normal arithmetic operations.
> 
> 0+(-0)?

A subtractive adder.

> >Thus, no need to perform a program check for -0.
> 
> I never saw a need to test for it regardless. Every 1s complement
> machine I know of lets you test for zero in a single instruction.

Try the Univac mainframes.

I once got bagged by one of a Univac-designed machine that
did 0 x n = -0 for any negative value of n.  This wasn't
the way it should work, but it worked that way to be
compatible with an earlier machine.  ["It's a mistake, but
we are consistently wrong."]

> >> How many machines now offer ones complement arithmetic?
> 
> Before the S/360 captured the market there were large numbers of
> machines in the lines started with the CDC 160, CDC 6660 and the
> UNIVAC 1107. The shift seemed to be a copycat issue more than a
> technological one.

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[Shmuel (Seymour J.) Metz]

In <20060719.79A3E90.87CE@mojaveg.lsan.sisna.com>, on 07/19/2006
   at 09:11 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
said:

>A subtractive adder.

How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring
nor complementation.

>Try the Univac mainframes.

Which ones? the 490 and the 1107 lines let you test for zero in a
single instruction.

>I once got bagged by one of a Univac-designed machine that did 0 x n
>= -0 for any negative value of n. 

And that was a problem because?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[Everett M. Greene]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> writes:
> mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said:
> 
> >A subtractive adder.
> 
> How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring
> no complementation.

Context was deleted so I have no idea what you're trying
to say above.

> >Try the Univac mainframes.
> 
> Which ones? the 490 and the 1107 lines let you test for zero in a
> single instruction.

They test for +0 in one instruction.  If you want to reliably
test for zero, you have to add 0 first.

> >I once got bagged by one of a Univac-designed machine that did 0 x n
> >= -0 for any negative value of n. 
> 
> And that was a problem because?

Because the ensuing test for zero wasn't working reliably.

Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications)

[Shmuel (Seymour J.) Metz]

In <20060720.79BD230.8698@mojaveg.lsan.sisna.com>, on 07/20/2006
   at 08:46 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
said:


>"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid>
>writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: >
>> >A subtractive adder.
>> 
>> How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring
>> no complementation.

>Context was deleted so I have no idea what you're trying to say
>above.

Robin wrote "A properly designed 1s complement machine would not
generate -0 in normal arithmetic operations."

I responded "0+(-0)?".

You responded "A subtractive adder."

I'm trying to say that there's nothing about 0+(-0) requiring a
subtractive adder.

>They test for +0 in one instruction.  If you want to reliably test
>for zero, you have to add 0 first.

From JZ in UP-4053, UNIVAC 1108 PROCESSOR AND STORAGE:

     Program control is transferred to U if the (A) are all zeros or
all ones.

I repeat, which UNIVAC mainframe are you talking about? It's clearly
not the 1108.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

Shmuel (Seymour J.) Metz wrote:

(snip)

> Robin wrote "A properly designed 1s complement machine would not
> generate -0 in normal arithmetic operations."

> I responded "0+(-0)?".

> You responded "A subtractive adder."

> I'm trying to say that there's nothing about 0+(-0) requiring a
> subtractive adder.

There are adder designs that reduce the generation of -0.

In any case, Seymour Cray, who probably knows more about fast
processor design than anyone reading this newsgroup, designed
ones complement machines for many years.  There is also a lot
of literature on processor design.

Fortran and C definitely allow ones complement arithmetic, so a standard 
conforming program for those languages has to allow for it.

(I didn't look it up for PL/I or ADA, but most likely they do, too.
Java is the only language that I know doesn't allow it.)

Unless someone wants to go to the literature and find the known
answers, there doesn't seem to be much point in arguing it here.

-- glen

Re: ONES COMPLEMENT

[John W. Kennedy]

glen herrmannsfeldt wrote:
> (I didn't look it up for PL/I or ADA, but most likely they do, too.
> Java is the only language that I know doesn't allow it.)

Apart from Java's requirement of 2's-complement, the only case I can 
recall is that Ada goes out of its way to /permit/ 2's-complement. PL/I 
certainly doesn't have any particular requirement.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"

Re: ONES COMPLEMENT

[robin]

John W. Kennedy wrote in message ...
>glen herrmannsfeldt wrote:
>> (I didn't look it up for PL/I or ADA, but most likely they do, too.
>> Java is the only language that I know doesn't allow it.)
>
>Apart from Java's requirement of 2's-complement, the only case I can
>recall is that Ada goes out of its way to /permit/ 2's-complement. PL/I
>certainly doesn't have any particular requirement.

PL/I was designed at a time when ones and twos complement machines
were in use.  There's no reason why PL/I won't run on either
architecture.

Re: ONES COMPLEMENT

[robin]

glen herrmannsfeldt wrote in message ...
>Shmuel (Seymour J.) Metz wrote:
>
>> I'm trying to say that there's nothing about 0+(-0) requiring a
>> subtractive adder.
>
>There are adder designs that reduce the generation of -0.
>
>In any case, Seymour Cray, who probably knows more about fast
>processor design than anyone reading this newsgroup, designed
>ones complement machines for many years.

That doesn't make it [ones complement] a good design.

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

Shmuel (Seymour J.) Metz wrote:
(snip)

> Robin wrote "A properly designed 1s complement machine would not
> generate -0 in normal arithmetic operations."

> I responded "0+(-0)?".

> You responded "A subtractive adder."

> I'm trying to say that there's nothing about 0+(-0) requiring a
> subtractive adder.

Well, even more, the way I understand the logic of some machines,
as long as no arguments are negative zero they won't generate a
negative zero.  0+(-0) doesn't satisfy that case.

For those who care, consider that ones complement arithmetic
will normally generate -0 instead of +0.  Adding x and -x generates
all ones with no end around carry.  If you add the ones complements
of the two operands you get the complement of the result, and still
negative zero for zero sum.  The complement of that will be the correct
sum, and won't be negative zero unless both of the arguments are -0.

In addition, note that ECL supplies a signal and its complement without
any extra logic needed.

In any case, a high level language has to get it right even
if it takes extra instructions.

-- glen

Re: ONES COMPLEMENT

[Dick Hendrickson]

glen herrmannsfeldt wrote:

> Shmuel (Seymour J.) Metz wrote:
> (snip)
> 
>> Robin wrote "A properly designed 1s complement machine would not
>> generate -0 in normal arithmetic operations."
> 
> 
>> I responded "0+(-0)?".
> 
> 
>> You responded "A subtractive adder."
> 
> 
>> I'm trying to say that there's nothing about 0+(-0) requiring a
>> subtractive adder.
> 
> 
> Well, even more, the way I understand the logic of some machines,
> as long as no arguments are negative zero they won't generate a
> negative zero.  0+(-0) doesn't satisfy that case.
> 
> For those who care, consider that ones complement arithmetic
> will normally generate -0 instead of +0.  Adding x and -x generates
> all ones with no end around carry.  If you add the ones complements
> of the two operands you get the complement of the result, and still
> negative zero for zero sum.  The complement of that will be the correct
> sum, and won't be negative zero unless both of the arguments are -0.

It's been a long time, but my recollection is that the CDC
machines used a subtractor rather than an adder.  This was
done to mostly eliminate the -0 problem.  Rather than do
X + Y, they did X - (-Y).  Then, if Y happened to be -X the
subtractor saw X + (-X) as X - (--X) which worked out to
X - X and then to zero.

I think the only problem was  0 + 0 which became 0 - (-0)
and then -0 .

> 
> In addition, note that ECL supplies a signal and its complement without
> any extra logic needed.

Maybe, but the CDC 1604s used discrete parts.  Transistors,
resistors, on a 3 inch by 3 inch circuit board.  I'm pretty
sure that some design decisions were heavily influenced by
parts count.

> 
> In any case, a high level language has to get it right even
> if it takes extra instructions.

Absolutely.

Dick Hendrickson
> 
> -- glen
> 

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

Dick Hendrickson wrote:

(snip, I wrote)

>> In addition, note that ECL supplies a signal and its complement without
>> any extra logic needed.

> Maybe, but the CDC 1604s used discrete parts.  Transistors,
> resistors, on a 3 inch by 3 inch circuit board.  I'm pretty
> sure that some design decisions were heavily influenced by
> parts count.

Well, the IBM 360/91 used ASLT, which is pretty much ECL built
from discrete transistors glued on a ceramic substrate.
Most 360's were SLT, which is pretty much discrete TTL.

-- glen

Re: ONES COMPLEMENT

[robin]

Shmuel (Seymour J.) Metz wrote in message <44c00809$1$fuzhry+tra$mr2ice@news.patriot.net>...
>In <20060720.79BD230.8698@mojaveg.lsan.sisna.com>, on 07/20/2006
>   at 08:46 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene)
>said:
>
>>"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid>
>>writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: >
>>> >A subtractive adder.
>>>
>>> How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring
>>> no complementation.
>
>>Context was deleted so I have no idea what you're trying to say
>>above.
>
>Robin wrote "A properly designed 1s complement machine would not
>generate -0 in normal arithmetic operations."

They are not my words.  From earlier posts, it looks like E. Green's post.

Re: ONES COMPLEMENT

[glen herrmannsfeldt]

Everett M. Greene wrote:

(snip)

> A properly designed 1s complement machine would not
> generate -0 in normal arithmetic operations.  Thus,
> no need to perform a program check for -0.

As far as I know, they are designed either to not generate
-0 under normal conditions, or to compare -0 equal to +0,
or both.

One solution is to do subtraction as the basic operation,
such that subtracting two of the same number will generate +0,
and addition as subtraction of the complement.
-0 can still result if -0 is used as an operand, though.

For a parallel adder, as all machines have had for about 40 years now,
no extra hardware is needed, nor is more time needed.  The "add with 
carry" operation that some machines have is not available, though.

Twos complement machines might require extra hardware to handle the 
overflow on negate or absolute value, which can't overflow on ones 
complement machines.

For multiply and divide it might be that ones complement is a little 
easier, though the difference should be small.

-- glen

Re: ONES COMPLEMENT

[Tom Linden]

On Tue, 18 Jul 2006 23:54:39 -0700, glen herrmannsfeldt  
<gah@ugcs.caltech.edu> wrote:

> One solution is to do subtraction as the basic operation,
> such that subtracting two of the same number will generate +0,
> and addition as subtraction of the complement.
> -0 can still result if -0 is used as an operand, though.

or mask the sign bit for a zero compare instruction

Re: ONES COMPLEMENT

[robin]

glen herrmannsfeldt wrote in message ...
>Everett M. Greene wrote:
>
>(snip)
>
>> A properly designed 1s complement machine would not
>> generate -0 in normal arithmetic operations.  Thus,
>> no need to perform a program check for -0.
>
>As far as I know, they are designed either to not generate
>-0 under normal conditions, or to compare -0 equal to +0,
>or both.

Or none.
In some cases, -0 is treated as a negative number,
and +0 as a positive, and -0 is not equal to +0.