434,587 Members | 1,047 Online + Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,587 IT Pros & Developers. It's quick & easy.

range vs precisionC

 P: n/a What is the difference between range and precision in c? Also, if c doesn't support fixed point numbers, how is the addition of two integers possible? Chad Apr 16 '06 #1
32 Replies

 P: n/a "Chad" writes: What is the difference between range and precision in c? Range refers to the ability to represent very large or very small numbers in the same datum. Say a variable of type double, x sometimes was the distance between a proton and an electron and also the distance from the sun to some distant galaxy. Floating point numbers are approximations of the infinite number of points on the real number line; precision has to do with how good that approximation is. See this for more: http://en.wikipedia.org/wiki/Floating_point You can find the key factoids about your particular installation by examining the constants in Also, if c doesn't support fixed point numbers, how is the addition of two integers possible? The binary point is taken to be immediately to the right of the least significant binary digit (bit). The tools are there to improve on that if that doesn't please you. Apr 16 '06 #2

 P: n/a Chad wrote: What is the difference between range and precision in c? Also, if c doesn't support fixed point numbers, how is the addition of two integers possible? The range of a type is the span of values it can represent. An `int', for example, has a range of at least -32767 through +32767, perhaps more. The precision of a type is the granularity with which it divides up its range. The `int' can represent values to a precision of one unit, but cannot represent half a unit or a tenth of a unit. For floating-point types the granularity varies with the magnitude of the value, so it is customary to state the precision in relative rather than absolute terms: so-and-so many digits rather than plus-or-minus so-and-so much. (Don't confuse precision with accuracy. If I say that the square root of two is 2.7182818284590452353602874713527 I have made a statement that is extremely precise but wildly inaccurate.) The addition of integers is possible because C knows how to add integers. If that's not a satisfactory answer, you'll need to explain your doubts more clearly: Why do you think fixed-point arithmetic is involved in any way? -- Eric Sosman es*****@acm-dot-org.invalid Apr 16 '06 #3

 P: n/a > The addition of integers is possible because C knows how to add integers. If that's not a satisfactory answer, you'll need to explain your doubts more clearly: Why do you think fixed-point arithmetic is involved in any way? -- Eric Sosman es*****@acm-dot-org.invalid On another site, I had a question about converting floating point to binary and back. Anyhow, during this lecture, I had someone tell me that fixed-point and floating-point where two different things. This was something I wasn't aware of. After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. Hence, the questions. Chad Apr 16 '06 #4

 P: n/a Chad wrote: The addition of integers is possible because C knows how to add integers. If that's not a satisfactory answer, you'll need to explain your doubts more clearly: Why do you think fixed-point arithmetic is involved in any way? Eric Sosman On another site, I had a question about converting floating point to binary and back. Anyhow, during this lecture, I had someone tell me that fixed-point and floating-point were two different things. This was something I wasn't aware of. After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. Hence, the questions. Chad I think fixed-point arithmetic can have more than one meaning. In one sense, C supports fixed-point arithmetic, with the point fixed at the least significant end of the machine word. But descriptions of old algorithms suggest that there used to be another meaning, more like scaled, where the programmer would decide that his machine word represented say 20 integer bits and 12 fraction bits. This just means a shift after each multiplication, but as a concept it's quite different from integer or floating-point. I don't know whether there was ever any support for the practice of this concept, either in old hardware or in a programming language. -- Apr 16 '06 #5

 P: n/a "Chad" writes: On another site, I had a question about converting floating point to binary and back. Anyhow, during this lecture, I had someone tell me that fixed-point and floating-point where two different things. This was something I wasn't aware of. After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. Hence, the questions. I remeber that thread. The guy who kept that thread alive said this in message 11. --- clip---- Wow that Klien guy [Jack Klien] is so ignorant, I can't believe he is employed. lmfao, I used to do fixed point arithmetic on 16 bit architecture, there was no way you could squeeze out the accuracy and performance with BCD. I was not alone other people that wrote similar functions did not try either. BCD was invented by ignorants. ---- clip---- The guy lost any credibility he had when he insulted Jack Klein like that. That is not a typo or a premature send. That is a planned response. If you want to pursue fixed point, take a look at this. http://www.answers.com/fixed-point&r=67 Apr 16 '06 #6

 P: n/a Eric Sosman wrote: (Don't confuse precision with accuracy. If I say that the square root of two is 2.7182818284590452353602874713527 I have made a statement that is extremely precise but wildly inaccurate.) Samuel Johnson, who wrote the famous dictionary, and who was known for his careful use of language, once asked a woman her age. She replied that she was 25 and a half. Dr. Johnson observed that her answer was "very precise, but not very accurate." JS Apr 16 '06 #7

 P: n/a "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. But you can implement fixed-point arithmetic in C; for example, the instructions for one part of an operating system project that I wrote explain how to do so: http://www.stanford.edu/class/cs140/...l%20Arithmetic -- "It would be a much better example of undefined behavior if the behavior were undefined." --Michael Rubenstein Apr 16 '06 #8

 P: n/a Ben Pfaff wrote: "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. But you can implement fixed-point arithmetic in C; for example, the instructions for one part of an operating system project that I wrote explain how to do so: http://www.stanford.edu/class/cs140/...l%20Arithmetic The only time you would need fixed-point numbers is when you are outputting. printf does support fixed point, I believe. In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. Apr 16 '06 #9

 P: n/a Andrew Poelstra writes: Ben Pfaff wrote: "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. But you can implement fixed-point arithmetic in C; for example, the instructions for one part of an operating system project that I wrote explain how to do so: http://www.stanford.edu/class/cs140/...l%20Arithmetic The only time you would need fixed-point numbers is when you are outputting. How do you propose to do fixed-point multiplication and division without some kind of fix-up? printf does support fixed point, I believe. I don't understand what you mean by that. In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. I think you're wrong. -- "Some programming practices beg for errors; this one is like calling an 800 number and having errors delivered to your door." --Steve McConnell Apr 16 '06 #10

 P: n/a "bert" writes: [...] I think fixed-point arithmetic can have more than one meaning. In one sense, C supports fixed-point arithmetic, with the point fixed at the least significant end of the machine word. But descriptions of old algorithms suggest that there used to be another meaning, more like scaled, where the programmer would decide that his machine word represented say 20 integer bits and 12 fraction bits. This just means a shift after each multiplication, but as a concept it's quite different from integer or floating-point. I don't know whether there was ever any support for the practice of this concept, either in old hardware or in a programming language. A number of languages have direct support for fixed-point arithmetic. (Ada is one of them; I think PL/I is another.) No particular hardware support is needed; addition and subtraction work exactly like integer addition and subtraction, and muliplication and division just require a scaling operation. It's easily emulated in other languages; building support into a language gives you numeric literals and a convenient syntax for declaring fixed-point types. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 16 '06 #11

 P: n/a Andrew Poelstra writes: Ben Pfaff wrote: "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. But you can implement fixed-point arithmetic in C; for example, the instructions for one part of an operating system project that I wrote explain how to do so: http://www.stanford.edu/class/cs140/...l%20Arithmetic The only time you would need fixed-point numbers is when you are outputting. printf does support fixed point, I believe. In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. Incorrect. Fixed-point has arithmetic properties that are very different from those of floating-point, properties that can be quite useful in some circumstances. For example, fixed-point with a scale factor of 100 lets you do precise calculations with money; floating-point introduces rounding errors, because 0.01 can't be represented exactly in binary. (Some monetary calculations, such as interest calculations, might yield results that require better precision than 0.01, but that's another topic.) -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 16 '06 #12

 P: n/a Keith Thompson wrote: "bert" writes:I think fixed-point arithmetic can have more than one meaning. Inone sense, C supports fixed-point arithmetic, with the point fixedat the least significant end of the machine word. But descriptionsof old algorithms suggest that there used to be another meaning,more like scaled, where the programmer would decide that hismachine word represented say 20 integer bits and 12 fractionbits. In both cases the meaning is the same: the binary point is fixed for a particular variable. Integer arithmetic is indeed fixed point. It is limited in that the user cannot specify the location of the binary point. A number of languages have direct support for fixed-point arithmetic. (Ada is one of them; I think PL/I is another.) No particular hardware support is needed; addition and subtraction work exactly like integer addition and subtraction, and muliplication and division just require a scaling operation. This refers to language-supported fixed-point arithmetic in which the location of the binary can be specified. In the most general case, such as I think PL/I supports, it can be specified independently for each variable. If the operands of an addition or subtraction operator have different scale factors then scaling needs to be performed before the operation. The result will need to be scaled afterwards if storing in a variable with a different scale factor than used for the operation. Fixed point arithmetic can be done in C, but the user must track the scaling and often employ higher precision arithmetic for intermediate results. Some hardware, at least in the past, had both an integer multiply and a fractional multiply, which assumes that the binary point is to the left of the most significant bit. A fractional multiplication might not retain all the bits of the product: a 64-bit fraction times a 64-bit fraction might yield a 64-bit fractional result. A floating point multiply unit typically has a fractional multiply for the mantissas. -- Thad Apr 16 '06 #13

 P: n/a Keith Thompson wrote: Andrew Poelstra writes: The only time you would need fixed-point numbers is when you areoutputting. printf does support fixed point, I believe. Incorrect. Fixed-point has arithmetic properties that are very different from those of floating-point, properties that can be quite useful in some circumstances. For example, fixed-point with a scale factor of 100 lets you do precise calculations with money; floating-point introduces rounding errors, because 0.01 can't be represented exactly in binary. Good point. As another example, low-end embedded processors (without floating point, having short hardware-supported data types, and with limited RAM) can benefit significantly from careful use of fixed-point arithmetic. -- Thad Apr 16 '06 #14

 P: n/a Ben Pfaff wrote: How do you propose to do fixed-point multiplication and division without some kind of fix-up? By doing floating-point arithmetic and then chopping off any extra decimals. Do you want fixed-point arithmetic in the sense of having rounding errors? printf does support fixed point, I believe. I don't understand what you mean by that. printf will allow you to specify how many decimal points to display. In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. I think you're wrong. Thank you for the comment. If you elaborate perhaps I'll be able to correct myself and become a smarter person. Apr 17 '06 #15

 P: n/a "Andrew Poelstra" writes: I think you're wrong. Thank you for the comment. If you elaborate perhaps I'll be able to correct myself and become a smarter person. Better informed, not smarter. LOL. Apr 17 '06 #16

 P: n/a osmium wrote: "Andrew Poelstra" writes: I think you're wrong. Thank you for the comment. If you elaborate perhaps I'll be able to correct myself and become a smarter person. Better informed, not smarter. LOL. Exactly. The message immediately after yours answered my question, proving that perhaps I should read ahead before posting. I had a snappy comeback, but I forgot it, so I'll just wink. ;-) Apr 17 '06 #17

 P: n/a Andrew Poelstra writes: Ben Pfaff wrote: How do you propose to do fixed-point multiplication and division without some kind of fix-up? By doing floating-point arithmetic and then chopping off any extra decimals. Do you want fixed-point arithmetic in the sense of having rounding errors? If you want fixed-point arithmetic, presumably it's because floating-point arithmetic is not suitable. For example, in the example I cited earlier, floating-point arithmetic was not allowed at all. -- "I hope, some day, to learn to read. It seems to be even harder than writing." --Richard Heathfield Apr 17 '06 #18

 P: n/a On 16 Apr 2006 06:50:32 -0700, "Chad" wrote: What is the difference between range and precision in c? Also, if cdoesn't support fixed point numbers, how is the addition of twointegers possible? I suspect your question is about floating point numbers but for completeness, range also applies to integers. For integer types, the range is the set of values between the minimum and maximum allowable values, inclusive. The standard provides a set of macros so your code has access to these values (e.g., INT_MIN and INT_MAX for int). Each of these values is represented exactly. For floating point types, the range is the smallest and largest allowable positive values plus the corresponding negative values plus 0.. But not all values in this range can be represented. Since different systems use different representations and since binary is not intuitively obvious in this regard, let's consider a system where a floating point value is represented by a signed two decimal digit exponent (base 10) and a signed four decimal digit mantissa with an implied decimal point before the first mantissa digit. Using ^ for exponentiation like the math newsgroups do, the largest value that can be represented is 9999*10^99 and the smallest positive value is 0001*10^-99. The range, expressed in normal scientific notation, is 1.0*10^-103 to 9.999*10^98. If you attempt to multiply 1024 (represented as 1024*10^4) by itself, instead of 1048576, you get 1048*10^7 (or perhaps 1049 depending on how rounding is performed). Similarly, you cannot represent 1/3 exactly on this system. You have to settle for 3333*10^0. You also end up with non-arithmetic results such as 10,000+1 == 10,000. The system is limited to four digits of precision even though the range spans 200 orders of magnitude. When you consider the binary techniques actually used, the problem is compounded since "simple" decimal values such as 10.1 cannot be represented exactly. Again, the standard provides a set of macros so your code can know what the limits are (e.g., DBL_DIG, decimal digits of precision, and DBL_EPSILON, the smallest number which when added to 1.0 produces a result greater than 1.0). You might look up the differences between precision, significance, and accuracy in a math reference. Remove del for email Apr 17 '06 #19

 P: n/a Andrew Poelstra writes: Ben Pfaff wrote: How do you propose to do fixed-point multiplication and division without some kind of fix-up? By doing floating-point arithmetic and then chopping off any extra decimals. [...] No, floating-point arithmetic isn't necessary. In languages that support it, fixed-point numbers are effectively just scaled integers. For addition and subtraction, and for fixed-by-integer multiplication and fixed-by-integer division, the scale factor can be ignored. Fixed-by-fixed multiplication and division are a bit more complicated; you need to scale the result, or possibly pre-scale the operands, and you might need extended precision for the intermediate result. Scaling is just a simple shift if the scale factor is a power of 2; otherwise you need to multiply or divide by the scale factor. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 17 '06 #20

 P: n/a "Andrew Poelstra" wrote in message news:a5w0g.28677\$WI1.7194@pd7tw2no... Ben Pfaff wrote: "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. But you can implement fixed-point arithmetic in C; for example, the instructions for one part of an operating system project that I wrote explain how to do so: http://www.stanford.edu/class/cs140/...l%20Arithmetic The only time you would need fixed-point numbers is when you are outputting. printf does support fixed point, I believe. Or doing fast arithmetic internally with known limited range. Or doing saturating arithmetic. Or... In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. Not quite true. The argument for *decimal* fixed point is that it's way easier to match a host of laws that dictate rounding of tax computations, etc. A heroic effort in binary can be trivial in decimal. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com Apr 17 '06 #21

 P: n/a P.J. Plauger a écrit : Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. After reading that proposal, I was struck by the fact that since quite a long time we are turning around the problem of defining SUBTYPES for the language. Consider this: int a; and volatile int a; The second is a SUBTYPE of integer, i.e. an integer with special characteristics, in this case that is volatile. In the same manner, fixed point could be understood as a subtype of double/float, etc, where the implementation changes. This is even more obvious when further down in the proposal there is the definition of address spaces, and we have declarations like: _X char a,b,c; (page 38) This declaration means that the characters a,b, and c are stored in an address space named _X. Recently, Microsoft decided to standardize the different __declspec(foo) declarations that sprinkle the windows headers, and decided to adopt a standard annotation system for declaring variables. At the same time, gcc has its __attribute__ construct that does the same thing . What is needed now, I think, is to realize that subtypes (and all those ad hoc implementations) are a real NEED for the language, and that we should try to address THIS problem rather than defining a new ad hoc solution for each specific need. What is needed is a general syntax that allows compiler to ignore subtype specifications when not supported but would allow standadization of annotations so that they would be compatible, in the sense that #pragma is used. jacob Apr 17 '06 #22

 P: n/a P.J. Plauger wrote: "Andrew Poelstra" wrote in message news:a5w0g.28677\$WI1.7194@pd7tw2no... Ben Pfaff wrote: "Chad" writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. And then there is also TR24732 which specifies decimal floating point support to the C language. Are we likely to eventually see both fixed point and decimal floating point support in C or is one likely to win out over the other? What are the current demands for support of each of these in the language? Robert Gamble Apr 17 '06 #24

 P: n/a Robert Gamble wrote: P.J. Plauger wrote: "Andrew Poelstra" wrote in message news:a5w0g.28677\$WI1.7194@pd7tw2no... Ben Pfaff wrote: "Chad" writes:> After some googling, I saw some comments on other newsgroups> that said C didn't support fixed-point. C doesn't have built-in support for fixed-point arithmetic, except for integer arithmetic as a special case. Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. And then there is also TR24732 which specifies decimal floating point support to the C language. Are we likely to eventually see both fixed point and decimal floating point support in C or is one likely to win out over the other? What are the current demands for support of each of these in the language? For what I'm doing now decimal support would be useful, for what I used to do (which others still do) fixed point would be useful. So add both would be my vote. -- Flash Gordon, living in interesting times. Web site - http://home.flash-gordon.me.uk/ comp.lang.c posting guidelines and intro: http://clc-wiki.net/wiki/Intro_to_clc Apr 17 '06 #25

 P: n/a jacob navia writes: P.J. Plauger a écrit : Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. After reading that proposal, I was struck by the fact that since quite a long time we are turning around the problem of defining SUBTYPES for the language. Consider this: int a; and volatile int a; The second is a SUBTYPE of integer, i.e. an integer with special characteristics, in this case that is volatile. In the same manner, fixed point could be understood as a subtype of double/float, etc, where the implementation changes. [...] No, fixed-point types are not subtypes of floating-point types, any more than integer types are subtypes of floationg-point types. If S is a subtype of type T, then surely every value of type S must also be a value of type T. For example, in languages that support subtypes, you might define an integer type with a range of -32768..+32767, and a subtype of that type with a range of -99..+99. A small fixed-point type might happen to have values that are a subset of the values of a larger floating-point type, just as, for example, every 32-bit integer value might be exactly representable in a 64-bit floating-point type. But this is neither necessary nor useful. If a given fixed-point type and a given floating-point type have the same size (and no "padding bits"), each type will inevitably be able to represent values that the other cannot. There is no subset relationship. (I put "padding bits" in quotation marks because the standard defines the term only for integer types.) Mathematically, the representable values of a fixed-point type are less dense than those of a floating-point type for values near zero, but more dense for values with larger magnitudes; fixed-point doesn't "waste" bits on a variable scale factor (the exponent). -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 17 '06 #26

 P: n/a "P.J. Plauger" writes: [...] In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. Not quite true. The argument for *decimal* fixed point is that it's way easier to match a host of laws that dictate rounding of tax computations, etc. A heroic effort in binary can be trivial in decimal. How so? For simple calculations with money (accurate to dollars and cents, or the local equivalent), I would (naively) think that binary integers scaled by a factor of 100 would be adequate. For example, one dollar would be represented as 100, or 1100100 in binary. Are the requirements for more complex calculations (interest, taxes, etc.), particularly calculations with intermediate results that aren't whole numbers of cents, more difficult to implement correctly in binary? (I think you've already indicated the answer is yes; I'm curious about the details, at least at a high level.) -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 17 '06 #27

 P: n/a "Robert Gamble" wrote in message news:11**********************@i40g2000cwc.googlegr oups.com... P.J. Plauger wrote: "Andrew Poelstra" wrote in message news:a5w0g.28677\$WI1.7194@pd7tw2no... > Ben Pfaff wrote: >> "Chad" writes: >> >>> After some googling, I saw some comments on other newsgroups >>> that said C didn't support fixed-point. >> >> C doesn't have built-in support for fixed-point arithmetic, >> except for integer arithmetic as a special case. Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. And then there is also TR24732 which specifies decimal floating point support to the C language. Are we likely to eventually see both fixed point and decimal floating point support in C or is one likely to win out over the other? Each has different constituencies. What are the current demands for support of each of these in the language? Binary fixed-point arithmetic has been a common ad hoc extension for C compilers targeting DSPs. I believe the Embedded C TR does a nice job of subsuming past extensions in a well designed language/library extension. Decimal floating-point is being advanced by IBM because a) IEEE/754R will specify it, b) it has desirable properties, and c) IBM allegedly has hardware support for it in the pipeline. It comes with features that give you the advantages of decimal fixed-point arithmetic as well. Between the case made by IBM and the demonstrable past success of decimal arithmetic in older programming languages, both WG14 and WG21 were sold on specifying it in yet another non-normative TR. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com Apr 17 '06 #28

 P: n/a "Flash Gordon" wrote in message news:67************@news.flash-gordon.me.uk... Robert Gamble wrote: P.J. Plauger wrote: "Andrew Poelstra" wrote in message news:a5w0g.28677\$WI1.7194@pd7tw2no... Ben Pfaff wrote:> "Chad" writes:>>> After some googling, I saw some comments on other newsgroups>> that said C didn't support fixed-point.> C doesn't have built-in support for fixed-point arithmetic,> except for integer arithmetic as a special case. Well, it kinda does now. TR18037 (Embedded C) defines a well thought out addition to C for fixed point arithmetic. It'll be included in our next release, though only the EDG front end supports the language part. It's intended primarily for DSPs, but it's generally useful. And then there is also TR24732 which specifies decimal floating point support to the C language. Are we likely to eventually see both fixed point and decimal floating point support in C or is one likely to win out over the other? What are the current demands for support of each of these in the language? For what I'm doing now decimal support would be useful, for what I used to do (which others still do) fixed point would be useful. So add both would be my vote. As I mentioned in my previous post, there's effectively fixed-point support as well as floating-point in the decimal proposal. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com Apr 17 '06 #29

 P: n/a "Keith Thompson" wrote in message news:ln************@nuthaus.mib.org... "P.J. Plauger" writes: [...] In other words, what type of decimal math the language uses is irrelevant, as long as you can output in the format you want. Not quite true. The argument for *decimal* fixed point is that it's way easier to match a host of laws that dictate rounding of tax computations, etc. A heroic effort in binary can be trivial in decimal. How so? For simple calculations with money (accurate to dollars and cents, or the local equivalent), I would (naively) think that binary integers scaled by a factor of 100 would be adequate. For example, one dollar would be represented as 100, or 1100100 in binary. Are the requirements for more complex calculations (interest, taxes, etc.), particularly calculations with intermediate results that aren't whole numbers of cents, more difficult to implement correctly in binary? (I think you've already indicated the answer is yes; I'm curious about the details, at least at a high level.) If you can use scaled integers, then the problems are tractable, but at the cost of doing fixed-point arithmetic in software. If you try to round binary floating-point fractions by decimal rounding rules, however, it's amazingly hard to get right. And politicians tend to think in decimal, for good or for ill. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com Apr 17 '06 #30

 P: n/a P.J. Plauger a écrit : [snip] Proposals are always welcome. There are two major annotations systems in use: __declspec(annotation) (Microsoft) __attribute__ (gcc) We could toss a coin, and use one or the other, it doesn't really matter. What is important is that we could add things in a portable manner like this int foo(char * __declspec(NonNull) inputPtr); Then, the compiler could emit a warning when seeing foo(NULL); A (admitedly) trivial case, but there are others. This could be VERY useful for making assertions automatic. Within a debugging setting the compiler could silently emit assertions to test annotations like this. The C standard could standardize some very common annotations like NonNull (for pointers) Positive (i.e. > 0) and many others. All this within the context of argument passing. But in another contexts, this would be a bonus. For instance we would not need any special syntax like _X char a,b,c; as proposed in the document TR18037, but we could use __declspec(AddressSpace _X) char a,b,c; and the code would remain portable. jacob Apr 17 '06 #31

 P: n/a In article Andrew Poelstra writes: Ben Pfaff wrote: How do you propose to do fixed-point multiplication and division without some kind of fix-up? By doing floating-point arithmetic and then chopping off any extra decimals. Do you want fixed-point arithmetic in the sense of having rounding errors? How do you do that when you want to round 1/3 to two decimals after the decimal point? You may note that 0.33 is *not* exactly representable in binary floating-point arithmetic. -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ Apr 18 '06 #32

 P: n/a On Sun, 16 Apr 2006 17:07:03 -0600, Thad Smith wrote: Keith Thompson wrote: A number of languages have direct support for fixed-point arithmetic. (Ada is one of them; I think PL/I is another.) No particular hardware support is needed; addition and subtraction work exactly like integer addition and subtraction, and muliplication and division just require a scaling operation. This refers to language-supported fixed-point arithmetic in which the location of the binary can be specified. In the most general case, such as I think PL/I supports, it can be specified independently for each PL/I, Ada, COBOL all support different fixed-point positions for each variable; in fact I don't see how you could make effective use of any system where all variables were scaled by the same amount -- sort of like APL's global origin setting to 0 or 1? What a mess that was. PL/I supports both fixed-point binary and decimal. Ada in principle supports fixed-point of any radix, although (as typical) verbosely. It's debatable if it's a programming language, but SQL supports fixed-point decimal. variable. If the operands of an addition or subtraction operator have different scale factors then scaling needs to be performed before the operation. The result will need to be scaled afterwards if storing in a variable with a different scale factor than used for the operation. Fixed point arithmetic can be done in C, but the user must track the scaling and often employ higher precision arithmetic for intermediate results. There was under development, and I believe now finished (haven't checked recently), a "Technical Report" (essentially a standardized but optional add-on) on C for embedded programming that includes fixed-point and saturating arithmetic and distinct memory spaces. - David.Thompson1 at worldnet.att.net May 1 '06 #33

This discussion thread is closed

Replies have been disabled for this discussion. 