Simplicity has a future

[Keith Thompson]

It is an analogue device. So instead of having eight on/off transistors to
represent an 8-bit byte, it has a single charge, which it can resolve to 256
levels with acceptable accuracy. There is always the slight danger, however,
of a shift by one place.
The memory is worse that a conventional one, because it is less reliable, so
why use it? Because it is cheaper to produce.
So you see that a shift from 12 to 18 is impossible. However a shift from 12
to 11 is possible, if we use ASCII. However if we don't use ASCII, but some
encoding where digits are contiguous with non-digits, AI or an intelligent
human reader can make the correction. "Buy 1* eggs" is nonsense, but since *
is contigous with 2, and '#' is contiguous with eight, the correct meaning
can be retrieved. Similarly English text with one lettfr wrong is perfectly
readable.

Where the memory falls down is where the computer insists on an exact
representation, for instance a list of random numbers. Obviously you
wouldn't use it for a life support system.

If it's as unreliable as you suggest, I wouldn't use it at all.

Mechanisms for automatically correcting memory errors are well known
and commonly implemented in current bit-oriented memory. They don't
depend on assumptions about what the data is really supposed to look
like.

If this hypothetical memory is so cheap, it would be worthwhile to use
a bit more and dedicate some of it to error detection and correction,
to the point where it's as reliable as current bit-oriented memory.

With the kind of error correction you're talking about, your
hypothetical memory wouldn't even be able to store a copy of this
article. The AI would probably "correct" this:
If a word reads "exactky" the AI will correct it to "exactly".
to this:
If a word reads "exactly" the AI will correct it to "exactly".

If it can't reliably store arbitrary data, whether it looks right or
not, it's not really memory.

 

[Keith Thompson]

This is comp.lang.c and the C standards require that the digits
be numerically contiguous. 2 cannot be numerically contiguous with *
because 2 must be numerically contiguous with 1 and 3.

That was the point. Malcolm is trying to construct a hypothetical
future system on which a requirement of the current C standard (the
contiguity of the digits) would be an inconvenience.

IMHO there are much better ways to make the same point (e.g, if
trinary storage replaces binary for some reason).

 

[RSoIsCaIrLiIoA]

Look Tomas,
you should restrain from insulting other people just because they refuse
to learn all the complexities of C++.

No. They aren't "mickey-mouse" programmers but real programmers that
want to use a programming language to do a specific JOB. Period.

If you read the article that I quoted in CNN, people do not reject the
"modern" hypercomplex phones just because they are lazy but because they
want to USE a phone for what is intended: communicate by phone with
other people. PERIOD.

C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.

C has less surprises, less to learn, and uses FAR LESS MEMORY.

Not only RAM, that nobody cares too much, but HUMAN MEMORY, a far more
precious resource than RAM!

The memory footprint of a language is the amount of data your brain
must load into your neural network to be able to use that language
efficiently.

The memory footprint of C++ is enormous.

*the point is to find what to get and what to lose.*

i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions
If there are these changes and if i don't use the remain, C++ should
be a very easy language.

C++ specifications run down for
pages and pages, and basically, it is impossible for a human mind
to follow the complexities of name resolution without using the
debugger. The C++ name resolution for overloaded operators runs for
several pages of specifications and imply a topological sort of the
class hierarchy. Which human mind can do that without having a machine
(compiler) at hand?

it is not a problem,
it is easy: i write a dummy function that has the appearance that i
want; i compile (using C++ compiler) it for assembly and i find the
name. so i can write that function in assembly or in any other
language that allow that name.

People that reject a language where they can't possibly know what
are they calling, aren't stupid. The contrary is true. They just
follow the KISS principle!

KEEP IT SIMPLE!

i agree but i think that "simple" is to use C++ classes too
for to put in order functions and data. it is possible the compiler
has to use not simple names. the important it is that the programmer
can easy find and use these names (if necessary with use of the
compiler too).

 

[santosh]

*the point is to find what to get and what to lose.*

i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions

Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.

 

[vario]

Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.

functions like sscanf scanf fgets strcpy str* etc sprintf
are well tested for doing buffer overflows and are not easy too
(so for write with them a bulletproof function you have to write for 2
or 3 days and if it is goes wrong the function for input is not
bulletproof too )

function like malloc, new() don't find errors of out of bound in
memory arrays

 

[Andrew Poelstra]

functions like sscanf scanf fgets strcpy str* etc sprintf
are well tested for doing buffer overflows and are not easy too
(so for write with them a bulletproof function you have to write for 2
or 3 days and if it is goes wrong the function for input is not
bulletproof too )

Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.

function like malloc, new() don't find errors of out of bound in
memory arrays

OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.

 

[santosh]

Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.


OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.

Some compilers, like MSVC and lcc-win32 provide an option to turn on
bounds checking. But as you say, it's better to write well thought out
code rather than cross your fingers and rely on external aids.

 

[vario]

Some compilers, like MSVC and lcc-win32 provide an option to turn on
bounds checking. But as you say, it's better to write well thought out
code rather than cross your fingers and rely on external aids.

fate un poco quello che vi piace a me piace mettere tutto sottosopra e
ordinare poi

 

[Malcolm]

If it's as unreliable as you suggest, I wouldn't use it at all.

Let's say we are writing a video game.
The game consists largely of raster data for images, audio samples, and 3d
mesh data.
If a pixel slips a place it makes no difference whatsoever, similarly with
an audio sample. An error in 3d normal similarly should make no difference,
whilst a slip in a coordinate will just introduce a tiny visual glitch, if
you are unlucky.
So the memory is perfectly acceptable for these purposes. Say that it slips
one 256th value per day of operation, and 99% of the memory hold this type
of data. On average, the game will malfunction three to four times a year.
That's not good, but a marketing person could well judge that it is
acceptable, if it means that the games can be bigger and faster, or the
console cheaper. You get software crashes much more frequently than that.

Obviously executable instructions would have to be held in conventional
chips. But what about text data? We don't really want to hold text data in
this memory, but at the endo of the day we are talking about an error-rate
in human-readable text that is smaller than a newspaper misprint rate. If it
is cheap and convenient enough, some of that memory might well be used for
text.

 

[Malcolm]

Then why are you trying to complicate the language with foolishness
such as operator overloading, garbage collection, references, etc.?

Garbage collection actually simplifies things. Consider

char **raster(int width, int height)
{
char **answer;
int i;
int ii;

answer = malloc(height * sizeof(char *));
if(!answer)
return 0;
/* don't strictly need this, but for safety */
for(i=0;i<height;i++)
answer =0;
for(i=0;i<height;i++)
{
answer = malloc(width);
if(!answer)
{
for(ii=0;ii<i;ii++)
free(answer[ii]);
free(answer);
return 0;
}
}

return answer;
}

char **raster(int width, int height)
{
char **answer;
int i;

answer = gmalloc(height * sizeof(char *));
if(!answer)
return 0;
for(i=0;i<height;i++)
{
answer = gmalloc(width);
if(!answer)
return 0;
}
}

With exceptions

char **raster(int width, int height)
{
char **answer;
int i;

answer = xmalloc(height * sizeof(char *));
for(i=0;i<height;i++)
answer = xmalloc(width);
return answer;
}

The snag with exceptions is that people try to complicate things by allowing
user defined excepetions. A subroutine can run out of memory, or it can get
into an illegal state because of some internal error. So we only need two
exceptions, and most programs can ignore them and simply terminate when they
occur.

 

[Walter Roberson]

Let's say we are writing a video game.
The game consists largely of raster data for images, audio samples, and 3d
mesh data.
If a pixel slips a place it makes no difference whatsoever, similarly with
an audio sample. An error in 3d normal similarly should make no difference,
whilst a slip in a coordinate will just introduce a tiny visual glitch, if
you are unlucky.
So the memory is perfectly acceptable for these purposes.

Modern image files and audio files contain data -about- the image or
audio. For audio in particular, the control data is not always just
in header fields that could be stored seperately: audio/video
streams contain mixed-in information about field sizes, number
of repeats, which part of the active whole is changing, resolution,
and so on. If you have something go wrong in the control data, then
the effects on the image or audio sample could be quite large.
Indeed, you should consider modern A/V file formats to essentially
be compressed data -- corrupt any part of the data and you can
end up with something -quite- different from that point onward,

Say that it slips
one 256th value per day of operation, and 99% of the memory hold this type
of data. On average, the game will malfunction three to four times a year.

Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.

 

[CBFalconer]

.... snip ...

Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.

No they don't. Some memory _systems_ provide ECC for the purpose,
which requires extra memory bits and so-called ECC memory. The
vast majority of PCs sold today omit all this for bean counting
reasons, and take advantage of the ignorance of the unwashed
public, who in turn are failing to insist on ECC memory and
reliability.

Always insist on ECC memory in any new systems you buy.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Malcolm]

No they don't. Some memory _systems_ provide ECC for the purpose,
which requires extra memory bits and so-called ECC memory. The
vast majority of PCs sold today omit all this for bean counting
reasons, and take advantage of the ignorance of the unwashed
public, who in turn are failing to insist on ECC memory and
reliability.

Always insist on ECC memory in any new systems you buy.

It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a malfunction
every few weeks really too bad, given that the software will probably crash
due to programming errors several times during that period? It depends what
the price premium is, and what your attitude is to money. Bill Gates can
spend an extra hundred dollars without worrying about it. Some poor single
mother scraping togther money for a Christmas present might well feel that
non-ECC is an economy she can make.

 

[Stan Milam]

jacob navia posted:






I insult people's stupidity, nothing more.

You must be young. Go ahead and insult people's stupidity - There's a
lot around. But remember the persone you are insulting for their
stupidity may someday be your boss. Then who will feel stupid. Don't
say it can't happen, I've seen it happen many times.

Learning a programming language isn't about "one specific job". If it was,
I'd have learned several hundred programming languages by now.

I don't think you got the point. I could get a lot more work if I would
learn C# or V.B.. I've got enough work doing C, thank you very much.
It's where I want to be doing what I want.

I too like simple gadgets.

Ditto.

A computer programming language isn't a gadget, it's a tool. Draw the
distinction.

Yes it is a tool, but it can be either very simple or very complex and
you get the same results, from C or C++, do you not?

I choose simple and efficient.

They're either learning C++ the wrong way, or they're incredibly stupid.

I was writing brilliant C++ programs by the time I was fifteen... surely it
can't be *that* complicated.

You must be brilliant because you are so humble about it. But hey, you
are young, and that makes a big difference. When I was 15 I was like
sponge soaking up all knowledge I could get. Now I am closer to 50 and
I am still absorbing knowledge, just not at the pace I did at 15. And
there is ever more knowledge to acquire. After awhile I want to do
something else like play with my kids and have a life. I still have to
bring the paycheck home but I do not have or want to give any more of my
life to learning yet another language of the moment. C does just fine
and I've got nearly twenty years of useful C library routines that has
been ported to multiple platforms. The library has encapsulated most of
the common things that I am asked to do, and they always wonder how I am
so quick to get the work done. Amazing how productive you can be when
you stop reinventing the wheel.

Explain to me how a programming language can use far less more memory?

You'd be correct in thinking that some C++ features introduce overhead
(e.g. virtual functions) -- however, any such overhead is pay as you go.

I can copy-paste your C code and compile it as C++. If my version is any
slower or uses less memory, I'll eat my hat.






You speak English. How many english words are there in your head? Take a
guess. The answer is far more than you imagine.

Computer programming languages aren't about memory games, they're about
being experienced with particular features and functionality.

Not once have I sat and scratched my head and thought "What's a virtual
function again?".

If memory is such a problem for you, start taking fish oils.

Ah, wait until you are my age. But then again, this is like insulting
someone for stupidity. We've all been stupid at one time or another
about something. Right now you are so ignorant of your own stupidity
that you do not even realize you are being stupid. And some day you
will be the "old guy" and your memory will not be what it once was. But
hopefully by then you will have shed much of your present stupidity.

And it is absolutely NOTHING compared to the amount of "data" stored in my
brain for speaking English, Irish, French and German.

Again, your argument is based on the alleged inherent incompetence that
programmers possess.






For a badger, maybe.






Oh my God I must be a genius... put me in the Guinness book of records! I
wonder how many more geniuses there are on comp.lang.c++?






That's why you get the hang of it and it becomes second nature. When I'm
speaking English, I don't stop and think "Is it 'you are' or 'you is'?".
When I'm driving, I don't stop and think "Do I press in the clutch, and
them move the gear stick, or... do I move the gear stick and then press in
the clutch?". When I'm reaching to get a cup out of the cupboard, I don't
stop and think "Should I flex my biscep or my tricep?".






Far greater feats have been achieved with the human mind. Ever hear of
those people who go to Vegas and count cards? I claim to be an expert C++
programmer, yet I bow to such advanced mental capabilities.






I'll use the word "novice" if you'd prefer.






Yes, I too am an advocate of "keep it simple". However, I draw the line at
"dumb it down".


-Tomás

--
Regards,
Stan Milam
=============================================================
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
=============================================================

 

[CBFalconer]

It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a malfunction
every few weeks really too bad, given that the software will probably crash
due to programming errors several times during that period? It depends what
the price premium is, and what your attitude is to money. Bill Gates can
spend an extra hundred dollars without worrying about it. Some poor single
mother scraping togther money for a Christmas present might well feel that
non-ECC is an economy she can make.

That periodic malfunction may not be noticeable, because it has
destroyed some heart software that hasn't been used in the
interim. So ECC is always valuable, and omitting it is a false
economy. For example, what is the cost of reinstalling everything
from CDs, assuming you even have the original CDs, in time and
trouble.

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

 

[Richard Heathfield]

Malcolm said:

It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a
malfunction every few weeks really too bad,
Yes.

given that the software will
probably crash due to programming errors several times during that period?

That's really too bad, too.

It depends what the price premium is, and what your attitude is to money.
Bill Gates can spend an extra hundred dollars without worrying about it.
Some poor single mother scraping togther money for a Christmas present
might well feel that non-ECC is an economy she can make.

Another economy she can make is that of not buying software that crashes her
machine several times every few weeks. It is an economy that everyone
should make, to discourage sloppy programming practices.

 

[Richard Tobin]

That periodic malfunction may not be noticeable, because it has
destroyed some heart software that hasn't been used in the
interim. So ECC is always valuable, and omitting it is a false
economy. For example, what is the cost of reinstalling everything
from CDs, assuming you even have the original CDs, in time and
trouble.

The chance of a memory error resulting in the need to reinstall is so
low it is not usually worth the money. I don't think I've seen a case
attributable to it in 15 years, and none for certain before that.
If we'd put ECC memory in all our machines it would have added up
to a huge amount over the years.

It's much more important of course if you are producing data whose
value depends on its absolute reliability.

Incidentally, memory errors were much more common before manufacturers
discovered that much of the radiation came from the (usually ceramic)
chip packaging rather than cosmic rays.

-- Richard

 

[CBFalconer]

The chance of a memory error resulting in the need to reinstall is
so low it is not usually worth the money. I don't think I've seen
a case attributable to it in 15 years, and none for certain before
that. If we'd put ECC memory in all our machines it would have
added up to a huge amount over the years.

You don't know, because the non-ECC machine simply ignores the
error. It may (lucky) or may not (unlucky) cause an immediate
crash. Mostly you will be unlucky. The error cause is likely to
be something completely random, such as a cosmic ray.

We were much better off in the early days when all PCs had parity
memory and crashed on any error. More annoyed, but better off.
The head in the sand technique doesn't really work.

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

 

[Richard Bos]

fate un poco quello che vi piace a me piace mettere tutto sottosopra e
ordinare poi

Oh ja? Wel, _jouw_ mammie draagt legerkistjes!

Richard

 

[James Dow Allen]

Incidentally, memory errors were much more common before manufacturers
discovered that much of the radiation came from the (usually ceramic)
chip packaging rather than cosmic rays.

<amazing true stories>

I remember in the 1970's some chip salesmen trying to discourage
purchase
of Japanese chips, by claiming that their materials had residual
radioactivity
from Hiroshimi and Nagasaki!

In fact Japanese chips were far more reliable, partly because their
"clean rooms"
were much cleaner. A friend was chief scientist at a chip
manufacturer.
When failure rates went up, he appeared on the factory floor and
demanded: "OK, which one of you girls changed her brand of hair spray?"

</amazing true stories>

James Dow Allen