* Ada vs Delphi? @ 1999-08-06 0:00 Andre Ratel 1999-08-06 0:00 ` William Starner ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 Ada vs Delphi? Andre Ratel @ 1999-08-06 0:00 ` William Starner 1999-08-06 0:00 ` William Starner 1999-08-07 0:00 ` tmoran 1999-08-06 0:00 ` Steve Doiel 1999-08-07 0:00 ` Ada vs Delphi? Gautier 2 siblings, 2 replies; 49+ messages in thread From: William Starner @ 1999-08-06 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 ` William Starner @ 1999-08-06 0:00 ` William Starner 1999-08-07 0:00 ` tmoran 1 sibling, 0 replies; 49+ messages in thread From: William Starner @ 1999-08-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 ` William Starner 1999-08-06 0:00 ` William Starner @ 1999-08-07 0:00 ` tmoran 1999-08-07 0:00 ` Aidan Skinner 1 sibling, 1 reply; 49+ messages in thread From: tmoran @ 1999-08-07 0:00 UTC (permalink / raw) > 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?) ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-07 0:00 ` tmoran @ 1999-08-07 0:00 ` Aidan Skinner 1999-08-07 0:00 ` Gautier 0 siblings, 1 reply; 49+ messages in thread From: Aidan Skinner @ 1999-08-07 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-07 0:00 ` Aidan Skinner @ 1999-08-07 0:00 ` Gautier 0 siblings, 0 replies; 49+ messages in thread From: Gautier @ 1999-08-07 0:00 UTC (permalink / raw) > I don't think ObjectAda has a unix version. It does (HP, Sun) - not tested here (SGI...) -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 Ada vs Delphi? Andre Ratel 1999-08-06 0:00 ` William Starner @ 1999-08-06 0:00 ` Steve Doiel 1999-08-09 0:00 ` Paul Groves 1999-08-07 0:00 ` Ada vs Delphi? Gautier 2 siblings, 1 reply; 49+ messages in thread From: Steve Doiel @ 1999-08-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 ` Steve Doiel @ 1999-08-09 0:00 ` Paul Groves 1999-08-08 0:00 ` Steve Doiel ` (6 more replies) 0 siblings, 7 replies; 49+ messages in thread From: Paul Groves @ 1999-08-09 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves @ 1999-08-08 0:00 ` Steve Doiel 1999-08-10 0:00 ` Ray Blaak 1999-08-09 0:00 ` Gautier ` (5 subsequent siblings) 6 siblings, 1 reply; 49+ messages in thread From: Steve Doiel @ 1999-08-08 0:00 UTC (permalink / raw) >>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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-08 0:00 ` Steve Doiel @ 1999-08-10 0:00 ` Ray Blaak 1999-08-10 0:00 ` Steve Doiel 0 siblings, 1 reply; 49+ messages in thread From: Ray Blaak @ 1999-08-10 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-10 0:00 ` Ray Blaak @ 1999-08-10 0:00 ` Steve Doiel 1999-08-14 0:00 ` Andre Ratel 0 siblings, 1 reply; 49+ messages in thread From: Steve Doiel @ 1999-08-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-10 0:00 ` Steve Doiel @ 1999-08-14 0:00 ` Andre Ratel 0 siblings, 0 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves 1999-08-08 0:00 ` Steve Doiel @ 1999-08-09 0:00 ` Gautier 1999-08-11 0:00 ` Andre Ratel 1999-08-09 0:00 ` Aidan Skinner ` (4 subsequent siblings) 6 siblings, 1 reply; 49+ messages in thread From: Gautier @ 1999-08-09 0:00 UTC (permalink / raw) > > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Gautier @ 1999-08-11 0:00 ` Andre Ratel 1999-08-12 0:00 ` Gautier 1999-08-12 0:00 ` Gautier 0 siblings, 2 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-11 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Andre Ratel @ 1999-08-12 0:00 ` Gautier 1999-08-12 0:00 ` Gautier 1 sibling, 0 replies; 49+ messages in thread From: Gautier @ 1999-08-12 0:00 UTC (permalink / raw) > "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Andre Ratel 1999-08-12 0:00 ` Gautier @ 1999-08-12 0:00 ` Gautier 1999-08-14 0:00 ` Andre Ratel 1 sibling, 1 reply; 49+ messages in thread From: Gautier @ 1999-08-12 0:00 UTC (permalink / raw) To: Andre Ratel > {$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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-12 0:00 ` Gautier @ 1999-08-14 0:00 ` Andre Ratel 1999-08-14 0:00 ` Gautier ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Andre Ratel @ 1999-08-14 0:00 ` Gautier 1999-08-16 0:00 ` Gautier 1999-08-15 0:00 ` Steve Doiel 1999-08-17 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 49+ messages in thread From: Gautier @ 1999-08-14 0:00 UTC (permalink / raw) To: Andre Ratel > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Gautier @ 1999-08-16 0:00 ` Gautier 0 siblings, 0 replies; 49+ messages in thread From: Gautier @ 1999-08-16 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Andre Ratel 1999-08-14 0:00 ` Gautier @ 1999-08-15 0:00 ` Steve Doiel 1999-08-17 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 49+ messages in thread From: Steve Doiel @ 1999-08-15 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Andre Ratel 1999-08-14 0:00 ` Gautier 1999-08-15 0:00 ` Steve Doiel @ 1999-08-17 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 49+ messages in thread From: Robert I. Eachus @ 1999-08-17 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves 1999-08-08 0:00 ` Steve Doiel 1999-08-09 0:00 ` Gautier @ 1999-08-09 0:00 ` Aidan Skinner 1999-08-09 0:00 ` Robert Dewar ` (3 subsequent siblings) 6 siblings, 0 replies; 49+ messages in thread From: Aidan Skinner @ 1999-08-09 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves ` (2 preceding siblings ...) 1999-08-09 0:00 ` Aidan Skinner @ 1999-08-09 0:00 ` Robert Dewar 1999-08-09 0:00 ` Robert Dewar ` (2 subsequent siblings) 6 siblings, 0 replies; 49+ messages in thread From: Robert Dewar @ 1999-08-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves ` (3 preceding siblings ...) 1999-08-09 0:00 ` Robert Dewar @ 1999-08-09 0:00 ` Robert Dewar 1999-08-11 0:00 ` Andre Ratel 1999-08-10 0:00 ` Brian Rogoff 1999-08-11 0:00 ` Ada vs Delphi? Andre Ratel 6 siblings, 1 reply; 49+ messages in thread From: Robert Dewar @ 1999-08-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-11 0:00 UTC (permalink / raw) -= 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Andre Ratel @ 1999-08-11 0:00 ` Robert Dewar 1999-08-14 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Ted Dennison 2 siblings, 1 reply; 49+ messages in thread From: Robert Dewar @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Robert Dewar @ 1999-08-14 0:00 ` Andre Ratel 1999-08-17 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Andre Ratel @ 1999-08-17 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 49+ messages in thread From: Robert I. Eachus @ 1999-08-17 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` David Botton 1999-08-14 0:00 ` Andre Ratel 1999-08-11 0:00 ` Ted Dennison 2 siblings, 2 replies; 49+ messages in thread From: Robert Dewar @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` David Botton 1999-08-14 0:00 ` Andre Ratel 1 sibling, 0 replies; 49+ messages in thread From: David Botton @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` David Botton @ 1999-08-14 0:00 ` Andre Ratel 1 sibling, 0 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Ted Dennison 1999-08-14 0:00 ` Andre Ratel 2 siblings, 1 reply; 49+ messages in thread From: Ted Dennison @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Ted Dennison @ 1999-08-14 0:00 ` Andre Ratel 1999-08-16 0:00 ` Ted Dennison 0 siblings, 1 reply; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-14 0:00 ` Andre Ratel @ 1999-08-16 0:00 ` Ted Dennison 0 siblings, 0 replies; 49+ messages in thread From: Ted Dennison @ 1999-08-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves ` (4 preceding siblings ...) 1999-08-09 0:00 ` Robert Dewar @ 1999-08-10 0:00 ` Brian Rogoff 1999-08-11 0:00 ` Scientific calculations (was Re: Ada vs Delphi? ) Vladimir Olensky 1999-08-11 0:00 ` Ada vs Delphi? Andre Ratel 6 siblings, 1 reply; 49+ messages in thread From: Brian Rogoff @ 1999-08-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-10 0:00 ` Brian Rogoff @ 1999-08-11 0:00 ` Vladimir Olensky 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Robert Dewar 0 siblings, 2 replies; 49+ messages in thread From: Vladimir Olensky @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-11 0:00 ` Scientific calculations (was Re: Ada vs Delphi? ) Vladimir Olensky @ 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Robert Dewar 1 sibling, 0 replies; 49+ messages in thread From: Robert Dewar @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-11 0:00 ` Scientific calculations (was Re: Ada vs Delphi? ) Vladimir Olensky 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Vladimir Olensky 1 sibling, 1 reply; 49+ messages in thread From: Robert Dewar @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Vladimir Olensky 1999-08-13 0:00 ` Robert Dewar 1999-08-13 0:00 ` Gautier 0 siblings, 2 replies; 49+ messages in thread From: Vladimir Olensky @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-11 0:00 ` Vladimir Olensky @ 1999-08-13 0:00 ` Robert Dewar 1999-08-13 0:00 ` Brian Rogoff 1999-08-15 0:00 ` Vladimir Olensky 1999-08-13 0:00 ` Gautier 1 sibling, 2 replies; 49+ messages in thread From: Robert Dewar @ 1999-08-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-13 0:00 ` Robert Dewar @ 1999-08-13 0:00 ` Brian Rogoff 1999-08-15 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 49+ messages in thread From: Brian Rogoff @ 1999-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-13 0:00 ` Robert Dewar 1999-08-13 0:00 ` Brian Rogoff @ 1999-08-15 0:00 ` Vladimir Olensky 1999-08-15 0:00 ` Vladimir Olensky 1 sibling, 1 reply; 49+ messages in thread From: Vladimir Olensky @ 1999-08-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-15 0:00 ` Vladimir Olensky @ 1999-08-15 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 49+ messages in thread From: Vladimir Olensky @ 1999-08-15 0:00 UTC (permalink / raw) 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; } ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Scientific calculations (was Re: Ada vs Delphi? ) 1999-08-11 0:00 ` Vladimir Olensky 1999-08-13 0:00 ` Robert Dewar @ 1999-08-13 0:00 ` Gautier 1 sibling, 0 replies; 49+ messages in thread From: Gautier @ 1999-08-13 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-09 0:00 ` Paul Groves ` (5 preceding siblings ...) 1999-08-10 0:00 ` Brian Rogoff @ 1999-08-11 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Ada vs Component Pascal (was: Ada vs Delphi?) Ted Dennison 6 siblings, 2 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-11 0:00 UTC (permalink / raw) -= 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Ada vs Delphi? Andre Ratel @ 1999-08-11 0:00 ` Robert Dewar 1999-08-14 0:00 ` Andre Ratel 1999-08-11 0:00 ` Ada vs Component Pascal (was: Ada vs Delphi?) Ted Dennison 1 sibling, 1 reply; 49+ messages in thread From: Robert Dewar @ 1999-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-11 0:00 ` Robert Dewar @ 1999-08-14 0:00 ` Andre Ratel 0 siblings, 0 replies; 49+ messages in thread From: Andre Ratel @ 1999-08-14 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Ada vs Component Pascal (was: Ada vs Delphi?) 1999-08-11 0:00 ` Ada vs Delphi? Andre Ratel 1999-08-11 0:00 ` Robert Dewar @ 1999-08-11 0:00 ` Ted Dennison 1 sibling, 0 replies; 49+ messages in thread From: Ted Dennison @ 1999-08-11 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ada vs Delphi? 1999-08-06 0:00 Ada vs Delphi? Andre Ratel 1999-08-06 0:00 ` William Starner 1999-08-06 0:00 ` Steve Doiel @ 1999-08-07 0:00 ` Gautier 2 siblings, 0 replies; 49+ messages in thread From: Gautier @ 1999-08-07 0:00 UTC (permalink / raw) To: 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? 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~1999-08-17 0:00 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-08-06 0:00 Ada vs Delphi? Andre Ratel 1999-08-06 0:00 ` William Starner 1999-08-06 0:00 ` William Starner 1999-08-07 0:00 ` tmoran 1999-08-07 0:00 ` Aidan Skinner 1999-08-07 0:00 ` Gautier 1999-08-06 0:00 ` Steve Doiel 1999-08-09 0:00 ` Paul Groves 1999-08-08 0:00 ` Steve Doiel 1999-08-10 0:00 ` Ray Blaak 1999-08-10 0:00 ` Steve Doiel 1999-08-14 0:00 ` Andre Ratel 1999-08-09 0:00 ` Gautier 1999-08-11 0:00 ` Andre Ratel 1999-08-12 0:00 ` Gautier 1999-08-12 0:00 ` Gautier 1999-08-14 0:00 ` Andre Ratel 1999-08-14 0:00 ` Gautier 1999-08-16 0:00 ` Gautier 1999-08-15 0:00 ` Steve Doiel 1999-08-17 0:00 ` Robert I. Eachus 1999-08-09 0:00 ` Aidan Skinner 1999-08-09 0:00 ` Robert Dewar 1999-08-09 0:00 ` Robert Dewar 1999-08-11 0:00 ` Andre Ratel 1999-08-11 0:00 ` Robert Dewar 1999-08-14 0:00 ` Andre Ratel 1999-08-17 0:00 ` Robert I. Eachus 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` David Botton 1999-08-14 0:00 ` Andre Ratel 1999-08-11 0:00 ` Ted Dennison 1999-08-14 0:00 ` Andre Ratel 1999-08-16 0:00 ` Ted Dennison 1999-08-10 0:00 ` Brian Rogoff 1999-08-11 0:00 ` Scientific calculations (was Re: Ada vs Delphi? ) Vladimir Olensky 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Robert Dewar 1999-08-11 0:00 ` Vladimir Olensky 1999-08-13 0:00 ` Robert Dewar 1999-08-13 0:00 ` Brian Rogoff 1999-08-15 0:00 ` Vladimir Olensky 1999-08-15 0:00 ` Vladimir Olensky 1999-08-13 0:00 ` Gautier 1999-08-11 0:00 ` Ada vs Delphi? Andre Ratel 1999-08-11 0:00 ` Robert Dewar 1999-08-14 0:00 ` Andre Ratel 1999-08-11 0:00 ` Ada vs Component Pascal (was: Ada vs Delphi?) Ted Dennison 1999-08-07 0:00 ` Ada vs Delphi? Gautier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox