Ada vs Delphi?

Ada vs Delphi?

[Andre Ratel]

I am currently using Delphi (and Object Pascal) for my scientific
programming. I heard a lot lately about Ada. From what I have
seen, its syntax is very similar to Object Pascal. (This is no
surprise since both languages are derived from Algol.)

What would be the advantages of Ada over Delphi?

	Andre

Re: Ada vs Delphi?

[Steve Doiel]

Andre Ratel wrote in message <37ab421a.5414989@news.total.net>...
>I am currently using Delphi (and Object Pascal) for my scientific
>programming. I heard a lot lately about Ada. From what I have
>seen, its syntax is very similar to Object Pascal. (This is no
>surprise since both languages are derived from Algol.)
>
>What would be the advantages of Ada over Delphi?
>
> Andre
>

In our shop we're using Delphi for visual interfaces and Ada 95 for our
optimization program.

Adavantage of Delphi
  Delphi is hard to beat for quickly assembling a user interface.

Advantage of Ada
  Types may be derived from Ada.Finalization.Controlled in order to
eliminate the risk of memory leaks.  Delphi has no counterpart.  In Delphi
it is easy to create memory leaks.

  Ada is more stronly typed.  In Delphi different types may be freely mixed
in an expression which may lead to suprises (bugs).  In Ada type conversions
must be explicit.

  Ada supports overloading of operators, functions, and procedures.

  Programs written in Ada are more likely to be portable to other
architectures.  Delphi lives only on PC's.

  Ada is available from multiple sources.  If you're not happy with Aonix,
go to AdaCore.  If your not happy with AdaCore go to RRSoftware.  With
Delphi, if you're not happy with Inprise (formerly Borland) you're out of
luck.

  Ada is more fully defined.  With Ada you can refer to the language
reference manual regardless of which compiler you're using and get a fairly
explicit description of how things work.  With Delphi you must often refer
to trial and error.

  Ada includes tasking as a part of the language which makes threaded
applications portable.

I'm sure there are a lot more differences.

I hope this helps,

SteveD

Re: Ada vs Delphi?

[Paul Groves]

>In our shop we're using Delphi for visual interfaces and Ada 95 for our
>optimization program.
>
>Adavantage of Delphi
>  Delphi is hard to beat for quickly assembling a user interface.
Or C Builder, they use the virtually the same IDE interface.

>Advantage of Ada
>  Types may be derived from Ada.Finalization.Controlled in order to
>eliminate the risk of memory leaks.  Delphi has no counterpart.  In Delphi
>it is easy to create memory leaks.
Isn't it just as 'easy' to "create memory leaks" in Ada?
Delphi (Pascals) pointer types are just like Ada's access
types so the same is possible in both languages.
Delphi does use pointers all over the place for its
interfacing stuff -- VCL.  The poster was just asking about
scientific programming so this shouldn't really be a big
problem.  

>  Ada is more stronly typed.  In Delphi different types may be freely mixed
>in an expression which may lead to suprises (bugs).  
I was not aware of this.  Delphi is based strongly on
Pascal, which has one of the most securely enforced type
domains I've seen.  All types convertions in Delphi occur
through well defined type co-ercion functions -- Theres no
'casting', which is what can lead to problems...

>  Ada supports overloading of operators, functions, and procedures.
Not always a good thing.

>  Programs written in Ada are more likely to be portable to other
>architectures.  Delphi lives only on PC's.
True, but again - If the guy just wants to do scientific
programming Pascal would do and its portable.

>  Ada is more fully defined.  
From what you say below, you mean better documented?

>With Ada you can refer to the language
>reference manual regardless of which compiler you're using and get a fairly
>explicit description of how things work.  With Delphi you must often refer
>to trial and error.
Borland's help files are always crap -- I'll give you that
one.

>  Ada includes tasking as a part of the language which makes threaded
>applications portable.
Delphi has a thread component its not portable obviously...

I'm not an advocate of Delphi - personally I think it sucks.
Someone should write a better 'Visual Pascal'  Then again,
I'm not a fan of Ada.  The only *truely* well-defined
language that I ENJOY using is Pascal...

Pauly.

Re: Ada vs Delphi?

[Steve Doiel]

>>Advantage of Ada
>>  Types may be derived from Ada.Finalization.Controlled in order to
>>eliminate the risk of memory leaks.  Delphi has no counterpart.  In Delphi
>>it is easy to create memory leaks.
>Isn't it just as 'easy' to "create memory leaks" in Ada?
>Delphi (Pascals) pointer types are just like Ada's access
>types so the same is possible in both languages.
>Delphi does use pointers all over the place for its
>interfacing stuff -- VCL.  The poster was just asking about
>scientific programming so this shouldn't really be a big
>problem.

Yes.  It is easy to create memory leaks in Ada.  It is also easy to derive
controlled types in Ada in such a way that they are immune to memory leaks.
If all dynamically allocated objects in your application are controlled, the
application will be immune to memory leaks.

Delphi has not couterpart to controlled types.  There is currently no way in
Delphi that you can make objects clean up after themselves to avoid memory
leaks.  (I wish there was... as I mentioned we are using Delphi for our
visual Apps)



>>  Ada is more stronly typed.  In Delphi different types may be freely
mixed
>>in an expression which may lead to suprises (bugs).
>I was not aware of this.  Delphi is based strongly on
>Pascal, which has one of the most securely enforced type
>domains I've seen.  All types convertions in Delphi occur
>through well defined type co-ercion functions -- Theres no
>'casting', which is what can lead to problems...


In Ada you can define two distinct types:

  type length is new float;
  type weight is new float;

If you attempt to assign a variable of type length to a variable of type
weight, it will result in a compile time error.

In Delphi if you define two types:

  type
    length = double;
    weight = double;

You may freely assign values of type length to values of type weight without
warning.

SteveD

Re: Ada vs Delphi?

[Ray Blaak]

"Steve Doiel" <nospam_steved@pacifier.com> writes:
> In Delphi if you define two types:
> 
>   type
>     length = double;
>     weight = double;
> 
> You may freely assign values of type length to values of type weight without
> warning.

Actually, in Delphi, this is supposed to be the equivalent of the Ada:

   type
     length = type double;
     weight = type double;

On the other hand, I don't know if the compiler actually enforces it, but I
believe it is supposed to.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Ada vs Delphi?

[Steve Doiel]

Ray Blaak wrote in message ...

>Actually, in Delphi, this is supposed to be the equivalent of the Ada:
>
>   type
>     length = type double;
>     weight = type double;
>
>On the other hand, I don't know if the compiler actually enforces it, but I
>believe it is supposed to.
>

The following compiles with no errors on Delphi 3

procedure TForm1.FormCreate(Sender: TObject);
  type
    length = type double;
    weight = type double;
  var
   a : length;
   b : weight;
begin
  a := b;
end;

But thanks, I had never seen that syntax before.

SteveD

>--
>Cheers,                                        The Rhythm is around me,
>                                               The Rhythm has control.
>Ray Blaak                                      The Rhythm is inside me,
>blaak@infomatch.com                            The Rhythm has my soul.

Re: Ada vs Delphi?

[Andre Ratel]

On Tue, 10 Aug 1999 19:22:01 -0700, "Steve Doiel"
<nospam_steved@pacifier.com> wrote:

>Ray Blaak wrote in message ...
>
>>Actually, in Delphi, this is supposed to be the equivalent of the Ada:
>>
>>   type
>>     length = type double;
>>     weight = type double;
>>
>>On the other hand, I don't know if the compiler actually enforces it, but I
>>believe it is supposed to.
>>
>
>The following compiles with no errors on Delphi 3
>
>procedure TForm1.FormCreate(Sender: TObject);
>  type
>    length = type double;
>    weight = type double;
>  var
>   a : length;
>   b : weight;
>begin
>  a := b;
>end;
>
>But thanks, I had never seen that syntax before.
>
>SteveD

From Delphi 4's Help on _Type compatibility and identity_:

<<<
To understand which operations can be performed on 
which expressions, we need to distinguish several kinds of
compatibility among types and values. These include type 
identity, type compatibility, and assignment-compatibility.
>>>

Help on  _Type identity_:

<<<
Type identity is almost straightforward. When one type 
identifier is declared using another type identifier, without
qualification, they denote the same type. Thus, given the 
declarations

type
  T1 = Integer;
  T2 = T1;
  T3 = Integer;
  T4 = T2;

T1, T2, T3, T4, and Integer all denote the same type. To create
distinct types, repeat the word type in the declaration. For example,

type TMyInteger = type Integer;

creates a new type called TMyInteger which is not identical to
Integer.
>>>

Help on _Type compatibility_:

<<<
Every type is compatible with itself. Two distinct types are
compatible if they satisfy at least one of the following conditions.

  - They are both real types.
  - They are both integer types.
  - One type is a subrange of the other.
  - Both types are subranges of the same type.
  - Both are set types with compatible base types.
>>>
(plus other conditions, less relevant to this discussion).


Help on _Assignment  compatibility_:

<<<
Assignment-compatibility is not a symmetric relation. An 
expression of type T2 can be assigned to a variable of type 
T1 if the value of the expression falls in the range of T1 and
at least one of the following conditions is satisfied.

  - T1 and T2 are of the same type, and it is not a file type or 
     structured type that contains a file type at any level.
  - T1 and T2 are compatible ordinal types.
  - T1 and T2 are both real types.
  - T1 is a real type and T2 is an integer type.
>>>
(plus other conditions, less relevant here).

I hope this shed a bit of light on how various types are
managed in Object Pascal.

	Andre

Re: Ada vs Delphi?

[Robert Dewar]

In article <37ae1fc8.653954@news.clara.net>,
  paulyg@clara.net (Paul Groves) wrote:
> >  Types may be derived from Ada.Finalization.Controlled in
order to
> >eliminate the risk of memory leaks.  Delphi has no
counterpart.  In Delphi
> >it is easy to create memory leaks.
> Isn't it just as 'easy' to "create memory leaks" in Ada?
> Delphi (Pascals) pointer types are just like Ada's access
> types so the same is possible in both languages.
> Delphi does use pointers all over the place for its
> interfacing stuff -- VCL.  The poster was just asking about
> scientific programming so this shouldn't really be a big
> problem.

The idea that scientific programming does not need dynamic
allocation and pointers reflects completely out of date
thinking. Modern scientific programming uses extremely
sophisticated data structures, often highly dynamic in
nature.

And no, it is NOT "just as easy" to create memory leaks in
Ada, it sounds like you do not really understand how controlled
types work. They are a vital facility in a language where
storage allocation is manual.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Gautier]

> >  Ada is more stronly typed.  In Delphi different types may be freely mixed
> >in an expression which may lead to suprises (bugs).

> I was not aware of this.  Delphi is based strongly on
> Pascal, which has one of the most securely enforced type
> domains I've seen.  All types convertions in Delphi occur
> through well defined type co-ercion functions -- Theres no
> 'casting', which is what can lead to problems...

If they have kept compatibility from Turbo Pascal, there is
a total casting between byte (unsigned_8), short_integer (integer_8),
word (unsigned_16), integer (integer_16), longint (integer_32)...

The bugs from unsigned <-> signed are the most vicious.

Has this changed in Delphi (read: have they "Adaized" this) ?

-- 
Gautier (when PC/16 bit => Turbo Pascal; when others => Ada )

--------
http://members.xoom.com/gdemont/

Re: Ada vs Delphi?

[Andre Ratel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Mon, 09 Aug 1999 10:57:51 +0200, Gautier
<gautier.demontmollin@maths.unine.ch> wrote:

>If they have kept compatibility from Turbo Pascal, there is
>a total casting between byte (unsigned_8), short_integer (integer_8),
>word (unsigned_16), integer (integer_16), longint (integer_32)...
>
>The bugs from unsigned <-> signed are the most vicious.

There's also the wrap arounds (so I always keep range checking
enabled.)

>Has this changed in Delphi (read: have they "Adaized" this) ?

Not with Delphi 4 (but version 5 is supposed to get out this 
month :-). Here's from the doc of Delphi 4:

     "If an operand�s type is a subrange of an integer type,
      it is treated as if it were of the integer type."
           (Oplg.pdf - Object Pascal Language Guide, p. 4-7)

     "Performing arithmetic on signed and unsigned Integers
      results in all values being promoted to Int64 to avoid
      potential overflow."
                        (del4new.hlp  -  Compatibility issues)

I just tried this

<<<<<<<<<<
{$RANGECHECK ON}

  var
    n1, n2: shortint; {range: -128 .. 127}
    N: integer; {range: 2147483648 .. 2147483647}

  begin
    n1:= 120;
    n2:= 120;
    N:= n1 + n2;
    Writeln(N);
  end;
>>>>>>>>>>

The result was, appropriately 240.

Now, if I know that n1 and n2 are both in the range -128..127
while their sum is outside this range, I don't understand what's 
wrong with assigning (n1 + n2) to an integer.

	Andre

Re: Ada vs Delphi?

[Gautier]

>      "Performing arithmetic on signed and unsigned Integers
>       results in all values being promoted to Int64 to avoid
>       potential overflow."
>                         (del4new.hlp  -  Compatibility issues)

Glups ?!!! It's a recipe for absolute slowness on 32-bit machines !
It's like old BASICs where everything was converted to floating-point !
If in addition Delphi still doesn't provide code optimization...

-- 
Gautier

Re: Ada vs Delphi?

[Gautier]

> {$RANGECHECK ON}
> 
>   var
>     n1, n2: shortint; {range: -128 .. 127}
>     N: integer; {range: 2147483648 .. 2147483647}
> 
>   begin
>     n1:= 120;
>     n2:= 120;
>     N:= n1 + n2;
>     Writeln(N);
>   end;
> >>>>>>>>>>

> The result was, appropriately 240.

> Now, if I know that n1 and n2 are both in the range -128..127
> while their sum is outside this range, I don't understand what's
> wrong with assigning (n1 + n2) to an integer.

Neither Delphi nor you can guess if the result of an expression
like (n1 + n2) alone will be in some range. You just were lucky because
Borland has choosen to convert your shortints *before* the addition!
Let's see what happens in Turbo Pascal 6 (16 bit):

{$R+}

  var
    n1, n2: shortint; {range: -128 .. 127}
    i1,i2:  integer;  {range: -32768..32767}
    N: longint; {range: -2147483648 .. 2147483647}

  begin
    n1:= 120;
    n2:= 120;
    N:= n1 + n2;
    Writeln(N);

    i1:= 32000;
    i2:= 32000;
    N:= i1 + i2;
    Writeln(N);
  end.

The 1st result is 240: Borland has converted the signed 8-bit n1,n2
to 16-bit, then added them, converted to a 32-bit one (N).

The second is catastrophic: -1536 with range checks ON !
What happened ? The addition is a normal 16-bit one. BUT it's
an UNSIGNED one (0..65536), so not catched by range check: 64000
Then the thing (now again understood as a SIGNED thing: -1536)
is converted to the signed longint !!

The problem with these automatic castings is double, since
Borland chooses the signed/unsigned and the 8/16/32/64 bits
representation for you!

In Ada you can handle ranges and bits independently:
e.g. a 32-bit subtype of range -127..128, etc. etc.
In the same subtype family (e.g. integer, natural, positive)
you can write n1+n2 safely, without explicit conversion, as
there is no bad surprise with hidden type conversions; ranges
will be checked correctly - provided you didn't suppress them
at compile time...

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada vs Delphi?

[Andre Ratel]

My post is a bit long. I apologize, but I really want to get to the
bottom of this.

-=[Knowing the range]=----------

On Thu, 12 Aug 1999 10:03:52 +0200, Gautier
<Gautier.deMontmollin@Maths.UniNe.CH> wrote:

>Neither Delphi nor you can guess if the result of an expression
>like (n1 + n2) alone will be in some range. 

It depends. More often than not, I use integers as counters.
For example, let's consider an hypothetical situation in which 
we have the following loop

<<<
  for n1:= -128 to 127
    for n2:= -128 to 127
      begin
        sum:= n1 + n2;
        ...
      end; {for}
>>>

We know the ranges of n1 and n2 and we have a pretty good idea
of the range of sum. Now, how do we declare these variables?
One way to do it, is to put all related variables in a same
set, chosen large enough to contain all their possible 
values:

  var
    n1, n2, sum: integer;

The other would be to use smaller sets:

  var
    n1, n2: -128..127; {or equivalently: n1, n2: shorting;}
    sum: integer;

With the latter declarations, we won't run into trouble if:
  - the right-side of the expression is evaluated using the
    largest set of integers (longint)
  - the result is typecasted into the variable on the left-side
  - some kind of error message pops up if one of the variable
    gets outside its declared range.

When I began programming in Turbo Pascal, I tended to follow 
this second approach but ran into all sorts of problems. Now,
apart from a few exceptional cases, I use integers or longints.

A safe language should be such that all evaluations are performed
using the largest set of numerals available (longint for integers,
extended for real numbers). The responsability of the programmer
would be then to choose the appropriate type of variables for 
_storing_ the results in memory. (I am aware that this might lead 
to problems in efficiency.)

Let's see if Turbo Pascal satisfies this safety requirement.


-=[Calculating with floating point]=----------

From the Turbo Pascal (v. 5) Reference Guide (pp. 185-186):

<<<
The extended type is the basis of all floating-point computations
with the 8087. Turbo Pascal uses the extended format to store
all non-integer numeric expressions using extended precision.
The entire right-side of the following assignment, for instance,
will be computed in extended before being converted to the type
on the left side:

  {$N+} {using the numerical coprocessor}
  
  var
    X, A, B, C: real;
  begin
    X:= (B + Sqrt(B*B - A*C))/A;
  end;

With no special effort by the programmer, Turbo Pascal performs
computations using the precision and range of the extended type.
The added precision means smaller round-off errors, and the
additional range means overflow and underflow are less common.
>>>

So, for floating points, everything seems safe enough.


-=[Calculating with integers]=----------

From the Reference Guide p. 26:

<<<
  * The type with an integer constant is the predefined 
    integer with the smallest range that includes the value
    of the integer constant.
  * For all binary operators (an operator that takes two
    operands), both operands are converted to their common
    type before the operation. The _common_type_ is the 
    predefined integer type with the the smallest range that
    includes all possible values of both types. For instance,
    the common type of integer and byte is integer, and the
    common type of integer and word is longint. The operation
    is performed using the precision of the common type, and
    the result type is the common type.
  * The expresssion on the right of an assignment is evaluated
    independently from the size or the type of the variable on
    the left.
  * Any byte sized operand is converted to an intermediate 
    word-sized type operand that is compatible with both 
    integer and word before any arithmetic operation is
    performed.
>>>

So the problems of Turbo Pascal with integers arise from the
fact that, for the evaluation of expressions, the common type
is used instead of the largest set available (longint).


-=[Your example]=----------

I can now better understand the example you gave me.

<<<
{$R+}

  var
    n1, n2: shortint; {range: -128 .. 127}
    i1,i2:  integer;  {range: -32768..32767}
    N: longint; {range: -2147483648 .. 2147483647}

  begin
    n1:= 120;
    n2:= 120;
    N:= n1 + n2;
    Writeln(N);

    i1:= 32000;
    i2:= 32000;
    N:= i1 + i2;
    Writeln(N);
  end.
>>>

Since n1 and n2 are byte-sized, they are both converted to
word-sized and this is why, for (n1 + n2), we get the correct
result 240.

For (i1 + i2), the common type (integer) is used for the 
evaluation and, since the sum is outside the range, we get
the wrong result -1536. This problem could be avoided if,
instead of using the common type, Turbo Pascal would use
longint.

I tried your example with Turbo Pascal 5 (I admit, at first,
I didn't believe the results and tought there was some
error in the listing). I also tried some variations on it.
First, I replaced the n1, n2, i1, and i2 declarations by

    n1, n2: -128..127;
    i1, i2: -32768..32767;

and, not surprisingly, got the same results (240 and -1536).

Now, what would happen if I declare i1 and i2 as constants:

<<<
{$R+}

  const
    i1 = 32000;
    i2 = 32000;
    
  var
    n1, n2: shortint; {range: -128 .. 127}
    N: longint; {range: -2147483648 .. 2147483647}

  begin
    n1:= 120;
    n2:= 120;
    N:= n1 + n2;
    Writeln(N);

    N:= i1 + i2;
    Writeln(N);
    N:= i1 - 5*i2; {here, I put something new}
    Writeln(N);
  end.
>>>

According to the first rule above, i1 and i2 should each be 
casted as "integer with the smallest range that includes the
value of the integer constant". Since integer is the smallest 
range including 32000, we should again get into trouble.
Surprisingly, when I run the above program, I get the correct
results:
  240
  64000
  -128000
So, it seems, something is still escaping me. (On the other hand,
I'm glad that, here, we get the correct answers. Otherwise, using
constants would turn into a programming nightmare.)


-=[Handling types with Ada]=----------

Getting back to my first example:

<<<
  for n1:= -128 to 127
    for n2:= -128 to 127
      begin
        sum:= n1 + n2;
        ...
      end; {for}
>>>

how would you declare variables n1, n2, and sum in Ada?

> In Ada you can handle ranges and bits independently:
> e.g. a 32-bit subtype of range -127..128, etc. etc.
> In the same subtype family (e.g. integer, natural, positive)
> you can write n1+n2 safely, without explicit conversion, as
> there is no bad surprise with hidden type conversions; ranges
> will be checked correctly - provided you didn't suppress them
> at compile time...

This is new to me. I've never seen something like this in the
languages I used before (Fortran 77, Pascal, C, IDL). I think
I'm beginning to get the idea but I would appreciate a small
example of this, just to see how this looks like in Ada.

	Andre

PS: Thanks to all those who participate in this exchange. I really
    appreciate the input.

Re: Ada vs Delphi?

[Gautier]

> It depends. More often than not, I use integers as counters.
> For example, let's consider an hypothetical situation in which
> we have the following loop

> <<<
>   for n1:= -128 to 127
>     for n2:= -128 to 127
>       begin
>         sum:= n1 + n2;
>         ...
>       end; {for}
> >>>

In the most cases, simply declare "sum" as integer and
everything will be fine. NB: n1 & n2 are declared and semantically
exist from begin of loop till end of loop, like in a true
mathematical sum.
If you need longer integers, you'll force their type

  for n1 in long_integer'(-128)..127 loop

or -if you need to know how many bits-

  for n1 in integer_64'(-128)..127 loop

In any case, every mistake will be catched either at compile time
or at run-time (when range chacks are on).

(...)

> A safe language should be such that all evaluations are performed
> using the largest set of numerals available (longint for integers,
> extended for real numbers).

Such an approach is safe but can be redhibitory slow.
In fact it facilitates the job for writing small and fast
compilers in assembler...

With explicit type conversions and operators precisely defined
for such or such type, there is a _safe_ and _fast_ solution.

Let's see Borland's example:

>   {$N+} {using the numerical coprocessor}
> 
>   var
>     X, A, B, C: real;
>   begin
>     X:= (B + Sqrt(B*B - A*C))/A;
>   end;

According to their doc, there will be 6 real-to-extended conversions
and 1 extended-to-real: 8-(( . In addition the "real" type in TP
is an old floating-point type not related to FPU: the 7 conversions
are made "by hand" in TP' run-time library !!
A quick disassembly gives:

	mov	ax,[b]
	mov	bx,[b+2]
	mov	dx,[b+4]
	call	frealext		;SYSTEM.TPU
	mov	ax,[b]
	mov	bx,[b+2]
	mov	dx,[b+4]
	call	frealext		;SYSTEM.TPU
	fmulp	st(1),st

Just for doing B*B . No wonder that TP is not a star in numerics...

A Turbo Ada would have (in its Ada.Numerics.***)
"+", "-", "*", "/", "Sqrt" functions for real and the same
set for any other available floating-point type (FPU or not),
with the most direct code (i.e. the fastest one) each time, all
being absolutely safe... If you need a certain precision,
you store the values in floating-point variables of the precision
required.

(...) [my example]

> For (i1 + i2), the common type (integer) is used for the
> evaluation and, since the sum is outside the range, we get
> the wrong result -1536. This problem could be avoided if,
> instead of using the common type, Turbo Pascal would use
> longint.

It would not be smart at all for 16-bit code - Borland wanted
a not too slow code for integers - as 99% other contexts with
(i1 + i2) keep in the range. In addition the problem would
arise again with adding (2000000000+2000000000) : it means
that everything should be computed with 64 bits (Delphi it seems);
but then I come with an example with (2^63+2^63) and now
everything should be computed with 128 bits (even slower)!
You see that this is not the right approach.

The problem here that TP has been written without precise
idea about it, adding features from versions to versions...
Their {$R+} (range check on) should have catched the overflow
if they hadn't confused signed and unsigned for 16-bit "+".
NB: I've discovered that bug by constructing my example!

> {$R+}
> 
>   const
>     i1 = 32000;
>     i2 = 32000;
> 
>   var
>     n1, n2: shortint; {range: -128 .. 127}
>     N: longint; {range: -2147483648 .. 2147483647}
> 
>   begin
>     n1:= 120;
>     n2:= 120;
>     N:= n1 + n2;
>     Writeln(N);
> 
>     N:= i1 + i2;
>     Writeln(N);
>     N:= i1 - 5*i2; {here, I put something new}
>     Writeln(N);
>   end.

> According to the first rule above, i1 and i2 should each be
> casted as "integer with the smallest range that includes the
> value of the integer constant". Since integer is the smallest
> range including 32000, we should again get into trouble.
> Surprisingly, when I run the above program, I get the correct
> results:
>   240
>   64000
>   -128000
> So, it seems, something is still escaping me.

The thing is that when TP sees an expression with
numbers only, it computes it at compile-time.
E.g. you'll find in assembler code that TP hardcoded
     N:= i1 - 5*i2;
as
     N:= -128000

With typed constants you would find the bug again...
NB: in Turbo Pascal, typed constants are in fact variables,
you can change their value!!!

> -=[Handling types with Ada]=----------
> how would you declare variables n1, n2, and sum in Ada?
(...)
> > In Ada you can handle ranges and bits independently:
(...)
> This is new to me. I've never seen something like this in the
> languages I used before (Fortran 77, Pascal, C, IDL). I think
> I'm beginning to get the idea but I would appreciate a small
> example of this, just to see how this looks like in Ada.
See at beginning...

This Ada feature is at the same time the safest and the fastest
for calculations (integer/flaoting-point/fixed-point).

Even respectable Fortran compilers used for high-precision
number-crunching do horrible mismashes with precision due to weak
typing.

First of all, it you compile a constant explicitly typed as
double-precision with DEC Fortran or Lahey Fortran, both
will cut with a smile all extra decimals as if it was single-precision
!!!

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada vs Delphi?

[Gautier]

Some amendements / words to defend Borland -sorry- Inprise
Pascal:

* The other Intel-FPU specific types are not implicitely converted
to extended (unless they are internally by FPU itself!),
so there might no be such conversions as with real <-> extended.
To that respect TP (6) doesn't seem to follow the rule
in their Reference Guide (TP 5) ...

* For the "32000+32000=-1536" bug, it's more an overflow
checking problem than a range check one. Since overflow
checking appears only in TP/BP 7 ($Q+) one shouldn't blame TP6...
NB: not tested the case on TP7...

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada vs Delphi?

[Steve Doiel]

[snip]
>
> Getting back to my first example:
>
> <<<
>   for n1:= -128 to 127
>     for n2:= -128 to 127
>       begin
>         sum:= n1 + n2;
>         ...
>       end; {for}
> >>>
>
> how would you declare variables n1, n2, and sum in Ada?

In Ada you need not declare the loop variables.  If wish to you
can as I have done in the example below (a sample program which
does compile):

procedure ngdemo is

  type aByteRange is range -128..127;

  sum : Integer;

begin
  for n1 in aByteRange range -128 .. 127 loop
    for n2 in aByteRange range -128 .. 127 loop
      sum := Integer( n1 ) + Integer( n2 );
      -- If you try to compile using just
      --  sum := n1 + n2;
      -- you get a compile time error:
      --   expected type "Standard.integer"
      --   found type aByteRagne defined at line 3
    end loop;
  end loop;
end ngdemo;

In this example I have forced the indexes n1 and n2 to be
of a type that ranges from -128 to 127.  Clearly the intermediate
result for calculating sum would have to exceed this range, so
I cast both n1 and n2 to integer before performing the addition.

This is likely what is intended by the example.

But... I am making an assumption about casting the type of
n1 and n2 to Integer.  Ada does not make this assumption.  As
a matter of fact Ada makes no assumptions about how you wish
to operate or convert between types.  That is in my opinion one
of its advantages over Delphi.

SteveD

Re: Ada vs Delphi?

[Robert I. Eachus]

Andre Ratel wrote:
> 
> My post is a bit long. I apologize, but I really want to get to the
> bottom of this.

    Fine but you need to understand that the water is really deep.

> A safe language should be such that all evaluations are performed
> using the largest set of numerals available (longint for integers,
> extended for real numbers). The responsability of the programmer
> would be then to choose the appropriate type of variables for
> _storing_ the results in memory. (I am aware that this might lead
> to problems in efficiency.)

  Hmmm.  Ada has a several types one of which is _universal_integer_
which really are universal types, containing, in this case, all possible
integers.
It is possible to generate values of these universal types at run-time,
and there are specific rules for how to value such expressions.  (For
static expressions, you get them right, at compile time, no matter how
far out they are.)

  But what about expressions containing mixtures of two different
classes?  Things get really tricky.  For example, how do you evaluate:
System.Max_Binary_Modulus + System.Min_Int? At compile time of course,
but what if one value is a run-time value? (Assume that Long_Integer is
the largest integer type, and Long_Modular is the largest modular type
and they have the same number of bits):

  X: Modular := ...;
  Y: Modular := Modular'Modulus - X;

  Foo'Modulus cannot be represented as a value of type Foo for any Foo,
but in this case there is no larger type.  So how do you deal with this
case?  As a special case, since the idiom is useful.  But what about:

  X: Integer := ...;
  Y: Modular := Modular(Modular'Modulus + X);

  It looks like you should use the Modular type to evaluate this
expression, but you can't, you really have to follow the rules and do
the addition, then the conversion.  The conversion will fail unless X is
negative, but if you convert X first, the conversion would fail only
when it shouldn't.  Again, you might want to special case such an
expression, because no arithmetic operations are required.  In fact the
compiler might not even need to treat it as a special case. 
(Modular'Modulus is congruent to 0 mod itself, so you just have to do
the constraint check right.

    There is an even more vexatious problem with no static values.
Watch:

    X: Integer := ...;
    Y: Modular := ...;

    if Integer'Pos(X) - Modular'Pos(Y) > 42 then...

    Now what do you do?  (For those who are not Ada experts those
operands and operations are of type _universal_integer_, the result is
of course Boolean.)  The expression must be evaluated at run-time, and
there is no machine arithmetic type which will always get the right
answer.  For those of you who are Ada experts, yes there is an AI on the
subject, but we are still working on it...

    In Ada I had to work hard to get a legal example of the problem, but
what does Delphi do in a similar case?
 
>   * For all binary operators (an operator that takes two
>     operands), both operands are converted to their common
>     type before the operation. The _common_type_ is the
>     predefined integer type with the the smallest range that
>     includes all possible values of both types. For instance,
>     the common type of integer and byte is integer, and the
>     common type of integer and word is longint. The operation
>     is performed using the precision of the common type, and
>     the result type is the common type.

    But there is no possible common type between (long) integer and
(long) unsigned!
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs Delphi?

[Robert Dewar]

In article <37ae1fc8.653954@news.clara.net>,
  paulyg@clara.net (Paul Groves) wrote:

> I was not aware of this.  Delphi is based strongly on
> Pascal, which has one of the most securely enforced type
> domains I've seen.  All types convertions in Delphi occur
> through well defined type co-ercion functions -- Theres no
> 'casting', which is what can lead to problems...

If Pascal is the "most securetly enforced type domain" that
you have seen, you have certainly not seen Ada, or many other
languages that have much more comprehensive strong typing
systems. What you can do in Pascal, which you cannot do in
Ada, is to freely mix "different" integer types. I put the
"different" in quotes since really there is only one integer
type in Pascal (at least by Ada standards).

>>  Ada supports overloading of operators, functions, and
>>  procedures.

> Not always a good thing.

Nothing is *always* a good thing, in the sense that this feature
can be overused, but it is a VERY powerful capability that is
indeed notably missing in Pascal. For example, if you create
an matrix package, you can use standard arithmetic notation
(e.g. + = matrix addition), which can make code much easier
to read and maintain.

> >  Programs written in Ada are more likely to be portable to
> >  other architectures.  Delphi lives only on PC's.
> True, but again - If the guy just wants to do scientific
> programming Pascal would do and its portable.

You would *really* have to know Pascal well, and know the
standard well to voluntarily restrict yourself to the portable
standard Pascal (e.g. how many people know that it is valid
in Pascal to do a *right to left* short circuit evaluation of
a logical operation).

> >  Ada is more fully defined.
> From what you say below, you mean better documented?

No, not at all, documentation is a different issue

> >With Ada you can refer to the language
> >reference manual regardless of which compiler you're using
> >and get a fairly
> >explicit description of how things work.  With Delphi you
> >must often refer
> >to trial and error.
> Borland's help files are always crap -- I'll give you that
> one.

This has nothing to do with help files. What we are talking
about here is the absence of even a semi-formal definition
of Delphi, let alone a carefully reviewed international
standard.

> >  Ada includes tasking as a part of the language which makes
> >threaded
> >applications portable.
> Delphi has a thread component its not portable obviously...

and very much non-standard, and hence not well documented.

> I'm not an advocate of Delphi - personally I think it sucks.
> Someone should write a better 'Visual Pascal'  Then again,
> I'm not a fan of Ada.  The only *truely* well-defined
> language that I ENJOY using is Pascal...

Pascal is really not "truely" well defined. FOr one thing, it
is a mess that the ANSI standards and ISO standards are
different (I assume this is still the case, if this abominable
state of affairs has been fixed, let me know).

Second, almost no Pascal compilers implement exactly the
standard and nothing more. One of the VERY important aspects
of Ada is that a standard Ada compiler is not permitted any
extensions over what is in the standard, so in practice it is
far easier to write portable Ada programmers, and there is
one source of the standard semantics.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Andre Ratel]

-= Mixing types =-------------------------

On Mon, 09 Aug 1999 02:51:34 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:

> What you can do in Pascal, which you cannot do in
>Ada, is to freely mix "different" integer types. I put the
>"different" in quotes since really there is only one integer
>type in Pascal (at least by Ada standards).

I'm not sure I fully understand. Let's say n1 and n2 are known
to be non-negative integers (called cardinals in Delphi) but their
difference  might be positive or negative. In Delphi, I would then
declare these variables as

  type
    n1, n2: cardinal; 
    N21, N12: integer; 

and I could have something like

  begin
    n1:= 0;
    n2:= 8;
    N21:= n2 - n1;
    Writeln(IntToStr(N21));
    N12:= n1 - n2;
    Writeln(IntToStr(N12));
  end;     

This seems OK with me and, with range checking off, would give the
right answers (8 and -8). On the other hand, a statement like
    Writeln(IntToStr(n1 - n2));
would give  4294967288.

Now, with the above definitions of variables, a statement like
    N21:= n2 - n1;
would not be valid with Ada?

rem: If, in the above program, I add the compiler directive
       {$RANGECHECK ON}
     calculating N12 leads to a range check error (although
     N12 has been declared as an integer).

-= Absence of standards =--------------------------

>Pascal is really not "truely" well defined. FOr one thing, it
>is a mess that the ANSI standards and ISO standards are
>different (I assume this is still the case, if this abominable
>state of affairs has been fixed, let me know).

I often read this as one of the main reasons for the demise
of Pascal and its replacement by C. (As for the other reason,
I would suggest that C simply rides on the popularity of Unix.)

>Second, almost no Pascal compilers implement exactly the
>standard and nothing more. One of the VERY important aspects
>of Ada is that a standard Ada compiler is not permitted any
>extensions over what is in the standard, so in practice it is
>far easier to write portable Ada programmers, and there is
>one source of the standard semantics.

This is certainly one major advantage of Ada over Delphi.

	Andre

Re: Ada vs Delphi?

[Ted Dennison]

In article <37b129ae.43419124@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:

>   type
>     n1, n2: cardinal;
>     N21, N12: integer;

> Now, with the above definitions of variables, a statement like
>     N21:= n2 - n1;
> would not be valid with Ada?

It depends on how "cardinal" is defined. If it were defined as a
completely separate type, eg:
   type Cardinal is 0..Integer'max;

then no, that would not be allowed. If you wanted to do that you'd have
to be more explicit about it. eg:
   N21 := Cardinal(n2 - n1);

And of course the type conversion would probably cause a constraint
check (unless they are turned off, or the compiler can determine ahead
of time that the check will always pass).

However, I could use a "subtype" instead of a completely different
integer type. (I'm not sure if Delphi's "cardinal" includes 0 or not,
but lets assume it does .If not, substitute "Natural" with "Positive"
below). Ada has a predefined subtype of Integer named "Natural" that
achieves the same effect. IAW, the following *is* legal Ada:
   n1, n2 : Natural;

   N21 := n2 - n1;

So the answer is, it could be either legal or not legal, depending on
how you the developer, want it to be.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Andre Ratel]

On Wed, 11 Aug 1999 15:13:02 GMT, Ted Dennison <dennison@telepath.com>
wrote:

>In article <37b129ae.43419124@news.total.net>,
>  aratel@total.net (Andre Ratel) wrote:
>
>>   type
>>     n1, n2: cardinal;
>>     N21, N12: integer;
>
>> Now, with the above definitions of variables, a statement like
>>     N21:= n2 - n1;
>> would not be valid with Ada?
>
>It depends on how "cardinal" is defined. If it were defined as a
>completely separate type, eg:
>   type Cardinal is 0..Integer'max;

Sorry, I should have mentioned this. In Delphi, a cardinal is defined 
as an unsigned 32-bit with range  0 .. 4294967295  whereas an
integer is a signed 32-bit with range  2147483648 .. 2147483647.
So, yes, cardinal is a completely different type and it contains 0.

>then no, that would not be allowed. If you wanted to do that you'd have
>to be more explicit about it. eg:
>   N21 := Cardinal(n2 - n1);

Since N21 was declared an integer, I think we should have instead

  N21:= Integer(n2 -n1);

or, to avoid any erroneous results

  N21:= Integer(n2) - Integer(n1);

>However, I could use a "subtype" instead of a completely different
>integer type. (I'm not sure if Delphi's "cardinal" includes 0 or not,
>but lets assume it does .If not, substitute "Natural" with "Positive"
>below). Ada has a predefined subtype of Integer named "Natural" that
>achieves the same effect. IAW, the following *is* legal Ada:
>   n1, n2 : Natural;
>
>   N21 := n2 - n1;

If I understand correctly, in Ada, some types have subtypes. So I
could declare

  N21: Integer;
 n1, n2: Natural;

and evaluate the expression

  N21:= n2 - n1;

without problem.

That's interesting. Thanks.

	Andre

Re: Ada vs Delphi?

[Ted Dennison]

In article <37b54687.54956646@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:

> Sorry, I should have mentioned this. In Delphi, a cardinal is defined
> as an unsigned 32-bit with range  0 .. 4294967295  whereas an
> integer is a signed 32-bit with range  2147483648 .. 2147483647.
> So, yes, cardinal is a completely different type and it contains 0.
...
> If I understand correctly, in Ada, some types have subtypes. So I
> could declare
>
>   N21: Integer;
>  n1, n2: Natural;
>
> and evaluate the expression
>
>   N21:= n2 - n1;
>
> without problem.

Exactly. The only hitch is that subtypes cannot have a greater range
than their base type. So Natural'last = Integer'last. If you want to use
that extra bit for a larger positive range, you'd have to go to a
separate integer type (actually probably a modular type, but let's not
get into that here). In that case you will have to perform the explicit
conversions to get the assignment to work. And of course the conversion
will raise an exception if the value won't fit in an integer.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Robert Dewar]

In article <37b129ae.43419124@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:
> This is certainly one major advantage of Ada over Delphi.

Note that in some respects comparing Ada to Delphi is itself
a type error :-)

Delphi is an implementation of a language, and not just a
language, whereas Ada is a language.

Yes, you can talk about the language implemented by Delphi,
which is a dialect of Pascal, but still the use of the word
Delphi can cause confusion.

In particular, the major strength of Delphi in my opinion is
not the language, which is usable, but definitely inferior
to other possibilities, but rather the implementation of the
entire system, and the integration of this implementation with
the visual environment of the OS. That's truly impressive.

There is nothing of course to prevent a similarly impressive
system being constructed around any other language, but that's
not a language issue.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[David Botton]

I would say that Ada is not as far a way as people think. It is only a
matter of time until tools like AdaGTK, TASH, or Rapid combined with
component tools like AdaCOM, GNACK and AdaBorker will make possible and
provide enviornents as powerful as Delphi, with the added advantage of being
cross platform, having a more robust language, and be _OpenSource_.

David Botton

Robert Dewar wrote in message <7os93j$fef$1@nnrp1.deja.com>...

>There is nothing of course to prevent a similarly impressive
>system being constructed around any other language, but that's
>not a language issue.

Re: Ada vs Delphi?

[Andre Ratel]

On Wed, 11 Aug 1999 16:41:25 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:

>In article <37b129ae.43419124@news.total.net>,
>  aratel@total.net (Andre Ratel) wrote:
>> This is certainly one major advantage of Ada over Delphi.
>
>Note that in some respects comparing Ada to Delphi is itself
>a type error :-)
>
>Delphi is an implementation of a language, and not just a
>language, whereas Ada is a language.
>
>Yes, you can talk about the language implemented by Delphi,
>which is a dialect of Pascal, but still the use of the word
>Delphi can cause confusion.

You are right, of course. In fact, the language is Object Pascal
and Delphi is the programming environment around it. 

In Delphi circles, some people tend nonetheless to say that they
are programming in Delphi instead of Pascal. It seems this has to 
do with the defamation of Pascal by the C propagandists :-). For a
more elaborate explanation of this, you can read the Introduction of

  Don Taylor, Jim Mischel, John Penman, and Terence Goggin
  Kick Ass Delphi Programming
  (Coriolis Group, 1996)


	Andre

Re: Ada vs Delphi?

[Robert Dewar]

In article <37b129ae.43419124@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:
> -= Mixing types =-------------------------
>
> I'm not sure I fully understand. Let's say n1 and n2 are known
> to be non-negative integers (called cardinals in Delphi) but
their
> difference  might be positive or negative. In Delphi, I would
then
> declare these variables as
>
>   type
>     n1, n2: cardinal;
>     N21, N12: integer;
>
> and I could have something like
>
>   begin
>     n1:= 0;
>     n2:= 8;
>     N21:= n2 - n1;
>     Writeln(IntToStr(N21));
>     N12:= n1 - n2;
>     Writeln(IntToStr(N12));
>   end;
>
> This seems OK with me and, with range checking off, would give
the
> right answers (8 and -8). On the other hand, a statement like
>     Writeln(IntToStr(n1 - n2));
> would give  4294967288.
>
> Now, with the above definitions of variables, a statement like
>     N21:= n2 - n1;
> would not be valid with Ada?


You definitely do NOT understand, which is not surprising since,
as I expected, Delphi is not strongly typed in this area.

Your view of types above is strictly structural, you declare
things to be signed or unsigned according to their value range
and then worry about mixing these values.

That has nothing at all to do with the kind of strong typing
we are talking about, where you have:

  type minutes is range 0 .. 59;
  type seconds is range 0 .. 59;

  mm : m;
  ss : s;

Now mm and ss have IDENTICAL representation, but are of quite
different types, so an assignment

  mm := ss;

which is almost *certainly* a bug, is statically illegal, just
as illegal in fact as trying to assign a record to an integer.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Andre Ratel]

On Wed, 11 Aug 1999 16:37:54 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:

>You definitely do NOT understand, which is not surprising since,
>as I expected, Delphi is not strongly typed in this area.

The Delphi books I have say that it is strongly typed (but, of
course, they compare it to C :-).

>Your view of types above is strictly structural, you declare
>things to be signed or unsigned according to their value range
>and then worry about mixing these values.
>
>That has nothing at all to do with the kind of strong typing
>we are talking about, where you have:
>
>  type minutes is range 0 .. 59;
>  type seconds is range 0 .. 59;
>
>  mm : m;
>  ss : s;

I suppose, here, you meant
  mm: minutes;
  ss: seconds;

>Now mm and ss have IDENTICAL representation, but are of quite
>different types, so an assignment
>
>  mm := ss;
>
>which is almost *certainly* a bug, is statically illegal, just
>as illegal in fact as trying to assign a record to an integer.

OK. I'm putting all the pieces together now. And I suppose
that if mm and ss are related and you need to combine them
in a single expression, you would proceed through typecasting.
For example, 

  type minutes is range 0 .. 59;
  type seconds is range 0 .. 59;
  type count is range 0..3600;

  mm : minutes;
  ss : seconds;
  cc: count;

  cc:= 60*count(mm) + count(ss);

But how do you avoid complex expressions becoming cumbersome?


	Andre

Re: Ada vs Delphi?

[Robert I. Eachus]

Andre Ratel wrote:
  
> But how do you avoid complex expressions becoming cumbersome?
 
    By defining the operators you need so that the code makes sense. 
For example:

  function Clock return Tick;
  type Tick is new Integer; -- lets assume a 1 millisecond clock.
  type Seconds is delta 0.001 digits 6; -- let's use a decimal type for
kicks.
  type Minutes is range -186400..186399;
  ...
  function "+" (L: Tick; R: Seconds) return Seconds;
  function "+" (L: Tick; R: Seconds) return Tick;
  pragma Inline("+"); -- applies to both functions.
  ...
  function "+" (L: Tick; R: Seconds) return Seconds is
  begin return Seconds(L)/1000 + R; end "+";
  function "+" (L: Tick; R: Seconds) return Tick is 
  begin return L + Tick(R * 1000); end "+";

  Now you can write:

    Total_Waiting_Time: Seconds := 0.0;
  ...
  function Something;
    Now: Tick := Clock;
  begin -- waiting ;-)
    Acquire_Lock;
    Actually_Do_Something;
    Release_Lock;
    Total_Waiting_Time := Total_Waiting_Time + Clock - Now;
  end;  
  
  Of course, this is all expository.  You don't want to do that, even
when you are writing a simulation package because the language provides
two time packages (Ada.Calendar and Ada.Real_Time) plus a type
Standard.Duration with many types and conversions already defined.  (In
addition if you use a predefined time type, you can use it in delay and
delay until statements.)

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs Delphi?

[Aidan Skinner]

On Mon, 09 Aug 1999 01:38:17 GMT, Paul Groves <paulyg@clara.net> wrote:

>>eliminate the risk of memory leaks.  Delphi has no counterpart.  In Delphi
>>it is easy to create memory leaks.
>Isn't it just as 'easy' to "create memory leaks" in Ada?

Not if you use Ada.Finalization.Controlled

>Delphi (Pascals) pointer types are just like Ada's access
>types so the same is possible in both languages.

Except if you derive a type from Controlled (or Limited_Controlled)
you can put automatic memory deallocation code into a procedure which
is automatically called when the object is destroyed. You don't have
to do it by hand every time.

>>  Ada is more stronly typed.  In Delphi different types may be freely mixed

>I was not aware of this.  Delphi is based strongly on
>Pascal, which has one of the most securely enforced type

Other people have pointed out that it's possible to define multiple
types of one base type 

>>  Ada supports overloading of operators, functions, and procedures.
>Not always a good thing.

No, but then giving people a text editor is not always a good
thing. <g>

Overloading, when used properly, allows people to do sensible things
like have input/output procedures called "Put" and "Get" for every type.

>I'm not a fan of Ada.  The only *truely* well-defined
>language that I ENJOY using is Pascal...

Have you seriously tried Ada? It's very similar to Pascal in good
ways, and different from Pascal in good ways as well. It's not without
fault, but it's a lot better than most as a general purpouse
programming language.

- Aidan (still does scripting in sh)
-- 
Gimme money, gimme sex, gimme UNIX and root access.
http://www.skinner.demon.co.uk/aidan/

Re: Ada vs Delphi?

[Brian Rogoff]

On Mon, 9 Aug 1999, Paul Groves wrote:
> >Advantage of Ada
> >  Types may be derived from Ada.Finalization.Controlled in order to
> >eliminate the risk of memory leaks.  Delphi has no counterpart.  In Delphi
> >it is easy to create memory leaks.
> Isn't it just as 'easy' to "create memory leaks" in Ada?

Yes, but that isn't the point. By using controlled types it is easier to
create programs that don't leak resources (memory, file handles, etc...). 

> Delphi (Pascals) pointer types are just like Ada's access
> types so the same is possible in both languages.

Ada also doesn't confuse access types and "objects", like many other
languages, so you don't need to hit the heap as hard as in some other 
OO languages. 

> >  Ada supports overloading of operators, functions, and procedures.
> Not always a good thing.

Overloading is very useful in writing readable programs, if you have 
the discipline and good taste to use it wisely. Many nice languages 
I've used, like Ocaml, don't have it, but I find that a bug in ML not 
a bug in Ada. 

> 
> >  Programs written in Ada are more likely to be portable to other
> >architectures.  Delphi lives only on PC's.
> True, but again - If the guy just wants to do scientific
> programming Pascal would do and its portable.

Given that comment, I'm quite certain that you don't know Ada, or, 
more importantly, scientific programming.

-- Brian

Scientific calculations (was Re: Ada vs Delphi? )

[Vladimir Olensky]

Brian Rogoff wrote in message ...
>On Mon, 9 Aug 1999, Paul Groves wrote:


<snipped>

>> True, but again - If the guy just wants to do scientific
>> programming Pascal would do and its portable.
>
>Given that comment, I'm quite certain that you don't know Ada, or,
>more importantly, scientific programming.



To do any job in a most effective way one should choose the most appropriate
tools for that job.
For engineering and scientific calculations there exist several very
powerful tools:
Mathcad, Maple, Mathematica  and some others.
So in practice there is no need to reinvent the wheel at all.

My favorite one is MathCad Professional.  It can do almost everything
including powerful symbolic calculations (very powerful AI feature) and it's
own programming as well as visualisation of the results using OpenGL. There
are many additional specialized packages for it as well as electronic books.
It also allows you to add your own DLL libraries if you want to add
something that does not exist (very unlikely).
What is most important all your calculations are done in a "human" notation,
the same as you do it on the paper.

Anyone who is interested may have a look at
1.  http://www.mathsoft.com
2. http://www.mathematica.com


Regards.

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Robert Dewar]

In article <rr2f32q3krl93@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> My favorite one is MathCad Professional.  It can do almost
everything
> including powerful symbolic calculations (very powerful AI
feature) and it's
> own programming as well as visualisation of the results using
OpenGL.

Actually I would draw a parallel here between thinking all
scientific calculations can be done using MathCad, with thinking
that all Fiscal processing in the IS area can be done using
high level fourth generation programming languages.

It is not that these tools (in either case) are not useful. They
are VERY useful, but their domain is (in both cases) quite
limited, and a remarkable amount of programming is still done
using conventional programming languages. I am sure that COBOL
is still by far the most commonly used language, counting only
new projects starting, in the IS community (partly because there
are not many alternatives -- Ada 95 is from a technical point of
view an attractive alternative, but it is not an easy sell for
non-technical reasons).

In fact referring to calculations is significant in this post.
Calculations as such are often a rather small part of the
task of a scientific program. THe idea that SP is simply about
calculations is a little bit like thinking that all COBOL
programs do is input-output and simple report generation :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Vladimir Olensky]

Robert Dewar wrote in message <7os9j4$fs7$1@nnrp1.deja.com>...
>In article <rr2f32q3krl93@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> My favorite one is MathCad Professional.  It can do almost
>everything
>> including powerful symbolic calculations (very powerful AI
>feature) and it's
>> own programming as well as visualisation of the results using
>OpenGL.
>
>Actually I would draw a parallel here between thinking all
>scientific calculations can be done using MathCad, with thinking
>that all Fiscal processing in the IS area can be done using
>high level fourth generation programming languages.



You probably did not understood the idea of my post.
The point is not that  MathCad, Maple or Mathematica  can always "replace
conventional programming languages for 'scientific programming' ". There is
also difference between engineering domain and scientific domain. Some tools
are purely engineering - AutoCad,PCAD, Electronic Workbench etc., some
others  mentioned above cover both (but not totally). There is no universal
tool for all of course.

The point is that if there exist specialized tools there is no need to
reinvent the wheel.
First try these tools and  only then decide if you need to spend time and
efforts to do anything additional (and here you may use any conventional
programming language -C, Ada, Pascal etc.)
Idea is that one should use right tools for right job.

As I mentioned earlier these tools are easily extensible (in the field of
numeric calculations) using external libraries (there are a lot of them in
almost any field). New ones  appear in time. One of  them that is worth
mentioning is wavelet pack (wavelet transforms is new revolutionary thing
that comes from theoretical studies to real life  and soon will change a lot
of things in signal processing - e.g. data compressing, image processing
etc.)
Also there are great number of ready to use solutions to  many problems in
engineering and scientific domains.

As I mentioned one of  the main powers of Maple, MathCad is the very
powerful engine for symbolic calculations.
This AI feature is extremely expressive.
First you can  find the symbolic solution of the problem and then use
numeric calculations.

Taking into account your comments I might think that you probably are not
very familiar with these tools or did not use them much.


Regards.

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Gautier]

MathCAD and Mathematica are nice... for *small* size calculations.

There are many problems with these programs for doing *numeric*
(not symbolic) calculations:

- as it's interpreted, with dynamic formulas, it's *hyper-slow*:
  colleagues here did calculations that lasted ~one day on a 200Mhz
  machine with Mathematica, often interrupted by crashes or endless
  garbage collections. Compiled (Ada or Fortran) on a 500Mhz AXP, it
  lasted a few seconds...

- even the latest Mathematica has enormous precison problems (surely
  due to weak typing...)

- the methods are hidden and proprietary: no way to see their bugs
  or what "'epsilon"s they really use.

- with non small problems, these user-oriented programs begin to
  panic very early (virtual memory, garbage collection etc.)

- no way to customize the classical methods (my present work...)

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Robert Dewar]

In article <rr3kb1t2krl47@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> Taking into account your comments I might think that you
probably are not
> very familiar with these tools or did not use them much.
>


I am actually very familiar with these tools, they are just not
relevant for large segments of the scientific programming
community (I hope you do not think MINDO3 could have been
done using Mathcad :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Brian Rogoff]

On Fri, 13 Aug 1999, Robert Dewar wrote:
> In article <rr3kb1t2krl47@corp.supernews.com>,
>   "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> > Taking into account your comments I might think that you
> probably are not
> > very familiar with these tools or did not use them much.
> 
> I am actually very familiar with these tools, they are just not
> relevant for large segments of the scientific programming
> community (I hope you do not think MINDO3 could have been
> done using Mathcad :-)

These tools are the scientific programming equivalent of scripting
languages. They're very useful, and often just what you want if you 
are solving fairly small problems and the algorithms they use match what
you need, but are not useful in high performance computing. Since we 
were discussing Delphi/Pascal vs Ada, I thought that high performance 
was included in the context, and hence Fortran, C, C++ would be comparable 
but MATLAB, Mathematica, Maple, and Axiom not. 

Incidentally, Ada fans will probably find Axiom and its language (once 
Sketchpad, now K# I think) very interesting.

-- Brian

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Vladimir Olensky]

Robert Dewar wrote in message <7ovp6j$vrl$1@nnrp1.deja.com>...
>In article <rr3kb1t2krl47@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> Taking into account your comments I might think that you
>probably are not
>> very familiar with these tools or did not use them much.
>>
>
>
>I am actually very familiar with these tools, they are just not
>relevant for large segments of the scientific programming
>community (I hope you do not think MINDO3 could have been
>done using Mathcad :-)

If it is already done in any programming language then it can be easily
added to MathCad Professional.
It's one of it's powers to be easily extended.


Of course no one will insist to use MathCad to simulate nuclear explosion or
do weather forecast or solve aerodynamic equations (aerodynamic tube tests
simulation) in a scaled real-time manner. These *big* kinds of problems
require supercomputers, parallel computation threads using multiprocessors
systems etc.

As Gautier mentioned  MathCad and others such tools are user oriented and
better suited for relatively "small" problems. The border line between
"small" and "big" calculations depends on several different factors and can
be easily estimated.
Some *big* calculations (from numerical point of view)  may be transformed
to *small* ones using symbolic calculation engine or can even be  solved
symbolically which is most preferable.
What is interesting what is "small" now in MathCad was really "big" some
time ago.
Moreover as results of work in the field of artificial intelligence gets
implemented in such products their power is amazingly increasing (again
about AI - symbolic engine- this is what I like most of all).

I do not know much how  Maple and Mathematica  deal with it but MathCad
Professional (only Professional version) is easily extendable with your own
computational functions that become part of it.  In this sense MathCad
Professional is close to other open integrated development systems like
Delphi.
MathCad Professional comes with nice user guide of how to do this and it
supplies all the include files and LIB files with MathCad specific data  for
different compilers (unfortunately no Ada among them - mostly C,CPP  -but
Ada can be used also after translating small C header file to Ada).

As far as for speed all of MathCad built-in  formulas   have been done in
efficient manner (e.g. creating vector V of MAX(i)=100000 elements and then
applying sin(Pi/k) to each element  takes six seconds on my PC.
I did the similar things (applying some function to each vector element)
with vectors of 10000000 elements and no problems ( time taken depends on
amount of phisycal memory - if memory occupied by vector is greater then
this time is affectred by  the memory swapping  with HD)
Dynamic formulars which user creates using MathCad scripting language of
course  have a speed of any scripting language.

So if one can not find what is needed within built-it functions and he/she
is not satisfied with the speed of dynamic formulas (when calculations need
to be done frequently for long period of time) and there is no commercial
libraries in this area from vendor or third parties them one can create
his/her own libraries (DLLs) for use them with MathCad.
After that your numerical sulutions become part of MathCad and will be
combined with all other powers of it.
Very similar to Delphi.

Quote from MathCad documentation:
"To create customized functions, you will first need to create source code
in C or C++,
then compile the source code with a 32-bit compiler. Next, you will link the
object files
together with the MathSoft-provided mcaduser.lib library to create a DLL.
Finally,
you will place your DLL into the userefi subdirectory and add an entry to
user.xml
so that your function appears in the Insert Function dialog box."


As far for speed  of numeric calculations this is only last fraction of all
the time spent to solve the problem.
Previous one is time to express problem  in the language of the tool you are
using.
As MathCad uses human language then this time is relatively small.
If one prefers to do it using any programming language then this will be the
time to code this problem in programming language, build it, debug etc.  and
make sure that everything is correct from all points of view.
The sum of these time and computation time gives you  time to solve the
problem.
From above it is clear where is the border between "small" and "big"
calculations.
Of course there are many other factors that can move this border in both
directions.

Regards.

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Vladimir Olensky]

Vladimir Olensky wrote in message ...
>>
>If it is already done in any programming language then it can be easily
>added to MathCad Professional.
>It's one of it's powers to be easily extended.


Small example from MathCAD of how easily it can be done :


//////////////////////////////////////////////
#include "mcadincl.h"


LRESULT cmplxsumFunction(   LPCOMPLEXSCALAR     c,
                                LPCCOMPLEXSCALAR    a,
                                LPCCOMPLEXSCALAR    b   );

    FUNCTIONINFO    cmplxsum =


    "cmplxsum",                         // Name by which mathcad will
recognize the function
    "a,b",                              // cmplxsum will be called as
cmplxsum(a,b)
    "complex sum of scalars a and b",       // description of cmplxsum(a,b)
    (LPCFUNCTION)cmplxsumFunction,      // pointer to the executible code
    COMPLEX_SCALAR,
    2,                  // the return type is also a complex scalar
    { COMPLEX_SCALAR, COMPLEX_SCALAR}   // both arguments are complex
scalars
    };



    // this code executes the addition
    LRESULT cmplxsumFunction(   LPCOMPLEXSCALAR     c,  //put return value
here
                                LPCCOMPLEXSCALAR    a,  // 1st argument
                                LPCCOMPLEXSCALAR    b   ) // 2nd argument
    {

        //  add real parts of a and b
        //  and put them into c
        c->real = a->real + b->real;
        c->imag = a->imag + b->imag;


        return 0;               // return 0 to indicate there was no error

    }

BOOL WINAPI _CRT_INIT(HINSTANCE hinstDLL, DWORD dwReason, LPVOID
lpReserved);

BOOL WINAPI DllEntryPoint (HANDLE hDLL, DWORD dwReason, LPVOID lpReserved)
{
  switch (dwReason)
  {
    case DLL_PROCESS_ATTACH:         // DLL is attaching to the address
space of the current process.

      if (!_CRT_INIT(hDLL, dwReason, lpReserved))
        return FALSE;

        CreateUserFunction( hDLL, &cmplxsum );
      break;

    case DLL_THREAD_ATTACH:         // A new thread is being created in the
current process.
    case DLL_THREAD_DETACH:        // A thread is exiting cleanly.
    case DLL_PROCESS_DETACH:      // The calling process is detaching the
DLL from its address space.

      if (!_CRT_INIT(hDLL, dwReason, lpReserved))
        return FALSE;
      break;

  }
  return TRUE;
}

Re: Scientific calculations (was Re: Ada vs Delphi? )

[Robert Dewar]

In article <rr2f32q3krl93@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> My favorite one is MathCad Professional.  It can do almost
everything
> including powerful symbolic calculations (very powerful AI
feature) and it's
> own programming as well as visualisation of the results using
OpenGL. There
> are many additional specialized packages for it as well as
electronic books.
> It also allows you to add your own DLL libraries if you want
to add
> something that does not exist (very unlikely).
> What is most important all your calculations are done in a
"human" notation,
> the same as you do it on the paper.

Mathcad and similar tools are indeed very useful, but to think
that they replace conventional programming languages for
"scientific programming" in general shows a lack of knowledge
of the field. I can promise you that the complex codes used
for semi-empirical approaches for solution of the general
Schrodinger equation in computational chemistry
applications (to compute total energies) are NOT done using
tools like this. I just take
one example (from my father's work -- MINDO3), but anyone in
the field can supply lots more examples.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Andre Ratel]

-= About pointers =--------------------

On Mon, 09 Aug 1999 01:38:17 GMT, paulyg@clara.net (Paul Groves)
wrote:

>Delphi (Pascals) pointer types are just like Ada's access
>types so the same is possible in both languages.
>Delphi does use pointers all over the place for its
>interfacing stuff -- VCL.  The poster was just asking about
>scientific programming so this shouldn't really be a big
>problem.  

For my current work, I don't use pointers. I generally tend to avoid
them (but maybe I'm missing something). The only case where I 
would use pointers is for sorting.


-= Overloading =--------------------

>>  Ada supports overloading of operators, functions, and procedures.
>Not always a good thing.

Delphi now support overloading of methods (since version 4, I think)
but not with operators (at least not to my knowledge).


-= Platforms =--------------------

>>  Programs written in Ada are more likely to be portable to other
>>architectures.  Delphi lives only on PC's.

Borland is said to be working on a Linux version of Delphi.


-= Language definition and manuals =--------------------

>>  Ada is more fully defined.  
>From what you say below, you mean better documented?
>
>>With Ada you can refer to the language
>>reference manual regardless of which compiler you're using and get a fairly
>>explicit description of how things work.  With Delphi you must often refer
>>to trial and error.
>Borland's help files are always crap -- I'll give you that
>one.

I fully agree. Delphi's language definition is not precise enough
(Borland Pascal with Objects, v. 7 was somewhat better in this
respect). As for the manuals, they are very inequal in quality 
and the on-line help is even worst. (Some parts look like they 
have been written by Nostradamus.)

When I began working with Delphi, this was a major source of
frustration. I often found myself trying out things and writing
little notes to myself about stuff which should have been
documented. I had the impression of doing part of Borland's
job instead of working on my own problems.  (And they call
this RAD!) Now, at last, I think (and I hope) I understand all
I need to know to do my own stuff.

I stuck with Delphi instead of moving to C because I really
enjoy using an Algol-like syntax (one might say that I'm a
die hard Algolic :-).


-= Pascal =--------------------

>I'm not an advocate of Delphi - personally I think it sucks.
>Someone should write a better 'Visual Pascal'  Then again,
>I'm not a fan of Ada.  The only *truely* well-defined
>language that I ENJOY using is Pascal...

Have you looked into Component Pascal? It is the latest
brainchild of Niklaus Wirth (the inventor of Pascal, Modula,,
and Oberon).  

The product is named Black Box. I have dowloaded it last 
Sunday (about 6 MB) and installed it on my hard disk (it 
takes about 17 MB if you install everything, including 
documentation, tutorials, examples, and database support).
I went through the Guided Tour, looked at the Map Contents,
and read part of the Black Box Advantage. There's also an
Appendix listing the differences between ordinary Pascal
and Component Pascal (there are differences).

Component Pascal is presented as being one step ahead of
Object Programming in terms of modularity, reusability, scalability,
and robustness . It seems they tried to bring into a single language
all the good things about Pascal, Modula, Ada, Eiffel, and even Java. 
I must say that, after reading a large part of the rationale behind
the language, I was very impressed (but my background is in 
Physics, not Computer Science). 

How all this has been implemented into the product remains to 
be seen. I would need to work with the product for many months 
to get a good grasp of its strengths and limitations.

Anyhow, I you want to have a look at it, you can get  it at
   http://www.oberon.ch/prod/BlackBox/
It is free as long as you don't use it for a commercial product
and, besides the PC version, you can also download the beta
release of a Mac version.

I anyone has tried Component Pascal, I would appreciate his/her
comments.

	Andre

PS: The post you were replying to didn't reach my ISP's
        newsserver.  This is why I had to include in this text my
        comments about  the original post. I apologize.

Ada vs Component Pascal (was: Ada vs Delphi?)

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

In article <37b1282b.43031685@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:

> Have you looked into Component Pascal? It is the latest
> brainchild of Niklaus Wirth (the inventor of Pascal, Modula,,
> and Oberon).
>
> The product is named Black Box. I have dowloaded it last
> Anyhow, I you want to have a look at it, you can get  it at
>    http://www.oberon.ch/prod/BlackBox/

I surfed around thier site a bit.

First off, the copyright on the language definition document is held by
OberonMicrosystems, not N. Wirth. Admittedly he is on the board of
directors for OM, but I could find nothing to indicate he had an active
hand in the development of the language.

Their main selling points seem to be the rapid "component" development
environment (which could be built around *any* language), and the
"simplicity" (aka: lack of features) of the language.

The environment admittedly looks nice. But the language doesn't seem to
support tasking, parameterized classes, or low-level systems
programming. If you never had those features in your language before,
fine. But I don't think I could go back to that. Ada might not (yet)
have a slick Windows GUI development environemnt of that caliber, but
there are several contending environments that I can get for free (even
for commercial work). Some even provide portable GUIs.

A cynic might go through that site and come away with the following
series of events:

1993: OberonMicrosystems founded by N. Wirth and others at ETH Z�rich to
explore the growing commercial possiblities in the Oberon language.

1995: OM marketing grows dissatisfied with their competive position vs.
Delphi. After a braistorming session, it was decided that a
Delphi-killer product would have the following characteristics:
  o  It would of course have a complete RAD environment.
  o  The language would be named "Pascal".
  o  It would have extensions that they could tout as "Object-Oriented"
  o  Like Delphi, it would be under complete control of the vendor.
  o  To reduce implementation and maintence costs, it would have as few
features as possible.

1997: OM publishes a suitably modified version of the Oberon-2 report,
dubbed "Component Pascal Language Report (preliminary)". (see section 1,
paragraph 1 of the report). Since the language is under their complete
control, they don't ever bother revising the report past the
"preliminary" stage.


If you are a Delphi customer, this is probably a description of a system
worth looking into. But personally, I wouldn't like the idea of forgoing
all the extra features and capabilities of Ada, and subjecting myself to
a closed language and a closed-source development environment.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Robert Dewar]

In article <37b1282b.43031685@news.total.net>,
  aratel@total.net (Andre Ratel) wrote:
> For my current work, I don't use pointers. I generally tend to
> avoid them (but maybe I'm missing something). The only case
> where I  would use pointers is for sorting.

Well of course scientific programming is a VERY broad term, and
in fact I would guess that SP covers pretty much the entire
range of programming techniques and approaches. What is
interesting is that quite a bit of work in SP (I know for
example of Olaf Widlund's work in this area) involves the
introduction of quite sophisticated data structures, and
associated algorithms, for instance complex graph traversal
algorithms. Such data structures are naturally and efficiently
represented using pointers, instead of having to encode them
in arrays.

The interesting point here is that what is happening is that
advanced techniques from the algorithms area of computer science
are migrating into the SP area. Historically, much SP was done
by scientists with limited CS training (my own degrees are in
chemistry, back from the days when I was doing large scale SP
myself in crystalography). Now, with more people trained in
CS and algorithms being interested in SP, the fields are much
closer together, and it is in the interface that a lot of
very interesting work is done (of course I am particularly
aware of that due to my association with the Courant Institute
:-)



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada vs Delphi?

[Andre Ratel]

On Wed, 11 Aug 1999 16:55:27 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:

>Well of course scientific programming is a VERY broad term

In Physics (at least for the part I know), it is mainly number
crunching or data analysis together with some graphical
way to display the results. Here, number crunching means:
  - numerical evaluation of expressions 
  - solving trancendental equations
  - numerical integration
  - solving system of differential equations with boundary conditions.

My main concerns are numerical accuracy and stability. (For
instance, how many good programmers are aware that, when 
evaluating an expression like  sqrt(1.0 + x), one should use 
Taylor approximation when x << 1.0?)

I recall seeing pointers in Numerical Recipes in Pascal but they
were used to define open arrays. Now those arrays have been 
implemented in Object Pascal without having to work with
pointers.

>in fact I would guess that SP covers pretty much the entire
>range of programming techniques and approaches. What is
>interesting is that quite a bit of work in SP (I know for
>example of Olaf Widlund's work in this area) involves the
>introduction of quite sophisticated data structures, and
>associated algorithms, for instance complex graph traversal
>algorithms. Such data structures are naturally and efficiently
>represented using pointers, instead of having to encode them
>in arrays.

This might be a question of personal preference. In Physics, I
have often seen very abstract treatments of very simple things. In
my view, formalism should clarify the meaning of results and
not obscure it. In addition, errors are much easier to spot when
everything is kept as simple as possible.

The same can be said for algorithms. Some authors use
pointers, API calls, and complex data structures, others
can do the same job without them. Some procedures
will be very general with lots of overhead, others will
only concentrate on a single task.

C programmers seem to have a lot of fun with pointers. I have
some problems trusting the end result, especially since I know
a few of them which cannot even understand parts of their own 
code six months after writing it.

Optimization is also a very popular subject of discussion. When
I had a PC-XT, I spent some time optimizing my code. When I
upgraded to a 486- 33 MHz, all this work became irrelevant.

>The interesting point here is that what is happening is that
>advanced techniques from the algorithms area of computer science
>are migrating into the SP area. Historically, much SP was done
>by scientists with limited CS training (my own degrees are in
>chemistry, back from the days when I was doing large scale SP
>myself in crystalography). Now, with more people trained in
>CS and algorithms being interested in SP, the fields are much
>closer together, and it is in the interface that a lot of
>very interesting work is done 

I certainly don't have this impression when I look around me.
In the old days, most scientific programming was done in
Fortran and Lisp, then Algol, Pascal, Ada, and Prolog. (Cobol 
was never used in science). In addition, we could really
concentrate on solving the numerical aspect of the problem.

Now, since those CS guys came along,  C and Visual Basic
are mainstream and we have to spend most of your time
making nice user interfaces.

>(of course I am particularly aware of that due to my association 
>with the Courant Institute
>:-)

I should have known: you live in a priviledged environment :-).
What are the programming languages being used there?

	Andre

PS: I'm probably missing some very good things. I wouldn't be the
    the first time. For example, I didn't use OOP until I realized

    that this could free me from having to choose between adding new
    global variables (a bad thing) or having procedures with too many
    arguments (cumbersome). I now really enjoy using objects. What a
    wonderful paradigm!

Re: Ada vs Delphi?

[William Starner]

Andre Ratel wrote:
> 
> I am currently using Delphi (and Object Pascal) for my scientific
> programming. I heard a lot lately about Ada. From what I have
> seen, its syntax is very similar to Object Pascal. (This is no
> surprise since both languages are derived from Algol.)

Actually, IIRC, Ada was derived from Pascal, which explains much of the
similarity. The OO stuff developed independently, though.
 
> What would be the advantages of Ada over Delphi?

The advantages are:

(1) More consistent syntax - Ada was designed to be a large language, whereas
Delphi is a small language that grew.

(2) More portability - Delphi is not portable to anything but Windows without
major changes (depending - I don't know if gpc or Free Pascal could compile an
Object Pascal program that only used ISO I/O.) Ada is portable to almost
everything under the sun. 

(3) More scientific support - This one's a little iffy, but I believe there's
more support for Ada in the scientific world than Delphi.

(4) Better interfacing - Ada's designed to be compatible with the wealth of code
written in C and Fortran.

The primary disadvantage is that Ada doesn't have great GUI support. The best I
could mention would be GLADE & GtkAda, but GLADE's Unix only. I'm not aware of
any GUI-builders for Ada on Windows (though I'm sure the people who use Ada on
Windows will come up with some.)

Re: Ada vs Delphi?

[William Starner]

William Starner wrote:
> The primary disadvantage is that Ada doesn't have great GUI support. The best I
> could mention would be GLADE & GtkAda, but GLADE's Unix only. 

Correction - news of GtkAda & GLADE for Win32 just came across chat@gnat.com.
It's still probably not going to equal the support Delphi could give you.

Re: Ada vs Delphi?

[tmoran]

> I'm not aware of any GUI-builders for Ada on Windows ...
There's at least one for Gnat, one from Aonix for ObjectAda,
and one from RR Software for any Windows platform.  (Actually,
perhaps each will run on any platform?)

Re: Ada vs Delphi?

[Aidan Skinner]

On Sat, 07 Aug 1999 01:31:02 GMT, tmoran@bix.com <tmoran@bix.com> wrote:

>> I'm not aware of any GUI-builders for Ada on Windows ...
>There's at least one for Gnat, one from Aonix for ObjectAda,
>and one from RR Software for any Windows platform.  (Actually,
>perhaps each will run on any platform?)

GLADE, a GTK-based GPL'd GUI builder (http://glade.pn.org) should work
on anything with GTK ported (in theory). I don't know if anybody has
actually done so yet, but it shouldn't be too hard to port.

I don't think ObjectAda has a unix version.

- Aidan 
-- 
Gimme money, gimme sex, gimme UNIX and root access.
http://www.skinner.demon.co.uk/aidan/

Re: Ada vs Delphi?

[Gautier]

> I don't think ObjectAda has a unix version.

It does (HP, Sun) - not tested here (SGI...)

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada vs Delphi?

[Gautier]

> I am currently using Delphi (and Object Pascal) for my scientific
> programming. I heard a lot lately about Ada. From what I have
> seen, its syntax is very similar to Object Pascal. (This is no
> surprise since both languages are derived from Algol.)

> What would be the advantages of Ada over Delphi?

For scientific programming, the advantages are enormous:

- the language is standardized instead of proprietary;

- there are plenty of compilers;

- these compilers provide optimization;

- you can compile the same program on other platforms than Windows
  e.g. I'm using the same Finite Element library sources on
  a DEC Alpha for calculations and on a PC for post-processing
  and display;

- you can set the precision of floating-point types;
  you can obtain all limitations of floating-point types
  ('first, 'last, 'epsilon, ... attributes);

- you can define vectors, matrices etc. and operators on these objects;

- bounds of array are always available, in an elegant and easy way
  ('first, 'last, 'range attributes);

- generics allows you to program one thing for various usages,
  e.g. matrices with integer or floating-point componants;

a small example:

  function "*"(A:matrix; x:vector) return vector is
    r: field_elt;
    Ax: vector(A'range(1));
    begin
      if A'length(2)/=x'length then raise constraint_error; end if;
      for i in A'range(1) loop
        r:= zero;
        for j in x'range loop
            r:= r + A(i,j-x'first+A'first(2)) * x(j);
        end loop;
        Ax(i):= r;
      end loop;
      return Ax;
    end;


-- 
Gautier

--------
http://members.xoom.com/gdemont/