hrubin@pop.stat.purdue.edu (Herman Rubin) (02/21/91)
In article <9102210042.AA12291@ucbvax.Berkeley.EDU>, JBS@IBM.COM writes: > > Herman Rubin says: > Do you mean to tell me that computations involving both integers and > floating-point numbers are not important? Or that dividing floats by > floats, obtaining an integer quotient and a floating remainder, likewise? > That particular step is the first step of any trigonometric or exponential > function computation when it is not known in advance that the argument is > small. There are other periodic and related functions for which this is > useful. It would also speed up interpolation, etc. > > Since argument reduction for the trigonometric functions is > done in practice by multiplying by 1/pi I do not see how it would ben- > efit from your proposed instruction. I believe this instruction would > have little general utility. There is somewhat greater loss of accuracy in this, and it is still needed to extract the integer part to an integer register and the fractional part. Thus, it needs at least three operations, instead of one. Also, if one is calculating something like x - ln(1+x), a natural operation in certain problems, the computing problems become a little larger than one would expect. In fact, to avoid a loss of accuracy in some quite usual situations, it would even be a good idea to have Boolean operations on floats, and unnormalized floating arithmetic. Floating arithmetic, apart from some preliminaries, and normalization problems, is exactly the same as integer, so why should there be a separate arithmetic unit even? > An efficient way to do the fortran "x=dint(y)" is important. > This is lacking on the Risc System 6000 as was pointed out in a Los > Alamos report. By the way is it true that it is impossible to > reasonably express this in ADA? > Peter Montgomery says: > Yes, most programs are written in these languages. > As Dan says, the language designers made mistakes. During one > review period for Fortran 90, I requested an operation which > takes four nonnegative integers a, b, c, n with > a < n or b < n (c is optional and defaults to 0). > The requested operation returns q and/or r, where > > a*b + c = q*n + r and 0 <= r < n > > Why didn't you ask for an integer*8 data type? Wouldn't > that give you what you want and have much more general utility? Yes and no. It would have much more general utility, but it would do an abysmally inefficient job in this situation. You would need to have a way of indicating that the product of two integers*4 is an integer*8, which I do not know how to do in any language with which I am familiar without writing it as a function, and I do not think that one should have to write mult48(a,b) instead of a*b. In addition, how would you write the operation which, when applied to a*b+c and n, yields both q and r? Is the reason why it is difficult to get double length multiplication, and division with quotient and remainder, that the language designers left these out, and then the As far as adding this type, why not allow the user to add any type? This was present for up to three additional types on Fortran VI(?) on the CDC3600. > I would like an instruction which counts the number of ones in > the binary representation of an integer but I find it hard to argue > that this would be widely used. Cray seems to find this one important enough to include on his machines, which have a real paucity of instructions. I think you will find that those who want to add "bizarre" instructions in both hardware and software to do what the present stuff does not do well understand the problems of both, and have some idea of what is feasible at reasonable cost. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/25/91)
In article <9102220245.AA14853@ucbvax.Berkeley.EDU>, JBS@IBM.COM writes: ................ > Regarding a function to get a the 8 byte product of 2 > 4 byte integers I don't see why this is any worse than Montgomery's > function. In any case it is not needed. Let i4,j4 be 4 byte > i8,j8,k8 be 8 byte. Then write > i8=i4 > j8=j4 > k8=i8*j8 > A sufficiently intelligent compiler will do the right thing. It may > work to write > k8=i4*j4 > This sometimes works in the analogous case where k8 is 4 byte and i4 > and j4 are 2 bytes. However I am not sure strictly speaking that it > should. What does the Fortran standard say? The first approach would require a very intelligent compiler, indeed. The second approach is the "right" one. However, every standard I have read would try the first. Since i8*j8 might not even exist on the machine, at best an inlined function would have to be brought in instead of the single hardware instruction for k8=i4*j4. I have never seen any language description in which the type of the result in a replacement statement affected what operation is performed. The closest I know is the C format, which may or may not work, k8 = (*int8)i4*j4. > As for getting both q and r this is easy just write > iq=ia/ib > ir=mod(ia,ib) > A reasonable compiler will only generate 1 divide with remainder. > I will confess however that while this works when everything is > 4 bytes I don't quite see how to make it work when ia is 8 bytes > (since it seems unreasonable to define the quotient of a 8 byte > integer by a 4 byte integer to be 4 bytes and if it is defined > to be 8 bytes it is then unsafe to use the usual 8 byte by 4 byte > giving 4 byte quotient instruction). > James B. Shearer I do not see why the case of ia being 8 bits is any worse. Sure, there is the problem of overflow, but so what? Also, it should not be ever necessary to do something as complicated as the mod(ia,ib) notation for basic operators, or even not so basic, and more than it should be necessary to write add(a,b) for a+b. But what is really needed in notation is something like iq,ir = ia/ib. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
john@mingus.mitre.org (John D. Burger) (02/26/91)
hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > I have never seen any language description in which the type of the > result in a replacement statement affected what operation is > performed. In Common Lisp, the assignment operator is SETF. One can write SETF methods specialized on the types of the various entities involved in the assignment, including the value being assigned. For example, imagine that I have implemented PERSON objects, which have a NAME attribute. This is meant to be a string. I retrieve the name of a person with an expression like: (PERSON-NAME P1) and I set the name of a person in the following way: (SETF (PERSON-NAME P1) "fred") As I said, the name of a person is a string, but perhaps, for convenience, I want to be able to do the following: (SETF (PERSON-NAME P1) 'FRED) where FRED is a Lisp symbol, not a string. What I can do is write a SETF method for PERSON-NAME that specializes on the symbol type and turns the symbol into a string. (DEFMETHOD (SETF PERSON-NAME) ((NEW-NAME SYMBOL) (P PERSON)) (SETF (PERSON-NAME P) (SYMBOL-NAME NEW-NAME))) Forget the syntax, the short story is that this method will get called whenever an expression like (SETF (PERSON-NAME X) Y) is evaluated and X is a PERSON and Y is a SYMBOL. -- John Burger john@mitre.org "You ever think about .signature files? I mean, do we really need them?" - alt.andy.rooney
tom@nw.stl.stc.co.uk (03/01/91)
> I have never seen any language description in which the type of the > result in a replacement statement affected what operation is > performed. There are quite a few such languages. In the dialect of Algol we use here for writing operating systems (and much else) it's easy to give an example. Let's suppose that R1 and R2 are floating point variables, and I1 and I2 are integer variables. Now look at two statements A: R1:= I2+R2 B: I1:= I2+R2 These are replacement statements. The type of the result in the first is float, in the second it's integer. In the first I2 is floated and a floating point add performed. In the second R2 is fixed and an integer addition is performed. Given the ranges allowed for integer and float and the different ways precision may be lost, it seems reasonable to consider the two operations radically different (they even have different failures). This sort of thing arises in every language I know which has implicit coercions. Even in Fortran:- 1 I1 = I2 2 R1 = I2 the statements 1 and two perform different operations (copy and float respectively) just because the result type is different. So what is Prof Rubin trying to say here? Obviously not what he said (he knows Fortran well enough to know that happens). Tom Thomson [tom@nw.stl.stc.co.uk International Computers Ltd, Manchester M12 5DR, UK