Re: Pi Forums

"I think element14 owes a lot to RasPi and its Foundation".

As a very rare contributer I also think the RasPi and it´s Foundation owes a lot to Element 14 and the excellent after sales service.  Over the last 14 months I have purchased three Raspberry Pi. a self assembly Gertboard Kit, a PiFace Digital and most recently a BBB.  Every time Element 14 have done what they said they would do with very propmpt replies to any questions.  In particular Rachel has been very efficient and helpful.

Colin Gearon.

Colin Gearon wrote:

 

I also think the RasPi and it´s Foundation owes a lot to Element 14

Very true.  E14/Farnell hasn't really put a foot wrong throughout the whole Pi saga, not significantly.

Their site collapsed during launch for a few days, but that was caused by RPF's entirely ridiculous concept of opening the floodgates to pre-orders at a single instant of time and requiring customers to compete.  This is not just the power of hindsight.  Every web service on the planet with the exception of Google and Facebook is likely to collapse when 100k+ people hit it within a few seconds, and subsequent recovery is prevented because of the retries.  I blame the collapse squarely on RPF's faulty planning.  The fact that  RS collapsed at the same time offers proof of that.  At worst, Farnell and RS were guilty of not telling RPF that such an approach was not feasible given their server capabilities, although competition between them may have prevented either party saying "We can't do that".  It was obvious though.  Even RPF's forum sysadmin could have told them that.  It was even checkable in advance with a load test script.

Once Pi became available, my only significant criticisms of E14/Farnell are that the export site provides substandard Farnell service (compared to Farnell UK), and that they haven't been fast enough at putting Pi on a regular product footing now that it is ex-stock.  This still hasn't happened, and that's a fault because substandard service should never be considered "business as usual" for Farnell.  Also, they could have volunteered a bit more information when people were asking for it, but none of these things are epic disasters.

So on the whole, almost full marks.

And in case anyone suspects that this is just being nice to our hosts here, I think we've made our feelings quite plain and unambiguous when we've criticised the dreadful handling of knode discussions for BBB, so we don't hesitate to highlight things that are are broken when they are.  This problem is still present, but the fault was acknowledged rapidly and an update is in progress for end of Q3 so we live with it, unhappily but patiently.

Well done E14 on Pi.

Frank,

   You've gotten some good advice.  He're my 2 cents:

Teach what you know.  If you know Basic, teach that.  Don't try to learn

Python or whatever just because someone else thinks it's the perfect

teaching language.  There is no perfect teaching language, and any language

you pick, or topics you pick, will likely be considered a bad choice by someone.

The students will be able to tell right away whether you know and are enthusiastic

about what you're teaching, and that's what matters most.

Michael wrote:

There are two parts to your problem.

I think there are a lot of parts in general to the problem of how to introduce

students to computers and/or computer science.  For example, a very small

percentage of students like programming.   I don't think there's any magic

solution, such as "physical computing" that will make the subject universally

appealing. 

Secondly, you can't advertise computing as a secure career path.  Programming

is relatively easy to outsource to low-wage countries, and the field changes

so rapidly that employers are often looking primarily for young programmers who

don't need to be trained on the latest technologies, and who are willing to work

long hours.

Thirdly, the field of computing is so vast that anything you teach will just be

an "exposure" to one or more aspect of the subject, so there is no point trying to

teach the "right" lessons.

Fourthly, the field is young enough that there is very little consensus on

standard technologies or even terminologies.  One of the most fundamental

concepts of programming is the subprogram, but in various languages it is

called a procedure, or a function, or a method.  There is also no consensus

in programming on how or even whether to declare variables.   Some languages

are good for efficiency, some for safety, some for productivity, some for

client-side web applications, some for server-side web applications, etc.

So the students will likely soon be re-learning anything you teach.

coder27 wrote:

 

Thirdly, the field of computing is so vast that anything you teach will just be

an "exposure" to one or more aspect of the subject, so there is no point trying to

teach the "right" lessons.

Very well said.  Even those who have been in the discipline for many decades, including academia and industry, know only a very tiny fraction of its full extent.  It's a bit disconcerting to face that reality, but not a reason for depression.  We just have to pick and choose from the vast mountain and find one or two narrow areas where we can accomplish something.

This is also one very good reason to highlight the difference between education and vocational training.  Education is that aspect of our learning that is so general that it provides us with a base or foundation for everything we do in the future, but on its own is of very limited direct applicability.  In contrast, vocational training is directly applicable, but may be useful only briefly and our experience of it may not translate to future endeavours at all.  (All learning usually involves both, but the percentage of each may vary almost 0-100%.)

Giving youngsters strong vocational training makes little sense, since the number that will be able to apply it is likely to be low or even zero if it's in an area of change like so many are in practical computing.  This makes coder27's remark about no point trying to teach the "right" lessons spot on.  Instead, focus on educating them about widely applicable concepts, because those will stand them in good stead forever, even outside of the discipline.

Morgaine.

Morgaine Dinova wrote:

 

Education is that aspect of our learning that is so general that it provides us with a base or foundation for everything we do in the future, but on its own is of very limited direct applicability.

Taken to its extreme, this statement brings up a wonderful quote from the depths of my memory:

The principle is so perfectly general that no particular application can be made of it.

I have found in practice that computing has a nice balance between theory and practice, with far more emphasis on practice AKA "the bag of tricks".  This is particularly true if computing is taught by engineers.

Oh, it's very easy to find examples of pure 100% education accompanied by no vocational training material whatsoever in this field, and very useful it is too.

For example, you can teach people iteration using only a PDL and sequence diagrams, and they won't be able to apply it directly at all unless they've grasped the concept well and can translate it into a real program written in a language that has a real implementation on a machine to which they have access and learn to run.  These practical hurdles seem like nothing to us, but in many parts of the world they would be vast compared to the relative ease of obtaining written educational material.

I have found in practice that computing has a nice balance between theory and practice, with far more emphasis on practice AKA "the bag of tricks".  This is particularly true if computing is taught by engineers.

Computer science, when not taught by engineers, is all about putting away "the bag of tricks."

The monster we are trying to tame is complexity, not efficiency.

The bag of tricks may help efficiency, but it makes code fragile.

The next time the underlying hardware is upgraded, the trick will likely

either not work correctly, or not be more efficient.  In any case, the trick

will impede maintenance.

For example, there is a really clever way to compute absolute value

of a 2's-complement number in three machine-code instructions without

a conditional instruction that may cause the pipeline to stall.  But someone

reading the code will have absolutely no idea what it does, unless well documented.

And the next hardware upgrade may eliminate the overhead of pipeline stalls

in such cases, or may have a single instruction that computes absolute value

in one cycle.

http://stackoverflow.com/questions/664852/which-is-the-fastest-way-to-get-the-absolute-value-of-a-number

(see reply by vicatcu)

Edited to add:  that's the wrong link, as noted below!

Frank,

  Here's a practical suggestion.  Computer systems are complex devices.

Most complex devices are best explained in a hierarchical fashion, rather than

jumping randomly between levels in the hierarchy.  This notion leaps out at you

if you look at the RPF's first few educational videos, compared say with MIT's

first computer science course.  Clive jumps randomly within a few minutes between

all sorts of concepts presumably unfamiliar to the viewer, such as programming languages,

IDEs, GUI's, shells, flowcharts, pseudocode, algorithms, functions, variables,

debugger break-points, text files, translators, USB ports, network ports, RAM/ROM,

BIOS, and fetch/decode/execute cycles.

For example, a galaxy such as the Milky Way is a complex object.  Viewed as a galaxy,

it can be seen to have properties such as spiral arms made of fuzzy dots of light.

Zooming in on a fuzzy dot, such as our sun, you see a solar system with orbiting

planets.  The planets are important at this level of abstraction, but they are unimportant

at the galaxy level.  Zooming in on a planet, such as Earth, you see it has a moon orbiting it,

and has blue oceans, clouds, and land masses.  Again, such features are important at

this level of detail, but not at higher levels.  You can zoom in on a particular continent,

and you will see mountains, plains, rivers, cities, etc.  You can zoom in on a particular city,

and see streets, buildings, people, etc.  You can zoom in on a particular person,

and see a face, torso, limbs, etc.  You can zoom in on the torso, and find various

internal organs and blood vessels, etc.  You can zoom in on the heart and find

its chambers and valves, and zoom further and find cells. You can zoom in on cells,

and find a cell membrane, and a nucleus, etc.  In the nucleus you will find chromosomes,

and you can keep zooming to find genes, atoms, protons/electrons/neutrons, quarks, etc.

The key feature is that what is important at one level is unimportant at other levels,

and you can begin your study at any level by ignoring higher and lower levels.

A computer system can be explained at the level of a programming language,

or it can be explained at the level of its instruction-set architecture, or other

levels, both higher and lower. But if you randomly jump around between levels,

you will probably just confuse your audience.

coder27 wrote:

 

For example, there is a really clever way to compute absolute value

of a 2's-complement number in three machine-code instructions without

a conditional instruction that may cause the pipeline to stall.  But someone

reading the code will have absolutely no idea what it does, unless well documented.

And the next hardware upgrade may eliminate the overhead of pipeline stalls

in such cases, or may have a single instruction that computes absolute value

in one cycle.

http://stackoverflow.com/questions/664852/which-is-the-fastest-way-to-get-the-absolute-value-of-a-number

(see reply by vicatcu)

Ooh, that is a cute way to do it.  Yes, it needs to be well documented, just like any trick.  But I would see that exactly as something that should be taught since it helps students master 2's complement arithmetic.

uint32_t temp = value >> 31;     // make a mask of the sign bit
value ^= temp;                   // toggle the bits if value is negative
value += temp & 1;               // add one if value was negative 

Hmm, that looks more like 4 machine instructions since the last one does two operations, AND followed by ADD.  The ARM instruction set has a condition code field for most instructions which allows you to do it in two very straightforward instructions, one to test the value of X and one to conditionally replace it with -X.  You might be able to combine the test of X with a previous operation and get by with just one instruction.  Thumb2 requires an additional IF instruction.  Other instruction sets have conditional register-to-register moves.

Of course, getting the compiler to notice that it can use conditional instuctions can be problematic, particularly if you use vicatcu's trick.  This gives another important lesson since it requires students to understand computers at the machine-language level, and the whole idea of avoiding conditional branches is because of pipelining, which is another thing students of computing should understand.  Amazing how something as simple as finding absolute value opens multiple cans of worms

oh eeek !!!!!!

uint32_t temp = value >> 31;

is implementation dependent behaviour in C.

I'm assuming that value is int32_t so this applies:

The (1999) ISO standard for the C programming language defines the C language's right shift operator in terms of divisions by powers of 2.^[5] Because of the aforementioned non-equivalence, the standard explicitly excludes from that definition the right shifts of signed numbers that have negative values. It doesn't specify the behaviour of the right shift operator in such circumstances, but instead requires each individual C compiler to specify the behaviour of shifting negative values right.^{[note 6]}

note 6 says:

^ The C standard was intended to not restrict the C language to either ones' complement or two's complement architectures. In cases where the behaviours of ones' complement and two's complement representations differ, such as this, the standard requires individual C compilers to document the actual behaviour of their target architectures. The documentation for GCC, for example, documents its behaviour as employing sign-extension

(from http://en.wikipedia.org/wiki/Arithmetic_shift)

@John,

I know you didn't actually say it was C but I felt I should warn the unwary - of course in assembler there is no dificulty in specifying logical or artimetic shifts - and in VHDL we can do anything.

MK

Hmm, that looks more like 4 machine instructions since the last one does two operations, AND followed by ADD.

Oops, you're right.  That wasn't the clever 3-instruction way I was thinking of.  This is:

http://www.geeksforgeeks.org/compute-the-integer-absolute-value-abs-without-branching/

Michael Kellett wrote:

 

oh eeek !!!!!!

 

uint32_t temp = value >> 31;

 

is implementation dependent behaviour in C.

 

I'm assuming that value is int32_t so this applies:

 

The (1999) ISO standard for the C programming language defines the C language's right shift operator in terms of divisions by powers of 2.^[5] Because of the aforementioned non-equivalence, the standard explicitly excludes from that definition the right shifts of signed numbers that have negative values. It doesn't specify the behaviour of the right shift operator in such circumstances, but instead requires each individual C compiler to specify the behaviour of shifting negative values right.^{[note 6]}

 

note 6 says:

 

 

^ The C standard was intended to not restrict the C language to either ones' complement or two's complement architectures. In cases where the behaviours of ones' complement and two's complement representations differ, such as this, the standard requires individual C compilers to document the actual behaviour of their target architectures. The documentation for GCC, for example, documents its behaviour as employing sign-extension

 

(from http://en.wikipedia.org/wiki/Arithmetic_shift)

 

@John,

 

I know you didn't actually say it was C but I felt I should warn the unwary - of course in assembler there is no dificulty in specifying logical or artimetic shifts - and in VHDL we can do anything.

 

MK

The last one's complement machine I used was a Univac 1110.  Negative zeros could sometime do nasty things.

OTOH, one's complement arithmetic is a nice way to implement floating-point addition and subtraction.  Who's ready for a carry look-ahead end-around carry?

I'm afraid that I do make heavy use of the fact that all the machines I run on are two's complement.  For example, I represent angles using Binary Angular Measurement, where two's complement and unsigned numbers represent exactly the same angle.

Michael Kellett wrote:

 

oh eeek !!!!!!

 

uint32_t temp = value >> 31;

 

is implementation dependent behaviour in C.

 

I'm assuming that value is int32_t so this applies:

 

The (1999) ISO standard for the C programming language defines the C language's right shift operator in terms of divisions by powers of 2.^[5] Because of the aforementioned non-equivalence, the standard explicitly excludes from that definition the right shifts of signed numbers that have negative values. It doesn't specify the behaviour of the right shift operator in such circumstances, but instead requires each individual C compiler to specify the behaviour of shifting negative values right.^{[note 6]}

 

note 6 says:

 

 

^ The C standard was intended to not restrict the C language to either ones' complement or two's complement architectures. In cases where the behaviours of ones' complement and two's complement representations differ, such as this, the standard requires individual C compilers to document the actual behaviour of their target architectures. The documentation for GCC, for example, documents its behaviour as employing sign-extension

 

(from http://en.wikipedia.org/wiki/Arithmetic_shift)

 

@John,

 

I know you didn't actually say it was C but I felt I should warn the unwary - of course in assembler there is no dificulty in specifying logical or artimetic shifts - and in VHDL we can do anything.

 

MK

The last one's complement machine I used was a Univac 1110.  Negative zeros could sometime do nasty things.

OTOH, one's complement arithmetic is a nice way to implement floating-point addition and subtraction.  Who's ready for a carry look-ahead end-around carry?

I'm afraid that I do make heavy use of the fact that all the machines I run on are two's complement.  For example, I represent angles using Binary Angular Measurement, where two's complement and unsigned numbers represent exactly the same angle.

I would like to take a moment to compliment everyone here for spelling "complement" correctly.  Anyone who's taught this material knows what I'm talking about.

I'm afraid that I do make heavy use of the fact that all the machines I run on are two's complement.  For example, I represent angles using Binary Angular Measurement, where two's complement and unsigned numbers represent exactly the same angle.

Maybe you should be using a higher-level language that supports fixed-point types.

I believe Ada has direct support for this, with the advantage that the compiler worries

about the representation, not the programmer.

Then there is initialization which ruins the old kid's joke about Mississippi.