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  
Share this Question
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 <float.h>
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.  
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 floatingpoint
types the granularity varies with the magnitude of the
value, so it is customary to state the precision in
relative rather than absolute terms: soandso many
digits rather than plusorminus soandso 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 fixedpoint arithmetic is involved in any way?

Eric Sosman es*****@acmdotorg.invalid  
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 fixedpoint arithmetic is involved in any way?
 Eric Sosman es*****@acmdotorg.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 fixedpoint and floatingpoint 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 fixedpoint.
Hence, the questions.
Chad  
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 fixedpoint 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 fixedpoint and floatingpoint 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 fixedpoint. Hence, the questions. Chad
I think fixedpoint arithmetic can have more than one meaning. In
one sense, C supports fixedpoint 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 floatingpoint. 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.
  
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 fixedpoint and floatingpoint 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 fixedpoint. 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/fixedpoint&r=67  
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  
P: n/a

"Chad" <cd*****@gmail.com> writes: After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint.
C doesn't have builtin support for fixedpoint arithmetic,
except for integer arithmetic as a special case. But you can
implement fixedpoint 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  
P: n/a

Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint.
C doesn't have builtin support for fixedpoint arithmetic, except for integer arithmetic as a special case. But you can implement fixedpoint 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 fixedpoint 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.  
P: n/a

Andrew Poelstra <ap*******@shaw.ca> writes: Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint. C doesn't have builtin support for fixedpoint arithmetic, except for integer arithmetic as a special case. But you can implement fixedpoint 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 fixedpoint numbers is when you are outputting.
How do you propose to do fixedpoint multiplication and division
without some kind of fixup?
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  
P: n/a

"bert" <be************@btinternet.com> writes:
[...] I think fixedpoint arithmetic can have more than one meaning. In one sense, C supports fixedpoint 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 floatingpoint. 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 fixedpoint 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 fixedpoint types.

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

Andrew Poelstra <ap*******@shaw.ca> writes: Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint. C doesn't have builtin support for fixedpoint arithmetic, except for integer arithmetic as a special case. But you can implement fixedpoint 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 fixedpoint 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. Fixedpoint has arithmetic properties that are very
different from those of floatingpoint, properties that can be quite
useful in some circumstances. For example, fixedpoint with a scale
factor of 100 lets you do precise calculations with money;
floatingpoint 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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

Keith Thompson wrote: "bert" <be************@btinternet.com> writes:
I think fixedpoint arithmetic can have more than one meaning. In one sense, C supports fixedpoint 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.
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 fixedpoint 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 languagesupported fixedpoint 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 64bit fraction times a 64bit
fraction might yield a 64bit fractional result. A floating point
multiply unit typically has a fractional multiply for the mantissas.

Thad  
P: n/a

Keith Thompson wrote: Andrew Poelstra <ap*******@shaw.ca> writes: The only time you would need fixedpoint numbers is when you are outputting. printf does support fixed point, I believe.
Incorrect. Fixedpoint has arithmetic properties that are very different from those of floatingpoint, properties that can be quite useful in some circumstances. For example, fixedpoint with a scale factor of 100 lets you do precise calculations with money; floatingpoint introduces rounding errors, because 0.01 can't be represented exactly in binary.
Good point. As another example, lowend embedded processors (without
floating point, having short hardwaresupported data types, and with
limited RAM) can benefit significantly from careful use of fixedpoint
arithmetic.

Thad  
P: n/a

Ben Pfaff wrote: How do you propose to do fixedpoint multiplication and division without some kind of fixup?
By doing floatingpoint arithmetic and then chopping off any extra
decimals. Do you want fixedpoint 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.  
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.  
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. ;)  
P: n/a

Andrew Poelstra <ap*******@shaw.ca> writes: Ben Pfaff wrote: How do you propose to do fixedpoint multiplication and division without some kind of fixup?
By doing floatingpoint arithmetic and then chopping off any extra decimals. Do you want fixedpoint arithmetic in the sense of having rounding errors?
If you want fixedpoint arithmetic, presumably it's because
floatingpoint arithmetic is not suitable. For example, in the
example I cited earlier, floatingpoint arithmetic was not
allowed at all.

"I hope, some day, to learn to read.
It seems to be even harder than writing."
Richard Heathfield  
P: n/a

On 16 Apr 2006 06:50:32 0700, "Chad" <cd*****@gmail.com> 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?
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 nonarithmetic 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  
P: n/a

Andrew Poelstra <ap*******@shaw.ca> writes: Ben Pfaff wrote: How do you propose to do fixedpoint multiplication and division without some kind of fixup?
By doing floatingpoint arithmetic and then chopping off any extra decimals.
[...]
No, floatingpoint arithmetic isn't necessary.
In languages that support it, fixedpoint numbers are effectively just
scaled integers. For addition and subtraction, and for
fixedbyinteger multiplication and fixedbyinteger division, the
scale factor can be ignored. Fixedbyfixed multiplication and
division are a bit more complicated; you need to scale the result, or
possibly prescale 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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

"Andrew Poelstra" <ap*******@shaw.ca> wrote in message
news:a5w0g.28677$WI1.7194@pd7tw2no... Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint. C doesn't have builtin support for fixedpoint 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 fixedpoint 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 fixedpoint 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  
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  
P: n/a

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:44***********************@news.wanadoo.fr... 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.
const and volatile are more in the line of *access qualifiers*. Once
you extract the rvalue, an int is an int. (In this sense, access
qualifiers are partway toward storage class specifiers like static
and register.)
In the same manner, fixed point could be understood as a subtype of double/float, etc, where the implementation changes.
Uh, no it's not. Except possibly in the broad sense that integers are
a special case of floatingpoint. But that viewpoint doesn't win you
much.
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.
Yep. Technology like that has been kicking around for decades.
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.
Proposals are always welcome.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com  
P: n/a

P.J. Plauger wrote: "Andrew Poelstra" <ap*******@shaw.ca> wrote in message news:a5w0g.28677$WI1.7194@pd7tw2no...
Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
After some googling, I saw some comments on other newsgroups that said C didn't support fixedpoint.
C doesn't have builtin support for fixedpoint 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  
P: n/a

Robert Gamble wrote: P.J. Plauger wrote: "Andrew Poelstra" <ap*******@shaw.ca> wrote in message news:a5w0g.28677$WI1.7194@pd7tw2no...
Ben Pfaff wrote: "Chad" <cd*****@gmail.com> writes:
> After some googling, I saw some comments on other newsgroups > that said C didn't support fixedpoint. C doesn't have builtin support for fixedpoint 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.flashgordon.me.uk/
comp.lang.c posting guidelines and intro: http://clcwiki.net/wiki/Intro_to_clc  
P: n/a

jacob navia <ja***@jacob.remcomp.fr> 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, fixedpoint types are not subtypes of floatingpoint types, any
more than integer types are subtypes of floationgpoint 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 fixedpoint type might happen to have values that are a subset
of the values of a larger floatingpoint type, just as, for example,
every 32bit integer value might be exactly representable in a 64bit
floatingpoint type. But this is neither necessary nor useful. If a
given fixedpoint type and a given floatingpoint 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 fixedpoint type are
less dense than those of a floatingpoint type for values near zero,
but more dense for values with larger magnitudes; fixedpoint doesn't
"waste" bits on a variable scale factor (the exponent).

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

"P.J. Plauger" <pj*@dinkumware.com> 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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.  
P: n/a

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com... P.J. Plauger wrote: "Andrew Poelstra" <ap*******@shaw.ca> wrote in message news:a5w0g.28677$WI1.7194@pd7tw2no...
> Ben Pfaff wrote: >> "Chad" <cd*****@gmail.com> writes: >> >>> After some googling, I saw some comments on other newsgroups >>> that said C didn't support fixedpoint. >> >> C doesn't have builtin support for fixedpoint 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 fixedpoint 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 floatingpoint 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 fixedpoint 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 nonnormative TR.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com  
P: n/a

"Flash Gordon" <sp**@flashgordon.me.uk> wrote in message
news:67************@news.flashgordon.me.uk... Robert Gamble wrote: P.J. Plauger wrote: "Andrew Poelstra" <ap*******@shaw.ca> wrote in message news:a5w0g.28677$WI1.7194@pd7tw2no...
Ben Pfaff wrote: > "Chad" <cd*****@gmail.com> writes: > >> After some googling, I saw some comments on other newsgroups >> that said C didn't support fixedpoint. > C doesn't have builtin support for fixedpoint 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 fixedpoint
support as well as floatingpoint in the decimal proposal.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com  
P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "P.J. Plauger" <pj*@dinkumware.com> 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 fixedpoint arithmetic in software. If you try to
round binary floatingpoint 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  
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  
P: n/a

In article <j5C0g.30517$P01.19133@pd7tw3no> Andrew Poelstra <ap*******@shaw.ca> writes: Ben Pfaff wrote: How do you propose to do fixedpoint multiplication and division without some kind of fixup?
By doing floatingpoint arithmetic and then chopping off any extra decimals. Do you want fixedpoint 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 floatingpoint arithmetic.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/  
P: n/a

On Sun, 16 Apr 2006 17:07:03 0600, Thad Smith <Th*******@acm.org>
wrote: Keith Thompson wrote:
<snip> A number of languages have direct support for fixedpoint 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 languagesupported fixedpoint 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 fixedpoint 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 fixedpoint binary and decimal. Ada in principle
supports fixedpoint of any radix, although (as typical) verbosely.
It's debatable if it's a programming language, but SQL supports
fixedpoint 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 addon) on C for embedded programming that includes
fixedpoint and saturating arithmetic and distinct memory spaces.
 David.Thompson1 at worldnet.att.net   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 1818
 replies: 32
 date asked: Apr 16 '06
