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

Groups > comp.lang.misc > #2067 > unrolled thread

C: 100 Things

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

Contents

  C: 100 Things "BartC" <bc@freeuk.com> - 2014-04-29 17:57 +0100
    Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 07:40 +0100
      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 12:16 +0100
        Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 13:54 +0100
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 14:39 +0100
            Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 20:18 +0100
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 22:40 +0100
                Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-04-30 22:09 +0000
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 23:36 +0100
                    Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:03 +1200
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:47 +0100
                Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-01 00:35 +0100
                  Re: 100 Things Andy Walker <news@cuboid.co.uk> - 2014-05-01 11:03 +0100
                    Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 20:16 +0100
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 12:44 +0100
                    Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 11:11 +0100
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 13:32 +0100
                        Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 16:42 +0100
                          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 17:54 +0100
            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:01 +1200
        Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 21:13 -0400
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:26 +0100
            Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
        Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 13:42 +1200
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:35 +0100
            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 21:02 +1200
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 10:40 +0100
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 22:06 +1200
            Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 11:08 +0200
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 11:02 +0100
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 13:57 +0200
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 15:12 +0100
                    Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 17:18 +0200
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 17:04 +0100
                        Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:30 +0000
                          Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-02 08:30 +1200
                              Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 01:29 -0400
                                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 02:37 -0400
                                  Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 15:39 -0400
                                    Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 17:30 -0400
                                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-04 20:05 +1200
                                  Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-04 13:28 -0400
                                    Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-05 07:40 +1200
                        Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 22:00 +0200
                          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 23:24 +0100
                            Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 08:59 +0200
                              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 09:53 +0100
                                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 11:22 +0200
                      Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:26 +0000
                        Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                          Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-02 02:49 +0000
    Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 22:08 -0400
    Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-25 23:53 +0100
      Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 05:38 -0400
        Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-26 13:51 +0100
          Re: C: 100 Things rick.c.hodgin@gmail.com - 2014-10-25 04:48 -0700
    Re: C: 100 Things "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-10-25 04:50 -0700

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

#2171 — Re: 100 Things

On Sat, 03 May 2014 15:39:17 -0400, George Neuner <gneuner2@comcast.net>  
wrote:
> On Sat, 03 May 2014 02:37:54 -0400, "Rod Pemberton"
> <dont_use_email@xnothavet.cqm> wrote:
>> On Sat, 03 May 2014 01:29:10 -0400, George Neuner <gneuner2@comcast.net>
>> wrote:

>>> Rod is correct that C defines 'byte' as a minimal addressable unit and
>>> defines characters as data which fits into a byte.
>>
>> Oh, I thought Ian was saying I made the wrong assumption on which
>> languages were being discussed.  I thought C, C++, and variations
>> were under discussion.  So, I was going to go back and check what
>> languages were being discussed, but didn't.
>>
>> Before that, I thought Kaz was saying C didn't support sizes other
>> than 8, 16, 32, 64, which it can.  Standardized microprocessor
>> architecture is what lends itself to 8-bits and multiples.
>
> I haven't seen the whole thread, but ISTM Kaz [will correct me I'm
> sure] is arguing that C doesn't have mechanism to semantically define
> new numeric types (or subtypes), so programmers are de facto
> constrained to those types that C provides.
>

True.

Oh, wow, okay, maybe *I* should re-read the entire thread ... ;-)

> Which is true with the minor exception that you can abuse bitfields to
> create a restricted width integer.  It doesn't buy you very much
> because bitfields are restricted to register width [or less!] and the
> result still is just a C integer with the same semantics only having a
> smaller +/- range and maybe slower access.

Yeah, I always thought the problem was that C doesn't have a carry
flag even though most microprocessors do.  In assembly, you can use
the carry flag to construct larger integers from smaller ones.  In C,
the code to do that is a bit of a mess.

> E.g., there is no way to define your new integer type to have
> different semantics such as arbitrary range, or a range with gaps, or
> saturation vs wrap-around arithmetic, or overflow signaling, etc.

True.

You're limited to what C provides, or whatever you can concoct.
There is no formal method to extend the language proper.


Rod Pemberton

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

#2172 — Re: 100 Things

George Neuner wrote:
> On Fri, 02 May 2014 08:30:49 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> Rod Pemberton wrote:
>>> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>>>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>>
>>>>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>>>>
>>>>>> And those that don't, you program in another language... Right?
>>>>>
>>>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>>>> and so> does Java.
>>>>
>>>> These languages support *only* these types.
>>>>
>>>
>>> By "these languages", I'm assuming you mean C/C++ and derivatives.
>>
>> Your understanding is arse about face.
>
> Rod is correct ...

I was referring to the By "these languages" in reply to "C# supports 8, 
16, 32 and (I assume) 64-bit data types, and so does Java.".

-- 
Ian Collins

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

#2173 — Re: 100 Things

On Sun, 04 May 2014 20:05:11 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>George Neuner wrote:
>> On Fri, 02 May 2014 08:30:49 +1200, Ian Collins <ian-news@hotmail.com>
>> wrote:
>>
>>> Rod Pemberton wrote:
>>>> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>>>>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>>>
>>>>>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>>>>>
>>>>>>> And those that don't, you program in another language... Right?
>>>>>>
>>>>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>>>>> and so> does Java.
>>>>>
>>>>> These languages support *only* these types.
>>>>>
>>>>
>>>> By "these languages", I'm assuming you mean C/C++ and derivatives.
>>>
>>> Your understanding is arse about face.
>>
>> Rod is correct ...
>
>I was referring to the By "these languages" in reply to "C# supports 8, 
>16, 32 and (I assume) 64-bit data types, and so does Java.".

Regardless, you could have said it more nicely.  ;-)


Both C# and Java are C derived [at least in part], their numerics have
*similar* semantics to C numerics, and they share C's inability to
define new numeric types/subtypes with differing behavior.

IMO the respective numeric behaviors of C, C++, C# and Java all can
legitimately be lumped together under the heading "C-like".  YMMV.

Before you respond, let me say that defining a new object that
encapsulates and manipulates a value is not the same as defining a new
type of value.  It is ad hoc, error prone and, because none of these
languages [that phrase again 8-)] define their numeric tower in terms
of objects, correct substitution use of your new "type" can't be
verified in all situations.

George

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

#2175 — Re: 100 Things

George Neuner wrote:
> On Sun, 04 May 2014 20:05:11 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> George Neuner wrote:
>>> On Fri, 02 May 2014 08:30:49 +1200, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>>>
>>>> Rod Pemberton wrote:
>>>>> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>>>>>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>>>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>>>>
>>>>>>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>>>>>>
>>>>>>>> And those that don't, you program in another language... Right?
>>>>>>>
>>>>>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>>>>>> and so> does Java.
>>>>>>
>>>>>> These languages support *only* these types.
>>>>>>
>>>>>
>>>>> By "these languages", I'm assuming you mean C/C++ and derivatives.
>>>>
>>>> Your understanding is arse about face.
>>>
>>> Rod is correct ...
>>
>> I was referring to the By "these languages" in reply to "C# supports 8,
>> 16, 32 and (I assume) 64-bit data types, and so does Java.".
>
> Regardless, you could have said it more nicely.  ;-)

Where I come from, my reply would have been considered polite!

> Both C# and Java are C derived [at least in part], their numerics have
> *similar* semantics to C numerics, and they share C's inability to
> define new numeric types/subtypes with differing behavior.
>
> IMO the respective numeric behaviors of C, C++, C# and Java all can
> legitimately be lumped together under the heading "C-like".  YMMV.
>
> Before you respond, let me say that defining a new object that
> encapsulates and manipulates a value is not the same as defining a new
> type of value.  It is ad hoc, error prone and, because none of these
> languages [that phrase again 8-)] define their numeric tower in terms
> of objects, correct substitution use of your new "type" can't be
> verified in all situations.

I wouldn't lump C++ in with those (!) languages, given one of the 
language design goals is to enable user defined objects to behave as a 
built in type.  The use of a class template for complex numbers is a 
good example of this put to use.

-- 
Ian Collins

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

#2117 — Re: 100 Things

On Thu, 1 May 2014 17:04:22 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
> 
>>> Because 7-bits isn't a likely memory-width size.
>>
>> 1-bit of Boolean isn't either. So what?
> 
> OK, if we extend it a little to include sub-byte types, then in the sequence 
> 1, 2, 4, 8, 16, 32, 64 bits, 8 or 16 are still the best choices.

No, they are not. Bit size is pretty much irrelevant for wast majority of
programming problems.

In the cases where memory layout is relevant (e.g. I/O), bit size is not
sufficient.

>>> You need to find out what those types actually mean. Usually the API will
>>> not tell you.
>>
>> Ah, but they do:
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
> 
> Thanks. When I first delved into this, I didn't have the internet. But 
> notice that the sizes, when given, are in terms of bits, and whether signed 
> or unsigned. It would be simplest if the language to be used for interfacing 
> to it could also define its own types the same way. In the language /you're/ 
> proposing, it would be difficult.

Why should it be difficult? I didn't say that memory layout should not be
controllable in some cases. But defining types in terms of layout is
rubbish.

You must *always* specify the type in terms of the semantics of its values,
e.g. range, if we consider ranged integer types.

You may add representation constraints to the above, if and only if
necessary, which is well beyond under 1% of all cases. 

>>>> As it does not make sense for numeric types in general.
>>>
>>> Yes it does.
>>
>> Again, complex numbers *are* numbers.
> 
> Most people who are not mathematicians would disagree (actually most people 
> would not know what a complex number is).

In that case they don't know what number is, and should probably avoid
using numbers.
 
> (BTW what /is/ the largest value that can be represented in IEEE 754 64-bit 
> floating point, which is not Inf?)

The largest value is ( 2 - 1 / 2**52 ) *  2**1023

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2125 — Re: 100 Things

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1tzmth5camkrp.dc82q58olxqa$.dlg@40tude.net...
> On Thu, 1 May 2014 17:04:22 +0100, BartC wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>
>>>> Because 7-bits isn't a likely memory-width size.
>>>
>>> 1-bit of Boolean isn't either. So what?
>>
>> OK, if we extend it a little to include sub-byte types, then in the
>> sequence
>> 1, 2, 4, 8, 16, 32, 64 bits, 8 or 16 are still the best choices.
>
> No, they are not. Bit size is pretty much irrelevant for wast majority of
> programming problems.

Bit size is everywhere. Even OSes are marketed as 16-, 32- and 64-bit. IP
addresses are 32 or 128 bits. Processors are generally 8 to 64 bits. Unix
date stamps are 64-bits. Pointers are 32 or 64 bits. UTF-8/16/32 use
8/16/32-bit strings. Files sizes will be 32 or 64 bits. Audio quality is 8
or 16 bits. Digital video is 8-bits per channel.

So everyone is aware of this stuff, even the general public, yet you seem
insistent on keeping programmers away from knowing all these technical
details?

>> Thanks. When I first delved into this, I didn't have the internet. But
>> notice that the sizes, when given, are in terms of bits, and whether
>> signed
>> or unsigned. It would be simplest if the language to be used for
>> interfacing
>> to it could also define its own types the same way. In the language
>> /you're/
>> proposing, it would be difficult.
>
> Why should it be difficult? I didn't say that memory layout should not be
> controllable in some cases. But defining types in terms of layout is
> rubbish.
>
> You must *always* specify the type in terms of the semantics of its
> values,
> e.g. range, if we consider ranged integer types.

OK so, you have that 16-bit WORD type (unsigned not signed as I'd thought).
You need it in the middle of a struct so it's got to be the right width.
Have would *you* define such a type, in whatever language idiom you like?
(But using a range restraint such as 0 to 65535 might not work, as this is 
not guaranteed to be 16-bits, nor offset as you'd expect.)

>> (BTW what /is/ the largest value that can be represented in IEEE 754
>> 64-bit
>> floating point, which is not Inf?)
>
> The largest value is ( 2 - 1 / 2**52 ) *  2**1023

So just shy of 2**1024. And around 1.7e308, pretty much what C's DBL_MAX is
reported as on my x86 machine,  and what my 'real.max' will tell me.

Why were you saying, if I understood you correctly, that this is
meaningless? With regard to complex types, then each component would have
the same limit.

-- 
Bartc 

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

#2133 — Re: 100 Things

On Thu, 1 May 2014 23:24:26 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1tzmth5camkrp.dc82q58olxqa$.dlg@40tude.net...
>> On Thu, 1 May 2014 17:04:22 +0100, BartC wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>>
>>>>> Because 7-bits isn't a likely memory-width size.
>>>>
>>>> 1-bit of Boolean isn't either. So what?
>>>
>>> OK, if we extend it a little to include sub-byte types, then in the
>>> sequence 1, 2, 4, 8, 16, 32, 64 bits, 8 or 16 are still the best choices.
>>
>> No, they are not. Bit size is pretty much irrelevant for wast majority of
>> programming problems.
> 
> Bit size is everywhere.
[...]
> So everyone is aware of this stuff, even the general public, yet you seem
> insistent on keeping programmers away from knowing all these technical
> details?

Knowing? I had an impression that you wanted making programmers *dependent*
on these irrelevant details. Why should my program be *semantically* (sic!)
dependent on the width of the memory bus?

>>> Thanks. When I first delved into this, I didn't have the internet. But
>>> notice that the sizes, when given, are in terms of bits, and whether signed
>>> or unsigned. It would be simplest if the language to be used for interfacing
>>> to it could also define its own types the same way. In the language /you're/
>>> proposing, it would be difficult.
>>
>> Why should it be difficult? I didn't say that memory layout should not be
>> controllable in some cases. But defining types in terms of layout is
>> rubbish.
>>
>> You must *always* specify the type in terms of the semantics of its values,
>> e.g. range, if we consider ranged integer types.
> 
> OK so, you have that 16-bit WORD type (unsigned not signed as I'd thought).
> You need it in the middle of a struct so it's got to be the right width.
> Have would *you* define such a type, in whatever language idiom you like?

WORD is a modular type of 2**16 modulo. How the compiler represents it, I
don't care 99% of the time, if there is no requirement regarding this.

> (But using a range restraint such as 0 to 65535 might not work, as this is 
> not guaranteed to be 16-bits, nor offset as you'd expect.)

Of course it does. Here is an example in Ada, which deals with these issues
right:

   type WORD is mod 2**16;

This defines type semantics, most people stop here.

But for Windows API, specifically, add:

   for WORD'Size use 16;

This does not change the type semantics, it puts a *representation*
constraint on its implementation. This also makes the program non-portable
for the machines where this constraint cannot be satisfied. Such machines
exist, e.g. DSP where memory unit size is 32. But I don't care here,
because there is no Windows on DSP.

Note, a fundamental language design principle:

   Separation of implementation and interface, representation and semantics

>>> (BTW what /is/ the largest value that can be represented in IEEE 754
>>> 64-bit floating point, which is not Inf?)
>>
>> The largest value is ( 2 - 1 / 2**52 ) *  2**1023
> 
> So just shy of 2**1024. And around 1.7e308, pretty much what C's DBL_MAX is
> reported as on my x86 machine,  and what my 'real.max' will tell me.
> 
> Why were you saying, if I understood you correctly, that this is
> meaningless?

I didn't say it is. I said it is ambiguous. When you clarified, that you
wanted a number of the following properties:

1. Real number (+Inf is not a real number)
2. Maximal number (there is no maximal real number)
3. Representable number (which makes 2 working, because IEEE double
precision values set is finite)

then I gave you the answer.

Now, forget all this, and imagine a programmer reading F'Max in the
program. How does he know is it 1+2+3 or only 2+3?

> With regard to complex types, then each component would have
> the same limit.

Huh, let it be polar Complex numbers: (r, f) = r * exp (j * Pi * f). There
is no limit of f in the sense r had.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2137 — Re: 100 Things

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1gmyk53pswewo$.1b5zpy5w0ksc4$.dlg@40tude.net...
> On Thu, 1 May 2014 23:24:26 +0100, BartC wrote:

>> OK so, you have that 16-bit WORD type (unsigned not signed as I'd
>> thought).
>> You need it in the middle of a struct so it's got to be the right width.
>> Have would *you* define such a type, in whatever language idiom you like?
>
> WORD is a modular type of 2**16 modulo. How the compiler represents it, I
> don't care 99% of the time, if there is no requirement regarding this.
>
>> (But using a range restraint such as 0 to 65535 might not work, as this
>> is
>> not guaranteed to be 16-bits, nor offset as you'd expect.)
>
> Of course it does. Here is an example in Ada, which deals with these
> issues
> right:
>
>   type WORD is mod 2**16;
>
> This defines type semantics, most people stop here.
>
> But for Windows API, specifically, add:
>
>   for WORD'Size use 16;
>
> This does not change the type semantics, it puts a *representation*
> constraint on its implementation. This also makes the program non-portable
> for the machines where this constraint cannot be satisfied. Such machines
> exist, e.g. DSP where memory unit size is 32. But I don't care here,
> because there is no Windows on DSP.

OK so in the end, it ends up specifying the same thing: unsigned (mod),
width 16 ('Size 16). In addition you have the ability to specify 'mod'
behaviour independently of what happens naturally in the hardware (so long
as 'Size is sufficient); in this case you've made them equivalent.

I just don't have the luxury (in the kind of C-class language I'm talking
about) of having a totally separate type model from that I would generally
expect to be provided in the hardware. At least not for primitive numeric
types. I start off with the expected set of hardware-provided numeric types,
perhaps extend them in either direction a little (shorter and longer) and
use largely the behaviours they are already expected to have, again extended
a little.

Maybe in another language I can do that (actually I do have a higher level
language, a dynamic one, but that just concerns itself a lot less with such
matters (unless it has to talk to Win32 again...); it's not interested in
having a type-system which can define different classes of numeric types. In
fact it deliberately prohibits defining new numeric types for the sake of
simplicity.)

All it comes down to, is some of us choose not to program in Ada. (It's a
good thing that some people do, to end up with robust, safe software which
necessarily has had a lot of thought go into it, but some people want to be 
able to program more informally and with smaller, simpler tools.)

Also some of us are not mathematicians. (Clearly you would prefer that only
mathematicians ought to be allowed to program.)

-- 
Bartc 

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

#2138 — Re: 100 Things

On Fri, 2 May 2014 09:53:20 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1gmyk53pswewo$.1b5zpy5w0ksc4$.dlg@40tude.net...
>> On Thu, 1 May 2014 23:24:26 +0100, BartC wrote:
> 
>>> OK so, you have that 16-bit WORD type (unsigned not signed as I'd
>>> thought).
>>> You need it in the middle of a struct so it's got to be the right width.
>>> Have would *you* define such a type, in whatever language idiom you like?
>>
>> WORD is a modular type of 2**16 modulo. How the compiler represents it, I
>> don't care 99% of the time, if there is no requirement regarding this.
>>
>>> (But using a range restraint such as 0 to 65535 might not work, as this
>>> is
>>> not guaranteed to be 16-bits, nor offset as you'd expect.)
>>
>> Of course it does. Here is an example in Ada, which deals with these
>> issues
>> right:
>>
>>   type WORD is mod 2**16;
>>
>> This defines type semantics, most people stop here.
>>
>> But for Windows API, specifically, add:
>>
>>   for WORD'Size use 16;
>>
>> This does not change the type semantics, it puts a *representation*
>> constraint on its implementation. This also makes the program non-portable
>> for the machines where this constraint cannot be satisfied. Such machines
>> exist, e.g. DSP where memory unit size is 32. But I don't care here,
>> because there is no Windows on DSP.
> 
> OK so in the end, it ends up specifying the same thing: unsigned (mod),
> width 16 ('Size 16).

Yup, this is what we wanted it to be.

> In addition you have the ability to specify 'mod'
> behaviour independently of what happens naturally in the hardware (so long
> as 'Size is sufficient); in this case you've made them equivalent.

No, I first specify mod (type semantics), and, then, very, extremely
rarely, constrain the Size of its instances.

> I start off with the expected set of hardware-provided numeric types,
> perhaps extend them in either direction a little (shorter and longer) and
> use largely the behaviours they are already expected to have, again extended
> a little.

And the point was that this was a language design fault.

BTW, C tried to avoid this by introducing types blind types int, char, etc.
This by no means was a cure, because it replaced arbitrary semantics of
INTEGER*4 (in FORTRAN-IV) with ill-defined one of int.

I don't know what is worse, programming in terms of machine-specific types
or in terms of ill-defined types. Both is wrong.

> All it comes down to, is some of us choose not to program in Ada.

No. It is about language design principles.

> Also some of us are not mathematicians. (Clearly you would prefer that only
> mathematicians ought to be allowed to program.)

Not at all. On the contrary, it is a mystery to me why people who are
trying to bend virtually everything into a number, at the same time don't
want to know what numbers are.

If you don't want only mathematicians programming your language, then give
people something beyond numbers. But you say who needs a type system,
user-defined abstract types? Everything is a number...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2114 — Re: 100 Things

On 2014-05-01, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:i8gmjwf2beyz.12f8p3m5cxcnh$.dlg@40tude.net...
>>> On Thu, 1 May 2014 11:02:17 +0100, BartC wrote:
>> 
>>>> At the level we're talking about, generally we know the hardware can deal
>>>> with integer values that are 8, 16, 32 or 64 bits wide, and floating point
>>>> values that are 32 or 64 bits. (There might be a few extra odd ones such
>>>> as 80-bit floats, or software-supported 128-bit ints.)
>>>>
>>>> One way of choosing whether to use 8, 16, 32 or 64 bits for a storage
>>>> type (for storing data in memory), is to actually specify 8, 16, 32, or [64]
>>>> bits! It can't get any simpler.
>>>
>>> What do you do when there is no given machine type? Let you compile for
>>> 32-bit i686. There is no 64-bit integer. Wait, there is but you need
>>> special instructions. It is not the way to deal with this. You don't make
>>> the language semantics dependent on the target machine.
>> 
>> That machines generally work in powers-of-two bitwidths is well-known.
>
> And those that don't, you program in another language... Right?

Anyway, C doesn't specify bitwidths that are powers of two. In fact,
it originally ran on some machines that had 18 bit ints.

C specifies minimum sizes for certain types. The CHAR_BIT preprocessor constant
gives how many bits are in a signed or unsigned char (and therefore byte).
It is at least eight but doesn't have to be. Example: IBM mainframes
with 9 bit bytes, and 36 bit words.

Since C99, C also has some exact width types in popular power-of-two-bits sizes
like int32_t, declared as a typedef in a header. Since this might not be
available, there is a way to test for it at preprocessing time.

C code that needs, say, 32 bit two's complement arithmetic, and run on any
machine, just needs to use an unsigned type which is at least 32 bits wide,
mask down results to fall into that range, and interpret bit 31 as a sign bit.

In C, you can easily write, say, an emulator for the Motorola 68000 that will
run anywhere there is an ISO conforming compiler which can accept a program
that large, targetting a machine with enough resources to run it.

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

#2120 — Re: 100 Things

On Thu, 01 May 2014 14:26:14 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:

> C specifies minimum sizes for certain types. The CHAR_BIT preprocessor
> constant gives how many bits are in a signed or unsigned char (and
> therefore byte).  It is at least eight but doesn't have to be.  Example:
> IBM mainframes with 9 bit bytes, and 36 bit words.

Upon first read, I took the "doesn't have to be" to mean it could be
7-bits or 6-bits etc.  C would work with that.  However, the C  
specifications
requires 8-bits or more.  So, to be clear:

s/doesn't have to be/or more/

I.e., one of those can mean above or below, while the other is above only.

;-)


Rod Pemberton

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

#2126 — Re: 100 Things

On 2014-05-01, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Thu, 01 May 2014 14:26:14 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>
>> C specifies minimum sizes for certain types. The CHAR_BIT preprocessor
>> constant gives how many bits are in a signed or unsigned char (and
>> therefore byte).  It is at least eight but doesn't have to be.  Example:
>> IBM mainframes with 9 bit bytes, and 36 bit words.
>
> Upon first read, I took the "doesn't have to be" to mean it could be
> 7-bits or 6-bits etc.  C would work with that.  However, the C  
> specifications
> requires 8-bits or more.  So, to be clear:
>
> s/doesn't have to be/or more/

A C dialect could have 7 bit bytes; it just wouldn't be conforming to ISO C.

Some programs would work, some wouldn't.

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

#2091

On Tue, 29 Apr 2014 12:57:25 -0400, BartC <bc@freeuk.com> wrote:

> Well, I put together my list. About 115 things listed actually.
> Too long to show here so is at:

What do I do with my "about 115" replies?

Don't worry, I can't handle a full blow conversation on all of
those.  You'd need to limit it to just a few.

>  [link]
>

I didn't see any way to reply to that there.  If it's not totally
anonymous, no email, no signup account, no personal info, then I
wouldn't use it anyway.


Rod Pemberton

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

#2515

"BartC" <bc@freeuk.com> wrote in message
news:3SQ7v.155346$AI5.24849@fx32.am4...

[List of things I didn't like about C]

> Well, I put together my list. About 115 things listed actually. Too long
> to
> show here so is at:  http://pastebin.com/vUVpF1uA (will be edited later).

[Link now expired]

> I didn't specifically set out to find faults with C, but a lot of this is
> how I'm used to doing things, and wondered why C used its own unique
> approach.
>
> And as promised, little of this actually results in a particularly higher
> level language (no OOP, no templates, no dynamic datatypes, no exceptions,
> no threading, nothing about the runtime library (actually that can be item
> #
> 116...).) It just makes more sense.

I've been working on a development of my own static, compiled language
(mainly, trying to get it up to speed, but given up on that aspect).

I only really use it for a limited number of projects (mainly interpreters)
so have not attempted to create a complete, well-rounded language. Even so,
I've gone through my list, and over 75% of my points have been covered, or
do not apply to my language (the rest are largely to do with suggested types
or features that aren't in C either, but which are not worth adding as I'm
now unlikely to use them).

It wasn't very hard either. So, creating a viable, less annoying alternative 
to C is quite possible! (And the problem with performance can be got around 
by using existing, optimising compiler 'back-ends', although that is not my 
style.)

-- 
Bartc 

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

#2516

On Fri, 25 Jul 2014 18:53:52 -0400, BartC <bc@freeuk.com> wrote:

> I've been working on a development of my own static, compiled language

What do you mean by "static" in this case?
E.g., not a dynamically typed language?

> (mainly, trying to get it up to speed, but given up on that aspect).

All projects just get set aside for the future ...

> I only really use it for a limited number of projects (mainly  
> interpreters) so have not attempted to create a complete,
> well-rounded language.

I think that's actually a very interesting point.  :-)

If a language does what's needed of it, why must it
be complete, and well-rounded?

C functions superbly with numerous flaws and issues.
I.e., a language which is broken in some or many ways
may result in improved effective of the language.
Do you agree?  Or, am I just being the Devil's advocate?

> It wasn't very hard either. So, creating a viable, less annoying  
> alternative to C is quite possible!

I agree with:

1) viable
2) alternative to C
3) simple  (unmentioned, perhaps not...)

... since I've done that for my own language.   But, as for
"less annoying", I'm not sure about that one.  Mine might
be more annoying ...  ;-)  It definately has issues that
need to be "pounded on" for a while.  Simplicity of
implementation was a key detail.  That may have resulted in
some annoyance.

> (And the problem with performance can be got around by
> using existing, optimising compiler 'back-ends', although that is not my  
> style.)

Does this matter for a one off language?


Rod Pemberton
P.S.  Posts I should to reply to here are piling up.  Sorry guys.

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

#2517

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
news:op.xjlmewoe6zenlw@localhost...
> On Fri, 25 Jul 2014 18:53:52 -0400, BartC <bc@freeuk.com> wrote:
>
>> I've been working on a development of my own static, compiled language
>
> What do you mean by "static" in this case?
> E.g., not a dynamically typed language?

Yes, statically typed and compiled to native code, versus dynamically typed
and using interpreted byte-code (the two main language categories I'm
interested in).

>> I only really use it for a limited number of projects (mainly
>> interpreters) so have not attempted to create a complete,
>> well-rounded language.
>
> I think that's actually a very interesting point.  :-)
>
> If a language does what's needed of it, why must it
> be complete, and well-rounded?

I'm being a little harsh on my own language; as it is, it can tackle most
things C can. But it doesn't quite meet my specification of what a C
replacement ought to be.

> C functions superbly with numerous flaws and issues.
> I.e., a language which is broken in some or many ways
> may result in improved effective of the language.
> Do you agree?  Or, am I just being the Devil's advocate?

Sure, C works, but can be a bit of pain.  But as an example I'm of what I on
about, see this link recently posted in comp.lang.c:

 https://software.intel.com/sites/landingpage/IntrinsicsGuide/

(about ways to directly code SSE and other x86-specific stuff from C). Click
on any of the functions, and you will see the descriptions use an Algol-like
pseudo-code language, uncannily similar to mine, not a C-like syntax with 
braces!

Pseudo-code often uses syntax like this, because it's clearer and not
cluttered with irrelevant details. So why don't actual languages uses
similar syntax? Well, mine do! C syntax is the main thing I have against the
language; it's also the easiest to do something about.

>> It wasn't very hard either. So, creating a viable, less annoying
>> alternative to C is quite possible!
>
> I agree with:
>
> 1) viable
> 2) alternative to C
> 3) simple  (unmentioned, perhaps not...)
>
> ... since I've done that for my own language.   But, as for
> "less annoying", I'm not sure about that one.  Mine might
> be more annoying ...  ;-)

If that's the one that you posted examples of some time back, then I agree
it can be annoying!

>> (And the problem with performance can be got around by
>> using existing, optimising compiler 'back-ends', although that is not my
>> style.)
>
> Does this matter for a one off language?

In my case, because the main application is an interpreter, performance is
crucial. But not actually so critical that it's in the language because it's
easy to throw in some assembly code. Then outperforming even highly
optimised C is child's play.

Outside the main core, however, this is not practical to do everywhere so
any extra performance is always welcome.

-- 
Bartc 

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

#2757

On Saturday, July 26, 2014 8:51:17 AM UTC-4, Bart wrote:
> Sure, C works, but can be a bit of pain.  But as an example I'm of what
> I on about, see this link recently posted in comp.lang.c:
> 
>  https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> 
> (about ways to directly code SSE and other x86-specific stuff from C). Click
> on any of the functions, and you will see the descriptions use an Algol-like
> pseudo-code language, uncannily similar to mine, not a C-like syntax with 
> braces!
> 
> Pseudo-code often uses syntax like this, because it's clearer and not
> cluttered with irrelevant details. So why don't actual languages uses
> similar syntax? Well, mine do! C syntax is the main thing I have against the
> language; it's also the easiest to do something about.

I intend on introducing types which relate 1:1 with their architectural
counterparts for items like mmxN, xmmN, and so on.  They will be defined
primitives with built-in structural components, such as a packed _xmm0
type holding _xmm.f321, _xmm.f322..., and _xmm.f641, _xmm.f642, and so
on to access their f32 and f64 (float and double) sub-components, along
with integer portions.

These will be used in code as:

    _xmm data1, data2, data3;
    // Code goes here to manipulate them in C or assembly
    printf("%f\n", _xmm.f322);  // 2nd float in this structure

Intel shipped over 100M units per quarter for the first time in Q3 2014.
Other architectures share many of the same features (ARM, for example,
supports SIMD with similar bit sizes and patterns).

I think the language itself should support the hardware it resides upon,
making it a closely coupled construct at the C level.  Above C you are
free to get into all manner of "grander" concepts, but I would even
argue at that point that such concepts should be then translated down
into C for easier debugging, which is translated down into assembly for
final debugging.

Ultimately a person should be able to write their software in comments.
Those comments translate into something like a flowchart.  That
flowchart then translates into something like the actual code to conduct
the work.  That code is at whatever level it's at, in whatever language
it's at, which is then translated down to C (a language designed to be
very close to hardware, yet expressible in human terms).  And that C is
then translated down to assembly, which is translated into machine code.

An app can then be debugged at any one of those levels to find out the
underlying components which need to be fixed, and the fixes can occur
at any of those levels, all with full edit-and-continue abilities.

Prayerfully that is... :-)

Best regards,
Rick C. Hodgin

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

#2758

Should be:

    _xmm data1, data2, data3;
    // Code goes here to manipulate them in C or assembly
    printf("%f\n", data1.f322);  // 2nd float in this structure

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

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

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

csiph-web