"Henri Wilson" HW@.... wrote in message
...
On Sun, 25 Feb 2007 10:32:32 -0000, "George Dishman"

wrote:


"Henri Wilson" HW@.... wrote in message
. ..
On 23 Feb 2007 01:45:05 -0800, "George Dishman"

wrote:
On 23 Feb, 09:07, HW@....(Henri Wilson) wrote:
...
It could easily be generated in radiation belts around
the whole binary system. That might act as a local EM reference frame

You still haven't learned what "reference frame" means.

Don't be silly George. I am using the term loosely here.

You are using it completely wrongly here.

The actual reference frame is that of the barycentre. I'm saying there
is
a
surrounding 'field' of some description that is virtually at rest wrt
the
barycentre and which tends to unify the speed of all light inside the
region to
'c' WRT the region. I say 'tends to' becuase its effect must obviously
taper
off with distance from the centre.
When I said the field 'constitutes a local reference frame' I mean 'the
field
defines the same frame as the barycentre' and can be used as a reference
for
light speed. It is just as legitimate to say 'speed wrt the barycentre'
as
'speed wrt the field'. They have the same meaning.

Utter garbage. You say later:

The origin of this frame is the barycentre of the pair.

The origin of a frame is whatever origin you use
for the measured values.

I didn't mean 'origin' as in 0,0 on a graph.

That's essentially what "reference frame" means, though it
doesn't imply a specific style of graph paper. It means
nothing more than the refernce point for measurements.

Oh Dear! ...and I thought I had been conversing with somebody who was a
little
more intelligent than the others....

Have another think George.

I meant the frame owes its existence to the fact that there is a
definable
centre of mass for the whole system.

No, a frame owes its existence to the fact that someone
has decided to choose a particular reference point for
his graph paper.

Load of crap George.
A frame is not a POINT.

No Henry, but the origin is.

A frame is everything at rest wrt a defined point....All frames are
infinite.

and unify
the emitted light speeds.

We are assuming its speed wrt Earth varies between about c+/-
0.00009.

No, we are taking as a given that the time between
pulse arrivals varies by about 90 parts per million.
Some of that variation is due to the velocity but
some will be due to c+v pulses catching up to c-v
pulses a little in the time before extinction
equalises their speeds.

...and that results in exactly the same doppler shift as your own
model.

What do you mean by my "own model", SR or my
corrections to your Ritzian version?

SR.

The only basic difference is that for small values of v, one uses the
equation
(c+v)/c and the other c/(c-v).

No, both those are for sound or a Galilean aether. For
SR the formula is sqrt((c+v)/(c-v)) as confirmed by Ives
and Stilwell.

If frequency f is transmitted and received as f' then:

f'/f = (c+v)/c

Define df = f' - f

df/f = v/c

For v c both c/(c-v) and sqrt((c+v)/(c-v)) give the
same expression with slight differences in the second
order part. Hence publications use a simple convention
when changing Doppler to radial speed: v/c = df/f
That's what you need to do in your program.

My program is correct...

No Henry, it isn't. You have already agreed the reasons
why it isn't correct.

and I don't predict speeds, I use the published
figures.

Your graph is not comparable to the published figures
because it does not calculate the value the way the
observations are obtained. the published figures are
based on the pulse rate alone, your aren't so your
red curve is useless.

The doppler equations for BaTh, LET and SR are virtually identical for
small v.

Not true.

I am suggesting you only need to calculate t = vR/c^2
for the value of v at each point rather than your
iterative sum at each point.

Sorry, I'm not with you.
What's R? It has dimensions of length.
I can't see an extinction RATE anywhere there.

The rate would be a function of time so as an exponential
it would include exp(-t/T) where T is some constant. The
speed difference would fall to 1/e or 37% in time T.



As a function of distance the term is exp(-t/R) where
R is the distance travelled in time T. Again the speed
difference would fall to 1/e or 37% in distance R.

Using Time or length is virtually the same anyway. I use length for my
xrate.

Exactly.

I don't think the exponential approach is workable because the integral is
definite.

Wrong again Henry, my simple equation is the result of your sum.

My series solution is far better.

No, it is only an approximation to the value I gave you,
but carry on using it if you like, it will give close to
the right answer, just slower.

George I think we are talking about different things again.

I'll explain what the two curves represent.
The blue one is the true c+v lightspeed wrt a flat plane normal to the
observer
LOS and close to the source. (We can ignore travel time across the
orbit).

It is the true velocity at that time so "travel time across the
orbit" doesn't come into it, but yes we both understand what the
curve represents.

The program assumes that hypothetical pulses of equal brightness are
emitted at
regular time intervals by the source as it orbits. At the observer
distance,
these pulses arrive in different concentrations, due to bunching.

Again we both understand that. Now what the red curve is supposed
to be is the "observed source velocity". I put that in quotes
because we cannot actually measure the source velocity directly
so what is done is the recedived pulse rate is published as a
velocity by applying the convention v/c = df/f. Your program
calculates the concentration of the pulses so all you need to do
is scale that as velocity and display it as the red curve.

No you are missing the point entirely. Forget pulsars for a minute.

No Henry we are talking _only_ about pulses for pulsars at the
moment. There are other considerations when looking at spectral
lines that will take a lot of sorting out but pulsars are
straightforward because they are long, independent bursts of
energy. You have already agreed all the relevant features, the
gaps between pulses are affected by acceleration as are the
pulse lengths so there is no doubt about the physics involved.
All you need to do now is code it correctly.

I'll be delighted to discuss otrher aspects once we finish with
pulsars but I have spent several weeks discussing J1909-3744
with you to the point where we have agreed all that is needed.

If you won't complete that topic, I am certain you won't
complete any other discussion either so it's a waste of time
starting.

snip photon stuff until later

The program divides the orbit period into 500 equal time intervals and
counts
the number of pulses that arrive at the observer in each interval. This
is
a
direct indicator of apparent brightness variation.

It is also the value that is used to work out the velocity in
actual observations.

Nah. It doesn't work like that.

Yes it does, that's how the astronomers do it so that's
what you have to do if your curve is to be comparable
to their results. If you don't, you have no way to use
the published data.

The red curve is derived by averaging the true SOURCE velocities of all
the
pulses that arrive in each particular interval.

That is where your error lies.

George, as a matter of interest I might investigate your claim further. It
could only work for fairly small magnitude changes but might actually
provide
some interesting results.
It would mean generally that observed velocities are much greater than the
true
ones.

Yes! That's why any attempt at using published data
must be compared with a curve generated by the same
method, your prgram must duplicate their technique.
At present your outputs are worthless.

You might be sorry you talked me into investigating this...

I won't be sorry no matter what it produces. At the
moment your program is unusable. I have a good idea
of amplitudes but I am less confident of my guess
about the phase shift it will produce so let's see
what it does.

George