Anisotropy and Mercury (2)

"Max Keon" wrote in message
u...

I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there. It
-can't be there on one path and not be there on another at the
-same time.

-The reason for the inconsistency is of course that, while it's
-in orbit, the fall direction doesn't always point at the Sun.
-The fall is then directly related to COS and pi. The average
-orbital second is 1/(pi/2) straight line seconds.

This paragraph replaces the above paragraph, for obvious reasons:
The reason for the inconsistency is of course that, while it's
in orbit, the fall direction doesn't always point at the Sun
along the path of the chosen diameter. The fall is then directly
related to COS and pi. The average orbital second is 1/(pi/2)
straight line seconds.


It is wrong anyway since it is changed by the anisotropy.
In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:

1) you gave me an equation for the acceleration

2) acceleration is defined as rate of change of velocity

3) velocity is defined as rate of change of location

Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.

That's what the program does, so for the anisotropy you have
described, the program results are valid to the accuracy I
demonstrated. That's the beginning and end of this argument.

George

"George Dishman" wrote in message
...
"Max Keon" wrote in message
u...

Firstly, I've included two paragraphs from your other reply
because I don't wish to go off on another tangent that repeats
what will be addressed here.

... leaving the final
approach to aphelion or perihelion somewhere in limbo. Then you
claim proof of an orbit eccentricity collapse?

The program waits until the fall to perihelion is
complete, it is triggered by the radius staring to
rise and it prints out the previous value which of
course is the smallest.

Maybe the trigger point does index around, but the aphelion
and perihelion approach is still halted at that point because
you are assuming that anisotropic gravity is inelastic. But
you have no evidence to support that assumption.

That value is greater than
it would have been without the anisotropy exactly
as you said it would be a few posts back

"exactly as I said it would be", was according to your reasoning
George, not mine. If I agree with the consequences of your
reasoning, that doesn't mean I accept your reasoning in
principle.

-------------

I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there. It
-can't be there on one path and not be there on another at the
-same time.

-The reason for the inconsistency is of course that, while it's
-in orbit, the fall direction doesn't always point at the Sun.
-The fall is then directly related to COS and pi. The average
-orbital second is 1/(pi/2) straight line seconds.

This paragraph replaces the above paragraph, for obvious reasons:
The reason for the inconsistency is of course that, while it's
in orbit, the fall direction doesn't always point at the Sun
along the path of the chosen diameter. The fall is then directly
related to COS and pi. The average orbital second is 1/(pi/2)
straight line seconds.

It is wrong anyway since it is changed by the anisotropy.

I take it that you were not aware that Mercury's fall distance
for each half orbit is equal to the orbit diameter, and that it's
equal to the time for the half orbit divided by pi/2 multiplied
by the orbital speed, because the consequences of that are far
reaching and would have been well documented by now. And you
would have made use of that logic when you were attempting to
calculate the acceleration distance in each chosen batch size
of dt seconds in length for your program, instead of going about
it the way you did.

Elaborating; The fall distance for Mercury's half orbit is
d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
of course the orbit diameter from aphelion to perihelion.
Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
acceleration rate to the far side of the orbit.

It can also be stated as dt = (2*d/newton)^.5 = 2417400 seconds.
That can be adjusted to include fall = (dt * newton^.5)^2 / 2
The values of dt and newton can then be set to suit one's needs,
and the result will always be correct. newton can be replaced by
anything, even the anisotropy.

Words don't mean much though, so I've modified your program
again and attached it to the post to prove my point. There's no
need to thank me.

In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:

1) you gave me an equation for the acceleration

2) acceleration is defined as rate of change of velocity

3) velocity is defined as rate of change of location

Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.

Without the anisotropy, you are plotting the path of a planet
in a sustainable orbit, and it makes no difference if the orbit
is elliptical or circular the same rules apply. The total radius
change is zero, even though the fall distance per half orbit
cycle is twice the radius.

Even though you deny that the radius changes, you attempt to
change it by the full extent of the anisotropy, which is
_blatantly_ wrong.

With dt set to 2417400 seconds, being half the orbit cycle time
/ (pi/2) and an added acceleration rate of e.g. 8e-7, according
to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
= 116002219315 meters for the half cycle. The fall without the
added acceleration is 115999881786 meters. That's a ratio of
1.00002015 to 1. That's comparable with va^2 / vb^2 found at this
address http://members.optusnet.com.au/maxkeon/peri.html

-----

Max Keon


'------------------------------
' This program does not represent reality. It's geared more to
' demonstrate that it doesn't.

' If you run the program you will notice that there is little or
' no orbit eccentricity decay due to the anisotropy. But there is
' a distinct radial contraction, as should be expected if the
' anisotropy is inelastic. Where the energy would go still
' remains a mystery.

' There are a couple of problems in running the program.
' XP becomes bogged down when the keyboard is rapidly accessed
' using the INKEY$ function. Constant key pushing is required
' to keep it going.
' And
' The greater the dt value the faster is the fall to the Sun.
' That is probably due to the greater degree of overlap at the
' end of each half cycle for the higher dt values, encroaching
' into the realm of the following half cycle.

DEFDBL A-Z
SCREEN 12
CLS
b$ = "Press any key to check progress. Escape exits the program."
c$ = "The program normally halts at aphelion and perihelion."

colr = 1 ' This sets the initial color for the orbit.
' The need for the color mix will become apparent.

CIRCLE (250, 250), 8, 14 ' Sun.
COLOR 7
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#' Multiplier for the graphics.
pi = 3.1416#

x = 69820000000#: vy = 38850# ' Aphelion start.
'x = 45961000000#: vy = 59017# ' Perihelion start.
' Swap the ' switches.
lastradius = x

dt = 100 ' Set dt to whatever you like.
' dt = 5000, 10000, 20000 gives a good comparison
' when fk is set to 1.

' f? are all flags.
fk = 0 ' Set fk = 1 to remove printing delays. Control Break
' is then the only way to break out of the program.
' The program can bog down when it's set to 0.

fs = 0 ' Set fs = 1 to exclude the anisotropy.
' Note that the orbit orientation spirals
' anticlockwise for either, an aphelion or perihelion
' start when the anisotropy is excluded. The probable
' cause is given in the intro. Whatever course the
' orbit orientation is following, it can still
' represent a stable orbit. When the anisotropy is
' included, an aphelion start spirals clockwise,
' further removing it from the stable orbit, while
' a perihelion start initially spirals anticlockwise
' at a faster rate than the stable orbit, then slowly
' reverts to a clockwise spiral as it falls to the
' Sun. Which is to be expected if anisotropic gravity
' is inelastic.

IF fk = 0 THEN LOCATE 26, 6: PRINT b$: LOCATE 27, 6: PRINT c$

aa:
r2 = x * x + y * y
radius = SQR(r2)
IF radius 1000000000000# THEN PRINT fr; "cycles": END
' This only applies after the fall has reached the Sun.

vr = (radius - lastradius) / dt
lastradius = radius

newton = G * M / r2

an = (vr / c) * newton
' 'an' is the anisotropy.

'v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.

acceleration = -newton

IF fs = 0 THEN GOSUB af
IF fs = 1 THEN GOSUB ag
' These original equations have been shifted.
' ax = acceleration * (x / radius)
' ay = acceleration * (y / radius)

vx = vx + dt * ax
vy = vy + dt * ay

x = x + dt * vx
y = y + dt * vy

CIRCLE (250 + x * multi, 250 + y * multi), 0, colr

IF an 0 THEN fx = 0
IF an 0 THEN an = -an: fx = 1 'The sign change accommodates
' an^.5 in the next equation if 'an' is negative.

fall = (dt * an ^ .5) ^ 2 / 2
' This equation gives the same result as compounding
' the anisotropy for each second.

IF fx = 1 THEN fall = -fall: an = -an ' The sign change to 'an',
' and its consequences are reset to the way they would
' normally be.
stora = stora + fall
storb = storb + stora ' Total fall storage.

IF fk = 0 THEN GOSUB ad ' Screen print options.
IF fk = 1 THEN GOSUB ae

IF fw 2000 THEN colr = colr + 1: fw = 0
IF colr 15 THEN colr = 1
fw = fw + 1

GOTO aa

'---This section simply compiles the anisotropic acceleration
'---for each second and stores it in stord. It provides the true
'---result with which to test the equation fall = (dt*an^.5)^2/2
'---
ab: IF ft = 0 THEN ana = an / 2: ft = 1
' The fall over the first second is .5 of the
' final acceleration rate at the end of that second.
storc = storc + ana
stord = stord + storc
tx = tx + 1
ana = an
IF tx dt THEN GOTO ab
LOCATE 6, 1
PRINT stord; "fall distance check per 1 second increments. "
tx = 0: storc = 0: stord = 0: ft = 0
'----------------

ac: LOCATE 1, 1: PRINT fr; "cycles "
PRINT " Batch size ="; dt; " seconds. "
PRINT radius; "radius "
PRINT an; "anisotropy "
PRINT fall; "meter fall distance per batch size. "
PRINT
PRINT -storb; "radius change. "
DO: s$ = INKEY$: LOOP UNTIL s$ ""
IF s$ = CHR$(27) THEN END
s$ = ""
RETURN

ad:
s$ = INKEY$: IF s$ "" THEN GOSUB ab
IF vr 0 AND fa = 0 THEN fb = 1: fa = 1: fr = fr + .5: GOSUB ab
IF vr 0 AND fb = 1 THEN fa = 0: fb = 0: fr = fr + .5: GOSUB ab
RETURN

ae:
IF vr 0 AND fa = 0 THEN fb = 1: fa = 1: fr = fr + .5
IF vr 0 AND fb = 1 THEN fa = 0: fb = 0: fr = fr + .5
' Cycle count (erroneously adds an extra half cycle
' for perihelion start).
RETURN

af:
ax = acceleration * (x / (radius + storb))
ay = acceleration * (y / (radius + storb))
' Apart from the improved precision, adjusting the
' radius with the total anisotropic fall for each dt
' second batch is no different to adding the
' anisotropy directly to newton and multiplying it
' by dt.
RETURN

ag:
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
' No anisotropy.
RETURN

On 4 Jul, 03:04, "Max Keon" wrote:
"George Dishman" wrote in message
...
"Max Keon" wrote in message
. au...
....
... leaving the final
approach to aphelion or perihelion somewhere in limbo. Then you
claim proof of an orbit eccentricity collapse?
The program waits until the fall to perihelion is
complete, it is triggered by the radius staring to
rise and it prints out the previous value which of
course is the smallest.

Maybe the trigger point does index around, but the aphelion
and perihelion approach is still halted at that point because
you are assuming that anisotropic gravity is inelastic.

No, you can read how the program works yourself,
there is no such assumption anywhere in it. I
find the perihelion and aphelion simply from the
minimum and maximum radius values, the radius is
found trivially by applying Pythagoras to the x
and y coordinates, and those in turn are found
by _correctly_ integrating the acceleration that
Newton plus your anisotropy provide.

But
you have no evidence to support that assumption.

I have told you repeatedly what the evidence is,
an elastic equation cannot depend on any variable
other than radius. You have speed in the equation
so it is inelastic, but this is irrelevant since
it does not appear anywhere in the program, a fact
you can check for yourself quite easily.

That value is greater than
it would have been without the anisotropy exactly
as you said it would be a few posts back

"exactly as I said it would be", was according to your reasoning
George, not mine. If I agree with the consequences of your
reasoning, that doesn't mean I accept your reasoning in
principle.

No, it means I accepted yours. You said the path
would be farther from the Sun and I agree, you
were correct.

I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there.

Since, for a given starting aphelion, the next
perihelion radius is increased by the anisotropy,
the "diameter" is not the same as it would be
without the anisotropy. The rest of the part of
your argument based on that assumption is
therefore invalid, as is your alternative program.

It
-can't be there on one path and not be there on another at the
-same time.

-The reason for the inconsistency is of course that, while it's
-in orbit, the fall direction doesn't always point at the Sun.
-The fall is then directly related to COS and pi. The average
-orbital second is 1/(pi/2) straight line seconds.

This paragraph replaces the above paragraph, for obvious reasons:
The reason for the inconsistency is of course that, while it's
in orbit, the fall direction doesn't always point at the Sun
along the path of the chosen diameter. The fall is then directly
related to COS and pi. The average orbital second is 1/(pi/2)
straight line seconds.
It is wrong anyway since it is changed by the anisotropy.

I take it that you were not aware that Mercury's fall distance
for each half orbit is equal to the orbit diameter,

It depends what you mean by "fall distance". I
took that to be the difference between aphelion
and perihelion but what you call the "diameter",
by which I assume you mean the major axis, is
the sum of the two, not the difference. In that
sense what you are saying makes no sense, but
since the length of the major axis is changed
by the anisotropy, it isn't relevant anyway.

and that it's
equal to the time for the half orbit divided by pi/2 multiplied
by the orbital speed, because the consequences of that are far
reaching and would have been well documented by now. And you
would have made use of that logic when you were attempting to
calculate the acceleration distance in each chosen batch size
of dt seconds in length for your program, instead of going about
it the way you did.

No, the definition of acceleration requires
that it be used exactly the way I used it. You
need to learn these basic definitions Max, there
is no flexibility in how you do this part, your
options are limited to changing the equation for
the acceleration if you don't like the outcome,
and if the equation is correctly derived from
your concepts then those concepts are wrong.

Elaborating; The fall distance for Mercury's half orbit is
d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
of course the orbit diameter from aphelion to perihelion.
Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
acceleration rate to the far side of the orbit.

No, acceleration is a vector and includes direction.
You are trying to use it as a scalar which is wrong
and will not work.

Words don't mean much though, so I've modified your program
again and attached it to the post to prove my point. There's no
need to thank me.

Since your approach is completely wrong, I feel no
temptation to do so. The program I gave you uses
the acceleration correctly. The values are of course
taken from your equation but now that I have showed
you how acceleration has to be used, you might want
to reconsider your equation.

In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:

1) you gave me an equation for the acceleration

2) acceleration is defined as rate of change of velocity

3) velocity is defined as rate of change of location

Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.

Without the anisotropy, you are plotting the path of a planet
in a sustainable orbit, and it makes no difference if the orbit
is elliptical or circular the same rules apply. The total radius
change is zero, even though the fall distance per half orbit
cycle is twice the radius.

Even though you deny that the radius changes, ..

At no time did I say the radius wasn't affected, you
have picked up a misunderstanding somewhere. Perhaps
it was when we were talking of a circular orbit.

.. you attempt to
change it by the full extent of the anisotropy, which is
_blatantly_ wrong.

Of course, and that is _correct_. You have in effect
told me how much to use when you included the term v/c
in your equation for the anisotropy, I include v/c
times the Newtonian value. If you think that is too
much, you need to change the factor v/c to something
smaller, but it is up to you to do that, I just add
whatever your equation demands.

With dt set to 2417400 seconds, being half the orbit cycle time
/ (pi/2) and an added acceleration rate of e.g. 8e-7, according
to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
= 116002219315 meters for the half cycle. The fall without the
added acceleration is 115999881786 meters.

Meaningless numbers Max, you have never understood that
acceleration is a _vector_, it includes _direction_ as
I explained to you in the very first exchanges on this
subject. It is the rate of change of velocity so that
means you have no choice but to find the velocity from
the acceleration by simple integration, which is what
my program does. As I have suggested before, you need
to go away and learn what a vector is before you can
sensibly continue this conversation.

George

"George Dishman" wrote in message
oups.com...
On 4 Jul, 03:04, "Max Keon" wrote:
"George Dishman" wrote in message
...
"Max Keon" wrote in message
u...

I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there.

Since, for a given starting aphelion, the next
perihelion radius is increased by the anisotropy,
the "diameter" is not the same as it would be
without the anisotropy.

The diameter from aphelion to perihelion is the sum of the two
radii because the perihelion will have advanced slightly by the
time Mercury has fallen to the true perihelion radius.

A point that you can never seem to grasp is that if Mercury is
further from the Sun than the normal perihelion radius when
radial velocity has ceased, thus reducing the anisotropy to zero
and reinstating normal gravity, Mercury will again fall because
it does not possess sufficient orbital speed to counteract the
resurrected pull of gravity. Nothing is lost of course because
it's always in a position of higher gravitational potential until
the perihelion radius has been reached. That's where orbital
speed will all be put back to the way it would normally be.

And that's also why the perihelion advances.
---

and that it's
equal to the time for the half orbit divided by pi/2 multiplied
by the orbital speed, because the consequences of that are far
reaching and would have been well documented by now. And you
would have made use of that logic when you were attempting to
calculate the acceleration distance in each chosen batch size
of dt seconds in length for your program, instead of going about
it the way you did.

No, the definition of acceleration requires
that it be used exactly the way I used it. You
need to learn these basic definitions Max, there
is no flexibility in how you do this part, your
options are limited to changing the equation for
the acceleration if you don't like the outcome,
and if the equation is correctly derived from
your concepts then those concepts are wrong.

I keep on telling you that the maths you are using is incapable
of describing the anisotropy. You are miles away from the truth
with what you are doing.

Elaborating; The fall distance for Mercury's half orbit is
d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
of course the orbit diameter from aphelion to perihelion.
Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
acceleration rate to the far side of the orbit.

No, acceleration is a vector and includes direction.
You are trying to use it as a scalar which is wrong
and will not work.

So you are saying that vectors and scalars are impossible to
compare? I seem to always get exactly the same fall distance from
dt^2 * anisotropy / 2 as from compounding the acceleration for
each second of dt.

Try running this program.

CLS : dt = 10000: an = 1: ax = an: ax = an / 2
aa: a = a + ax: b = b + a: ax = an: fa = fa + 1
IF fa dt THEN GOTO aa
PRINT b; "per compounding steps"
PRINT dt ^ 2 * an / 2; "per dt^2*an/2"

---

In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:

1) you gave me an equation for the acceleration

2) acceleration is defined as rate of change of velocity

3) velocity is defined as rate of change of location

Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.

Without the anisotropy, you are plotting the path of a planet
in a sustainable orbit, and it makes no difference if the orbit
is elliptical or circular the same rules apply. The total radius
change is zero, even though the fall distance per half orbit
cycle is twice the radius.

Even though you deny that the radius changes, ..

At no time did I say the radius wasn't affected, you
have picked up a misunderstanding somewhere. Perhaps
it was when we were talking of a circular orbit.

The following is an extract from your reply dated 23-5-07. The
subject title was then; Anisotropy in the gravity force, and
Mercury.

--------------------------
I wrote:
- Therein lies a problem. The anisotropy is an acceleration force,
- but you've treated it as a continuous force which is simply added
- or subtracted from the orbit radius according to radial velocity.

You wrote:
-That sentence makes very little sense so I'l take it
-bit by bit.
-
-We are treating the anisotropy like the Newtonian
-gravity as an acceleration, not a force. We are
-not including the mass of Mercury in any of the
-calculations because it would cancel out.
-
-The accelerations are continuous (both Newtonian and
-the anisotropy) in that they apply at all times and
-change smoothly with time, they aren't quantised and
-changing in discrete steps.
-
-That means that any time, the acceleration adds an
-amount to the velocity which is equalt to the product
-of the time and the acceleration. It doesn't add or
-subtract from the radius, I don't know where you got
-that idea.
-------------------------

If you hadn't included "(both Newtonian and the anisotropy)" you
could have been referring to the Newtonian component only. But
you were probably talking about average radius.

That should have prompted you to question your program though
because inelastic gravity _must_ cause the average radius to
decay.

.. you attempt to
change it by the full extent of the anisotropy, which is
_blatantly_ wrong.

Of course, and that is _correct_. You have in effect
told me how much to use when you included the term v/c
in your equation for the anisotropy, I include v/c
times the Newtonian value. If you think that is too
much, you need to change the factor v/c to something
smaller, but it is up to you to do that, I just add
whatever your equation demands.

Your whole concept is completely wrong. You have treated the
anisotropy as being entirely elastic, up to the point where
Mercury should fall to the normal aphelion or perihelion radius.
That's the part your program cannot accommodate.

If the anisotropy is elastic, then it is elastic. If it's
inelastic, it's inelastic, meaning that Mercury must lose energy
and _must_ fall to the Sun. What you have is an entirely elastic
situation which removes no energy from the system, but for some
obscure reason, the eccentricity decays.
That's hardly logical, is it!

There are several ways to arrive at the true fall distance for
the inelastic anisotropy. This one is very straight forward.

For the conditions:
anisotropy = 8e-7
r = 58000000000 meters
newton = GM/r^2

(GM/r)^.5 = 47838.26919945997 (v), is the orbital speed
required to maintain a normal stable orbit.

(newton + anisotropy)^.5 / (newton)^.5 * v
= 47838.75416438016 (vv), is the orbital speed required to
maintain a stable orbit if the anisotropy is included.

The ratio is, as always, 1.00001014 to 1.

With the added pull of gravity the orbital speed required to hold
a sustainable orbit is higher than its current speed, and so it
will fall to the Sun to some degree. But the fall will most
certainly not be to the full extent of the anisotropy. That fall
rate could only occur when orbital speed is zero.

Even if you don't agree with this equation,
fall = (vv - v) ^ 2 / v ^ 2 * anisotropy = 8.22e-17m/sec^2, you
must agree that the fall will be nothing like 100% of the
anisotropy while it's traveling 1 / 1.00001014 * 100 = 99.998986%
of the speed required to maintain a sustainable orbit _which has
no average radius reduction whatever_.

The elastic anisotropy simply travels the missing distance to
the true aphelion and perihelion radii.

With dt set to 2417400 seconds, being half the orbit cycle time
/ (pi/2) and an added acceleration rate of e.g. 8e-7, according
to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
= 116002219315 meters for the half cycle. The fall without the
added acceleration is 115999881786 meters.

Meaningless numbers Max, you have never understood that
acceleration is a _vector_, it includes _direction_ as
I explained to you in the very first exchanges on this
subject. It is the rate of change of velocity so that
means you have no choice but to find the velocity from
the acceleration by simple integration, which is what
my program does. As I have suggested before, you need
to go away and learn what a vector is before you can
sensibly continue this conversation.

It's not my understanding that's in question here George, it's
yours.

Perhaps your confusion stems from this simple fact.
For a mass in a stable concentric orbit around the Sun at a
radius of 5.8e10 meters, traveling at 48000m/sec, if the
..04m/sec^2 pull of gravity is suddenly switched off, its
trajectory will immediately shift along a straight line path
at a tangent to the orbit radius. The change is immediate.

An obvious consequence is that the process can be reversed so
that if the mass is traveling a straight line path at 48000m/sec
and the pull of gravity is suddenly applied when it's path is
perpendicular to the Sun at a radius of 5.8e11 meters, the mass
will undergo an immediate change of direction that takes it away
from its straight line path by .02 meters in the first second.
It's immediately accelerated to the Sun at the rate of .04
m/sec^2, falling into a concentric orbit around the Sun. Again
there is no delay.

But if the central mass was twice that of the Sun, the pull of
gravity is immediately applied at .08m/sec^2, so the mass
immediately shifts course by .04 meters in the first second and
continues to accelerate at .08m/sec^2. The change is again
immediate.

If the tangent radius was 4.1e10 meters, the resulting orbit
would again be circular. But if the radius remained as before,
the orbit becomes elliptical, with an aphelion radius of 5.8e10
meters.

By adding the anisotropy directly to newton, you have varied
the orbit shape according to each gravity change in the same way
as did the original shift from the straight line path. You have
simply shifted it from whatever path it was on at the time.

There's nothing wrong with that part, but you forgot to continue
on to the true aphelion and perihelion radii.

If this line represents the normal orbit trajectory between
aphelion and perihelion
- - - - - - - - - - - - - - - -
this is how the anisotropy changes the trajectory enroute to
perihelion.
_ - - - _
- -
Aphelion Perihelion


SUN

Note that Mercury is heading more toward the Sun than normal at
the end of the journey, where the perihelion would normally be
if there was no advance. And it has arrived there with a lesser
orbital speed than normal.

And this is how it affects the trajectory enroute to aphelion.

Aphelion Perihelion
- _ _ -
- - -


SUN

Mercury is now heading more away from the Sun at journey's end
where the aphelion would normally be if there was no advance.
Its path was nearer to the Sun so it arrives with a higher
orbital speed than normal. The consequence of that is obvious.
That's where your program fails to deliver.


I have previously assumed that your program causes the anisotropy
to generate a relatively enormous radius change for the up and
the down legs of Mercury's orbit. But in the process of pointing
out the root of your confusion, it has become apparent that the
cause is only that the anisotropy has been added to the normal
orbit as a distinct change which occurred suddenly at either
the aphelion or perihelion. That sudden change will have the same
consequences as applying gravity to the straight line path,
above.

A completely new orbit structure is forming.

-----

Max Keon

On 10 Jul, 11:42, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...

On 4 Jul, 03:04, "Max Keon" wrote:
"George Dishman" wrote in message
...
"Max Keon" wrote in message
m.au...
I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there.

Since, for a given starting aphelion, the next
perihelion radius is increased by the anisotropy,
the "diameter" is not the same as it would be
without the anisotropy.

The diameter from aphelion to perihelion is the sum of the two
radii because the perihelion will have advanced slightly by the
time Mercury has fallen to the true perihelion radius.

Yes, that makes it not quite a "diameter" but more of
a dogleg shape but that's a secondary point.

A point that you can never seem to grasp is that if Mercury is
further from the Sun than the normal perihelion radius when
radial velocity has ceased, thus reducing the anisotropy to zero
and reinstating normal gravity, Mercury will again fall because
it does not possess sufficient orbital speed to counteract the
resurrected pull of gravity.

Sorry Max, that's not the way it works. As the planet
is approaching perihelion, it already has enough speed
to throw it back out. What stops that is the momentum
directed inward and that is reduced by the anisotropy
so it doesn't get as close to the Sun before it starts
receding - the perihelion is increased.

....
and that it's
equal to the time for the half orbit divided by pi/2 multiplied
by the orbital speed, because the consequences of that are far
reaching and would have been well documented by now. And you
would have made use of that logic when you were attempting to
calculate the acceleration distance in each chosen batch size
of dt seconds in length for your program, instead of going about
it the way you did.
No, the definition of acceleration requires
that it be used exactly the way I used it. You
need to learn these basic definitions Max, there
is no flexibility in how you do this part, your
options are limited to changing the equation for
the acceleration if you don't like the outcome,
and if the equation is correctly derived from
your concepts then those concepts are wrong.

I keep on telling you that the maths you are using is incapable
of describing the anisotropy.

Yes, you keep telling me lots of crap and I keep
pointing out that fact. I am using the DEFINITION of
acceleration and therefore the maths I am doing is
correct.

You are miles away from the truth
with what you are doing.

What I am doing is correct BASED ON your eqiation
which tells me the acceleration. If my result is
wrong it must be because your equation is wrong.

Elaborating; The fall distance for Mercury's half orbit is
d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
of course the orbit diameter from aphelion to perihelion.
Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
acceleration rate to the far side of the orbit.
No, acceleration is a vector and includes direction.
You are trying to use it as a scalar which is wrong
and will not work.

So you are saying that vectors and scalars are impossible to
compare?

Of course. One is a single number and the other is a set
of numbers.

I seem to always get exactly the same fall distance from
dt^2 * anisotropy / 2 as from compounding the acceleration for
each second of dt.

That's because you are ignoring the direction.
Even limiting ourselves to the plane of the
orbit, acceleration is pair of numbers.

Try running this program.

CLS : dt = 10000: an = 1: ax = an: ax = an / 2
aa: a = a + ax: b = b + a: ax = an: fa = fa + 1
IF fa dt THEN GOTO aa
PRINT b; "per compounding steps"
PRINT dt ^ 2 * an / 2; "per dt^2*an/2"

You have ax but where is ay?


In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:

1) you gave me an equation for the acceleration

2) acceleration is defined as rate of change of velocity

3) velocity is defined as rate of change of location

Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.

Without the anisotropy, you are plotting the path of a planet
in a sustainable orbit, and it makes no difference if the orbit
is elliptical or circular the same rules apply. The total radius
change is zero, even though the fall distance per half orbit
cycle is twice the radius.

Even though you deny that the radius changes, ..
At no time did I say the radius wasn't affected, you
have picked up a misunderstanding somewhere. Perhaps
it was when we were talking of a circular orbit.

The following is an extract from your reply dated 23-5-07. The
subject title was then; Anisotropy in the gravity force, and
Mercury.

--------------------------I wrote:

- Therein lies a problem. The anisotropy is an acceleration force,
- but you've treated it as a continuous force which is simply added
- or subtracted from the orbit radius according to radial velocity.

You wrote:

-That sentence makes very little sense so I'l take it
-bit by bit.
-
-We are treating the anisotropy like the Newtonian
-gravity as an acceleration, not a force. We are
-not including the mass of Mercury in any of the
-calculations because it would cancel out.
-
-The accelerations are continuous (both Newtonian and
-the anisotropy) in that they apply at all times and
-change smoothly with time, they aren't quantised and
-changing in discrete steps.
-
-That means that any time, the acceleration adds an
-amount to the velocity which is equalt to the product
-of the time and the acceleration. It doesn't add or
-subtract from the radius, I don't know where you got
-that idea.
-------------------------

OK, all of that is correct.

If you hadn't included "(both Newtonian and the anisotropy)" you
could have been referring to the Newtonian component only. But
you were probably talking about average radius.

No I was talking about the accelerations only. I said:

-The accelerations are continuous (both Newtonian and
-the anisotropy) in that they apply at all times and
-change smoothly with time, they aren't quantised and
-changing in discrete steps.

which means the Newtonian acceleration is continuous
and also the acceleration from the anisotropy is
continuous. Neither of them changes in discrete steps
though we model them that way when writing software
and have to use tricks to remove the small errors that
causes.

That should have prompted you to question your program though
because inelastic gravity _must_ cause the average radius to
decay.

I think you are misreading the final paragraph. You
had previously said something like "acceleration
adds to the radius" and I said "No, acceleration adds
to the velocity". Of course during each one second
step, the velocity then adds to the radius but I was
pointing out that you had missed a step in the
process, not that the radius would be unaffected. Do
you see the difference?

.. you attempt to
change it by the full extent of the anisotropy, which is
_blatantly_ wrong.
Of course, and that is _correct_. You have in effect
told me how much to use when you included the term v/c
in your equation for the anisotropy, I include v/c
times the Newtonian value. If you think that is too
much, you need to change the factor v/c to something
smaller, but it is up to you to do that, I just add
whatever your equation demands.

Your whole concept is completely wrong. You have treated the
anisotropy as being entirely elastic, up to the point where
Mercury should fall to the normal aphelion or perihelion radius.
That's the part your program cannot accommodate.

I have told you several times, and you have the
code so you can check for yourself - the program
does not make any assumption one way or the other,
it does nothing other than integrate the acceleration
to get the velocity and then integrate that to get
the path. That follows automatically from the
definition of acceleration so cannot be wrong.

If the anisotropy is elastic, then it is elastic. If it's
inelastic, it's inelastic, meaning that Mercury must lose energy
and _must_ fall to the Sun. What you have is an entirely elastic
situation which removes no energy from the system, but for some
obscure reason, the eccentricity decays.
That's hardly logical, is it!

It is perfectly logical - the eccentricity can change while
the energy in the system can stay the same.

There are several ways to arrive at the true fall distance for
the inelastic anisotropy. This one is very straight forward.

The way I have done it correct. If your methods give the
same result, then they may be equivalent but if they
give a different answer they are wrong. This approach is
definitely not going to work:

For the conditions:
anisotropy = 8e-7
r = 58000000000 meters
newton = GM/r^2

(GM/r)^.5 = 47838.26919945997 (v), is the orbital speed
required to maintain a normal stable orbit.

For a circular orbit, yes.

(newton + anisotropy)^.5 / (newton)^.5 * v
= 47838.75416438016 (vv), is the orbital speed required to
maintain a stable orbit if the anisotropy is included.

No, for a circular orbit there is no _radial_ speed
towards or away from the Sun so the "v/c" in your
equation is zero and there is no anisotropy. The
stable speed must therefore be identical to the case
of Newtonian gravity only.

The ratio is, as always, 1.00001014 to 1.

It should be 1.0 precisely.

With the added pull of gravity ...

There is no added pull because the radial speed is
zero. I'll snip the next bit since you had previously
agreed that there would be no anisotropy for a circular
orbit and I can only imagine you got a bit confused
this time round.

I have previously assumed that your program causes the anisotropy
to generate a relatively enormous radius change for the up and
the down legs of Mercury's orbit. But in the process of pointing
out the root of your confusion, it has become apparent that the
cause is only that the anisotropy has been added to the normal
orbit as a distinct change which occurred suddenly at either
the aphelion or perihelion. ..

I think you have misread the program. It adds to
the velocity in each time step, not at aphelion or
perihelion, and it adds only as much as occurs
during the step, no matter what value you choose
for dt. A smaller choice of dt means smaller
amounts are added, but of course there are more
steps per orbit. The overall cumulative effect is
then the same.

In reality, your anisotropy would act continuously
all the time at a very low level, and the program
takes account of that as far as is practical so that
it is adequately accurate.

George

"George Dishman" wrote in message
oups.com...
On 10 Jul, 11:42, "Max Keon" wrote:
---

A point that you can never seem to grasp is that if Mercury is
further from the Sun than the normal perihelion radius when
radial velocity has ceased, thus reducing the anisotropy to zero
and reinstating normal gravity, Mercury will again fall because
it does not possess sufficient orbital speed to counteract the
resurrected pull of gravity.

Sorry Max, that's not the way it works. As the planet
is approaching perihelion, it already has enough speed
to throw it back out. What stops that is the momentum
directed inward and that is reduced by the anisotropy
so it doesn't get as close to the Sun before it starts
receding - the perihelion is increased.

The anisotropy does cause Mercury to fall short of reaching the
normal perihelion and aphelion radii, but that condition is
constant. The orbit shape is permanently changed to a different
shape that remains thus until something else changes it again.

We don't seem to be getting anywhere here, so I'll go back to
where it all began.

-------------------
I've also stored this part of the post on a web page so that
the images become an integral part of the story, at
http://members.optusnet.com.au/maxkeon/proven.html

-------------------

The original equation representing the effect of the anisotropy
on an upward moving mass relative to a gravity source was given
as ((c+v)^2/c^2)^.5*G*M/r^2-(G*M/r^2), while
((c-v)^2/c^2)^.5*G*M/r^2-(G*M/r^2) represented its effect on
a downward moving mass.

The equations have since been simplified to v/c(GM/r^2) and
-v/c(GM/r^2). The physical sign manipulation between the up and
the down legs of Mercury's eccentric orbit was essential when
using unsigned velocity so that the anisotropy could be
represented as it's supposed to be. i.e. The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.

Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.

That was an obvious concern for me when I was pressured into
using signed velocity to automate the anisotropy sign change,
thus making the equation elastic. The problem was that the
equation no longer represented the anisotropy.

The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.

The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.

In roughly determining the perihelion advance rate it was
necessary to magnify the anisotropy to arrive at a sensible
result because the distance covered in the final step at
perihelion or aphelion is greater than the observed advance rate
of 29000 meters per orbit cycle. The error margin is dependent
on the step size represented by dt in the program, and is at
least 1 second of travel time at 48000m/sec.

The program setup is currently dt=1000, with anisotropy * 1000,
which would seem to be back at square 1 with no multipliers. But
doubling the multiplier value for the anisotropy causes a four
fold increase in the perihelion advance rate, so the multiplier
alters the result at a squaring rate.

http://members.optusnet.com.au/maxkeon/a501.jpg
http://members.optusnet.com.au/maxkeon/a1001.jpg
http://members.optusnet.com.au/maxkeon/a2001.jpg

Each of these images was generated over 20 orbit cycles. The dark
blue circles indicate the aphelion and perihelion advance.

The actual advance can be determined by physically measuring the
angle of advance and dividing that by the number of cycles, the
multiplier squared, etc. For multipliers, 500, 1000 and 2000,
with the consequent results from running 20 cycles, 6.25, 25,
and 100 degrees (per images)

(1) 6.25 / 20 / (500^2 * 360) * 2.89e11 = 1003 meters.
(2) 25 / 20 / (1000^2 * 360) * 2.89e11 = 1003 meters.
(3) 100 / 20 / (2000^2 * 360) * 2.89e11 = 1003 meters.
(2.89e11 is the circumference at the perihelion radius)

The observed advance is 29000 meters per orbit. A long way short?
I wouldn't be too concerned because the anisotropy affects
everything that moves in the universe, which affects every
calculation to do motion and gravity. There's still a long way
to go yet.

The advance can also be determined by monitoring the y axis
length when Mercury is close to perihelion.

To eliminate the initial orbit wobble when the anisotropy is
first applied, the program was run until Mercury's advance had
arrived at the 180 mark, where the y axis was again crossing
through zero. These figures were generated from the first three
orbit cycles beyond the perihelion, using dt=100 and 2000 for
the anisotropy multiplier.

(a) y = -881201184: Initial chosen perihelion.
(b) y = -4797789427: Perihelion at next orbit.
(c) y = -8679411745: Next perihelion.
(d) y = -12497773124: Next perihelion.

(b - a) / 2000^2 = -979 meter advance.
(c - b) / 2000^2 = -970 meter advance.
(d - c) / 2000^2 = -955 meter advance.

-----

Max Keon


'----------------------
DEFDBL A-Z
SCREEN 12
CLS
CIRCLE (250, 250), 8, 14 'Sun
COLOR 7
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#' Multiplier for the graphics.
pi = 3.1416#

x = 69820000000#: vy = 38850# ' Aphelion start.
'x = 45961000000#: vy = 59017# ' Perihelion start.
' Swap the ' switches.

lastradius = x

dt = 1000

aa:
ryx = x * x + y * y
radius = SQR(ryx)

vr = (radius - lastradius) / dt
lastradius = radius

newton = G * M / ryx

IF vr 0 THEN anisotropy = -vr / c * newton * 1000
IF vr 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----

acceleration = -newton + anisotropy

ax = acceleration * (x / radius)
ay = acceleration * (y / radius)

vx = vx + dt * ax
vy = vy + dt * ay

v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.
' Direction of orbital speed change identifies the aphelion and
' perihelion (changing from increasing to decreasing speed, or
' vice versa).

x = x + dt * vx
y = y + dt * vy

CIRCLE (250 + x * multi, 250 - y * multi), 0, 11

IF lastv v AND fa = 0 THEN fb = 1: fa = 1: GOSUB ad
IF lastv v AND fb = 1 THEN fa = 0: fb = 0: GOSUB ad
' Detects aphelion or perihelion.
lastv = v

GOTO aa

ad:
CIRCLE (250 + x * multi, 250 - y * multi), 2, 14
' Identifies the aphelion and perihelion.

LOCATE 1, 1
cycl = cycl + .5
PRINT cycl; "cycles "

PRINT " x ="; x, " y ="; y
' x is only included to indicate where the
' y axis is measured (aphelion or perihelion).

PRINT " last x ="; xx, "last y ="; yy
xx = x: yy = y
IF cycl 20 THEN END
'DO: LOOP UNTIL INKEY$ ""
RETURN

On 17 Jul, 01:29, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 10 Jul, 11:42, "Max Keon" wrote:

---

A point that you can never seem to grasp is that if Mercury is
further from the Sun than the normal perihelion radius when
radial velocity has ceased, thus reducing the anisotropy to zero
and reinstating normal gravity, Mercury will again fall because
it does not possess sufficient orbital speed to counteract the
resurrected pull of gravity.
Sorry Max, that's not the way it works. As the planet
is approaching perihelion, it already has enough speed
to throw it back out. What stops that is the momentum
directed inward and that is reduced by the anisotropy
so it doesn't get as close to the Sun before it starts
receding - the perihelion is increased.

The anisotropy does cause Mercury to fall short of reaching the
normal perihelion and aphelion radii, but that condition is
constant.

As you previously described the anisotropy, that
would not be true. On the inward leg, the reduced
gravity would mean it would not fall as far as
under Newtonian gravity alone so the perihelion
would be increased. For a given orbital energy,
that means the aphelion would have been decreased.

On the outward leg, the increased gravity meant
the aphelion would be farther reduced. The second
orbit would then repeat the process but starting
from a smaller aphelion than the first orbit and
that would continue asymptotically towards a
circular orbit.

We don't seem to be getting anywhere here, so I'll go back to
where it all began.

Yes we need to but not for the reason you thought,
your story has changed.

The original equation representing the effect of the anisotropy
on an upward moving mass relative to a gravity source was given
as ((c+v)^2/c^2)^.5*G*M/r^2-(G*M/r^2), while
((c-v)^2/c^2)^.5*G*M/r^2-(G*M/r^2) represented its effect on
a downward moving mass.

The equations have since been simplified to v/c(GM/r^2) and
-v/c(GM/r^2). The physical sign manipulation between the up and
the down legs of Mercury's eccentric orbit was essential when
using unsigned velocity so that the anisotropy could be
represented as it's supposed to be. i.e. ...

This next bit is VERY important:

... The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.

That is the key statement here.

Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.

Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.

An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.

The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.

That was an obvious concern for me when I was pressured into
using signed velocity to automate the anisotropy sign change,
thus making the equation elastic.

Elastic versus inelastic is another matter, leave
it for a later discussion.

The problem was that the
equation no longer represented the anisotropy.

Not true Max, the equation _does_ represent what
you said above, inward motion decreases the pull
while outward motion increases it.

The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.

Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.

The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.

I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).
This is the key section:


ryx = x * x + y * y
radius = SQR(ryx)

vr = (radius - lastradius) / dt
lastradius = radius

That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.

newton = G * M / ryx

The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.

IF vr 0 THEN anisotropy = -vr / c * newton * 1000
IF vr 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----

Is it? Let's see:

acceleration = -newton + anisotropy

The value of newton is always positive.

On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.

On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.

This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:

a) acceleration is a larger negative number
than -newton in both cases

b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).

The latter is what causes the path to return to
the constant perihelion and aphelion values.

Clearly Max, if you change from saying the pull
is reduced on the inward leg to writing code in
which it is increased, the result is going to
be entirely different.

George

For some reason, Google keeps saying my reply
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.

On 17 Jul, 01:29, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
....
We don't seem to be getting anywhere here, so I'll go back to
where it all began.

This next bit is VERY important:

... The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.

That is the key statement here.

Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.

Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.

An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.

The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.

The problem was that the
equation no longer represented the anisotropy.

The equation I used represents what you said above.
You have offered an alternative in the code below
so let's look at that and see what you have done.

The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.

Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.

The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.

I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).

ryx = x * x + y * y
radius = SQR(ryx)

vr = (radius - lastradius) / dt
lastradius = radius

That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.

newton = G * M / ryx

The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.

This is the key section:

IF vr 0 THEN anisotropy = -vr / c * newton * 1000
IF vr 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----

Is it? Let's see:

acceleration = -newton + anisotropy

The value of newton is always positive.

On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.

On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.

This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:

a) acceleration is a larger negative number
than -newton in both cases

b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).

The latter is what causes the path to return to
the constant perihelion and aphelion values.

Clearly Max, if you say the pull is _reduced_ on
the inward leg but then write code in which it is
_increased_, the result is going to be entirely
different.

BTW, I agree that the results you should get with
that change to the anisotropy are what you have
shown in your graphics, though gut feel suggests
you will find the amount of perihelion advance is
greater than is observed.

George

For some reason, Google keeps saying my reply
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.

On 17 Jul, 01:29, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
....
We don't seem to be getting anywhere here, so I'll go back to
where it all began.

This next bit is VERY important:

... The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.

That is the key statement here.

Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.

Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.

An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.

The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.

The problem was that the
equation no longer represented the anisotropy.

The equation I used represents what you said above.
You have offered an alternative in the code below
so let's look at that and see what you have done.

The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.

Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.

The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.

I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).

ryx = x * x + y * y
radius = SQR(ryx)

vr = (radius - lastradius) / dt
lastradius = radius

That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.

newton = G * M / ryx

The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.

This is the key section:

IF vr 0 THEN anisotropy = -vr / c * newton * 1000
IF vr 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----

Is it? Let's see:

acceleration = -newton + anisotropy

The value of newton is always positive.

On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.

On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.

This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:

a) acceleration is a larger negative number
than -newton in both cases

b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).

The latter is what causes the path to return to
the constant perihelion and aphelion values.

Clearly Max, if you say the pull is _reduced_ on
the inward leg but then write code in which it is
_increased_, the result is going to be entirely
different.

BTW, I agree that the results you should get with
that change to the anisotropy are what you have
shown in your graphics, though gut feel suggests
you will find the amount of perihelion advance is
greater than is observed.

George

You are not alone... I have that often they cheat and I loose my post due
their censure.... But I never give up... even if need a hole day to
rewitting... Sometimes i forget the good points of the original post... Now
I backup before I send... But its happens I click send with the backup
securite mesure ... and You known what... than mostly that post doesn't show
up... Are they controling My Computer too?

Now some groups where not refreshed since more than 28 hours.... What do
they try to hide from the view of the Google Users...



"George Dishman" a écrit dans le message de news:
...
For some reason, Google keeps saying my reply
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.

On 17 Jul, 01:29, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
...
We don't seem to be getting anywhere here, so I'll go back to
where it all began.

This next bit is VERY important:

... The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.

That is the key statement here.

Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.

Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.

An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.

The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.

The problem was that the
equation no longer represented the anisotropy.

The equation I used represents what you said above.
You have offered an alternative in the code below
so let's look at that and see what you have done.

The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.

Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.

The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.

I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).

ryx = x * x + y * y
radius = SQR(ryx)

vr = (radius - lastradius) / dt
lastradius = radius

That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.

newton = G * M / ryx

The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.

This is the key section:

IF vr 0 THEN anisotropy = -vr / c * newton * 1000
IF vr 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----

Is it? Let's see:

acceleration = -newton + anisotropy

The value of newton is always positive.

On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.

On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.

This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:

a) acceleration is a larger negative number
than -newton in both cases

b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).

The latter is what causes the path to return to
the constant perihelion and aphelion values.

Clearly Max, if you say the pull is _reduced_ on
the inward leg but then write code in which it is
_increased_, the result is going to be entirely
different.

BTW, I agree that the results you should get with
that change to the anisotropy are what you have
shown in your graphics, though gut feel suggests
you will find the amount of perihelion advance is
greater than is observed.

George