range vs precisionC

[Chad]

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

[osmium]

"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.

[Eric Sosman]

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

[Chad]

> 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

[bert]

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.
--

[osmium]

"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

[John Smith]

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

[Ben Pfaff]

"Chad" <cd*****@gmail.com> 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

[Andrew Poelstra]

Ben Pfaff wrote:

"Chad" <cd*****@gmail.com> 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.

[Ben Pfaff]

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 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

[Keith Thompson]

"bert" <be************@btinternet.com> 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 <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.

[Keith Thompson]

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 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 <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.

[Thad Smith]

Keith Thompson wrote:

"bert" <be************@btinternet.com> 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.

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

[Thad Smith]

Keith Thompson wrote:

Andrew Poelstra <ap*******@shaw.ca> writes:

The only time you would need fixed-point numbers is when you are
outputting. 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

[Andrew Poelstra]

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.

[osmium]

"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.

[Andrew Poelstra]

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. ;-)

[Ben Pfaff]

Andrew Poelstra <ap*******@shaw.ca> 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

[Barry Schwarz]

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 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

[Keith Thompson]

Andrew Poelstra <ap*******@shaw.ca> 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 <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.J. Plauger]

"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 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

[jacob navia]

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.J. Plauger]

"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 r-value, 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 floating-point. 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

[Robert Gamble]

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 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

[Flash Gordon]

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 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

[Keith Thompson]

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, 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 <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.

[Keith Thompson]

"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.J. Plauger]

"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 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

[P.J. Plauger]

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:67************@news.flash-gordon.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 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

[P.J. Plauger]

"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 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

[jacob navia]

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

[Dik T. Winter]

In article <j5C0g.30517$P01.19133@pd7tw3no> Andrew Poelstra <ap*******@shaw.ca> 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, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dave Thompson]

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 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