On Thu, 03 Sep 2009 20:15:36 -0700, Chambers <Ben### [at] gmailcom>
wrote:

>Stephen wrote:
>> There are insulators between the cables and pylons so there is no path for the
>> electricity to flow there. The conductors are spaced far enough apart so that
>> the electricity cannot jump between them. This is called engineering. ;)
>
>I always assumed the cables themselves were insulated.
>
>Seriously, are we running uninsulated wires above our roadways?!?!? :o
>

I'll repost this link again but going straight to the relevant paragraph.
http://tinyurl.com/ls34v4

-- 

Regards
     Stephen

Post a reply to this message

On 3 Sep 2009 20:58:25 -0400, Jim Henderson <nos### [at] nospamcom> wrote:

>>>Because the bare wire isn't exposed, it's insulated.
>> 
>> Not on this side of the pond, Jim.
>
>Interesting, I hadn't noticed that - but I hadn't really thought to 
>look. :-)
>

Do so and report back ;)

>> I think he means jump or track to.
>
>Yeah, but it still would want to go to ground, and the water doesn't 
>provide a grounding influence that's stronger than staying with the wire.
>

Not necessarily, remember power transmission is 3 phase and the path could be
between phases.
-- 

Regards
     Stephen

Post a reply to this message

On 3 Sep 2009 20:58:45 -0400, Jim Henderson <nos### [at] nospamcom> wrote:

>> Yes but you Yanks have money to burn :P
>
>Not any more we don't.  We're burning China's money. :P

LOL
-- 

Regards
     Stephen

Post a reply to this message

> I always assumed the cables themselves were insulated.
>
> Seriously, are we running uninsulated wires above our roadways?!?!? :o

Yes, just look for "hit power line" on YouTube and you'll see plenty of 
random stuff (mostly trees) touching power lines and sparking or creating 
fires.

Post a reply to this message

Chambers schrieb:
> Only if you assume 'char' to be a text character, rather than an 8 bit 
> byte (which is what it really is, just as 'int' isn't really a true 
> integer, but rather a register-sized word on whatever machine you're 
> compiling for).

I really must object here for nitpicking's sake:


char is /not/ an 8 bit byte.

char instead is a data object /at least/ 8 bit in size and being a 
multiple of the architecture's basic storage unit. The exact size is 
defined in the compiler's <types.h> as CHAR_BIT.

On some exotic 7-bit architecture, for instance, char would have to be 
at least 14 bits in size.

There /are/ real-world architectures that do have 16-bit char types 
because they cannot individually address smaller words.

On such architectures, it is vital to note that sizeof() always returns 
a data object's size in multiples of whatever size a char occupies.


Furthermore, it should be noted that signed char and unsigned char /are/ 
integer types, and so are the short, int, long and long long types (both 
unsigned and signed, even if not explicitly qualified as such).


And no, "int" it is /not/ a register-sized word, but rather an integer 
occupying (but not necessarily fully utilizing) at least the "natural 
size suggested by the architecture of the execution environment", while 
at the same time guaranteeing to store any integer number in the range 
from -32767 (sic!) to 32767, with the exact limits being defined as 
INT_MIN and INT_MAX in <types.h>.


C data types can be real fun once you're leaving the safety of 
mainstream PC architecture :-P

Post a reply to this message

On Fri, 04 Sep 2009 00:55:22 +0200, "Fredrik Eriksson"
<fe79}--at--{yahoo}--dot--{com> wrote:

>>> That depends on the flame.
>>>
>>
>> Yip! A thermite lance or a nova will do it ;)
>
>A match will do just as well.

I was talking about the specific case of petrol vapour from a pump/fuel tank in
the open air.
Of course petrol is inflammable but in the above circumstance the air/vapour mix
goes from too rich to too lean very quickly.
Trust me :) I used to be in charge of a Fire and Gas section when I worked on an
Oil Rig. 
-- 

Regards
     Stephen

Post a reply to this message

On Fri, 4 Sep 2009 08:45:39 +0200, "scott" <sco### [at] scottcom> wrote:

>Funny, I always managed to light open containers of petrol *very* easily :-) 
>There's no huge explosion or fireball, just a nice steadily burning flame 
>from the top.
> 
Different circumstances, when you are trying to do it deliberately you can find
the right air/fuel mix by moving the match about. I bet if there had been a
strong wind it would have been very hard to light. And this is not because the
wind is blowing the flame out.

-- 

Regards
     Stephen

Post a reply to this message

clipka wrote:

> C data types can be real fun once you're leaving the safety of 
> mainstream PC architecture :-P

Indeed. Considering that C is supposedly *the* language for writing 
low-level code, I find it quite surprising that it provides absolutely 
no way to select a binary number of a specific size. It doesn't even 
seem to provide a vague suggestion of what size you're going to get; 
it's just random pot luck with each compiler you try...

Post a reply to this message

Invisible schrieb:
> Indeed. Considering that C is supposedly *the* language for writing 
> low-level code, I find it quite surprising that it provides absolutely 
> no way to select a binary number of a specific size.

That's actually its strength... until it comes to interfacing with the 
outside world, which is where things tend to get ugly.

Not commonly known, C99 also specifies that <stdint.h> shall contain 
typedefs for various integers to be used in case a particular size is 
desired:

- intN_t / uintN_t (e.g. int8_t) for exact size:

These are optional, unfortunately, but it makes sense considering that 
some architecture may have a bigger smallest-addressable-word size.

- int_leastN_t / uint_leastN_t for a certain minimum size:

These are mandatory at least for 8, 16, 32 and 64 bit.

- int_fastN_t / uint_fastN_t for fastest type of mininum size:

These are mandatory at least for 8, 16, 32 and 64 bit.


> It doesn't even 
> seem to provide a vague suggestion of what size you're going to get; 
> it's just random pot luck with each compiler you try...

Oh yes, it does: <types.h> gives you all you need to know about your 
int, short, long etc.

Well, /almost/ all: For some weird reason nobody seemes to have bothered 
mandating a standard #define to figure whether you're on a big-endian or 
little-endian machine.

Post a reply to this message

>> Indeed. Considering that C is supposedly *the* language for writing 
>> low-level code, I find it quite surprising that it provides absolutely 
>> no way to select a binary number of a specific size.
> 
> That's actually its strength... until it comes to interfacing with the 
> outside world, which is where things tend to get ugly.

And given that currently the number one use for C is to interface with 
the outside world... strange choice, that.

> Not commonly known, C99 also specifies that <stdint.h> shall contain 
> typedefs for various integers to be used in case a particular size is 
> desired:
> 
> - intN_t / uintN_t (e.g. int8_t) for exact size:
> 
> These are optional, unfortunately, but it makes sense considering that 
> some architecture may have a bigger smallest-addressable-word size.
> 
> - int_leastN_t / uint_leastN_t for a certain minimum size:
> 
> These are mandatory at least for 8, 16, 32 and 64 bit.
> 
> - int_fastN_t / uint_fastN_t for fastest type of mininum size:
> 
> These are mandatory at least for 8, 16, 32 and 64 bit.

Mmm, interesting. (But, presumably, unused?)

>> It doesn't even seem to provide a vague suggestion of what size you're 
>> going to get; it's just random pot luck with each compiler you try...
> 
> Oh yes, it does: <types.h> gives you all you need to know about your 
> int, short, long etc.
> 
> Well, /almost/ all: For some weird reason nobody seemes to have bothered 
> mandating a standard #define to figure whether you're on a big-endian or 
> little-endian machine.

I don't see anything useful listed - unless I'm looking at the wrong file...

Post a reply to this message