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

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

Re: should c be a subset of c++?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: should c be a subset of c++? "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-06 19:06 -0500
    Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 00:41 -0800
      Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-11-07 10:01 -0500
        Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 09:12 -0800
          Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-11-07 11:58 -0600
            Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 10:25 -0800
              Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-07 11:54 -0800
                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 14:22 -0800
                  Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-11-08 13:05 -0600
                    Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 11:39 -0800
                      Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 13:20 -0800
                        Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-11-13 16:36 -0500
                        Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-14 00:03 +0000
                          Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 17:06 -0800
                      Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-11-13 13:29 -0800
              Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-11-08 12:57 -0600
                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 11:37 -0800
                  Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-08 17:16 -0800
                    Re: should c be a subset of c++? supercat@casperkitty.com - 2015-11-08 18:19 -0800
                  Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-11-08 23:25 -0600
                  Re: should c be a subset of c++? Gareth Owen <gwowen@gmail.com> - 2015-11-10 22:34 +0000
          Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-13 22:18 +0000
            Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-14 00:11 +0000
              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:16 +0000
                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-17 21:09 -0800
                  Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 05:22 +0000
                  Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-18 06:03 -0800
                    Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 08:44 -0800
                      Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-18 09:11 -0800
                        Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 09:54 -0800
                          Re: should c be a subset of c++? Philip Lantz <prl@canterey.us> - 2015-11-24 01:49 -0800
                            Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-24 02:58 -0800
                              Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-24 11:58 +0000
                              Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-11-24 09:09 -0800
                                Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-25 00:12 -0800
                                  Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 12:35 +0000
                                  Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:30 +0000
                      Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:37 +0000
                      Re: should c be a subset of c++? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 15:40 -0800
    Re: should c be a subset of c++? Gareth Owen <gwowen@gmail.com> - 2015-11-10 22:20 +0000

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

#75693

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> That seems obviously wrong to me.
> A population can't be negative, surely? It's "really" positive.
> Also surface area.

How about the 4-norm of a time-like interval?

How about the energy density between two plates in the Casimir effect,
or one of the virtual particles responsible for Hawking radiation?

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

#75980

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> In the proton electron case, the signs are just a convention.
> There's no reason why electrons are negative, other than historical
> accident.

That's a nonsensical argument. Yes, electrons could have been positive -
but in that case, protons would have _had_ to be negative. Their charges
are opposite, so whatever choice you make, one, exactly one, of them has
to be positive, and the other negative. In the case of electrical
charge, however much you argue against it at a middle-school level,
physics _needs_ negative numbers - one way, or another.

Richard

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

#75993

Richard Bos <raltbos@xs4all.nl> wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
 
>> In the proton electron case, the signs are just a convention.
>> There's no reason why electrons are negative, other than historical
>> accident.
 
> That's a nonsensical argument. Yes, electrons could have been positive -
> but in that case, protons would have _had_ to be negative. Their charges
> are opposite, so whatever choice you make, one, exactly one, of them has
> to be positive, and the other negative. In the case of electrical
> charge, however much you argue against it at a middle-school level,
> physics _needs_ negative numbers - one way, or another.

Since electron currents are much more useful than proton currents,
some might suggest that having the electron positive would be more
convenient.

But most of EE does just fine with current being, by definition,
positve in the direction that positive charges would move. 

But even more, there are materials with a positive Hall coefficient.
That is, where the current charge carriers are positive.

Aluminum has both hole and electron bands, with the latter slightly
more populated at low magnetic field. At higher field, the hole bands
are more populated. As most electric power is sent through aluminum
wires (just about until it gets into your house) it isn't so far off
to say that current should be positive.

-- glen

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

#76303

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Bos <raltbos@xs4all.nl> wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>  
> >> In the proton electron case, the signs are just a convention.
> >> There's no reason why electrons are negative, other than historical
> >> accident.
>  
> > That's a nonsensical argument. Yes, electrons could have been positive -
> > but in that case, protons would have _had_ to be negative. Their charges
> > are opposite, so whatever choice you make, one, exactly one, of them has
> > to be positive, and the other negative. In the case of electrical
> > charge, however much you argue against it at a middle-school level,
> > physics _needs_ negative numbers - one way, or another.
> 
> Since electron currents are much more useful than proton currents,
> some might suggest that having the electron positive would be more
> convenient.
> 
> But most of EE does just fine with current being, by definition,
> positve in the direction that positive charges would move. 
> 
> But even more, there are materials with a positive Hall coefficient.
> That is, where the current charge carriers are positive.

All true, and all irrelevant - because in all those cases, _one_ of the
charges must be negative. We got to choose whether the electron or the
proton was negative, and arguably got it wrong - but even if we'd got it
right, we wouldn't have been able to avoid a negative charge on either
one particle or the other.

Richard

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

#76356

On Tuesday, November 17, 2015 at 10:17:25 PM UTC, Richard Bos wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
> > But even more, there are materials with a positive Hall coefficient.
> > That is, where the current charge carriers are positive.
> 
> All true, and all irrelevant - because in all those cases, _one_ of the
> charges must be negative. We got to choose whether the electron or the
> proton was negative, and arguably got it wrong - but even if we'd got it
> right, we wouldn't have been able to avoid a negative charge on either
> one particle or the other.
> 
If you observe cars travelling down a typical road, you might well come 
to the conclusion that the vehicle's velocity is signed. But it's just
an illusion, created by the fact that you can't measure the slight 
angular displacements.
What assurance do we have that particle charge signs aren't like that?

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

#76358

On 18/11/15 05:09, Malcolm McLean wrote:
> On Tuesday, November 17, 2015 at 10:17:25 PM UTC, Richard Bos wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>>
>>> But even more, there are materials with a positive Hall coefficient.
>>> That is, where the current charge carriers are positive.
>>
>> All true, and all irrelevant - because in all those cases, _one_ of the
>> charges must be negative. We got to choose whether the electron or the
>> proton was negative, and arguably got it wrong - but even if we'd got it
>> right, we wouldn't have been able to avoid a negative charge on either
>> one particle or the other.
>>
> If you observe cars travelling down a typical road, you might well come
> to the conclusion that the vehicle's velocity is signed.

Quite so, and for good reason.

> But it's just
> an illusion, created by the fact that you can't measure the slight
> angular displacements.

Actually, you can, if you have the right equipment. But, whether or not 
you can, the vehicle's velocity is still signed. Velocity is the change 
in displacement over time, and displacement is movement with respect to 
a fixed point in a particular fixed direction. Thus, if we (arbitrarily) 
define the fixed point as "right here", and the direction as "east", 
then a vehicle that is west of us and travelling in a westward direction 
has negative velocity. (A vehicle that is east of us and travelling in a 
westward direction still has negative velocity, but to measure this 
requires a certain degree of courage.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76398

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, November 17, 2015 at 10:17:25 PM UTC, Richard Bos wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> 
>> > But even more, there are materials with a positive Hall coefficient.
>> > That is, where the current charge carriers are positive.
>> 
>> All true, and all irrelevant - because in all those cases, _one_ of the
>> charges must be negative. We got to choose whether the electron or the
>> proton was negative, and arguably got it wrong - but even if we'd got it
>> right, we wouldn't have been able to avoid a negative charge on either
>> one particle or the other.
>> 
> If you observe cars travelling down a typical road, you might well come 
> to the conclusion that the vehicle's velocity is signed. But it's just
> an illusion, created by the fact that you can't measure the slight 
> angular displacements.
> What assurance do we have that particle charge signs aren't like that?

Velocity is a vector.  In a 1-+dimensional environment, it reduces to a
signed quantity.  Electrical charge is, as far as I know, a discrete
scalar with oppositely signed values.  The physical theory that
describes it has been confirmed to an impressive number of deimal
places.

Are you *still* trying to argue that negative values are not physically
significant?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76417

On Wednesday, November 18, 2015 at 2:03:52 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> Velocity is a vector.  In a 1-+dimensional environment, it reduces to a
> signed quantity.  Electrical charge is, as far as I know, a discrete
> scalar with oppositely signed values.  The physical theory that
> describes it has been confirmed to an impressive number of deimal
> places.
> 
> Are you *still* trying to argue that negative values are not physically
> significant?
> 
Let's say electrons and protons are in fact travelling like cars on a road down
a space which is constricted in all dimensions but one. Then their sign would
simply be the major vector.
Occasionally, as on a real road, one might do an about turn. And so flip
sign. Then it would collide in the space with another and you'd get a 
destructive event. But you'd hardly ever see that.
I'm not saying this is how the system works, but no one here has suggested
anything to show the contrary (I don't have freshman physics, there might be
a very simple reason why we know the system can't work like that). So sign
would be an illusion, an artefact of our instruments' limitations.
What leads me to suggest this is that we can't assign "negative" or "positive".  

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

#76427

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, November 18, 2015 at 2:03:52 PM UTC, Keith Thompson wrote:
[...]
>> Are you *still* trying to argue that negative values are not physically
>> significant?
>> 
> Let's say electrons and protons are in fact travelling like cars on a road down
> a space which is constricted in all dimensions but one. Then their sign would
> simply be the major vector.
> Occasionally, as on a real road, one might do an about turn. And so flip
> sign. Then it would collide in the space with another and you'd get a 
> destructive event. But you'd hardly ever see that.
> I'm not saying this is how the system works, but no one here has suggested
> anything to show the contrary (I don't have freshman physics, there might be
> a very simple reason why we know the system can't work like that). So sign
> would be an illusion, an artefact of our instruments' limitations.
> What leads me to suggest this is that we can't assign "negative" or "positive".  

There are real-world quantities for which both positive and negative
numbers make sense.

Do you *really* dispute that?  Citing specific cases where that might
not be 100% accurate is not particularly useful.  In any case, this is
not about C (unless you want to propose changes to the language to fit
your concept of physics).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76432

On Wednesday, November 18, 2015 at 5:11:30 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> There are real-world quantities for which both positive and negative
> numbers make sense.
> 
> Do you *really* dispute that?  Citing specific cases where that might
> not be 100% accurate is not particularly useful.  In any case, this is
> not about C (unless you want to propose changes to the language to fit
> your concept of physics).
> 
No-one is a stronger opponent of the unsigned size_t than me. 

I don't oppose negative values as intermediate results. But ultimately
the should cancel out. I think there a strong case for banning

unsigned char buff[100];
unsigned char *ptr = buff + 50;

ptr[-1] = 'x';

but not intermediate negative indices e.g. filtering the buffer with a
guard like if (index < 0 || index >= 100) continue;

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

#77066

Malcolm McLean wrote:
> No-one is a stronger opponent of the unsigned size_t than me. 
> 
> I don't oppose negative values as intermediate results. But ultimately
> the should cancel out. I think there a strong case for banning
> 
> unsigned char buff[100];
> unsigned char *ptr = buff + 50;
> 
> ptr[-1] = 'x';

Which of these would you also ban? (Given your declarations above.)
ptr--;
ptr -= 1;
ptr - 1;
*(ptr - 1);
*(ptr - 1) = 'x';

Or would you break the equivalence between *(a+b) and a[b]?

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

#77075

On Tuesday, November 24, 2015 at 9:49:36 AM UTC, Philip Lantz wrote:
> Malcolm McLean wrote:
> > No-one is a stronger opponent of the unsigned size_t than me. 
> > 
> > I don't oppose negative values as intermediate results. But ultimately
> > the should cancel out. I think there a strong case for banning
> > 
> > unsigned char buff[100];
> > unsigned char *ptr = buff + 50;
> > 
> > ptr[-1] = 'x';
> 
> Which of these would you also ban? (Given your declarations above.)
> ptr--;
> ptr -= 1;
> ptr - 1;
> *(ptr - 1);
> *(ptr - 1) = 'x';
> 
> Or would you break the equivalence between *(a+b) and a[b]?
>
There's a case for banning the lot, and not having pointer arithmetic
other than pointer differences. You could still generate pointers
with &array[i];
There are just one or two places you need ptr -1, for example in a typical
malloc() implementation where the control block is before the pointer.
 
If data is in an array, it makes sense to access it using array subscripts.
If it's not in an array, pointer arithmetic is pointless.

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

#77081

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> If data is in an array, it makes sense to access it using array subscripts.
> If it's not in an array, pointer arithmetic is pointless.

All data - at least, all data in an object - is in an array. Sometimes
it's in a single-element array, but that's still an array. Pointer
arithmetic is central to C's handling of data; removing it will leave
too large a hole to be readily replaced with something like Pascal
arrays.

Richard

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

#77110

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> There's a case for banning the lot, and not having pointer arithmetic
> other than pointer differences. You could still generate pointers
> with &array[i];
> There are just one or two places you need ptr -1, for example in a typical
> malloc() implementation where the control block is before the pointer.
>  
> If data is in an array, it makes sense to access it using array subscripts.
> If it's not in an array, pointer arithmetic is pointless.

Ok, so you don't like C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#77149

On Tuesday, November 24, 2015 at 5:10:00 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > If data is in an array, it makes sense to access it using array 
> > subscripts.
> > If it's not in an array, pointer arithmetic is pointless.
> 
> Ok, so you don't like C.
> 
In the olden days, C programmers were used to working in assembly,
and the instruction x[i] = 0 would compile to

register 1 = x;
register 2 = i;
register a = register 1 + register 2
write zero to register a

the instruction *ptr = 0 would compile to

register a = ptr
write zero to register a

so you could get a worthwhile speed-up using pointer arithmetic,
and it also made sense in the programmer's worldview.

But compilers and processors have moved on. There's seldom
any speed advantage for be gained by using a travelling pointer
rather than index i. So the occasions where pointer arithmetic
is useful are rare. Integrating with the C++ "iterator" nonsense
is one, implementing malloc() itself is another, and taking
the difference between two pointers is maybe another. But
shouldn't need to increment, decrement, or add a constant to a
pointer. (Of course taking &x[i] is effectively adding a constant
to a pointer, the need for the machine operation doesn't go
away).

Data will usually come in arrays, so access with x[i] and step through
with a for loop. If you need to support fast insertions and deletions,
use a linked list, and step through with 
for(ptr = head; ptr; ptr = ptr->next)

if it's a tree use the following pattern

while(node)
{
    /* operation here */
    if(node->child)
      foo(node->child);
    node = node->next;
}

those will support almost everything except special fast access containers,
databases, and so on. If you use such a structure, usually stepping
through the data is a special operation that is performed rarely
or has problems associated with it. 

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

#77157

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
 
(snip)

> In the olden days, C programmers were used to working in assembly,
> and the instruction x[i] = 0 would compile to
 
> register 1 = x;
> register 2 = i;
> register a = register 1 + register 2
> write zero to register a

Some processors have indexed addressing mode, combining the last
two steps. That might take more time than a non-indexed load, but
usually less than two instructions.
 
> the instruction *ptr = 0 would compile to
 
> register a = ptr
> write zero to register a
 
> so you could get a worthwhile speed-up using pointer arithmetic,
> and it also made sense in the programmer's worldview.

Also, computers were slower then, so "worthwhile speed-up" was easier.
 
> But compilers and processors have moved on. There's seldom
> any speed advantage for be gained by using a travelling pointer
> rather than index i. So the occasions where pointer arithmetic
> is useful are rare. Integrating with the C++ "iterator" nonsense
> is one, implementing malloc() itself is another, and taking
> the difference between two pointers is maybe another. But
> shouldn't need to increment, decrement, or add a constant to a
> pointer. (Of course taking &x[i] is effectively adding a constant
> to a pointer, the need for the machine operation doesn't go
> away).

Yes.  At least for a simple loop, the compiler should be able
to figure this out. Compilers have been able to do this on larger
machines for longer than there has been C. It took a little longer
for smaller computers.
 
> Data will usually come in arrays, so access with x[i] and step through
> with a for loop. If you need to support fast insertions and deletions,
> use a linked list, and step through with 
> for(ptr = head; ptr; ptr = ptr->next)
 
> if it's a tree use the following pattern
 
> while(node)
> {
>    /* operation here */
>    if(node->child)
>      foo(node->child);
>    node = node->next;
> }
 
> those will support almost everything except special fast access containers,
> databases, and so on. If you use such a structure, usually stepping
> through the data is a special operation that is performed rarely
> or has problems associated with it. 

For the simplest function indexing through arrays, I might still 
use the pointer increment loop. That is, where it is obvious I don't
need the pointer variables for anything else.

Otherwise, the extra work of saving the pointer, the reduction in
readability keeping track of which value is in which variable, 
makes the indexed form more readable.

-- glen

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

#77252

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Tuesday, November 24, 2015 at 5:10:00 PM UTC, Keith Thompson wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > 
> > > If data is in an array, it makes sense to access it using array 
> > > subscripts.
> > > If it's not in an array, pointer arithmetic is pointless.
> > 
> > Ok, so you don't like C.
> > 
> In the olden days, C programmers were used to working in assembly,

More Good Old Olden Days? Yes, back when men were _real_ men,
programmers were _real_ nerds, and optimisers were _real_ optimisers...
even back then, those pipe dreams were as realistic as the heroic tales
of the Wild Wild West.

Richard

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

#76501

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Wednesday, November 18, 2015 at 2:03:52 PM UTC, Keith Thompson wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > 
> > Velocity is a vector.  In a 1-+dimensional environment, it reduces to a
> > signed quantity.  Electrical charge is, as far as I know, a discrete
> > scalar with oppositely signed values.  The physical theory that
> > describes it has been confirmed to an impressive number of deimal
> > places.
> > 
> > Are you *still* trying to argue that negative values are not physically
> > significant?
> > 
> Let's say electrons and protons are in fact travelling like cars on a road down
> a space which is constricted in all dimensions but one.

No, let's not say something so spectacularly misapprehensive.

> I'm not saying this is how the system works, but no one here has suggested
> anything to show the contrary (I don't have freshman physics,

Frankly, from what you've been saying, I get the impression you don't
have middle-school physics.

Richard

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

#76695

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Wednesday, November 18, 2015 at 2:03:52 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Velocity is a vector.  In a 1-+dimensional environment, it
>> reduces to a signed quantity.  Electrical charge is, as far as I
>> know, a discrete scalar with oppositely signed values.  The
>> physical theory that describes it has been confirmed to an
>> impressive number of deimal places.
>>
>> Are you *still* trying to argue that negative values are not
>> physically significant?
>
> Let's say electrons and protons are in fact travelling like cars
> on a road [...]

By all means say it if you want to.  But say it somewhere else.
This is comp.lang.c.

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

#75690

"J. Clarke" <j.clarke.873638@gmail.com> writes:

> Malcolm, if you think that negative values have no reality in physics
> you have not passed freshman physics at any accredited university.

Gee, you think?

[toc] | [prev] | [standalone]

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

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

csiph-web