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

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

"The Unreasonable Effectiveness of C" by Damien Katz

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

Contents

  "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-14 11:55 -0600
    Re: "The Unreasonable Effectiveness of C" by Damien Katz JohnF <john@please.see.sig.for.email.com> - 2013-01-15 05:02 +0000
      Re: "The Unreasonable Effectiveness of C" by Damien Katz William Ahern <william@wilbur.25thandClement.com> - 2013-01-14 22:44 -0800
        Re: "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-15 11:20 -0600
          Re: "The Unreasonable Effectiveness of C" by Damien Katz Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-01-15 20:06 +0000
            Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-15 20:27 +0000
              Re: "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-15 17:06 -0600
            Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-17 01:52 -0600
        Re: "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-15 17:08 -0600
      Re: "The Unreasonable Effectiveness of C" by Damien Katz falk@rahul.net (Edward A. Falk) - 2013-01-15 22:39 +0000
      Re: "The Unreasonable Effectiveness of C" by Damien Katz Andrey Tarasevich <andreytarasevich@hotmail.com> - 2013-01-16 11:00 -0800
        Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-16 20:08 +0000
        Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-16 20:09 +0000
          Re: "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-16 15:36 -0600
          Re: "The Unreasonable Effectiveness of C" by Damien Katz William Ahern <william@wilbur.25thandClement.com> - 2013-01-16 14:01 -0800
            Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-17 02:15 -0600
              Re: "The Unreasonable Effectiveness of C" by Damien Katz James Kuyper <jameskuyper@verizon.net> - 2013-01-17 07:15 -0500
                Re: "The Unreasonable Effectiveness of C" by Damien Katz Nobody <nobody@nowhere.com> - 2013-01-17 15:09 +0000
                  Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-17 14:42 -0600
              Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-17 12:58 +0000
                Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-17 14:59 -0600
              Re: "The Unreasonable Effectiveness of C" by Damien Katz falk@rahul.net (Edward A. Falk) - 2013-01-19 23:37 +0000
                Re: "The Unreasonable Effectiveness of C" by Damien Katz Lynn McGuire <lmc@winsim.com> - 2013-01-19 18:47 -0600
                Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-20 00:49 +0000
        Re: "The Unreasonable Effectiveness of C" by Damien Katz Giorgos Keramidas <keramida@ceid.upatras.gr> - 2013-01-18 16:30 +0100
          Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 19:12 +0000
          Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-19 16:40 -0600
            Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-20 00:52 +0000
              Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-20 01:26 +0000
                Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-20 00:32 -0600
                  Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-20 01:42 -0600
                  Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-20 13:06 +0000
                    Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-20 11:30 -0600
              Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-19 19:28 -0600
            Re: "The Unreasonable Effectiveness of C" by Damien Katz William Ahern <william@wilbur.25thandClement.com> - 2013-01-19 19:05 -0800
              Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-20 01:32 -0600
                Re: "The Unreasonable Effectiveness of C" by Damien Katz William Ahern <william@wilbur.25thandClement.com> - 2013-01-20 00:29 -0800
                  Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-20 04:24 -0600
    Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-15 23:02 +0000
      Re: "The Unreasonable Effectiveness of C" by Damien Katz William Ahern <william@wilbur.25thandClement.com> - 2013-01-15 16:06 -0800
        Re: "The Unreasonable Effectiveness of C" by Damien Katz "Mel Smith" <med_cutout_syntel@aol.com> - 2013-01-15 17:54 -0700
        Re: "The Unreasonable Effectiveness of C" by Damien Katz BGB <cr88192@hotmail.com> - 2013-01-17 02:42 -0600
    Re: "The Unreasonable Effectiveness of C" by Damien Katz Robert Wessel <robertwessel2@yahoo.com> - 2013-01-18 01:09 -0600
      Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-18 11:45 +0000
        Re: "The Unreasonable Effectiveness of C" by Damien Katz Robert Wessel <robertwessel2@yahoo.com> - 2013-01-18 14:43 -0600
          Re: "The Unreasonable Effectiveness of C" by Damien Katz "BartC" <bc@freeuk.com> - 2013-01-18 23:31 +0000
            Re: "The Unreasonable Effectiveness of C" by Damien Katz glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 00:23 +0000
              Re: "The Unreasonable Effectiveness of C" by Damien Katz Ian Collins <ian-news@hotmail.com> - 2013-01-19 15:17 +1300

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

#30128 — "The Unreasonable Effectiveness of C" by Damien Katz

"The Unreasonable Effectiveness of C" by Damien Katz
    http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

" It's because C is so damn successful as an
abstraction over the underlying machine and making
that high level, it's made most low level languages
irrelevant. C is that good at what it does."

Lynn

[toc] | [next] | [standalone]

#30147

Lynn McGuire <lmc@winsim.com> wrote:
> "The Unreasonable Effectiveness of C" by Damien Katz
>    http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
> 
> " It's because C is so damn successful as an
> abstraction over the underlying machine and making
> that high level, it's made most low level languages
> irrelevant. C is that good at what it does."
> Lynn

C is often called a "portable assembly language" (google that
phrase for lots of relevant hits). So this is all pretty
well-known stuff already.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#30149

JohnF <john@please.see.sig.for.email.com> wrote:
> Lynn McGuire <lmc@winsim.com> wrote:
> > "The Unreasonable Effectiveness of C" by Damien Katz
> >    http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
> > 
> > " It's because C is so damn successful as an
> > abstraction over the underlying machine and making
> > that high level, it's made most low level languages
> > irrelevant. C is that good at what it does."
> > Lynn

> C is often called a "portable assembly language" (google that
> phrase for lots of relevant hits). So this is all pretty
> well-known stuff already.

The author would probably disagree with the implications of such a
description.

	That we have a hard time thinking of lower level languages we'd use
	instead of C isn't because C is low level. It's because C is so damn
	successful as an abstraction over the underlying machine and making
	that high level, it's made most low level languages irrelevant. C is
	that good at what it does.

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

#30158

On 1/15/2013 12:44 AM, William Ahern wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Lynn McGuire <lmc@winsim.com> wrote:
>>> "The Unreasonable Effectiveness of C" by Damien Katz
>>>     http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
>>>
>>> " It's because C is so damn successful as an
>>> abstraction over the underlying machine and making
>>> that high level, it's made most low level languages
>>> irrelevant. C is that good at what it does."
>>> Lynn
>
>> C is often called a "portable assembly language" (google that
>> phrase for lots of relevant hits). So this is all pretty
>> well-known stuff already.
>
> The author would probably disagree with the implications of such a
> description.
>
> 	That we have a hard time thinking of lower level languages we'd use
> 	instead of C isn't because C is low level. It's because C is so damn
> 	successful as an abstraction over the underlying machine and making
> 	that high level, it's made most low level languages irrelevant. C is
> 	that good at what it does.

I totally agree.  C is an awesome abstraction
of all machine languages.  C is awesome at
what it does.

Lynn

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

#30160

On Tue, 2013-01-15, Lynn McGuire wrote:
> On 1/15/2013 12:44 AM, William Ahern wrote:
...
>> The author would probably disagree with the implications of such a
>> description.
>>
>> 	That we have a hard time thinking of lower level languages we'd use
>> 	instead of C isn't because C is low level. It's because C is so damn
>> 	successful as an abstraction over the underlying machine and making
>> 	that high level, it's made most low level languages irrelevant. C is
>> 	that good at what it does.
>
> I totally agree.  C is an awesome abstraction
> of all machine languages.

Either that, or there's little chance of success if you create a
machine, no matter how good, if it cannot run C efficiently.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#30163

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

(snip)
> Either that, or there's little chance of success if you create a
> machine, no matter how good, if it cannot run C efficiently.

For many years, that was true for Fortran.  Maybe it still is.

For one, C allowed either of two possibilities when dividing
with negative numbers. Fortran allowed only one.

If any hardware generated the result that Fortran didn't allow,
it would have been less efficient for Fortran, and might not
have sold as well.

Also, my always favorite example is segment selector zero for protected
mode on the 80286 and later intel processors.

-- glen

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

#30172

On 1/15/2013 2:27 PM, glen herrmannsfeldt wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
> (snip)
>> Either that, or there's little chance of success if you create a
>> machine, no matter how good, if it cannot run C efficiently.
>
> For many years, that was true for Fortran.  Maybe it still is.
>
> For one, C allowed either of two possibilities when dividing
> with negative numbers. Fortran allowed only one.
>
> If any hardware generated the result that Fortran didn't allow,
> it would have been less efficient for Fortran, and might not
> have sold as well.
>
> Also, my always favorite example is segment selector zero for protected
> mode on the 80286 and later intel processors.
>
> -- glen

Many of the PLC machines do not have a fortran
(4, 77, 90, 95, 2003, etc) compiler.  You have
to translate your code to c using f2c (crap) or
for_c (a purchase tool).

Lynn

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

#30237

On 1/15/2013 2:06 PM, Jorgen Grahn wrote:
> On Tue, 2013-01-15, Lynn McGuire wrote:
>> On 1/15/2013 12:44 AM, William Ahern wrote:
> ...
>>> The author would probably disagree with the implications of such a
>>> description.
>>>
>>> 	That we have a hard time thinking of lower level languages we'd use
>>> 	instead of C isn't because C is low level. It's because C is so damn
>>> 	successful as an abstraction over the underlying machine and making
>>> 	that high level, it's made most low level languages irrelevant. C is
>>> 	that good at what it does.
>>
>> I totally agree.  C is an awesome abstraction
>> of all machine languages.
>
> Either that, or there's little chance of success if you create a
> machine, no matter how good, if it cannot run C efficiently.
>

yeah...

elsewhere on Usenet, there is an argument about machines using 
fat-pointers and tagged memory (say, where pointers are 128 bits wide, 
array accesses are bounds-checked, and every 64-bits of memory has 8 
bits of tag-data, ...).

oddly enough, they never really caught on.


> /Jorgen
>

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

#30173

On 1/15/2013 12:44 AM, William Ahern wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Lynn McGuire <lmc@winsim.com> wrote:
>>> "The Unreasonable Effectiveness of C" by Damien Katz
>>>     http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
>>>
>>> " It's because C is so damn successful as an
>>> abstraction over the underlying machine and making
>>> that high level, it's made most low level languages
>>> irrelevant. C is that good at what it does."
>>> Lynn
>
>> C is often called a "portable assembly language" (google that
>> phrase for lots of relevant hits). So this is all pretty
>> well-known stuff already.
>
> The author would probably disagree with the implications of such a
> description.
>
> 	That we have a hard time thinking of lower level languages we'd use
> 	instead of C isn't because C is low level. It's because C is so damn
> 	successful as an abstraction over the underlying machine and making
> 	that high level, it's made most low level languages irrelevant. C is
> 	that good at what it does.

I find it amazing that C works well on both
non-stack and stack machines.  OF course, so
does Fortran but it has it's own many
peculiarities and failings.

Lynn

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

#30170

In article <kd2nts$h7n$2@reader1.panix.com>,
JohnF  <john@please.see.sig.for.email.com> wrote:
>
>C is often called a "portable assembly language" (google that
>phrase for lots of relevant hits). So this is all pretty
>well-known stuff already.

That's how it was described to me when I first heard of it --
a high-level language with the power of assembly language.  I
was pretty skeptical at first.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

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

#30206

On 1/14/2013 9:02 PM, JohnF wrote:
> Lynn McGuire <lmc@winsim.com> wrote:
>> "The Unreasonable Effectiveness of C" by Damien Katz
>>     http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
>>
>> " It's because C is so damn successful as an
>> abstraction over the underlying machine and making
>> that high level, it's made most low level languages
>> irrelevant. C is that good at what it does."
>> Lynn
>
> C is often called a "portable assembly language" (google that
> phrase for lots of relevant hits). So this is all pretty
> well-known stuff already.

While it is generally true, the actual meaning of that characterization 
is not exactly unambiguous.

C language was true "portable assembler" - i.e. a tool for directly 
expressing the programmer's intent in near-machine language - mostly in 
its nascent stages, as described in "C Reference Manual" and the first 
edition of "C Programming Language". That was indeed a true "assembler".

The standardized C was considerably reworked and became more abstracted 
from the actual machines. In many cases when one refers to it as a 
"portable assembler" in the above sense of the term, it usually means 
that one simply lacks proper understanding of the true abstraction level 
built into the language features.

Yet, standardized C retained the crown of "portable assembler" in a 
different meaning of the term: it works rather well as a back end 
representation for various higher-level language translators, i.e. 
instead of translating the higher-level source into assembler it often 
makes much more sense to translate them into C.

-- 
Best regards,
Andrey Tarasevich

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

#30210

"Andrey Tarasevich" <andreytarasevich@hotmail.com> wrote in message 
news:kd6tc8$rna$1@dont-email.me...
> On 1/14/2013 9:02 PM, JohnF wrote:

>> C is often called a "portable assembly language" (google that
>> phrase for lots of relevant hits). So this is all pretty
>> well-known stuff already.

> Yet, standardized C retained the crown of "portable assembler" in a 
> different meaning of the term: it works rather well as a back end 
> representation for various higher-level language translators, i.e. instead 
> of translating the higher-level source into assembler it often makes much 
> more sense to translate them into C.

I've never had much luck using C as a target language. Some aspects of C are 
just not quite low-level enough and there can be many constructions, partly 
depending on the source language, not easily expressible in C but trivial in 
actual assembler.

There are advantages: the result is more portable, and you can take 
advantage of a good optimising C compiler to make your job easier. But there 
are some downsides too apart from the ones I've mentioned: having this extra 
dependency on a C compiler system for example.

Directly programming in assembly is like setting things in concrete compared 
with using any higher level language, so that is rarely the best approach. 
But generating assembly code  indirectly is not quite as bad as that.

-- 
Bartc 

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

#30211

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 1/14/2013 9:02 PM, JohnF wrote:

(snip)
>> C is often called a "portable assembly language" (google that
>> phrase for lots of relevant hits). So this is all pretty
>> well-known stuff already.
 
> While it is generally true, the actual meaning of that 
> characterization is not exactly unambiguous.
 
> C language was true "portable assembler" - i.e. a tool for directly 
> expressing the programmer's intent in near-machine language - mostly in 
> its nascent stages, as described in "C Reference Manual" and the first 
> edition of "C Programming Language". That was indeed a true "assembler".
 
> The standardized C was considerably reworked and became more abstracted 
> from the actual machines. In many cases when one refers to it as a 
> "portable assembler" in the above sense of the term, it usually means 
> that one simply lacks proper understanding of the true abstraction level 
> built into the language features.

Yes it is more abstract, but if you are careful with what opeations
you use, then you are still pretty close. 

But most good high-level langauges now include array operations.

You can say a=b+c; where a, b, and c are arrays (of any rank)
with appropriate dimensions, and it will add them element by element.

C still does not have array operations, and with the way C uses
pointers, it isn't so easy to see how to add them.
 
> Yet, standardized C retained the crown of "portable assembler" in a 
> different meaning of the term: it works rather well as a back end 
> representation for various higher-level language translators, i.e. 
> instead of translating the higher-level source into assembler it often 
> makes much more sense to translate them into C.

Much of the time, you can figure out exactly, or close enough, what
assembler code would be generated. (And the register allocation
is probably better than most assembler programmers would do.)

-- glen

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

#30216

On 1/16/2013 2:09 PM, glen herrmannsfeldt wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 1/14/2013 9:02 PM, JohnF wrote:
>
> (snip)
>>> C is often called a "portable assembly language" (google that
>>> phrase for lots of relevant hits). So this is all pretty
>>> well-known stuff already.
>
>> While it is generally true, the actual meaning of that
>> characterization is not exactly unambiguous.
>
>> C language was true "portable assembler" - i.e. a tool for directly
>> expressing the programmer's intent in near-machine language - mostly in
>> its nascent stages, as described in "C Reference Manual" and the first
>> edition of "C Programming Language". That was indeed a true "assembler".
>
>> The standardized C was considerably reworked and became more abstracted
>> from the actual machines. In many cases when one refers to it as a
>> "portable assembler" in the above sense of the term, it usually means
>> that one simply lacks proper understanding of the true abstraction level
>> built into the language features.
>
> Yes it is more abstract, but if you are careful with what opeations
> you use, then you are still pretty close.
>
> But most good high-level langauges now include array operations.
>
> You can say a=b+c; where a, b, and c are arrays (of any rank)
> with appropriate dimensions, and it will add them element by element.
>
> C still does not have array operations, and with the way C uses
> pointers, it isn't so easy to see how to add them.
>
>> Yet, standardized C retained the crown of "portable assembler" in a
>> different meaning of the term: it works rather well as a back end
>> representation for various higher-level language translators, i.e.
>> instead of translating the higher-level source into assembler it often
>> makes much more sense to translate them into C.
>
> Much of the time, you can figure out exactly, or close enough, what
> assembler code would be generated. (And the register allocation
> is probably better than most assembler programmers would do.)
>
> -- glen

How about the third party array operations in
OpenCL and CUDA ?

Lynn

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

#30217

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> > On 1/14/2013 9:02 PM, JohnF wrote:

> (snip)
> >> C is often called a "portable assembly language" (google that
> >> phrase for lots of relevant hits). So this is all pretty
> >> well-known stuff already.
>  
> > While it is generally true, the actual meaning of that 
> > characterization is not exactly unambiguous.
>  
> > C language was true "portable assembler" - i.e. a tool for directly 
> > expressing the programmer's intent in near-machine language - mostly in 
> > its nascent stages, as described in "C Reference Manual" and the first 
> > edition of "C Programming Language". That was indeed a true "assembler".
>  
> > The standardized C was considerably reworked and became more abstracted 
> > from the actual machines. In many cases when one refers to it as a 
> > "portable assembler" in the above sense of the term, it usually means 
> > that one simply lacks proper understanding of the true abstraction level 
> > built into the language features.

> Yes it is more abstract, but if you are careful with what opeations
> you use, then you are still pretty close. 

> But most good high-level langauges now include array operations.

No true Scotsman? I use many high-level languages, and none of them have
native support for vector operations. I did use R a few years ago to
validate some C code, I suppose. GCC has built-in vector extensions for C,
but they're only for single dimensions.

Some languages make it easier than others to compose vector libraries, of
course. C appears to be taking a different tack, which is tweaking the
language specification to make it easier for the compiler to auto-vectorize
loops.

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

#30240

On 1/16/2013 4:01 PM, William Ahern wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>> On 1/14/2013 9:02 PM, JohnF wrote:
>
>> (snip)
>>>> C is often called a "portable assembly language" (google that
>>>> phrase for lots of relevant hits). So this is all pretty
>>>> well-known stuff already.
>>
>>> While it is generally true, the actual meaning of that
>>> characterization is not exactly unambiguous.
>>
>>> C language was true "portable assembler" - i.e. a tool for directly
>>> expressing the programmer's intent in near-machine language - mostly in
>>> its nascent stages, as described in "C Reference Manual" and the first
>>> edition of "C Programming Language". That was indeed a true "assembler".
>>
>>> The standardized C was considerably reworked and became more abstracted
>>> from the actual machines. In many cases when one refers to it as a
>>> "portable assembler" in the above sense of the term, it usually means
>>> that one simply lacks proper understanding of the true abstraction level
>>> built into the language features.
>
>> Yes it is more abstract, but if you are careful with what opeations
>> you use, then you are still pretty close.
>
>> But most good high-level langauges now include array operations.
>
> No true Scotsman? I use many high-level languages, and none of them have
> native support for vector operations. I did use R a few years ago to
> validate some C code, I suppose. GCC has built-in vector extensions for C,
> but they're only for single dimensions.
>

I have seen hardly any languages which allow adding arrays in this way.

I have actually seen more which will interpret this as meaning you want 
to append the arrays into a single bigger array.

others will just be like "what?...".


> Some languages make it easier than others to compose vector libraries, of
> course. C appears to be taking a different tack, which is tweaking the
> language specification to make it easier for the compiler to auto-vectorize
> loops.
>

it also depends some on what exactly one means by "vector".

for example, many of my languages include built-in vectors, in roughly 
the same sense as GLSL, where they come in a variety of forms:
vec2, vec3, vec4, quat (vectors, float);
vec2d, vec3d, vec4d, quatd (vectors, double).

and generally support operations like add/subtract, dot-product, 
cross-product, ... with quat/quatd being slightly special (being 
quaternions and all), ...


but, some other people seem to use "vector" more in the sense of "array 
of indeterminate size which you do math on", others, as a synonym for 
"array" (holding pretty much anything, and dropping the sense of doing 
math on it), or go as far to use the term "vector" to refer to a bunch 
of copies of a program running in-parallel, in the sense of how shaders 
are executed on the GPU, ...

it gets ambiguous sometimes...

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

#30251

On 01/17/2013 03:15 AM, BGB wrote:
> On 1/16/2013 4:01 PM, William Ahern wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
...
>>> But most good high-level langauges now include array operations.
>>
>> No true Scotsman? I use many high-level languages, and none of them have
>> native support for vector operations. I did use R a few years ago to
>> validate some C code, I suppose. GCC has built-in vector extensions for C,
>> but they're only for single dimensions.
>>
> 
> I have seen hardly any languages which allow adding arrays in this way.

APL and IDL are the only two I know of, though there are probably others.
-- 
James Kuyper

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

#30257

On Thu, 17 Jan 2013 07:15:45 -0500, James Kuyper wrote:

>>>> But most good high-level langauges now include array operations.
>>>
>>> No true Scotsman? I use many high-level languages, and none of them
>>> have native support for vector operations. I did use R a few years ago
>>> to validate some C code, I suppose. GCC has built-in vector extensions
>>> for C, but they're only for single dimensions.
>>>
>>>
>> I have seen hardly any languages which allow adding arrays in this way.
> 
> APL and IDL are the only two I know of, though there are probably others.

C++ has std::valarray. Python has NumPy (although it's not actually part
of the standard library).

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

#30269

On 1/17/2013 9:09 AM, Nobody wrote:
> On Thu, 17 Jan 2013 07:15:45 -0500, James Kuyper wrote:
>
>>>>> But most good high-level langauges now include array operations.
>>>>
>>>> No true Scotsman? I use many high-level languages, and none of them
>>>> have native support for vector operations. I did use R a few years ago
>>>> to validate some C code, I suppose. GCC has built-in vector extensions
>>>> for C, but they're only for single dimensions.
>>>>
>>>>
>>> I have seen hardly any languages which allow adding arrays in this way.
>>
>> APL and IDL are the only two I know of, though there are probably others.
>
> C++ has std::valarray. Python has NumPy (although it's not actually part
> of the standard library).
>

well, granted, but I partly meant "plain old arrays", rather than arrays 
added as a library feature.

if one includes library features, then pretty much any language with 
overloaded operators can have them, and one can include C as well if 
they allow for a looser definition of "add" (which allows function calls).

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

#30254

"BGB" <cr88192@hotmail.com> wrote in message 
news:kd8c3h$2mh$1@news.albasani.net...
> On 1/16/2013 4:01 PM, William Ahern wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>>> But most good high-level langauges now include array operations.
>>> [You can say a=b+c; where a, b, and c are arrays (of any rank)]

>> No true Scotsman? I use many high-level languages, and none of them have
>> native support for vector operations. I did use R a few years ago to
>> validate some C code, I suppose. GCC has built-in vector extensions for 
>> C,
>> but they're only for single dimensions.
>>
>
> I have seen hardly any languages which allow adding arrays in this way.

It's not really that meaningful, except where you build a more specific type 
based on 'array', designed for mathematical work.

But if the language allows it, then it would quite likely be to allow list 
operations in general, so that in a = b op c, then 'op' is applied between 
all corresponding elements (as in languages such as "K", but without quite 
such an obvious syntax...)

> I have actually seen more which will interpret this as meaning you want to 
> append the arrays into a single bigger array.

That's far more useful. But better to use a symbol other than "+" I think.

-- 
Bartc 

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

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

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

csiph-web