Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #43306 > unrolled thread

Updating C default type

Back to article view | Back to comp.lang.c

Contents

  Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 16:48 +0000
    Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-22 18:59 +0200
      Re: Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 17:13 +0000
        Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 11:59 -0700
        Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:12 +0000
          Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-25 19:31 +0200
        Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:41 -0500
        Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 21:47 +0100
        Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:25 -0400
          Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-24 10:32 -0700
          Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 20:17 +0000
          Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 21:03 +0000
      Re: Updating C default type Gareth Owen <gwowen@gmail.com> - 2014-04-22 19:12 +0100
    Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 10:26 -0700
    Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 10:28 -0700
    Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 18:20 +0000
      Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 19:09 +0000
        Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:35 -0400
          Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:38 -0400
          Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:54 +0000
            Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 21:27 +0000
              Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 23:08 +0100
      Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:03 +0100
      Re: Updating C default type Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-23 09:59 +0200
      Re: Updating C default type David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
        Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-05-26 05:48 +0000
    Re: Updating C default type "Osmium" <r124c4u102@comcast.net> - 2014-04-22 14:01 -0500
      Re: Updating C default type Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2014-04-23 16:57 +0000
        Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-23 13:13 -0400
        Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 18:02 +0000
        Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 11:33 -0700
    Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:08 +0000
      Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:08 +0100
        Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 22:19 +0100
      Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 14:13 -0700
        Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 11:55 -0500
          Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 10:55 -0700
            Re: Updating C default type Robert Wessel <robertwessel2@yahoo.com> - 2014-04-24 00:03 -0500
          Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 22:37 -0700
            Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 12:05 +0000
        Re: Updating C default type gordonb.ez7sl@burditt.org (Gordon Burditt) - 2014-04-25 06:11 -0500
          Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:48 -0400
    Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:30 -0500
      Re: Updating C default type ralph <nt_consulting@yahoo.com> - 2014-04-22 23:18 -0500
    Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:28 -0400
    Re: Updating C default type gordonb.oztxz@burditt.org (Gordon Burditt) - 2014-04-24 23:50 -0500
      Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:41 -0400
    Re: Updating C default type Hans Vlems <hvlems@freenet.de> - 2014-05-25 23:57 -0700
      Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 01:55 -0700
      Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 13:01 +0100
        Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 13:12 -0700
          Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 22:31 +0100
            Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 23:55 +0100
            Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-05-26 17:11 -0700
      Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-05-27 07:54 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#43361

Kaz Kylheku <kaz@kylheku.com> wrote:
(snip, I wrote)
>>>>> The only language in relatively common use that I know of with
>>>>> a rational type is TIFF.
 
>>>>  The following is a program for a language called »C++«:
  
(snip, including snip of #includes)

>>>> { using r12 = ::std::ratio< 1, 2 >;
>>>>  using r24 = ::std::ratio< 2, 4 >;

>>> Hmm, OK, I meant as a fundamental data type, such that you didn't
>>> have to #include anything, and didn't have to declare its variables
>>> in a different way than more usual data types.  (What Java calls
>>> primitive data types.)

>>> If I could say:

>>> rational r12 = 1/2;
>>> rational r14 = 1/4;
>>> rational r34 = r12+r14;

>>> Then I would agree.
 
> Note to glen: if you could say rational r12 = 1/2, then you would 
> need the type system of C expressions to support an inherited 
> attribute scheme. I.e. the fact that the result is expected to 
> be of rational type flows across the tree down into the / node, 
> and causes a semantics change there to do a rational division.

Well, at that point I was only asking for it in initializers, 
but, yes, even that would be unusual. 

To be more C-like: 

rational r12 = 1r/2;
rational r14 = 1r/4;
rational r34 = r12+r14;

(I think r isn't used yet) would give a constant the rational type,
after which operations between it and int would also be rational.
 
> As it stands, C has synthesized attributes (for the most part): the type of
> an expression is known from the types of its constituents alone, and
> not from other context. (A few rules use inheritance. E.g. expressions are
> lvalues based on their contextual location, and that ripples down
> into their constituents. X is an lvalue in some contexts, and
> if X is an lvalue and a struct/union, then X.memb is, and so on.)

The only language I know that doesn't do that is verilog, where the
width of the left side of a continuous assignment (I suppose regular
assignment, too) affects the evaluation of the right side.
 
>> Like C, C++ packages in it's standard library many features that in
>> other languages are part of the language itself (e.g. <stdint.h>). Since
>> a conforming implementation of C (or C++) must provide support not only
>> for the language, but also for the standard library, I don't think it
>> makes much sense to make such distinctions.
 
> Yes it does. C and C++ are not designed in such a way that there is 
> no way to tell whether something is a language or library feature.

OK, consider String in Java. It is a class, mostly like any other
class, (specifically, it isn't a primitive type) but the compilers 
special case it. Even though Java doesn't have operator overloading,
the + and += operators can be applied to String. The compiler will
call a classes toString() method when needed for a non-String class,
and probably more that I forget or never knew. 

As with C and C++, String constants are special, and processed
appropriately by the compiler.
 
> There are features that, if removed from C, cannot be put back 
> by writing C code.
> Generally speaking, those are "language proper" and all else 
> is "library". The features that cannot be written in C enjoy 
> special privilege; they are better integrated which usually 
> makes them less cumbersome to use.

Yes. And if a language wants to have a rational type, it should
also be appropriately integrated into the language, like it 
is in TIFF.

> Support is not only a yes or no question but a how well question, 
> but also of how well: what level or depth of support.

Now, consider mixing ::std::ratio and other types. Are all the
appropriate operator overloading done for all combinations of
::std::ratio and all other types?  Not only primitive types
(as Java would describe them) but other ::std:: classes?
All other ::std:: classes?

-- glen

[toc] | [prev] | [next] | [standalone]

#43377

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message 
news:literals-20140422234233@ram.dialup.fu-berlin.de...
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>To be more C-like:
>>rational r12 = 1r/2;
>
>  In fact, in C++, one now can define literals and operators,
>  so that this works!
>
> #include <iostream>
> #include <ostream>
>
> struct rational { unsigned long long n; unsigned long long d;int s; };
> rational operator "" r( unsigned long long const i ){ return rational{ i, 
> 1, 1}; }
> rational operator/( rational m, int const i ){ m.d = i; return m;  }
> ::std::ostream & operator<<( ::std::ostream & out, rational const & m )
> { out << m.n << "/" << m.d; return out; }
>
> int main(){ rational r12 = 1r/2; ::std::cout << r12 << '\n'; }
>
> 1/2
>
>  (The implementation of »operator/« above is not semantically correct,
>  it just serves the demonstration purposes.)


#include <iostream>
#include <ostream>

typedef unsigned long long u64;

struct rational {u64 n,d; int s;}

rational operator "" r(u64 i) {
  return rational {i, 1, 1;}
}

rational operator / r(rational m, int i) {
  m.d=i;
  return m;
}

ostream & operator << (ostream &out, rational &m) {
  out << m.n "/" << m.d;
  return out;
}

int main(void) {
  rational r12 = 1r/2;
  cout << r12 << '\n';
}

Sorry, I had to retype your code properly spaced out to make any sense of 
it. (You seem to like combining long-winded stuff such as unsigned long long 
n, then repeating it as unsigned long long d, with some sort of new-line 
compactor!)

Presumably the issue you mentioned with "/" is to do with (a) needing to 
multiply by i; (b) dealing with negative i; (c)  having to reduce the new 
fraction to its lowest terms)? (And presumably there is a sign to be output 
by "<<".)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#43353

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
<snip>
> There are some languages, such as BASIC (in its original, and many
> implementations) that only supply a floating point data type.
> That is usually to make the langauge, and learning to use it,
> simpler. It complicates many algorithms.

For a more up-to-date example, see ECMAScript (AKA JavaScript).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#43407

On 04/22/14 20:20, glen herrmannsfeldt wrote:
> Another system sometimes used is rational (fractions) values.
> (The only language in relatively common use that I know of with
> a rational type is TIFF.) Each value is represented as a ratio
> (fraction) of two 32 bit integers.

Most languages in the LISP family have rational numbers.

Thomas

[toc] | [prev] | [next] | [standalone]

#44972

On Tue, 22 Apr 2014 18:20:00 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> Raj Pashwar <raj121190@hotmail.nospam.com> wrote:
> > <snip: use 'double' (i.e. floating-point) for all numbers?>
> <snip: other points>
> Also, note that floating point and integer aren't the only possible
> data types. There are systems that allow for non-integer fixed
> point values that have a fixed number of (decimal or binary or ...)
> digits after the radix point. Note that in most countries money
> is commonly described in a system with two digits after the decimal
> point. PL/I even allows for a negative number of digits after
> the radix (two or ten) point. 
> 
AFAIK all applicable machines actually implement integers in largish
or varying length binary, or decimal, or (usually) both. When you
declare things like PL/I FIXED DEC(8,4) or COBOL PIC 9999.9999 or Ada
delta .0001 the compiler and/or the language runtime library handles
scaling integers to get fixed-point. IIRC PL/I in particular had
rather unusual rules for fixed-point division which were entirely its
own and not from the underlying machine. (COBOL can do 'negative'
fractional digits, but only decimal at least standardly.)

> Another system sometimes used is rational (fractions) values.
> (The only language in relatively common use that I know of with
> a rational type is TIFF.) Each value is represented as a ratio
> (fraction) of two 32 bit integers.
> 
LISP has rationals, but I make no assertion as to common use.
(Also mostly-transparent multiprecision integer called 'bignum'.)

> Sometimes I write programs in AWK that could also be written
> in C.  AWK has some similarity to C, but no integer data type.
> 
Although it does print fp values that are actually (math) integers in
integer format. Ditto perl (which one might argue is just awk+1).

[toc] | [prev] | [next] | [standalone]

#45005

David Thompson <dave.thompson2@verizon.net> wrote:

(snip, I wrote)

>> Also, note that floating point and integer aren't the only possible
>> data types. There are systems that allow for non-integer fixed
>> point values that have a fixed number of (decimal or binary or ...)
>> digits after the radix point. Note that in most countries money
>> is commonly described in a system with two digits after the decimal
>> point. PL/I even allows for a negative number of digits after
>> the radix (two or ten) point. 
 
> AFAIK all applicable machines actually implement integers in largish
> or varying length binary, or decimal, or (usually) both. When you
> declare things like PL/I FIXED DEC(8,4) or COBOL PIC 9999.9999 or Ada
> delta .0001 the compiler and/or the language runtime library handles
> scaling integers to get fixed-point. IIRC PL/I in particular had
> rather unusual rules for fixed-point division which were entirely its
> own and not from the underlying machine. (COBOL can do 'negative'
> fractional digits, but only decimal at least standardly.)

The IBM description of fixed point instruction in the Principles
of Operations manuals for S/360 and successors describes then in
terms of fixed point where the user is expected to keep track of
the radix point, and not as integers. (Similar to the way
slide rule users are expected to keep track of the decimal
point.) The OS/360 assembler knows how to scale values, given 
a scale factor. (At least for binary constants, I am not so 
sure about decimal constants.) 

PL/I allows a pretty wide range, both positive and negative,
for the scale factor, and it applies to both decimal and binary
bases. 

While most IBM S/360 and successor PL/I compilers used BCD
arithmetic for FIXED BIN, some (CALL/OS for one) used binary.

-- glen

[toc] | [prev] | [next] | [standalone]

#43333

"Raj Pashwar" wrote:

> We know, that C was created when computers had poor CPU power, this led
> to many design decisions for C.
>
> Many of these now, are out of date, because even small microprocessors,
> have comparatively very powerful CPUs comparing to the 1970s.
>
> One good example, is the use of "int" as the default type. Today working
> with floating point operands is NOT expensive for modern CPUs. A "double"
> has much bigger range and precision than int. So a very easy improvement
> to C, will be to make return types for most standard functions, into
> "double".
>
> I.E. main() can return double, malloc() can take a double argument, ETC.
>
> Note, that a double can hold any int value, so any old code will be
> portable easily, therefore NO reason not to implement this improvement
> ASAP.

That is only true for one particular floating point specification; there is 
no *mandate* for C to use that form.  Do you want there to be an unsigned 
double?  There is a good reason not to do what you suggest, it is not 
portable and is a severe break with tradition.

Besides which, you will confuse the hell out of people if you start using 
double in lieu of int.  To do so would be like saying marriage was something 
between a man and a man.  Or childhood ended at age 25.  How in hell can we 
communicate with word  meanings in flux like that???

[toc] | [prev] | [next] | [standalone]

#43440

On Tue, 22 Apr 2014 14:01:36 -0500, Osmium wrote:
> Besides which, you will confuse the hell out of people if you start
> using double in lieu of int.  To do so would be like saying marriage was
> something between a man and a man.

Please do not spread your hate to this group. Are you a religious whacko, 
or just an ordinary workaday bigot?

Sadly for bitter losers like you, the world has moved on and equal 
marriage now has an unstoppable momentum. Even the current pope has 
accepted gay relationships.

QP

[toc] | [prev] | [next] | [standalone]

#43442

On 04/23/2014 12:57 PM, Quentin Pope wrote:
> On Tue, 22 Apr 2014 14:01:36 -0500, Osmium wrote:
>> Besides which, you will confuse the hell out of people if you start
>> using double in lieu of int.  To do so would be like saying marriage was
>> something between a man and a man.
> 
> Please do not spread your hate to this group. Are you a religious whacko, 
> or just an ordinary workaday bigot?
> 
> Sadly for bitter losers like you, the world has moved on and equal 
> marriage now has an unstoppable momentum. Even the current pope has 
> accepted gay relationships.

He might have been expressing homophobia, but that's not the only
possible interpretation of his words. He might have meant ""marriage was
ONLY something between a man and a man". Such a redefinition would
indeed cause a great deal of confusion (for instance, my wife would be
quite surprised to learn that she wasn't actually married), and as such
would be a good example of the problem he's talking about.

[toc] | [prev] | [next] | [standalone]

#43447

On 2014-04-23, Quentin Pope <qp19433@hotmail.NOSPAM.com> wrote:
> On Tue, 22 Apr 2014 14:01:36 -0500, Osmium wrote:
>> Besides which, you will confuse the hell out of people if you start
>> using double in lieu of int.  To do so would be like saying marriage was
>> something between a man and a man.
>
> Please do not spread your hate to this group. Are you a religious whacko, 
> or just an ordinary workaday bigot?
>
> Sadly for bitter losers like you, the world has moved on and equal 
> marriage now has an unstoppable momentum. Even the current pope has 
> accepted gay relationships.

The current pope has probably accepted plenty of dick, too, for that matter.

[toc] | [prev] | [next] | [standalone]

#43451

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
> On Tue, 22 Apr 2014 14:01:36 -0500, Osmium wrote:
>> Besides which, you will confuse the hell out of people if you start
>> using double in lieu of int.  To do so would be like saying marriage was
>> something between a man and a man.
>
> Please do not spread your hate to this group. Are you a religious whacko, 
> or just an ordinary workaday bigot?
[...]

I'm disappointed, but not surprised, that someone has taken the bait.
Can we please not discuss this issue here?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43335

On 2014-04-22, Raj Pashwar <raj121190@hotmail.NOSPAM.com> wrote:
> We know, that C was created when computers had poor CPU power, this led 
> to many design decisions for C.
>
> Many of these now, are out of date, because even small microprocessors, 
> have comparatively very powerful CPUs comparing to the 1970s.
>
> One good example, is the use of "int" as the default type. Today working 
> with floating point operands is NOT expensive for modern CPUs.

There is no "default type"; all declarations in C must have a type specifier
now. Defining a function with the "implicit int" rule is deprecated:

  func()   /* old style C: actually returns int */
  {
     return 0; /* no problem */
  }

> A "double" 
> has much bigger range and precision than int.

This is very silly argument. Floating point numbers and integers have different
semantics.

A double does not have greater precision than int; an integer *precisely* represents
integers. A double *imprecisely* approximates real numbers using rational numbers.
Operations on double are *inexact* in general.

A double also does not support bit operations.

> So a very easy improvement 
> to C, will be to make return types for most standard functions, into 
> "double".
>
> I.E. main() can return double, malloc() can take a double argument, ETC.

There is no reason to ever ask malloc for 10.3 bytes, or to return an
error status of 0.5 out of main. (Half succeeded?)

Can you name any serious high level language that uses doubles for error
codes, or sizes of memory allocations?

[toc] | [prev] | [next] | [standalone]

#43355

Kaz Kylheku <kaz@kylheku.com> writes:
<snip>
> Can you name any serious high level language that uses doubles for error
> codes, or sizes of memory allocations?

That may be correct for uninteresting reasons in that high-level
languages (modern ones at least) usually don't have error codes or
explicit allocation.  However, ECMAScript uses doubles for everything so
it may be a counter example (though you are free to consider it not
serious).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#43357

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.e9d550cc29eb70ccd801.20140422220854BST.87k3ahxeah.fsf@bsb.me.uk...
> Kaz Kylheku <kaz@kylheku.com> writes:
> <snip>
>> Can you name any serious high level language that uses doubles for error
>> codes, or sizes of memory allocations?
>
> That may be correct for uninteresting reasons in that high-level
> languages (modern ones at least) usually don't have error codes or
> explicit allocation.  However, ECMAScript uses doubles for everything so
> it may be a counter example (though you are free to consider it not
> serious).

There is also Lua. Both I imagine are implemented in C, and both would 
probably be considerably slower if the C only made use of doubles for 
everything. (I don't know if the OP was proposing using them for char types 
too. Strings made up of arrays of doubles would be interesting; at least no 
problem in representing Unicode.)

So in an interpreted (and perhaps not so serious) language, a doubles-only 
numeric type might work.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#43356

On Tuesday, April 22, 2014 8:08:49 PM UTC+1, Kaz Kylheku wrote:
> 
> A double does not have greater precision than int; an integer *precisely*
> represents integers. A double *imprecisely* approximates real numbers 
> using rational numbers.
> 
On a 32 bit system, double is the best integer type. It can represent more
integers than any 32 bit integer type, and arithmetical operations on them 
are exact as long as intermediate values don't overflow the range, in which
case they usually degrade gracefully.
The practical result is that the factorial function should usually be written
to return a double, to give a couple of extra usable values to N.

[toc] | [prev] | [next] | [standalone]

#43439

On 22-Apr-14 16:13, Malcolm McLean wrote:
> On Tuesday, April 22, 2014 8:08:49 PM UTC+1, Kaz Kylheku wrote:
>> A double does not have greater precision than int; an integer
>> *precisely* represents integers. A double *imprecisely*
>> approximates real numbers using rational numbers.
> 
> On a 32 bit system, double is the best integer type.

double is not an integer type at all, so "best" is moot.

> It can represent more integers than any 32 bit integer type,

Well, you'd expect that since double is a 64-bit type.  OTOH, double
can't represent all the integers that a 64-bit integer type can, so that
makes it rather poorly suited as a replacement.  Likewise, float can't
represent all the integers that a 32-bit integer type can.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#43446

Stephen Sprunk <stephen@sprunk.org> writes:
> On 22-Apr-14 16:13, Malcolm McLean wrote:
>> On Tuesday, April 22, 2014 8:08:49 PM UTC+1, Kaz Kylheku wrote:
>>> A double does not have greater precision than int; an integer
>>> *precisely* represents integers. A double *imprecisely*
>>> approximates real numbers using rational numbers.
>> 
>> On a 32 bit system, double is the best integer type.
>
> double is not an integer type at all, so "best" is moot.
>
>> It can represent more integers than any 32 bit integer type,
>
> Well, you'd expect that since double is a 64-bit type.  OTOH, double
> can't represent all the integers that a 64-bit integer type can, so that
> makes it rather poorly suited as a replacement.  Likewise, float can't
> represent all the integers that a 32-bit integer type can.

float and double are very commonly 32-bit and 64-bit types, respectively,
and systems with other sizes are probably becoming rarer as IEEE continues to
catch on.  But the language doesn't actually guarantee those particular sizes.
(Though I think the minimal requirements for double are such that it can't
be implemented in 32 bits.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43487

On Wed, 23 Apr 2014 10:55:47 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Stephen Sprunk <stephen@sprunk.org> writes:
>> On 22-Apr-14 16:13, Malcolm McLean wrote:
>>> On Tuesday, April 22, 2014 8:08:49 PM UTC+1, Kaz Kylheku wrote:
>>>> A double does not have greater precision than int; an integer
>>>> *precisely* represents integers. A double *imprecisely*
>>>> approximates real numbers using rational numbers.
>>> 
>>> On a 32 bit system, double is the best integer type.
>>
>> double is not an integer type at all, so "best" is moot.
>>
>>> It can represent more integers than any 32 bit integer type,
>>
>> Well, you'd expect that since double is a 64-bit type.  OTOH, double
>> can't represent all the integers that a 64-bit integer type can, so that
>> makes it rather poorly suited as a replacement.  Likewise, float can't
>> represent all the integers that a 32-bit integer type can.
>
>float and double are very commonly 32-bit and 64-bit types, respectively,
>and systems with other sizes are probably becoming rarer as IEEE continues to
>catch on.  But the language doesn't actually guarantee those particular sizes.
>(Though I think the minimal requirements for double are such that it can't
>be implemented in 32 bits.)


The 10 digit mantissa, -37..+37 exponent, plus a sign imply about 40.4
bits as a minimum.

[toc] | [prev] | [next] | [standalone]

#43490

On Wednesday, April 23, 2014 5:55:48 PM UTC+1, Stephen Sprunk wrote:
> 
> > It (double) can represent more integers than any 32 bit integer type,
> 
> Well, you'd expect that since double is a 64-bit type.  OTOH, double
> can't represent all the integers that a 64-bit integer type can, so that
> makes it rather poorly suited as a replacement.  Likewise, float can't
> represent all the integers that a 32-bit integer type can.
> 
It's a human tradeoff between precision and range. We usually allocate more
bits to the mantissa than the exponent, because we seldom need very large or
very small real values. 
Generally, if a number is data rather than an index or count, and it's not a
special case like RGB values or audio samples, I'll represent it as a double,
even if it's inherently integral. IEEE double can represent precisely all
integers from + to - 9007199254740992 (if I've got my calculations right).
That's better than a long, unlike long long it's seldom unsupported,
there isn't the annoying special case of the largest negative value being 
one greater than the largest positive value, and if you need more than
9 quadrillion, what are you representing? Even Obama's debt isn't that 
large. 

[toc] | [prev] | [next] | [standalone]

#43502

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

(snip)
> It's a human tradeoff between precision and range. We usually allocate more
> bits to the mantissa than the exponent, because we seldom need very large or
> very small real values. 

> Generally, if a number is data rather than an index or count, 
> and it's not a special case like RGB values or audio samples, 
> I'll represent it as a double, even if it's inherently integral. 

Reasonably often, I have values that I need to multiply by some 
integer, then divide by another integer, then truncate (as integer
divide naturally does). If the values are big enough, the product
doesn't fit in 32 bits, but I don't trust divide not to round, 
so I prefer (long long) for the intermediate.

Many compilers on 32 bit systems can do that using a 32 bit multiply
(with 64 bit product) and divide a 64 bit value by a 32 bit dividend
using the appropriate divide instruction. 

> IEEE double can represent precisely all
> integers from + to - 9007199254740992 (if I've got my 
> calculations right).
> That's better than a long, unlike long long it's seldom unsupported,
> there isn't the annoying special case of the largest negative value 
> being one greater than the largest positive value, and if you need 
> more than 9 quadrillion, what are you representing? 
> Even Obama's debt isn't that large. 

I might do that for add, subtract, and multiply but not for
divide or modulo.

-- glen

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web