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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham 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!tudelft.nl!txtfeed1.tudelft.nl!de-l.enfer-du-nord.net!gegeweb.org!aioe.org!not-for-mail From: Cesar Rabak Newsgroups: comp.lang.eiffel,comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Tue, 21 Jul 2009 11:45:30 -0300 Organization: Aioe.org NNTP Server Message-ID: References: <19vb3fanruozp.kpikpepa685o.dlg@40tude.net> NNTP-Posting-Host: CypMocAmQgU7ZoH9HGMqRg.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.7.9 X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message Cancel-Lock: sha1:Xu+C19mgGhzR9CQ6Z5Kr6hdMGVw= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Xref: g2news2.google.com comp.lang.eiffel:369 comp.lang.ada:7242 Date: 2009-07-21T11:45:30-03:00 List-Id: Dmitry A. Kazakov escreveu: > 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. > I agree. > 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 support for ADTs in Ada is appropriate for its primary use but for mathematics it is not enough, except if you don't care of coding a lot of boilerplate code to have all the consistency you'll need (see Ludovic's reply to my observation about I/O for example). > The property of 1 of real and 1 of integer are different. > This is what the notion of type is about. You did choose a very peculiar example :-) anyway for an [infinity] of values your assertion is reasonable true. > > 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. Ada here is not as suitable as other languages, which Lisp is a better example because Floats ultimately map to the underlying HW (a case of premature optimization), whereas it could store the number as rationals increasing accuracy and avoiding numerical instability. However, I agree if the OP is willing to develop the number crunching algorithms for similar languages (someone wrote in this thread 'Pascal like') them Ada is OK. > > 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... > After years working with both strong (and static) typed and more 'dynamic' ones, I disagree on this. Strong static typing plus the need of the signatures as we're discussing here brings a lot of artifacts that do not anything to do with the problem to be solved. For doing experimental work (here as opposed to, say, writing a library for publishing) I suggest all be done in a dynamic language.