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 1 of 3  [1] 2 3  Next page →

#43306 — Updating C default type

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.

Thanks
Raj

[toc] | [next] | [standalone]

#43310

Le 22/04/2014 18:48, Raj Pashwar a écrit :
> 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.
>
> Thanks
> Raj
>

I do not follow you. What would mean

buffer = malloc(3.14);

????

Allocate 3 bytes and a few bits of the next one? Or what?

There are many situations where int makes sense and not floating point!

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

#43312

On Tue, 22 Apr 2014 18:59:37 +0200, jacob navia wrote:

> Le 22/04/2014 18:48, Raj Pashwar a écrit :
>> 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.
>>
>> Thanks Raj
>>
>>
> I do not follow you. What would mean
> 
> buffer = malloc(3.14);
> 
> ????
> 
> Allocate 3 bytes and a few bits of the next one? Or what?
> 
> There are many situations where int makes sense and not floating point!

Of course, it does NOT make sense. However in this case, the benefit is 
the extra RANGE of double, not precision.

With a double arg, malloc could allocate upto 1.7e308 bytes. It will be 
many years, before RAM density increases to exceed this size. Whereas, int 
can only allocate upto 2e9 bytes.

In other cases, i.e. return value for main(), BOTH the extra precision 
AND extra range of double can be valuable.

Regards,
Raj

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

#43332

Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
[...]
> Of course, it does NOT make sense. However in this case, the benefit is 
> the extra RANGE of double, not precision.

That extra range is of no benefit.

> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be 
> many years, before RAM density increases to exceed this size. Whereas, int 
> can only allocate upto 2e9 bytes.

malloc's argument is of type size_t, not int.  Implementations
already define size_t as an unsigned type large enough to represent
the size of any allocatable object.  On many current systems,
the maximum value of size_t is 2**64-1, about 18 quintillion.
If future systems are allocate more than that, they can make size_t
a larger unsigned integer type.

The extra precision (malloc(3.5)) is obviously of no benefit at all,
nor is the ability to represent negative numbers.  The extra range
is of no real benefit either, given that implementations can make
size_t as wide as they need to.  Even if that weren't the case,
that extra range comes at the cost of precision.  You could ask
malloc to allocate 2**64 bytes, but not 2**64-1, because 2**64-1
cannot be represented as a double (in a typical implementation).

> In other cases, i.e. return value for main(), BOTH the extra precision 
> AND extra range of double can be valuable.

Not particularly.  The full range of int typically isn't used.
The C standard defines the meaning of 2 or 3 return values (0,
EXIT_SUCCESS, and EXIT_FAILURE, where EXIT_SUCCESS is usually equal
to 0).  POSIX discards all but the low-order 8 bits.  The "curl"
command has the greatest number of distinct return status values
that I know of, and it only goes from 0 to 88.  Programs that need
to communicate more information than can be stored in a status
code can already do so in a variety of ways, such as by writing
information to stdout or to a file.

The Plan 9 operating system, as I recall, uses a string rather than
an integer as the exit status of a program.  It's an interesting
idea, but it's equally interesting to note that it hasn't caught
on elsewhere.

Your proposed change would break a large percentage of existing
code for no benefit that I can see.

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

#43337

On 2014-04-22, Raj Pashwar <raj121190@hotmail.NOSPAM.com> wrote:
> On Tue, 22 Apr 2014 18:59:37 +0200, jacob navia wrote:
>> I do not follow you. What would mean
>> 
>> buffer = malloc(3.14);
>> 
>> ????
>> 
>> Allocate 3 bytes and a few bits of the next one? Or what?
>> 
>> There are many situations where int makes sense and not floating point!
>
> Of course, it does NOT make sense. However in this case, the benefit is 
> the extra RANGE of double, not precision.

We have long int, and long long. A double can have more range than long long
(when both are 64 bits), but in the outer reaches of its range, a double does not
represent every consecutive integer.

Note that malloc's argument isn't int, but size_t.  size_t can be easily defined
as the widest available unsigned type.

Can you name one single computing platform whose C compiler's widest unsigned type
is not enough to represent the largest possible memory allocation?

> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be 
> many years, before RAM density increases to exceed this size.

RAM has to be addressable; if RAM gets to that size, there will have to be
pointers which can address it, and along with those pointers there will be
wider integer types.

In 1975, C compilers didn't have 64 bit types; now they do.

128 bit numbers are around the corner; GCC already provides them in software.

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

#43573

Le 22/04/2014 21:12, Kaz Kylheku a écrit :
> 128 bit numbers are around the corner; GCC already provides them in software.

lcc-win also. I recycled the 64 bit assembler code running in  32 bit 
platforms to cater now 128 bits in  a 64 bit platform.

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

#43348

On 22-Apr-14 12:13, Raj Pashwar wrote:
> On Tue, 22 Apr 2014 18:59:37 +0200, jacob navia wrote:
>> Le 22/04/2014 18:48, Raj Pashwar a écrit :
>>> 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.
>>> 
>>> Thanks Raj
>> 
>> I do not follow you. What would mean
>> 
>> buffer = malloc(3.14);
>> 
>> ????
>> 
>> Allocate 3 bytes and a few bits of the next one? Or what?
>> 
>> There are many situations where int makes sense and not floating
>> point!
> 
> Of course, it does NOT make sense. However in this case, the benefit
> is the extra RANGE of double, not precision.
> 
> With a double arg, malloc could allocate upto 1.7e308 bytes. It will
> be many years, before RAM density increases to exceed this size.
> Whereas, int can only allocate upto 2e9 bytes.

First of all, the argument to malloc() is size_t, not int.

Second, systems with a 64-bit size_t can (in theory) allocate up to
18,446,744,073,709,551,615 (2^64-1) bytes.  If the system could allocate
more memory than that, it would have an even bigger size_t.

double adds nothing here; actually, it makes things worse since it is
limited to 15 decimal digits of precision, whereas a 64-bit size_t has
20 decimal digits of precision.

Systems with a 32-bit size_t can't allocate more than 4,294,967,295
(2^32-1) bytes, but that's the point: if they could allocate more than
that, they'd have a larger size_t.  So, double still adds nothing.

And, of course, using a non-integer type raises questions of what it
means to allocate a fractional byte of memory; that means new error
conditions, new bugs, etc.

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]

#43350

"Raj Pashwar" <raj121190@hotmail.NOSPAM.com> wrote in message 
news:lj6802$cek$1@speranza.aioe.org...
> On Tue, 22 Apr 2014 18:59:37 +0200, jacob navia wrote:

> Of course, it does NOT make sense. However in this case, the benefit is
> the extra RANGE of double, not precision.

For extra range, extended precision libraries are available. This will deal 
with *millions* of digits, considerably more than double.


> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be
> many years, before RAM density increases to exceed this size.

With only 1e80 particles in the entire universe, I'm not sure it's even 
possible for that much memory to exist.

> Whereas, int
> can only allocate upto 2e9 bytes.

or 9e18 with 64-bits. For the next few years, that will be plenty.

-- 
Bartc 

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

#43515

On 4/22/2014 1:13 PM, Raj Pashwar wrote:
> On Tue, 22 Apr 2014 18:59:37 +0200, jacob navia wrote:
>
>> Le 22/04/2014 18:48, Raj Pashwar a écrit :
[...]
>>> I.E. main() can return double, malloc() can take a double argument,
>>> ETC.
[...]
>> I do not follow you. What would mean
>>
>> buffer = malloc(3.14);
>>
>> ????
>>
>> Allocate 3 bytes and a few bits of the next one? Or what?
>>
>> There are many situations where int makes sense and not floating point!
>
> Of course, it does NOT make sense. However in this case, the benefit is
> the extra RANGE of double, not precision.

So malloc() should be passed an *approximate* number of bytes to allocate?

> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be
> many years, before RAM density increases to exceed this size. Whereas, int
> can only allocate upto 2e9 bytes.

First, I wasn't aware that ints were limited to 32 bits.

Second, malloc() takes size_t, not int.

Finally, since the value passed to malloc() must, logically, be able to be 
express in no more bits than the number of bits in an address, why do you 
feel it is important to be able to pass values larger than the address 
space, and to do so using approximate rather than exact values?

I just tried a simple program which shows me sizeof() for "void *", 
"size_t", and "double".  All return 8.  On such a system, it would not be 
possible to pass malloc() an exact value for "sufficiently large" buffers, 
if it were passed a double rather than size_t.  (Or, if size_t were a double.)

> In other cases, i.e. return value for main(), BOTH the extra precision
> AND extra range of double can be valuable.

Assuming, of course, that the host system were written to expect such a value.

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

#43519

On Thursday, April 24, 2014 5:25:47 PM UTC+1, Ken Brody wrote:
>
> I just tried a simple program which shows me sizeof() for "void *",  
> "size_t", and "double".  All return 8.  On such a system, it would not be 
> possible to pass malloc() an exact value for "sufficiently large" buffers, 
> if it were passed a double rather than size_t.  (Or, if size_t were a double.)
> 
>Finally, since the value passed to malloc() must, logically, be able to be 
>express in no more bits than the number of bits in an address, why do you 
>feel it is important to be able to pass values larger than the address 
>space, and to do so using approximate rather than exact values? 
> 
Let's say we've got a calculation which demands a massive size of memory.
That could easily happen if your algorithm needs O(2^N) memory.

With an integer type, the calculation will overflow, possibly leading to a
seemingly successful return. With a double, it will either go to a huge value
or saturate at infinity. The system can't honour such a request, so it returns
NULL and the program refuses to process the dataset in the normal way.

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

#43525

Ken Brody <kenbrody@spamcop.net> wrote:

(snip on floating point arguments to malloc(), among others)

> So malloc() should be passed an *approximate* number of bytes to allocate?
 
>> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be
>> many years, before RAM density increases to exceed this size. Whereas, int
>> can only allocate upto 2e9 bytes.
 
> First, I wasn't aware that ints were limited to 32 bits.
 
> Second, malloc() takes size_t, not int.
 
> Finally, since the value passed to malloc() must, logically, be able to be 
> express in no more bits than the number of bits in an address, why do you 
> feel it is important to be able to pass values larger than the address 
> space, and to do so using approximate rather than exact values?

The OP should get a Burroughs B5500, though he might also have to
write the C compiler for it.

The floating point format of the B5500 is designed such that it
can also be the fixed point (integer) format.

The significand has the binary point on the right, such that it is
an integer. The exponent is not biased, such that an exponent of
zero has all bits zero. The normalization prefers a zero exponent 
if no significant bits are lost. It is word addressed with 48 bit
words, allowing for either 48 bits in floating point or 40 bits
for integers.

The normal text form is eight 6 bit characters per word, which would
not work for C's char, though.


-- glen

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

#43526

Ken Brody <kenbrody@spamcop.net> wrote:
> On 4/22/2014 1:13 PM, Raj Pashwar wrote:

(snip)
>> Of course, it does NOT make sense. However in this case, the 
>> benefit is the extra RANGE of double, not precision.
 
> So malloc() should be passed an *approximate* number of bytes 
> to allocate?
 
>> With a double arg, malloc could allocate upto 1.7e308 bytes. 
>> It will be many years, before RAM density increases to exceed 
>> this size. Whereas, int can only allocate upto 2e9 bytes.
 
> First, I wasn't aware that ints were limited to 32 bits.
 
> Second, malloc() takes size_t, not int.
 
> Finally, since the value passed to malloc() must, logically, 
> be able to be express in no more bits than the number of bits 
> in an address, why do you feel it is important to be able to 
> pass values larger than the address space, and to do so using 
> approximate rather than exact values?

Not disagreeing with the rest, but this doesn't follow.

If the addressing space requires even one more bit than the next
smallest size, that size is used for size_t.

While we now have many "64 bit" machines that allocate 64 bits
for addresses, most (or all) are physically unable to address
that many bits. To save on logic that won't be used in the life
of the actual chip, they don't put it all in. Usually some address
bits are required to be zeros (or all ones).

It is not at all unusual for an address not to be a power of two
bits wide, though the available integer types might be. 

> I just tried a simple program which shows me sizeof() for "void *", 
> "size_t", and "double".  All return 8.  On such a system, it would 
> not be possible to pass malloc() an exact value for "sufficiently 
> large" buffers, if it were passed a double rather than size_t.  
> (Or, if size_t were a double.)

Assuming 4TB swapping disks, and that you could put eight of
them on a system, you could address all the virtual memory 
with 45 bits. Physical addresses are likely smaller than that.

-- glen
 

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

#43322

jacob navia <jacob@spamsink.net> writes:

> I do not follow you. What would mean
> buffer = malloc(3.14);
>
> ????

I approve thoroughly of allocating pie.

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

#43315

Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
> 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.

There is no "default type" in C.  Certainly a lot of functions return
int, but plenty return other types.  Ideally, each returns the most
appropriate type for its semantics.  In many cases (perhaps most),
that happens to be an integer type.

There is no guarantee that double can hold all any int value.
I've worked on systems where int and double are both 64 bits, and
INT_MAX, for example, could not be stored in a double without loss
of information.

Floating-point types suffer from rounding errors.  Suppose exit(1)
indicates that the program failed.  What does exit(0.999999) mean?

malloc() takes a size_t argument, where size_t is an unsigned integer
type able to hold the size of any allocatable object.  On a 64-bit
system, size_t is likely to be 64 bits, and to be able to store
values that double cannot.  Exactly what benefit would making
malloc() take a double argument produce?  What would malloc(3.5) do?

Integer division truncates.  If I divide an integer value by 2,
I expect to get a truncated integer result, and I write code that
depends on this.  Are you going to pay me for time it takes to
adjust my code so it continues to work?

C is commonly used on small (or not so small) embedded systems,
some of which don't have hardware floating-point support.

I agree that your suggested change should be implemented as soon as
possible -- i.e., never.

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

#43316

On Tuesday, April 22, 2014 5:48:56 PM UTC+1, 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 
> 
It often makes sense to represent data as doubles, even if it is actually discrete. But index variables
should be integers, for example if you are doing a binary search then you need a rounded mean of
low and high for your next test, not the arithmetical mean.

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

#43325

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

There are a large number of algorithms that work with integers, and
not floating point values. Processors supply both data types to
allow for both kinds of algorithms. 

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.

At the time when C was new, most numerical (floating point)
algorithms were written in Fortran, and C was mostly used for
problems that didn't need, or rarely needed, floating point.
 
> 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.

On many systems, the largest integer type holds values that can't
be represented in the largest floating point type.

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. 

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.

Sometimes I write programs in AWK that could also be written
in C.  AWK has some similarity to C, but no integer data type.

-- glen

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

#43336

Stefan Ram <ram@zedat.fu-berlin.de> 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++«:
 
> #include <iostream>
> #include <ostream>
> #include <ratio>

(snip)

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

Maybe even:

printf("%r\n",r34);

-- glen

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

#43341

On 04/22/2014 03:09 PM, glen herrmannsfeldt wrote:
> Stefan Ram <ram@zedat.fu-berlin.de> 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++«:
>  
>> #include <iostream>
>> #include <ostream>
>> #include <ratio>
> 
> (snip)
> 
>> { 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.

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.

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

#43342

On 04/22/2014 03:35 PM, James Kuyper wrote:
...
> 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

That was meant to be <stdio.h>.

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

#43343

On 2014-04-22, James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/22/2014 03:09 PM, glen herrmannsfeldt wrote:
>> Stefan Ram <ram@zedat.fu-berlin.de> 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++«:
>>  
>>> #include <iostream>
>>> #include <ostream>
>>> #include <ratio>
>> 
>> (snip)
>> 
>>> { 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.

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

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

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.

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.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web