Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!mcvax!dik From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.lang.misc Subject: Re: Many people's opinions on computer languages Message-ID: <7649@boring.cwi.nl> Date: 23 Sep 88 22:32:24 GMT References: <3938@enea.se> <923@l.cc.purdue.edu> <382@quintus.UUCP><402@quintus.UUCP> <822@cernvax.UUCP> <8780@ihlpb.ATT.COM> Organization: CWI, Amsterdam Lines: 36 In article <8780@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes: > In article <822@cernvax.UUCP> hjm@cernvax.UUCP (Hubert Matthews) writes: > > >On a slightly less ethereal level, if Herman wants a 32 x 32 -> 64 multiply > >instruction, then I suggest that the real problem is not that the language > >doesn't let him specify this particular instruction, but that the language > >doesn't let him specify his data to a sufficiently high degree. > > That brings about the question: What is a sufficiently high degree of > precision? No matter what limit someone specifies for a given > implementation X, there is always someone who wants greater precision. There is a trade-off of course. I do not think there are many applications that require more than 100 digits of precision, but in the future? On the other hand, it is not exactly a question of not being able to specify your data to a sufficiently high degree. There is more involved. Just like a number of people would like to have a (function/operator) that returns both quotient and remainder of an integer division, it would be nice to have a (function/operator) that returns high order and low order part of a multiplication (which is available on many machines, the WE32000 being an exception). However, this is still not all you need for multiple precision arithmetic; how to write in a high level language the equivalent of: add *r0++,*r1++,*r2++ add first elements addc *r0++,*r1++,*r2++ add succesive elements with carry count1b count 1 and branch back so you need add and subtract that return carry bit also etc. In my opinion, when Herman wants to do efficient multiple precision arithmetic in a high level language, he is going the wrong way. At least with the current state of the art with high level languages. (And you open a whole new can of worms if you are going to look at vector processors.) -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax