range vs precisionC

[Keith Thompson]

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.

 

[P.J. Plauger]

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

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

 

[P.J. Plauger]

P.J. Plauger a écrit :

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]

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]

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.

 

[Keith Thompson]

P.J. Plauger a écrit :

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]

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

 

[P.J. Plauger]

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]

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]

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]

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

 

[Dave Thompson]

Keith Thompson wrote:

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