From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news2.euro.net!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!rz.uni-karlsruhe.de!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Newsgroups: comp.lang.eiffel,comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Tue, 21 Jul 2009 09:59:49 +0200 Message-ID: <19vb3fanruozp.kpikpepa685o.dlg@40tude.net> NNTP-Posting-Date: 21 Jul 2009 09:59:49 CEST NNTP-Posting-Host: eb8278f8.newsspool3.arcor-online.net X-Trace: DXC=^S[f[4Z:TeC6PJ?[X6JIXEMcF=Q^Z^V3H4Fo<]lROoRA^YC2XCjHcbIaQl;?6Gb3NODNcfSJ;bb[EIRnRBaCd On Mon, 20 Jul 2009 22:33:59 -0300, Cesar Rabak wrote: > Ludovic Brenta escreveu: >> Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada: >>> Nicholas Paul Collin Gloucester escreveu: >> [...] >>>> In this case there is a reason for having more types. An angle and a >>>> length are simply not interchangable, so they should not be >>>> represented both by Float. The amount of money equal to U.S.$1.00 is >>>> not equal to the amount of money equal to 1.00 Canadian dollar, but >>>> they are both written with the number 1.00. >>> I disagree strongly: an angle in radians is a real number as any other >>> there is not any intrinsic difference in its *type* on ordinary >>> Mathematics. Dimensionally they are 'pure numbers' with no unit >>> atached, your example on monetary units being fallacious, so non >>> sequitur. >> >> Ada is not a language for mathematicians (mathematicians would rather >> use e.g. Octave), it is a language for engineers. In engineering, >> there are very few pure numbers and quite a lot of dimensioned >> numbers. As an engineer, I certainly view angles, frequencies and >> dimensionless constants (e.g. correction factors) as all having >> different dimensions. > > Nice you bring this, Ludovic! However, remember the OP question: > > I'm a CS student and I often need to write number-crunching code dealing > with combinatorial optimization problems. > What I do usually is implementing ad-hoc algorithms and testing their > performance against other previously-known solutions, including general > solvers. > > > So your suggestion is to steer from Ada? I don't think that Ludovic's example with dimensioned values was a good argument. In fact there is no language with a good support of units. Ada is not an exception here. As for mathematics, Ada's type system is exactly right thing because it supports ADTs. Mathematician would never talk about floats, but reals, fields, rings etc. These mathematical structures are ADTs. An individual number without specifying the structure where it belongs to is meaningless in mathematics. The property of 1 of real and 1 of integer are different. This is what the notion of type is about. For number crunching it is even more important, because numerical methods deal with different models of numbers. Even if the domain set is say real (R), you might wish to consider to use something different than Long_Float, because Long_Float is just a model of R, which might turn unsuitable for your needs. Ada allows you to use various models, develop models of your own, and design algorithms in terms of a specific model, as well as generic ones in terms of some set of models. Another important aspect is strong typing, which allows you to concentrate on the problem rather than on debugging. Sometimes it is very difficult to debug scientific applications like number crunching, because in many cases you cannot tell whether the result is right. After all, the task of the application is to give a result. If you knew it, you would not need to crunch anything... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de