Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #4520 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-05-22 21:29 +0200 |
| Last post | 2011-06-02 15:26 -0700 |
| Articles | 20 on this page of 123 — 20 participants |
Back to article view | Back to comp.lang.c
Types in C jacob navia <jacob@spamsink.net> - 2011-05-22 21:29 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-22 12:48 -0700
Re: Types in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:03 +0100
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 10:35 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 08:40 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 17:19 +0000
Re: Types in C John Gordon <gordon@panix.com> - 2011-05-23 17:54 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:33 -0700
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:44 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:08 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 20:50 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 12:11 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:45 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:03 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:25 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 14:38 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:45 +0200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:10 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:12 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:27 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:33 +0200
Re: Types in C Martin Ambuhl <mambuhl@earthlink.net> - 2011-05-24 03:17 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 10:55 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:29 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:42 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:51 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:04 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:57 +1200
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:33 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:27 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 00:40 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 11:32 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 11:30 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 01:23 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:51 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:25 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:40 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:36 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 17:53 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:24 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:23 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:22 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 03:46 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:46 -0400
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:48 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:35 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:38 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:53 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:17 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 11:24 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:39 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 11:23 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:46 -0700
Re: Types in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-24 09:14 -0700
Re: Types in C Michael Press <rubrum@pacbell.net> - 2011-05-28 21:50 -0700
Re: Types in C "io_x" <a@b.c.invalid> - 2011-06-07 19:50 +0200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:33 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:03 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:27 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 13:47 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:45 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 00:07 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 08:05 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:54 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:03 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:12 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:03 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:19 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:20 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 00:46 -0500
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:36 -0400
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:58 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:40 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:36 -0400
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:10 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 18:19 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:42 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 23:47 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-25 10:13 -0400
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-24 22:19 -0600
Re: Types in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-25 07:04 +0100
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-25 08:53 -0700
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-25 10:11 -0600
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:02 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:37 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:15 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:25 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:39 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:10 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 01:58 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:56 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:32 +0000
Re: Types in C "BartC" <bc@freeuk.com> - 2011-05-25 01:29 +0100
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:20 -0500
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:42 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:07 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:16 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-25 03:36 +0000
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 01:26 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:04 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:06 -0700
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-05-30 22:42 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 17:45 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 08:47 -0700
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-31 13:54 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 00:16 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 18:30 -0500
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-06-02 22:44 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-06-02 22:49 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-06-02 15:26 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 13:27 -0700 |
| Message-ID | <lnsjs517sy.fsf@nuthaus.mib.org> |
| In reply to | #4585 |
jacob navia <jacob@spamsink.net> writes:
[...]
> What bothers me is that I get never a discussion about the main
> argumentation of my posts but always
>
> "Just a quibble" and the we start discussing about small details
> that are just that: details
That happens to be what I noticed. Should I not have bothered to
mention it? (Perhaps I shouldn't; I can't help noticing that you
rarely respond to me directly.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 22:33 +0200 |
| Message-ID | <ireg9p$o65$2@speranza.aioe.org> |
| In reply to | #4589 |
Le 23/05/11 22:27, Keith Thompson a écrit : > jacob navia<jacob@spamsink.net> writes: > [...] >> What bothers me is that I get never a discussion about the main >> argumentation of my posts but always >> >> "Just a quibble" and the we start discussing about small details >> that are just that: details > > That happens to be what I noticed. Should I not have bothered to > mention it? (Perhaps I shouldn't; I can't help noticing that you > rarely respond to me directly.) > The idea that you could discuss the main argumentation of my posts just doesn't even occur to you... And you CONFIRM what I say by snipping the MAIN part of my post: What about the functional definition of a type? YOU SNIPPED IT AGAIN!!! Incredible :-)
[toc] | [prev] | [next] | [standalone]
| From | Martin Ambuhl <mambuhl@earthlink.net> |
|---|---|
| Date | 2011-05-24 03:17 -0400 |
| Message-ID | <irfm3a$89i$1@dont-email.me> |
| In reply to | #4590 |
On 5/23/2011 4:33 PM, jacob navia wrote: > The idea that you could discuss the main argumentation > of my posts just doesn't even occur to you... Please stop repeating this mantra like a spoiled child. If you actually look at your "arguments' they are nothing but examples of the fallacy called "argument by assertion". You state claims and then you repeat those claims as "arguments" in support of themselves. When you actually post an actual argument, I will find the time to respond to it, whether in support, in opposition, or simply for clarification. > And you CONFIRM what I say by snipping the MAIN part of my post: The "MAIN part of your post" is a trivial restatement of your thesis and not worth bothering about.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-24 10:55 +0200 |
| Message-ID | <irfrq1$m2b$1@speranza.aioe.org> |
| In reply to | #4676 |
Le 24/05/11 09:17, Martin Ambuhl a écrit : > On 5/23/2011 4:33 PM, jacob navia wrote: > >> The idea that you could discuss the main argumentation >> of my posts just doesn't even occur to you... > > Please stop repeating this mantra like a spoiled child. If you actually > look at your "arguments' they are nothing but examples of the fallacy > called "argument by assertion". You state claims and then you repeat > those claims as "arguments" in support of themselves. When you actually > post an actual argument, I will find the time to respond to it, whether > in support, in opposition, or simply for clarification. > >> And you CONFIRM what I say by snipping the MAIN part of my post: > > The "MAIN part of your post" is a trivial restatement of your thesis and > not worth bothering about. > > Of course. "Spoiled child" "your arguments are nothing but ... fallacy" The ambuhlance is back OH despair...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 09:29 +1200 |
| Message-ID | <9401unFt2pU10@mid.individual.net> |
| In reply to | #4585 |
On 05/24/11 08:12 AM, jacob navia wrote: > > What do you think of the two definitions > (1) Functional (a type is an algorithm description) How would that work? An example would bring some clarification. > (2) Conceptual (A type embodies a concept in the program) That would be the more common use, your example of size_t for example. > And I think I am missing one: > > (3) A type implies a set of operations allowed with it. > > This would be different than (1) since (1) refers to calculating > the "value" stored in a type. > > I am sure (3) is missing but can't really identify it yet as > definitely distinct of (1). Please explain a bit more about 1). -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 23:42 +0200 |
| Message-ID | <irekbc$4dt$2@speranza.aioe.org> |
| In reply to | #4598 |
Le 23/05/11 23:29, Ian Collins a écrit : > On 05/24/11 08:12 AM, jacob navia wrote: >> >> What do you think of the two definitions >> (1) Functional (a type is an algorithm description) > > How would that work? An example would bring some clarification. > Well, in my first answer to Seebs in this thread I wrote: <quote> A first tentative, definition for what a type is, could be “a type is a definition of an algorithm for understanding a sequence of storage bits”. It gives the meaning of the data stored in memory. If we say that the object a is an int, it means that the bits stored at that location are to be understood as a natural number that is built by consecutive additions of powers of two as specified by its bits. If we say that the type of a is a double, it means that the bits are to be understood as the IEEE 754 (for instance) standard sequences of bits representing a double precision floating point value. <end quote> jacob
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 09:51 +1200 |
| Message-ID | <94036uFt2pU11@mid.individual.net> |
| In reply to | #4603 |
On 05/24/11 09:42 AM, jacob navia wrote: > Le 23/05/11 23:29, Ian Collins a écrit : >> On 05/24/11 08:12 AM, jacob navia wrote: >>> >>> What do you think of the two definitions >>> (1) Functional (a type is an algorithm description) >> >> How would that work? An example would bring some clarification. >> > > Well, in my first answer to Seebs in this thread I wrote: > > <quote> > A first tentative, definition for what a type is, could be “a type is a > definition of an algorithm for understanding a sequence of storage > bits”. It gives the meaning of the data stored in memory. If we say > that the object a is an int, it means that the bits stored at that > location are to be understood as a natural number that is built by > consecutive additions of powers of two as specified by its bits. > If we say that the type of a is a double, it means that the bits are to > be understood as the IEEE 754 (for instance) standard sequences of bits > representing a double precision floating point value. > <end quote> But that doesn't describe a algorithm. (3) A type implies a set of operations allowed with it. Comes closer. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-24 00:04 +0200 |
| Message-ID | <irell0$7nh$1@speranza.aioe.org> |
| In reply to | #4605 |
Le 23/05/11 23:51, Ian Collins a écrit :
> On 05/24/11 09:42 AM, jacob navia wrote:
>> Le 23/05/11 23:29, Ian Collins a écrit :
>>> On 05/24/11 08:12 AM, jacob navia wrote:
>>>>
>>>> What do you think of the two definitions
>>>> (1) Functional (a type is an algorithm description)
>>>
>>> How would that work? An example would bring some clarification.
>>>
>>
>> Well, in my first answer to Seebs in this thread I wrote:
>>
>> <quote>
>> A first tentative, definition for what a type is, could be “a type is a
>> definition of an algorithm for understanding a sequence of storage
>> bits”. It gives the meaning of the data stored in memory. If we say
>> that the object a is an int, it means that the bits stored at that
>> location are to be understood as a natural number that is built by
>> consecutive additions of powers of two as specified by its bits.
>> If we say that the type of a is a double, it means that the bits are to
>> be understood as the IEEE 754 (for instance) standard sequences of bits
>> representing a double precision floating point value.
>> <end quote>
>
> But that doesn't describe a algorithm.
Type: int
for (result=0,counter=0; counter<CHAR_BIT*sizeof(int);counter++) {
if (int&1)
result += (1 << counter);
}
ValueOfInt = result;
Type float
// Extract sign, mantissa and exponent.
// Apply formula
// result is value of double
Type someStruct
//At offset 0 extract first field
// At offset offsetof(second field) extract second
// etc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 10:57 +1200 |
| Message-ID | <940738Ft2pU15@mid.individual.net> |
| In reply to | #4609 |
On 05/24/11 10:04 AM, jacob navia wrote:
> Le 23/05/11 23:51, Ian Collins a écrit :
>> On 05/24/11 09:42 AM, jacob navia wrote:
>>> Le 23/05/11 23:29, Ian Collins a écrit :
>>>> On 05/24/11 08:12 AM, jacob navia wrote:
>>>>>
>>>>> What do you think of the two definitions
>>>>> (1) Functional (a type is an algorithm description)
>>>>
>>>> How would that work? An example would bring some clarification.
>>>>
>>>
>>> Well, in my first answer to Seebs in this thread I wrote:
>>>
>>> <quote>
>>> A first tentative, definition for what a type is, could be “a type is a
>>> definition of an algorithm for understanding a sequence of storage
>>> bits”. It gives the meaning of the data stored in memory. If we say
>>> that the object a is an int, it means that the bits stored at that
>>> location are to be understood as a natural number that is built by
>>> consecutive additions of powers of two as specified by its bits.
>>> If we say that the type of a is a double, it means that the bits are to
>>> be understood as the IEEE 754 (for instance) standard sequences of bits
>>> representing a double precision floating point value.
>>> <end quote>
>>
>> But that doesn't describe a algorithm.
>
> Type: int
>
> for (result=0,counter=0; counter<CHAR_BIT*sizeof(int);counter++) {
> if (int&1)
> result += (1<< counter);
> }
>
> ValueOfInt = result;
I'm sorry, but I still don't see a type defining an algorithm.
I was thinking more along the lines of "struct SomeAlgorithm" where the
struct has function pointer members that implement "some algorithm".
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-06-01 16:33 -0400 |
| Message-ID | <ap7du69s54v5di7pmjtpaqqoke93nh43rp@4ax.com> |
| In reply to | #4609 |
On Tue, 24 May 2011 00:04:16 +0200, jacob navia <jacob@spamsink.net>
wrote:
<snip: type determines values of representations=bits>
> Type: int
>
> for (result=0,counter=0; counter<CHAR_BIT*sizeof(int);counter++) {
> if (int&1)
> result += (1 << counter);
> }
>
> ValueOfInt = result;
>
int&1 is wrong unless you also shift int rightwards. You need
something like if( bits_of_int[counter] ) result += 1<<counter.
But I think writing this in C syntax is confusing; I would use either
mathematical notation (sigma for i=0 to nbits-1 of bit[i] x 2^i)
or a prose description. 1<<n is actually 2 up n, but that
is likely not clear to people reading this kind of tutorial.
*After* you understand how binary (integer) representations work,
*then* it makes sense that 1<<n is the n'th power of two.
In fact if I change the above to the most straightforward (to me)
correct C code I get:
for( value=0, bit=0; bit<CHAR_BIT*size; bit++)
if( representation & (1<<bit) ) value += 1<<bit;
return value;
which doesn't really explain much to the reader; it just says that the
integer value of some bits is the integer value of those same bits.
Finally, this is wrong for signed-int because it doesn't handle sign.
It is correct for unsigned-int, which as I said elsethread might be
the better example for a tutorial anyway.
ObPedantic: And it doesn't deal with padding bits. I wouldn't actually
explain them in a tutorial, at least not early on, because they are
rare, but I would mention the possibility.
<snip others>
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-23 19:33 -0500 |
| Message-ID | <ireqsu$8id$1@dont-email.me> |
| In reply to | #4585 |
On 5/23/2011 3:12 PM, jacob navia wrote:
> What do you think of the two definitions
> (1) Functional (a type is an algorithm description)
> (2) Conceptual (A type embodies a concept in the program)
>
> And I think I am missing one:
>
> (3) A type implies a set of operations allowed with it.
#1: Ironically, I'm not sure how this would apply to a function type or
an incomplete type.
I suppose for a function type, the algorithm could describe how
arguments are passed, given a calling convention.
Using "functional" might confuse a reader who might naively try to tie
"function type" to #1 while developing their understanding, even though
I doubt that's your intention.
#2: Sure. I'm not sure that that's a _distinguishing_ characteristic of
"type," though. I think there are a few other things which also embody
a concept in a program, including values.
enum fruit { apple, orange, banana, grapefruit };
#3: I like this one more than #1 and #2. :) A type is an attribute of
every expression, so operators can require certain types and/or can
behave in a particular manner, depending on the types of their operand
expressions.
"Type" is such a generic notion, in general, that to pin it down for
meaning in C, perhaps you'd have to build up some predicates which can
be said to be true or sometimes true of "type."
builtin, declared_where, declared, defined_where, defined,
function_or_object, complete_or_incomplete, qualifiers, qualified, size,
has_size, alignment, has_alignment, names_and_aliases, is_named, etc.
A type can also be [ab]used to accomplish other things, such as forcing
diagnostic messages or being used with 'sizeof' merely to carry a
constant value around.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 08:27 -0700 |
| Message-ID | <ln39k415lp.fsf@nuthaus.mib.org> |
| In reply to | #4585 |
jacob navia <jacob@spamsink.net> writes:
[...]
> What bothers me is that I get never a discussion about the main
> argumentation of my posts but always
>
> "Just a quibble" and the we start discussing about small details
> that are just that: details
Details are important. If I don't comment on your main point,
it's usually because I don't have much to say about it.
You've got perhaps a dozen people commenting on your posts, and
nearly 7 billion saying nothing at all -- but you choose to complain
about the ones who've actually taken the time to comment.
If you want me to spend my time discussing what you're interested
in, we can discuss consulting rates.
> What do you think of the two definitions
> (1) Functional (a type is an algorithm description)
> (2) Conceptual (A type embodies a concept in the program)
>
> And I think I am missing one:
>
> (3) A type implies a set of operations allowed with it.
>
> This would be different than (1) since (1) refers to calculating
> the "value" stored in a type.
>
> I am sure (3) is missing but can't really identify it yet as
> definitely distinct of (1).
The idea of a type being an algorithm doesn't seem quite right, even
after reading some of the followups in this thread. There might be any
number of algorithms associated with a type. I think you're thinking of
an algorithm whose end result tells us the meaning of a value, but I'd
say it's that meaning, rather than the method used to determine it,
that's significant.
The standard's definition of "type" is probably a decent starting point.
C99 6.2.5p1:
The meaning of a value stored in an object or returned by a
function is determined by the *type* of the expression used
to access it. (An identifier declared to be an object is
the simplest such expression; the type is specified in the
declaration of the identifier.)
Like many of the standard's "definitions", it's not really a definition.
It's a statement about types, not a statement of exactly what the word
"type" means.
For a tutorial, I might write something like:
A stored value consists of a collection of bits. A *type*
is what determines the meaning of that collection of bits.
For example, a 32-bit object containing the bits:
1000000010010010000111111011011
might represent the integer value 1078530011, the floating-point
value 3.1415927 (approximately), or a pointer value, depending
on the type of the object.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-05-31 00:40 -0700 |
| Message-ID | <kfn8vtnqpvh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #4585 |
jacob navia <jacob@spamsink.net> writes: >[snip] > > What do you think of the two definitions > (1) Functional (a type is an algorithm description) > (2) Conceptual (A type embodies a concept in the program) (2) is not definitional. It might be appropriate to discuss this idea as part of how/why different types are used, but it should not be part of defining what a type is. (1) has more of a definitional flavor, but the particulars are wrong in the context of C. Types in C are actually fairly complicated beasts, but in essence a type is a set of abstract values (the carrier set of the type) and a mapping (in the mathematical sense) between the abstract values and how those values are represented within the computer. (Types in C also include an identity so we can talk about two types being "the same type" or "different types" even when the carrier sets and the mappings are the same.) The relationship between abstract values and their representations is better and more usually expressed as a mapping, not by giving an algorithm. > And I think I am missing one: > > (3) A type implies a set of operations allowed with it. > > This would be different than (1) since (1) refers to calculating > the "value" stored in a type. > > I am sure (3) is missing but can't really identify it yet as > definitely distinct of (1). Here again this is not definitional. Certainly it is true that certain operations will work with certain types (or certain combinations of types), but types have meaning whether operations that work on those types exist or not. The relationship between types and operations should be discussed separately from explaining the idea of a type and defining what a type is.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-31 11:32 +0200 |
| Message-ID | <is2cjg$2oe$1@speranza.aioe.org> |
| In reply to | #5088 |
Le 31/05/11 09:40, Tim Rentsch a écrit :
> jacob navia<jacob@spamsink.net> writes:
>
>> [snip]
>>
>> What do you think of the two definitions
>> (1) Functional (a type is an algorithm description)
>> (2) Conceptual (A type embodies a concept in the program)
>
> (2) is not definitional. It might be appropriate to
> discuss this idea as part of how/why different types
> are used, but it should not be part of defining what a
> type is.
>
Yes, I have dropped that, replacing it with a "format",
not an algorithm. "int" would be a format (sign bit,
value, two's complement, etc)
> (1) has more of a definitional flavor, but the particulars
> are wrong in the context of C. Types in C are actually
> fairly complicated beasts, but in essence a type is a
> set of abstract values (the carrier set of the type) and
> a mapping (in the mathematical sense) between the abstract
> values and how those values are represented within the
> computer. (Types in C also include an identity so we can
> talk about two types being "the same type" or "different
> types" even when the carrier sets and the mappings are the
> same.) The relationship between abstract values and their
> representations is better and more usually expressed as a
> mapping, not by giving an algorithm.
>
Interesting. You would say then that int is a subset of the
natural integers from INT_MIN to INT_MAX. That would be the
mathematical definition.
Character strings would be
A character string would be a sequence of integers from
CHAR_MIN to CHAR_MAX of undetermined length followed by a zero.
Floating point would be a sequence of integers too:
boolean sign
integer exponent (possibly biased)
integer mantissa
Is that what you mean?
And what about
struct customer{char *name;double balance; }; ???
>
>> And I think I am missing one:
>>
>> (3) A type implies a set of operations allowed with it.
>>
>> This would be different than (1) since (1) refers to calculating
>> the "value" stored in a type.
>>
>> I am sure (3) is missing but can't really identify it yet as
>> definitely distinct of (1).
>
> Here again this is not definitional. Certainly it is true
> that certain operations will work with certain types (or
> certain combinations of types), but types have meaning
> whether operations that work on those types exist or not.
Well, operations have meaning too: 2+2 has a very concrete meaning...
> The relationship between types and operations should be
> discussed separately from explaining the idea of a type
> and defining what a type is.
IF we assume a mathematical description of a type. It can be
done for some primitive types but not with user defined types.
In any case thanks for your answer, it is an interesting viewpoint.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-31 11:30 -0700 |
| Message-ID | <lntycaoh8h.fsf@nuthaus.mib.org> |
| In reply to | #5095 |
jacob navia <jacob@spamsink.net> writes:
> Le 31/05/11 09:40, Tim Rentsch a écrit :
[...]
>> (1) has more of a definitional flavor, but the particulars
>> are wrong in the context of C. Types in C are actually
>> fairly complicated beasts, but in essence a type is a
>> set of abstract values (the carrier set of the type) and
>> a mapping (in the mathematical sense) between the abstract
>> values and how those values are represented within the
>> computer. (Types in C also include an identity so we can
>> talk about two types being "the same type" or "different
>> types" even when the carrier sets and the mappings are the
>> same.) The relationship between abstract values and their
>> representations is better and more usually expressed as a
>> mapping, not by giving an algorithm.
>>
>
> Interesting. You would say then that int is a subset of the
> natural integers from INT_MIN to INT_MAX. That would be the
> mathematical definition.
Yes, in part, but that doesn't capture the identity relationship
Tim mentioned. If that were the definition, then int and long would
be the same type if INT_MIN and INT_MAX happen to equal LONG_MIN
and LONG_MAX.
I'd say that representation is also part of what a type is. Type
int isn't just a set of mathematical integers, it's also a mapping
between certain bit patterns and those mathematical integers
This is probably getting too abstruse for an introductory tutorial.
In general, if I were trying to define a term for a C tutorial,
I'd either use the C standard's definition directly, or at least
use it as a starting point for a more beginner-friendly definition.
C's definition of "type" is in 6.2.5p1 (though, as I mentioned
before, it's not really a definition, a flaw it shares with a number
of other "definitions" in the C standard).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-06-01 01:23 -0700 |
| Message-ID | <kfntycaneo1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #5095 |
jacob navia <jacob@spamsink.net> writes:
> Le 31/05/11 09:40, Tim Rentsch a @C3{A9}crit :
>> jacob navia<jacob@spamsink.net> writes:
>>
>>> [snip]
>>>
>>> What do you think of the two definitions
>>> (1) Functional (a type is an algorithm description)
>>> (2) Conceptual (A type embodies a concept in the program)
>>
>> (2) is not definitional. It might be appropriate to
>> discuss this idea as part of how/why different types
>> are used, but it should not be part of defining what a
>> type is.
>>
>
> Yes, I have dropped that, replacing it with a "format",
> not an algorithm. "int" would be a format (sign bit,
> value, two's complement, etc)
>
>> (1) has more of a definitional flavor, but the particulars
>> are wrong in the context of C. Types in C are actually
>> fairly complicated beasts, but in essence a type is a
>> set of abstract values (the carrier set of the type) and
>> a mapping (in the mathematical sense) between the abstract
>> values and how those values are represented within the
>> computer. (Types in C also include an identity so we can
>> talk about two types being "the same type" or "different
>> types" even when the carrier sets and the mappings are the
>> same.) The relationship between abstract values and their
>> representations is better and more usually expressed as a
>> mapping, not by giving an algorithm.
>>
>
> Interesting. You would say then that int is a subset of the
> natural integers from INT_MIN to INT_MAX.
Yes, plus the mapping between those integers (not natural
integers, just integers) and their representations.
> That would be the mathematical definition.
It's a more formal sort of definition. It isn't "mathematical",
since there is no mathematics that goes with it.
> A character string would be a sequence of integers from
> CHAR_MIN to CHAR_MAX of undetermined length followed by a zero.
In fact "character string" is not a type. But a character array
is fixed-length sequence of _characters_, whose abstract values
are represented by binary-encoded integers. It's convenient to
operate on the integer representations, but the abstract values
are actually "characters" (or a sequence of characters for
character arrays). Here is another reason why 'char' is a
distinct type from both 'signed char' and 'unsigned char' --
the abstract values of 'char' are not integers but characters.
> Floating point would be a sequence of integers too:
> boolean sign
> integer exponent (possibly biased)
> integer mantissa
No, that's representation again. A floating-point type
is a set of real numbers (all of which are rational),
plus the formats, etc, for how each real number in the
set is represented (sign, exponent, etc).
> Is that what you mean?
As explained further above, yes.
> And what about
> struct customer{char *name;double balance; }; ???
An ordered pair of two values that belong to the sets
of abstract values of the types of the members, plus
how an abstract ordered pair maps to a struct in memory.
>>> And I think I am missing one:
>>>
>>> (3) A type implies a set of operations allowed with it.
>>>
>>> This would be different than (1) since (1) refers to calculating
>>> the "value" stored in a type.
>>>
>>> I am sure (3) is missing but can't really identify it yet as
>>> definitely distinct of (1).
>>
>> Here again this is not definitional. Certainly it is true
>> that certain operations will work with certain types (or
>> certain combinations of types), but types have meaning
>> whether operations that work on those types exist or not.
>
> Well, operations have meaning too: 2+2 has a very concrete meaning...
The key point is types don't need operations for their
definitions.
>> The relationship between types and operations should be
>> discussed separately from explaining the idea of a type
>> and defining what a type is.
>
> IF we assume a mathematical description of a type.
It doesn't have to do with whether the description is
"mathematical" or not. It's because in C types are not
defined by operations.
> It can be
> done for some primitive types but not with user defined types.
User-defined types (that is, structs and unions) actually
are quite easy to define without including or mentioning
operations.
The difficult case is pointers, because it's hard to understand
what the abstract values for a pointer type mean without
reference to what goes on in an execution environment. Furthmore
there is an aspect of type that doesn't show up in C's type
system related to lvalue-ness. For example, if we have 'int i;',
then 'i' and '43' are both of type 'int', but '&i' results in a
pointer to int, whereas '&43' is just gibberish.
> In any case thanks for your answer, it is an interesting viewpoint.
You're welcome, I'm glad it was helpful.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-23 16:51 -0400 |
| Message-ID | <43d4ef5f7d2b0f9-0f635@gmail.com> |
| In reply to | #4582 |
On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote: > On 2011-05-23, Keith Thompson <kst-u@mib.org> wrote: > > Just a quibble: size_t may be exactly the same type as unsigned long, > > since a typedef merely creates an alias for an existing type, not > > a new and distinct type. plain char and signed char (for example) > > are distinct in a way that size_t and unsigned long (for example) > > are not. > > True. Although, possibly confusingly, there are places where it seems > that the thing a typedef creates is itself then called "a type". The > wording is a bit fuzzy. > > We all know what we mean, I think. You could say it several ways: > > Typedef does not actually create types; instead, it creates > names which refer to existing types. > > Typedef creates types, but those types are identical to existing > types and can be used interchangably with them. How about the idea that typedefs create aliases for the basic built-in types supplied by the language spec.? [snip] > And that's why I tend to treat C *as if* that were true, because the only > code which I regard as "broken" which isn't broken according to the C type > system is generally bad code, and it prevents me from doing stupid things > as much. A language that protects you from doing dumb things is good, but flexibility is sacrificed as a consequence. How much of an issue this is for you depends on what your expectations are in regards to type enforcement. I wonder if Perl or Python could do the same integer pointer cast as I use to account for the free list in the allocator code I posted previously. My suspicion is that it would be fairly difficult to do in those languages. Worse, comp-sci profs (especially Pascal weenies) would hate it, I suspect, and would give a failing grade if anyone ever did something like that in their class. IMO, C is properly thought of as portable assembler, with the caveat that it gives you enough rope to be as HLL as you want it to be. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 09:25 +1200 |
| Message-ID | <9401m9Ft2pU9@mid.individual.net> |
| In reply to | #4592 |
On 05/24/11 08:51 AM, Uncle Steve wrote: > On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote: >> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote: >>> Just a quibble: size_t may be exactly the same type as unsigned long, >>> since a typedef merely creates an alias for an existing type, not >>> a new and distinct type. plain char and signed char (for example) >>> are distinct in a way that size_t and unsigned long (for example) >>> are not. >> >> True. Although, possibly confusingly, there are places where it seems >> that the thing a typedef creates is itself then called "a type". The >> wording is a bit fuzzy. >> >> We all know what we mean, I think. You could say it several ways: >> >> Typedef does not actually create types; instead, it creates >> names which refer to existing types. >> >> Typedef creates types, but those types are identical to existing >> types and can be used interchangably with them. > > How about the idea that typedefs create aliases for the basic built-in > types supplied by the language spec.? A typedef may provide an alias to any existing type, built-in, user defined or even incomplete. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 23:40 +0200 |
| Message-ID | <irek8e$4dt$1@speranza.aioe.org> |
| In reply to | #4597 |
Le 23/05/11 23:25, Ian Collins a écrit :
> On 05/24/11 08:51 AM, Uncle Steve wrote:
>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
>>> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote:
>> How about the idea that typedefs create aliases for the basic built-in
>> types supplied by the language spec.?
>
> A typedef may provide an alias to any existing type, built-in, user
> defined or even incomplete.
>
True, but the PURPOSE of typedefs is to HIDE the underlying type so that
source code refers to it INDIRECTLY.
The purpose of that indirection is twofold:
(1) To highlight a CONCEPT of the program:
typedef double CustomerBalance;
(2) To make code portable by abstracting the underlying type
away. (size_t for instance)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 08:36 -0700 |
| Message-ID | <lny61wyust.fsf@nuthaus.mib.org> |
| In reply to | #4602 |
jacob navia <jacob@spamsink.net> writes:
> Le 23/05/11 23:25, Ian Collins a écrit :
>> On 05/24/11 08:51 AM, Uncle Steve wrote:
>>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
>>>> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote:
>>> How about the idea that typedefs create aliases for the basic built-in
>>> types supplied by the language spec.?
>>
>> A typedef may provide an alias to any existing type, built-in, user
>> defined or even incomplete.
>>
>
> True, but the PURPOSE of typedefs is to HIDE the underlying type so that
> source code refers to it INDIRECTLY.
>
> The purpose of that indirection is twofold:
> (1) To highlight a CONCEPT of the program:
> typedef double CustomerBalance;
>
> (2) To make code portable by abstracting the underlying type
> away. (size_t for instance)
The purpose of a typedef is whatever the programmer wants to use it for.
It can be used simply to provide a shorter name for an existing type.
For example:
typedef unsigned long ulong;
typedef struct foo {
/* member declarations */
} foo;
Neither ulong nor foo provides an abstraction; they're both just
aliases.
Typedefs can certainly be *used* for the purposes you describe,
and a tutorial can and should discuss that. But if you want your
readers to understand the concept, I suggest that that should
include an understanding of what typedef means on the language level.
You are conflating the manner in which typedef is *used* with the
way the language defines it.
Incidentally, I've said that a typedef is an alias, and you've agreed
that that's what it does (see above), yet you insist that I'm wrong.
I think we're actually in agreement. Perhaps you'd be able to
acknowledge that if this were coming from someone other than me.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web