Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (04/20/91)
Today, I was trying to implement a fixed-point math module in M2, containing routines like Add, Sub, Mul, Div, etc. Using these routines really clutters your source with statements like: a := Add(Mul(b,c),d); in stead of the more readable: a := b*c+d; So what are people's opinions about adding operator overloading in M2? Best regards, Ben -- uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org
george@m2xenix.psg.com (George Emery) (04/23/91)
>containing routines like Add, Sub, Mul, Div, etc. Using these routines >really clutters your source with statements like: > > a := Add(Mul(b,c),d); > >in stead of the more readable: > > a := b*c+d; > Whenever I've written fixed point routines, I've always scaled INTEGERS and LONGINTs when printing. The advantage is that you can still use +, -, *, / in the normal fashion. You then merely need to remember to use the correct i/o routines. [Perhaps this is a good example of why we shouldn't have standard i/o packages?]
warwick@cs.uq.oz.au (Warwick Allison) (04/24/91)
>Today, I was trying to implement a fixed-point math module in M2, >containing routines like Add, Sub, Mul, Div, etc. Using these routines >really clutters your source with statements like: > a := Add(Mul(b,c),d); >instead of the more readable: > a := b*c+d; If you have TYPE FIXED=INTEGER; then + and - work fine, so you don't need Add & Sub, but Mul and Div require shifting. Pity Modula-2 doesn't have Ada-like facilities for infix operators. Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (04/27/91)
GE> Whenever I've written fixed point routines, I've always scaled GE> INTEGERS and LONGINTs when printing. The advantage is that you can GE> still use +, -, *, / in the normal fashion. You then merely need to GE> remember to use the correct i/o routines. [Perhaps this is a good GE> example of why we shouldn't have standard i/o packages?] Well, this won't work in all cases, and that's why I've started to encapsulate the fixed point routines in a separate module. Suppose that one uses a +/- 7.8 bit representation for a fixed point number. In this case, the fixed point number 1.0 will be represented by the 16 bit integer 256. Now we want to multiply 1.0 times 1.0. One could write this as: fix1 := 256; fix2 := 256; fix3 := (LONG(fix1) * LONG(fix2)) DIV 256; You cannot simply use (assuming you have 16-bit INTEGERs): fix3 := (fix1 * fix2) DIV 256; as this would cause an overflow during the multiplication. Furthermore, I think my original solution is more readable: fix3 := Mul(fix1, fix2); Althoug, again, operator overloading would make the even nicer: fix3 := fix1 * fix2; The same problem obviously applies to division and also to other representations for fixed point numbers like +/-.15 bit. Best regards, Ben -- uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org
Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (04/27/91)
>> a := Add(Mul(b,c),d); >> instead of the more readable: >> a := b*c+d; WA> WA> If you have WA> WA> TYPE FIXED=INTEGER; WA> WA> then + and - work fine, so you don't need Add & Sub, but Mul and WA> Div require shifting. Well, as I stated in a message to George Emery, the problem is not only the shifting, but also the possiblity of overflow. Furthermore, putting all my routines in a single fixed point module enable me to play a bit with different representations of fixed point numbers. This enables me to get optimum range and accuracy in my particular program. (I hope. B-)) Best regards, Ben -- uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org
george@m2xenix.psg.com (George Emery) (04/30/91)
Ben Stuyts writes: > GE> INTEGERS and LONGINTs when printing. The advantage is that you can > GE> still use +, -, *, / in the normal fashion. You then merely need to > GE> remember to use the correct i/o routines. [Perhaps this is a good > GE> example of why we shouldn't have standard i/o packages?] > >Well, this won't work in all cases, and that's why I've started to >encapsulate the fixed point routines in a separate module. Suppose that >one uses a +/- 7.8 bit representation for a fixed point number. In this >case, the fixed point number 1.0 will be represented by the 16 bit >integer 256. Now we want to multiply 1.0 times 1.0. One could write this >as: > > fix1 := 256; > fix2 := 256; > > fix3 := (LONG(fix1) * LONG(fix2)) DIV 256; > >You cannot simply use (assuming you have 16-bit INTEGERs): > > fix3 := (fix1 * fix2) DIV 256; > >as this would cause an overflow during the multiplication. So then you'd use LONGINT... Actually, I'm a little confused about each other's intentions. For fixed point, I was thinking of scaling for decimal representation, not binary as your example implies. I agree, however, that it sometimes is inconvenient to not have customary operators available. On the other hand, it is seldom, with simple numeric representations, necessary to go outside of what is already provided by the language. >The same problem obviously applies to division and also to other >representations for fixed point numbers like +/-.15 bit. Again, I think we're thinking of different ideas here. My understanding of fixed point numbers is that if you're trying to divide by a fraction of a bit, then you've picked the wrong range or you must represent the fraction-of-a-bit as a continued fraction approximation. Could you enlighten me? george@m2xenix.psg.com
timm@sed.novell.com (Tim Myers) (04/30/91)
In article <209.2812FBE7@puddle.fidonet.org> Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) writes: > So what are people's opinions about adding operator overloading in M2? I think it can improve the readability of programs when it is used properly. Thomas Boyer at Brigham Young University wrote a thesis on how he successfully implemented operator overloading in a Modula-2 compiler. ++Tim ========================================= Tim Myers Senior Software Consultant Novell, Inc. "Macintosh: the only GUI that doesn't SUCK."
Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (05/06/91)
>> You cannot simply use (assuming you have 16-bit INTEGERs): >> >> fix3 := (fix1 * fix2) DIV 256; >> >> as this would cause an overflow during the multiplication. GE> GE> So then you'd use LONGINT... I could, but don't really want to because of the performance penalty. The only reason I'd have for using LONGINT's would be to have better precision. For example, assuming 32-bit LONGINT's, I could use a +/- .31 representation. Again, this would cause overflows in certain situations. GE> Actually, I'm a little confused about each other's intentions. GE> For fixed point, I was thinking of scaling for decimal representation, GE> not binary as your example implies. Correct, I am looking at binary representations. More or less based on those of DSP's, so that it would be easy to convert all this stuff over to a DSP. GE> I agree, however, that it sometimes is inconvenient to not have GE> customary operators available. On the other hand, it is seldom, GE> with simple numeric representations, necessary to go outside of GE> what is already provided by the language. Well, it doesn't really matter if you talk about fixed point numbers or, for example, complex numbers. Yet in the case of complex numbers, the powers that be have opted to incorporate them into the language. It seems to me that adding operator overloading would have been a solution to *both* problems. >> The same problem obviously applies to division and also to other >> representations for fixed point numbers like +/-.15 bit. GE> GE> Again, I think we're thinking of different ideas here. My GE> understanding of fixed point numbers is that if you're trying to GE> divide by a fraction of a bit, then you've picked the wrong range or GE> you must represent the fraction-of-a-bit as a continued fraction GE> approximation. GE> Could you enlighten me? What do you mean by dividing by a fraction of a bit? What is so uncommon about division of fixed point numbers? It is particularly important for fixed point arithmatic to be able to scale the numbers properly. The only generic ways I know to do this are by division or multiplication. Best regards, Ben -- uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org
Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (05/06/91)
>> So what are people's opinions about adding operator overloading in >> M2? TM> TM> I think it can improve the readability of programs when it is used TM> properly. TM> TM> Thomas Boyer at Brigham Young University wrote a thesis on how he TM> successfully TM> implemented operator overloading in a Modula-2 compiler. That is very interesting. Could you please give me the title of that thesis? Best regards, Ben -- uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org