Einstein was right
Peter Riedt
Einstein was right when he said: “One experiment can prove me wrong; a
hundred experiments cannot prove me right”. The experiment to prove
Einstein wrong was the 1887 interferometer experiment of Michelson &
Morley (MMX). This experiment was expected to produce a measurable
outcome due to the interference of two light beams. When the predicted
fringe shift could not be observed, Lorentz proposed in 1905 that the
null result of the experiment could be explained by the length of the
parallel arm of the interferometer contracting according to the
formula L' = L*sqrt(1-vv/cc). It also was accompanied by a slowing
down of time and an increase of mass, all proportionally to the speed
of the equipment through space.
The Lorentz transformation formulas for length, time and mass can be
replaced by one formula, the Riedt Anisotropic Light Formula (RALF)
c' = c*1/sqrt(1-vv/cc) where the speed of the source is slightly
increasing the speed of light from 299792458m/sec to 299792459.5m/sec
but only in the direction of motion, aligned to the parallel arm.
Michelson and Morley write in the American Journal of Science
203/1887, describing their MMX interferometer experiment: ”The
distance travelled (by light to the end of the parallel arm of the
interferometer and back) is 2D(1+vv/cc), and the length of the other
path (across the perpendicular arm and back) is evidently 2D(1+vv/
2cc)”.
Using Michelson's formula 2D(1+vv/cc) we get
22.000000217450100000000000000m for the light path distance of the
parallel arm (dpar) and using 2D(1+vv/2cc) we get
22.000000108725000000000000000m for the light path distance of the
perpendicular arm (dper). (D=11m, v=29805m/sec, c=299792458m/sec).
Calculating the time for the transit of light across the parallel
light path using the formula
dpar/c' = 22.000000217450100000000000000m/299792459.5m/sec we get
0.000000073384101306261100000sec for tpar and
calculating the time for the transit of light across the perpendicular
light path using the formula
dper/c = 22.000000108725000000000000000m/299792458m/sec we get
0.000000073384101306261100000sec for tper.
As the transit times for the two light paths are identical, the null
result has been resolved by increasing the SPEED OF LIGHT on the
parallel arm due to the speed of the source rather than by the Lorentz
transformations which (incorrectly) reduced the LENGTH of the parallel
arm, dilated the TIME relating to the experiment and increased the
MASS of the object in line with its speed.
The orbital speed of the earth around the sun varies from a maximum of
30287m/sec to a minimum of 29292m/sec with an average speed of 29805m/
sec. I have used the average speed in the above example but using
either of the three speeds in my formula will produce identical
transit times for the perpendicular and parallel arms.
Peter Riedt
Inertial
"Peter Riedt" <rie...@yahoo.co.uk> wrote in message
news:d3e1b05b-312a-4de4...@j24g2000yqa.googlegroups.com...
> Einstein was right
About a good many things, yes. Not everything of course. Did you have
something particular in mind?
> Einstein was right when he said: �One experiment can prove me wrong; a
> hundred experiments cannot prove me right�.
That's how science works
> The experiment to prove
> Einstein wrong was the 1887 interferometer experiment of Michelson &
> Morley (MMX).
Wrong .. it is fully explained and consistent with SR.
> This experiment was expected to produce a measurable
> outcome due to the interference of two light beams.
Though SR predict a null result, which is consitent with what was observed.
[snip rest as your premise is refuted]
eric gisse
> Einstein was right
>
> Einstein was right when he said: ?One experiment can prove me wrong; a
> hundred experiments cannot prove me right?. The experiment to prove
> Einstein wrong was the 1887 [...]
For fucks sake.
> 0.000000073384101306261100000sec for tper.
Jesus christ.
[snip rest, unread]
Peter Riedt
Yes, 0.000000073384101306261100000sec for tper.
Henry Wilson DSc
wrote:
The null result was as expected because light is source dependent.
Einstein fluke another right answer.
>Peter Riedt
Henry Wilson...
Save the Planet....support my ONE-AND-A-HALF CHILD policy.
www.scisite.info/solution.rtf
eric gisse
The Michelson-Morely experiment did not have 28 decimal places of precision.
Stop being defective.
Inertial
"Henry Wilson DSc" <..@..> wrote in message
news:smvqj5hi1tkltnksv...@4ax.com...
MMX results is consistent with Emission Theory or LET or SR, but refute a
simple aether.
> Einstein fluke another right answer.
That was not Einstein's answer, you moron. A ballistic answer is refuted by
other experiments. The only theories which survive experimental testing are
SR and LET.
Henry Wilson DSc
No known experiment refutes BaTh. I have exposed the flaws in all those that
were claimed to do so.
Inertial
"Henry Wilson DSc" <..@..> wrote in message
WRONG
> I have exposed the flaws in all those that
> were claimed to do so.
NOPE
eric gisse
[...]
How's your code reading skill? Ralph posted approximately 10% of the code he
uses to "prove" light is ballistic, and it was a barrel of lulz.
I write better code when parsing Google output for vulnerable sites!
Inertial
"eric gisse" <jowr.pi...@gmail.com> wrote in message
news:hhlvh5$nkg$1...@news.eternal-september.org...
Given that I'm a professional software developer .. my skills pretty good.
Reading poorly written amateur code like that is painful though. But to
analyze it properly, I'd need to see the equations that he is supposedly
emulating etc, to verify that what he claims his program is doing is what it
is actually doing. And probably would want to see more than just 10% of it
.. I'm not sure whether the 10% shown is enough. Though I suppose if I had
the time I could reverse engineer it to determine what it was actually
emulating. Maybe if I get bored some time.
eric gisse
There's enough.
You can see him using constant light speed in distance calculations, using
the force for a circular orbit to describe an elliptical orbit, arbitrary
definitions of constants, etc. Read through my comments and you'll see.
Peter Riedt
>
> - Show quoted text -
The number of decimal places of precision in MMX is irrelevant. My
formula has 27 places to prove that the transit times over the
perpendicular and parallel armes are equal to an enormous acuracy at
all orbital speeds of the earth due to anisotropy of light.
Irrefutably and precisely explainig the null result better than
Lorentz who had to mess with time as well.
eric gisse
> On Jan 1, 1:02 pm, eric gisse <jowr.pi.nos...@gmail.com> wrote:
>> Peter Riedt wrote:
>> > On Dec 31 2009, 11:36 am, eric gisse <jowr.pi.nos...@gmail.com> wrote:
>> >> Peter Riedt wrote:
>> >> > Einstein was right
>>
>> >> > Einstein was right when he said: ?One experiment can prove me wrong;
>> >> > a hundred experiments cannot prove me right?. The experiment to
>> >> > prove Einstein wrong was the 1887 [...]
>>
>> >> For fucks sake.
>>
>> >> > 0.000000073384101306261100000sec for tper.
>>
>> >> Jesus christ.
>>
>> >> [snip rest, unread]
>>
>> > Yes, 0.000000073384101306261100000sec for tper.
>>
>> The Michelson-Morely experiment did not have 28 decimal places of
>> precision.
>>
>> Stop being defective.- Hide quoted text -
>>
>> - Show quoted text -
>
> The number of decimal places of precision in MMX is irrelevant. My
Yet you insist on reporting it to about 27 more decimal places than you have
access to. Hmm.
> formula has 27 places to prove that the transit times over the
> perpendicular and parallel armes are equal to an enormous acuracy at
> all orbital speeds of the earth due to anisotropy of light.
No, it does not work that way.
> Irrefutably and precisely explainig the null result better than
> Lorentz who had to mess with time as well.
Yeah "mess with time". What was he thinking.
Don't you think your time would be better spent on...anything else?
Henry Wilson DSc
wrote:
hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
Not one of your comments was worth a piece of shit.
You wouldn't have a clue how to write something like that.
I'm still laughing at your hopelessness.
Everything you said was wrong.
Henry Wilson DSc
You wouldn't be able to understand it any more than little eric did.
It's too brilliant for the likes of you. Your kind of software doesn't use
equations.
Inertial
"Henry Wilson DSc" <..@..> wrote in message
> On Sat, 2 Jan 2010 10:53:43 +1100, "Inertial" <relat...@rest.com> wrote:
>
>>
>>"eric gisse" <jowr.pi...@gmail.com> wrote in message
>>news:hhlvh5$nkg$1...@news.eternal-september.org...
>>> Inertial wrote:
>>> [...]
>>>
>>> How's your code reading skill? Ralph posted approximately 10% of the
>>> code
>>> he
>>> uses to "prove" light is ballistic, and it was a barrel of lulz.
>>>
>>> I write better code when parsing Google output for vulnerable sites!
>>
>>Given that I'm a professional software developer .. my skills pretty good.
>>Reading poorly written amateur code like that is painful though. But to
>>analyze it properly, I'd need to see the equations that he is supposedly
>>emulating etc, to verify that what he claims his program is doing is what
>>it
>>is actually doing. And probably would want to see more than just 10% of
>>it
>>.. I'm not sure whether the 10% shown is enough. Though I suppose if I
>>had
>>the time I could reverse engineer it to determine what it was actually
>>emulating. Maybe if I get bored some time.
>
> You wouldn't be able to understand it any more than little eric did.
Well.. it is pretty badly written.
> It's too brilliant for the likes of you.
BAHAHAHA. Too poorly written you mean
> Your kind of software doesn't use
> equations.
You wouldn't know.
eric gisse
[...]
>
> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>
> Not one of your comments was worth a piece of shit.
>
> You wouldn't have a clue how to write something like that.
>
> I'm still laughing at your hopelessness.
>
> Everything you said was wrong.
So when you write down the force for a circular orbit and then immediately
use it in an elliptical orbit, that isn't a mistake? Or when you write down
the time of flight assuming constant light speed, that isn't a mistake? Or
when you write down time of flight assuming 'no doppler' and then
immediately use the result in a spot where doppler would apply, that isn't a
mistake either?
You won't go through my response point by point and explain what the code
actually means and how I'm misunderstanding it because you can't.
You gambled that I would be incapable of doing even the most cursory of a
code review. Oops. You are so full of shit.
I will admit that you are correct when you say I am incapable of writing
something like that. I'd have to be drunk. Really drunk. I can still type
better than Porat even when I can't walk straight.
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>[...]
>
>>
>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>
>> Not one of your comments was worth a piece of shit.
>>
>> You wouldn't have a clue how to write something like that.
>>
>> I'm still laughing at your hopelessness.
>>
>> Everything you said was wrong.
>
>So when you write down the force for a circular orbit and then immediately
>use it in an elliptical orbit, that isn't a mistake?
Eric, there is a variable in the program called 'radvector'. It is the distance
from the focus to the point on the periphery or the ellipse. During the
geeration of the ellipse, its length changes with every iteration.
However there are many such subtleties in the program so you can be excused for
not understanding most of it. I wont call you a complete idiot.....yet. But if
you continue to rave , I might be forced to.
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>[...]
>
>>
>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>
>> Not one of your comments was worth a piece of shit.
>>
>> You wouldn't have a clue how to write something like that.
>>
>> I'm still laughing at your hopelessness.
>>
>> Everything you said was wrong.
>
>So when you write down the force for a circular orbit and then immediately
>use it in an elliptical orbit, that isn't a mistake? Or when you write down
>the time of flight assuming constant light speed, that isn't a mistake? Or
>when you write down time of flight assuming 'no doppler' and then
>immediately use the result in a spot where doppler would apply, that isn't a
>mistake either?
What the hell are you talking about now?
The program uses the principle that the star emits identical pulses of light at
equal time intervals around its orbit.
As the star moves around its (edge on) orbit, its light travels to Earth at c +
v(cos(theta)), where theta is the angle between the velocity vector at a
particular emission point and the LOS.
In other words, the pulses' speeds towards us changes continuously.
That casues them to bunch up and rarify as they travel through space, giving us
the impression that the star is changing brightness.
The process is blatantly obvious in the program.
>You won't go through my response point by point and explain what the code
>actually means and how I'm misunderstanding it because you can't.
I don't want to give away too many secrets. You might convert it to Java and
publish the thing as your own discovery...and become famous for proving
Einstein wrong.
>You gambled that I would be incapable of doing even the most cursory of a
>code review. Oops. You are so full of shit.
You get 9/10 for effort. 0/10 for performance.
>I will admit that you are correct when you say I am incapable of writing
>something like that. I'd have to be drunk. Really drunk.
Then you would write something like Andro's primitive program...
>I can still type
>better than Porat even when I can't walk straight.
Well you are probably right there.
Henry Wilson DSc
Hahahhahahahhha!
Inertial thinks she's a sofware engineer just because she drills holes in the
middle of CDs, all day.
eric gisse
> On Sat, 02 Jan 2010 04:09:29 -0800, eric gisse <jowr.pi...@gmail.com>
> wrote:
>
>>..@..(Henry Wilson DSc) wrote:
>>[...]
>>
>>>
>>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>>
>>> Not one of your comments was worth a piece of shit.
>>>
>>> You wouldn't have a clue how to write something like that.
>>>
>>> I'm still laughing at your hopelessness.
>>>
>>> Everything you said was wrong.
>>
>>So when you write down the force for a circular orbit and then immediately
>>use it in an elliptical orbit, that isn't a mistake? Or when you write
>>down the time of flight assuming constant light speed, that isn't a
>>mistake? Or when you write down time of flight assuming 'no doppler' and
>>then immediately use the result in a spot where doppler would apply, that
>>isn't a mistake either?
>
> What the hell are you talking about now?
The same thing I discussed in my comments, but without the actual code right
next to them for context. Go back to the comments and read.
>
> The program uses the principle that the star emits identical pulses of
> light at equal time intervals around its orbit.
Orbits which you calculate in a rather poor fashion, with the presumption of
another binary whose orbital properties are simply defined ad-hoc.
So why DO you think you can calculate the velocity of a binary star system
with an arbitrarily defined ratio of velocities? Why DO you think you can
use force for circular motion in elliptical orbits? Etc.
> As the star moves around its (edge on) orbit
Gosh didn't I make a comment or five about that?
> , its light travels to Earth
> at c + v(cos(theta)),
Which does not show up in any of the code you gave me. You try using that
assumption in the calculation of time lag, but you don't use it in the
calculation of the distance to the star which then propagates into how you
find time.
> where theta is the angle between the velocity vector
> at a particular emission point and the LOS.
Which you document as about as well as it is used.
> In other words, the pulses' speeds towards us changes continuously.
> That casues them to bunch up and rarify as they travel through space,
> giving us the impression that the star is changing brightness.
>
> The process is blatantly obvious in the program.
No, it is not. You posted a fraction of your code, and what made it through
is poorly documented and not formatted correctly.
>
>>You won't go through my response point by point and explain what the code
>>actually means and how I'm misunderstanding it because you can't.
>
> I don't want to give away too many secrets. You might convert it to Java
JAVA?
You gotta be high as BALLS or stupid as all hell to suggest that I'd port
your program to anything much less JAVA!
> and publish the thing as your own discovery...and become famous for
> proving Einstein wrong.
Hey shitbird, when YOU publish the code it is YOURS. Authorship doesn't go
away because someone else wishes it to.
You sit on your "discovery" because it isn't nearly as important as you
think it is. You continue to coo about how you are 'published' because you
put shit on your homepage. Turns out you know that claim is shit after all,
eh?
>
>>You gambled that I would be incapable of doing even the most cursory of a
>>code review. Oops. You are so full of shit.
>
> You get 9/10 for effort. 0/10 for performance.
You probably have not even fully read through my comments. If you had any
sense of pride in your work you would have shown exactly why I am wrong with
comments that actually touch upon code/math.
eric gisse
> On Sat, 02 Jan 2010 04:09:29 -0800, eric gisse <jowr.pi...@gmail.com>
> wrote:
>
>>..@..(Henry Wilson DSc) wrote:
>>[...]
>>
>>>
>>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>>
>>> Not one of your comments was worth a piece of shit.
>>>
>>> You wouldn't have a clue how to write something like that.
>>>
>>> I'm still laughing at your hopelessness.
>>>
>>> Everything you said was wrong.
>>
>>So when you write down the force for a circular orbit and then immediately
>>use it in an elliptical orbit, that isn't a mistake?
>
> Eric, there is a variable in the program called 'radvector'. It is the
> distance from the focus to the point on the periphery or the ellipse.
> During the
> geeration of the ellipse, its length changes with every iteration.
Which does not even touch upon let alone begin to respond to what I said.
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>
>> On Sat, 02 Jan 2010 04:09:29 -0800, eric gisse <jowr.pi...@gmail.com>
>> wrote:
>>
>>>..@..(Henry Wilson DSc) wrote:
>>>[...]
>>>
>>>>
>>>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>>>
>>>> Not one of your comments was worth a piece of shit.
>>>>
>>>> You wouldn't have a clue how to write something like that.
>>>>
>>>> I'm still laughing at your hopelessness.
>>>>
>>>> Everything you said was wrong.
>>>
>>>So when you write down the force for a circular orbit and then immediately
>>>use it in an elliptical orbit, that isn't a mistake?
>>
>> Eric, there is a variable in the program called 'radvector'. It is the
>> distance from the focus to the point on the periphery or the ellipse.
>> During the
>> geeration of the ellipse, its length changes with every iteration.
>
>Which does not even touch upon let alone begin to respond to what I said.
Nowhere does my program do what you claim...."write down the force for a
circular orbit and then immediately use it in an elliptical orbit..."
You are raving mad...totally incompetent....
You haven't found any errors in my program so don't lie to others that you
have.
eric gisse
> On Sat, 02 Jan 2010 12:19:04 -0800, eric gisse <jowr.pi...@gmail.com>
> wrote:
>
>>..@..(Henry Wilson DSc) wrote:
>>
>>> On Sat, 02 Jan 2010 04:09:29 -0800, eric gisse
>>> <jowr.pi...@gmail.com> wrote:
>>>
>>>>..@..(Henry Wilson DSc) wrote:
>>>>[...]
>>>>
>>>>>
>>>>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>>>>
>>>>> Not one of your comments was worth a piece of shit.
>>>>>
>>>>> You wouldn't have a clue how to write something like that.
>>>>>
>>>>> I'm still laughing at your hopelessness.
>>>>>
>>>>> Everything you said was wrong.
>>>>
>>>>So when you write down the force for a circular orbit and then
>>>>immediately use it in an elliptical orbit, that isn't a mistake?
>>>
>>> Eric, there is a variable in the program called 'radvector'. It is the
>>> distance from the focus to the point on the periphery or the ellipse.
>>> During the
>>> geeration of the ellipse, its length changes with every iteration.
>>
>>Which does not even touch upon let alone begin to respond to what I said.
>
> Nowhere does my program do what you claim...."write down the force for a
> circular orbit and then immediately use it in an elliptical orbit..."
Oh, so you assume circular orbits for everything? Or are you saying that bit
of code is superfluous?
You have one of four choices:
a) My initial assessment was right.
b) You don't actually use the code.
c) You assume circular orbits.
d) I misunderstood the repeated invocations of what is clearly the force for
a circular trajectory.
If the answer is "d", please explain the meaning of the code. If the answer
is "a,b, or c" please respond in an indignant and angry fashion using a non-
sequitur argument.
>
> You are raving mad...totally incompetent....
>
> You haven't found any errors in my program so don't lie to others that you
> have.
Feel free to respond to my comments as written.
Your code is right there, as are my comments. I always included enough code
for context, so if I am actually wrong you have nothing to worry about since
it should be 'obvious' I am wrong.
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>
>> On Sat, 02 Jan 2010 04:09:29 -0800, eric gisse <jowr.pi...@gmail.com>
>> wrote:
>>
>>>..@..(Henry Wilson DSc) wrote:
>>>[...]
>>>
>>>>
>>>> hahahahahhHAHAHAHAHHHHAWHAWHAWHAWHAHAHAHAHAHAHHHa!
>>>>
>>>> Not one of your comments was worth a piece of shit.
>>>>
>>>> You wouldn't have a clue how to write something like that.
>>>>
>>>> I'm still laughing at your hopelessness.
>>>>
>>>> Everything you said was wrong.
>>>
>>>So when you write down the force for a circular orbit and then immediately
>>>use it in an elliptical orbit, that isn't a mistake? Or when you write
>>>down the time of flight assuming constant light speed, that isn't a
>>>mistake? Or when you write down time of flight assuming 'no doppler' and
>>>then immediately use the result in a spot where doppler would apply, that
>>>isn't a mistake either?
>>
>> What the hell are you talking about now?
>
>The same thing I discussed in my comments, but without the actual code right
>next to them for context. Go back to the comments and read.
None of your comments makes any sense.
>> The program uses the principle that the star emits identical pulses of
>> light at equal time intervals around its orbit.
>
>Orbits which you calculate in a rather poor fashion, with the presumption of
>another binary whose orbital properties are simply defined ad-hoc.
The orbits I calculate are very precise. Computers can similate REAL
situations, you know. I generate ellipses in the same way that a planet
actually does...using F= -GMm/r^2. With double precision numbers and lots of
iterations the method works perfectly for the purpose. ven quite large
variations from perfect ellipses make little difference to he brightness curves
anyway. I spent a good deal of time checking that by deliberately distorting my
orbits.
My method is very convenient and takes only about half a second on my pretty
ordinary HP laptop.
If you want to criticise Newton's equation then you will have to explain why it
has given very precise predictions and results for many centuries....but you
obviously enjoy making an absolute fool of yourself...so don't hesitate to try.
>So why DO you think you can calculate the velocity of a binary star system
>with an arbitrarily defined ratio of velocities? Why DO you think you can
>use force for circular motion in elliptical orbits? Etc.
What the fuck are you talking about?
The force my program uses is GM/r^2 in the direction of the current radius
vector, the length of which changes with every iteration.
Accept it eric, you are a novice...a raw beginner...... I have been doing this
kind of thing for many years and know a hell of lot more about it than you do.
>> As the star moves around its (edge on) orbit
>
>Gosh didn't I make a comment or five about that?
That is explained very neatly. In your total ignorance, you even confused pitch
with YAW. Why don't you read something about the topic.
If an edge on orbit is rotated about an axis normal to the LOS, then ALL radial
velocities around the orbit are multiplied by the same cos(pitch) factor.
In case you don't know, 'radial velocity' is the components of peripheral
velocity in the Earth's direction.
>> , its light travels to Earth
>> at c + v(cos(theta)),
>
>Which does not show up in any of the code you gave me.
crap.
TaT = DoverC/(1+Yone) .....
Have a look at what Yone is.
>You try using that
>assumption in the calculation of time lag, but you don't use it in the
>calculation of the distance to the star which then propagates into how you
>find time.
You are raving again. You don't have a clue what the program does.
The star distance is selected in a combo box.
>> where theta is the angle between the velocity vector
>> at a particular emission point and the LOS.
>
>Which you document as about as well as it is used.
The angles, wrt the minor axis, for all ~30000 equi-temporal points around the
periphery are stored in an array.
>> In other words, the pulses' speeds towards us changes continuously.
>> That casues them to bunch up and rarify as they travel through space,
>> giving us the impression that the star is changing brightness.
>>
>> The process is blatantly obvious in the program.
>
>No, it is not. You posted a fraction of your code, and what made it through
>is poorly documented and not formatted correctly.
Your comments are crap.
Writing the program to do what it should was extremely difficult. Whether or
not the actual code is perfect is of no significance.
I have revise and simplified it many times over the years and will continue to
do so...that will not alter the results....WHICH CLEARLY PROVE THAT EINSTEIN
WAS WRONG.
>>>You won't go through my response point by point and explain what the code
>>>actually means and how I'm misunderstanding it because you can't.
>>
>> I don't want to give away too many secrets. You might convert it to Java
>
>JAVA?
>
>You gotta be high as BALLS or stupid as all hell to suggest that I'd port
>your program to anything much less JAVA!
>
>> and publish the thing as your own discovery...and become famous for
>> proving Einstein wrong.
>
>Hey shitbird, when YOU publish the code it is YOURS. Authorship doesn't go
>away because someone else wishes it to.
The writing of the code doesn't matter, dopey. It's what the program achieves
that tells us the facts...ie., Einstein was a con artist and a fool.
>You sit on your "discovery" because it isn't nearly as important as you
>think it is. You continue to coo about how you are 'published' because you
>put shit on your homepage. Turns out you know that claim is shit after all,
>eh?
eric, one day you might be able to do something useful too....so don't feel so
dejected when you see the successes of others.
>>>You gambled that I would be incapable of doing even the most cursory of a
>>>code review. Oops. You are so full of shit.
>>
>> You get 9/10 for effort. 0/10 for performance.
>
>You probably have not even fully read through my comments.
I answered every one. I even enjoyed doing it because they were so stupid..
>If you had any
>sense of pride in your work you would have shown exactly why I am wrong with
>comments that actually touch upon code/math.
I gave you credit for trying...
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>
>> On Sat, 02 Jan 2010 12:19:04 -0800, eric gisse <jowr.pi...@gmail.com>
>> wrote:
>>
>>>..@..(Henry Wilson DSc) wrote:
>>>> Eric, there is a variable in the program called 'radvector'. It is the
>>>> distance from the focus to the point on the periphery or the ellipse.
>>>> During the
>>>> geeration of the ellipse, its length changes with every iteration.
>>>
>>>Which does not even touch upon let alone begin to respond to what I said.
>>
>> Nowhere does my program do what you claim...."write down the force for a
>> circular orbit and then immediately use it in an elliptical orbit..."
>
>Oh, so you assume circular orbits for everything? Or are you saying that bit
>of code is superfluous?
>
>You have one of four choices:
>
>a) My initial assessment was right.
>b) You don't actually use the code.
>c) You assume circular orbits.
>d) I misunderstood the repeated invocations of what is clearly the force for
>a circular trajectory.
What the fuck are you talking about?
G = M/r^2 operates whether the orbit is circular or elliptical.
Maybe you are confused by the fact that I don't go to the trouble of generating
circular orbits as I do elliptical ones...that is for obvious reasons. Circles
are simple. v is constant and the array of orbital angles is based on a
straight sine function.
>If the answer is "d", please explain the meaning of the code. If the answer
>is "a,b, or c" please respond in an indignant and angry fashion using a non-
>sequitur argument.
I think you should read up on conics.
>> You are raving mad...totally incompetent....
>>
>> You haven't found any errors in my program so don't lie to others that you
>> have.
>
>Feel free to respond to my comments as written.
>
>Your code is right there, as are my comments. I always included enough code
>for context, so if I am actually wrong you have nothing to worry about since
>it should be 'obvious' I am wrong.
I have answered all of your comments. They were all wrong...without
exception...and you're still doing it.
Inertial
"Henry Wilson DSc" <..@..> wrote in message
Another lie by Henry. You are one of the most dishonest people I have had
the misfortune to deal with. How do you live with youtself knowing you are
a liar and a fraud?
Inertial
"Henry Wilson DSc" <..@..> wrote in message
The only con artist and fool here is you, Henry.
YBM
> You are raving again. You don't have a clue what the program does.
>
> The star distance is selected in a combo box.
I really enjoy such nonsensical commentary from Ralph.
A few years ago he wrote something like "My program has
eleven parameters, how could it be wrong?".
Now it's "It cannot be wrong! It's been selected from
a combo box!"
What a gonzo...
eric gisse
[...]
>>
>>The same thing I discussed in my comments, but without the actual code
>>right next to them for context. Go back to the comments and read.
>
> None of your comments makes any sense.
You have a great difficulty making sense of what people say.
SR? Incoherent - can't make heads or tails of it. Other people manage.
My comments? Perfectly legible English with the thought process all laid
out. Yet you are flummoxed.
Perhaps the problem is local?
>
>>> The program uses the principle that the star emits identical pulses of
>>> light at equal time intervals around its orbit.
>>
>>Orbits which you calculate in a rather poor fashion, with the presumption
>>of another binary whose orbital properties are simply defined ad-hoc.
>
> The orbits I calculate are very precise.
And you know this how?
> Computers can similate REAL
> situations, you know. I generate ellipses in the same way that a planet
> actually does...using F= -GMm/r^2. With double precision numbers and lots
> of iterations the method works perfectly for the purpose.
Yes, I've seen your implementation before. You used Euler's iterative method
which is known to be quite poor for simulating orbits.
> ven quite large
> variations from perfect ellipses make little difference to he brightness
> curves anyway. I spent a good deal of time checking that by deliberately
> distorting my orbits.
So the nature of the orbiting binary doesn't really change the brightness
curves? That's extremely odd, wouldn't you say?
I wonder how you calculate brightness.
>
> My method is very convenient and takes only about half a second on my
> pretty ordinary HP laptop.
>
> If you want to criticise Newton's equation then you will have to explain
> why it has given very precise predictions and results for many
> centuries....but you obviously enjoy making an absolute fool of
> yourself...so don't hesitate to try.
Sure. Post the code.
>
>>So why DO you think you can calculate the velocity of a binary star system
>>with an arbitrarily defined ratio of velocities? Why DO you think you can
>>use force for circular motion in elliptical orbits? Etc.
>
> What the fuck are you talking about?
It would be clear if you actually read my comments, but clearly that's too
much to ask.
Code:
If velratio = 0 Then Vtwo = 1 Else Vtwo = vone * velratio
Gosh, that looks rather arbitrary to me. You then use the Vtwo variable to
calculate the position of the star and the lag time with the following code
snippets:
Ytwo = velocity(r) * Vtwo * Sin(Vangle(r) + piyaw)
Tbt(r) = (DoverC / (1 + (velocity((r + Xlag) Mod (points -1)) * Ylag *
Vtwo))) + (PP * r)
You then later in the circlebright function define the velocity of the
second star the EXACT SAME WAY:
Vtwo = vone * velratio
> The force my program uses is GM/r^2 in the direction of the current radius
> vector, the length of which changes with every iteration.
Ah, and you are sure your code generates stable output is what, exactly?
By the way, do you think scientists are misguided because they don't use
visual basic like you do?
>
> Accept it eric, you are a novice...a raw beginner...... I have been doing
> this kind of thing for many years and know a hell of lot more about it
> than you do.
"Never argue with an idiot, they drag you down to their level and beat you
with experience."
>
>>> As the star moves around its (edge on) orbit
>>
>>Gosh didn't I make a comment or five about that?
>
> That is explained very neatly. In your total ignorance, you even confused
> pitch with YAW. Why don't you read something about the topic.
>
> If an edge on orbit is rotated about an axis normal to the LOS, then ALL
> radial velocities around the orbit are multiplied by the same cos(pitch)
> factor.
Which you do not do.
>
> In case you don't know, 'radial velocity' is the components of peripheral
> velocity in the Earth's direction.
>
>>> , its light travels to Earth
>>> at c + v(cos(theta)),
>>
>>Which does not show up in any of the code you gave me.
>
> crap.
> TaT = DoverC/(1+Yone) .....
So when theta is equal to 90 degrees, light travels at c with respect to the
observer? Really? That's 'ballistic theory' ? Are you sure?
Why isn't it (c+v)cos(theta)? I mean, that's exactly how velocities are
projected upon a direction in Newtonian mechanics. Aren't you always saying
how Newton is right?
Let's examine your definition of DoverC closely: DoverC = Stardist / c.
Now combine that with your definition of travel time: t = distance /
c(1+Yone).
Hmm.
Let's examine Yone: Yone = vone * velocity(r) * Sin(Vangle(r) + piyaw).
Huh? You have Yone that has units of [velocity]^2.
So we have a situation of you adding 1 to something that has units of
(L/T)^2. Are you sure that's intentional?
Now let's look at the overall equation for time. You have distance divided
by c times 1 + something of units (L/T)^2. How is that supposed to give you
time, exactly?
Where's the material that you claim is worth a dozen PhD's? Because this
stuff would make you fail an undergraduate computational physics course.
>
> Have a look at what Yone is.
Let's do that.
You define Yone in terms of vone, which you do not derive. It is an input
condition, so your claim that you simulate orbits is a bit of a lie.
Didn't I point out to you - a few times now - that spectrographic Doppler
allows you to accurately determine the velocities (at least projected
components of) of stars?
>
>>You try using that
>>assumption in the calculation of time lag, but you don't use it in the
>>calculation of the distance to the star which then propagates into how you
>>find time.
>
> You are raving again. You don't have a clue what the program does.
I have a reasonably good idea even though you admitted only posting a small
fraction of it.
>
> The star distance is selected in a combo box.
And you've repeatedly opined about how you can't trust the work of
astronomers. So how do you know the star distance?
>
>>> where theta is the angle between the velocity vector
>>> at a particular emission point and the LOS.
>>
>>Which you document as about as well as it is used.
>
> The angles, wrt the minor axis, for all ~30000 equi-temporal points around
> the periphery are stored in an array.
>
>>> In other words, the pulses' speeds towards us changes continuously.
>>> That casues them to bunch up and rarify as they travel through space,
>>> giving us the impression that the star is changing brightness.
>>>
>>> The process is blatantly obvious in the program.
>>
>>No, it is not. You posted a fraction of your code, and what made it
>>through is poorly documented and not formatted correctly.
>
> Your comments are crap.
They'll be even more crap once you read what I wrote above.
> Writing the program to do what it should was extremely difficult. Whether
> or not the actual code is perfect is of no significance.
In light of the GLARING freshman errors in unit analysis above, this
sentence of yours is especially funny.
[snip rest]
Henry Wilson DSc
wrote:
>..@..(Henry Wilson DSc) wrote:
>[...]
>> Computers can similate REAL
>> situations, you know. I generate ellipses in the same way that a planet
>> actually does...using F= -GMm/r^2. With double precision numbers and lots
>> of iterations the method works perfectly for the purpose.
>
>Yes, I've seen your implementation before. You used Euler's iterative method
>which is known to be quite poor for simulating orbits.
hahaaahhaha! Have a look at the ellipses. they are bloody nearly
perfect...definitely close enough for this purpose.
>> ven quite large
>> variations from perfect ellipses make little difference to he brightness
>> curves anyway. I spent a good deal of time checking that by deliberately
>> distorting my orbits.
>
>So the nature of the orbiting binary doesn't really change the brightness
>curves? That's extremely odd, wouldn't you say?
I didn't say that. Don't make an even bigger fool of yousel.
>I wonder how you calculate brightness.
i told you ...but it is probably tooo difficult for you to understand.
>> My method is very convenient and takes only about half a second on my
>> pretty ordinary HP laptop.
>>
>> If you want to criticise Newton's equation then you will have to explain
>> why it has given very precise predictions and results for many
>> centuries....but you obviously enjoy making an absolute fool of
>> yourself...so don't hesitate to try.
>
>Sure. Post the code.
You have the code already
>>>So why DO you think you can calculate the velocity of a binary star system
>>>with an arbitrarily defined ratio of velocities? Why DO you think you can
>>>use force for circular motion in elliptical orbits? Etc.
>>
>> What the fuck are you talking about?
>
>It would be clear if you actually read my comments, but clearly that's too
>much to ask.
>
>Code:
>
>If velratio = 0 Then Vtwo = 1 Else Vtwo = vone * velratio
>
>Gosh, that looks rather arbitrary to me. You then use the Vtwo variable to
>calculate the position of the star and the lag time with the following code
>snippets:
>
>Ytwo = velocity(r) * Vtwo * Sin(Vangle(r) + piyaw)
>Tbt(r) = (DoverC / (1 + (velocity((r + Xlag) Mod (points -1)) * Ylag *
>Vtwo))) + (PP * r)
>
>You then later in the circlebright function define the velocity of the
>second star the EXACT SAME WAY:
I already told you. I have a separate section for circular orbitsbecasue they
are much simpler to use.
>Vtwo = vone * velratio
yes. simple isn't it..
>> The force my program uses is GM/r^2 in the direction of the current radius
>> vector, the length of which changes with every iteration.
>
>Ah, and you are sure your code generates stable output is what, exactly?
>
>By the way, do you think scientists are misguided because they don't use
>visual basic like you do?
It doesn't matter what program produces the results, dopey, they will all be
the same. Even a Androcles gets the same curves with a very different program
and method..
>> Accept it eric, you are a novice...a raw beginner...... I have been doing
>> this kind of thing for many years and know a hell of lot more about it
>> than you do.
>
>"Never argue with an idiot, they drag you down to their level and beat you
>with experience."
Well I wont waste much more time on you. that's for sure.
>>>> As the star moves around its (edge on) orbit
>>>
>>>Gosh didn't I make a comment or five about that?
>>
>> That is explained very neatly. In your total ignorance, you even confused
>> pitch with YAW. Why don't you read something about the topic.
>>
>> If an edge on orbit is rotated about an axis normal to the LOS, then ALL
>> radial velocities around the orbit are multiplied by the same cos(pitch)
>> factor.
>
>Which you do not do.
eric, you're as dumb as Andro. what star velocities do gratings detect?
>> In case you don't know, 'radial velocity' is the components of peripheral
>> velocity in the Earth's direction.
>>
>>>> , its light travels to Earth
>>>> at c + v(cos(theta)),
>>>
>>>Which does not show up in any of the code you gave me.
>>
>> crap.
>> TaT = DoverC/(1+Yone) .....
>
>So when theta is equal to 90 degrees, light travels at c with respect to the
>observer? Really? That's 'ballistic theory' ? Are you sure?
For face on orbits, all light travels at c wrt the star over the whole orbit.
The program ignores proper speeds because they don't affect the brightness
curve shapes at all.
>Why isn't it (c+v)cos(theta)? I mean, that's exactly how velocities are
>projected upon a direction in Newtonian mechanics. Aren't you always saying
>how Newton is right?
No eric, the star is moving at v cos(theta) wrt earth. Its light leaves the
star at c wrt the star. So I'll leave it to you to recognize your mistake.
>
>Let's examine your definition of DoverC closely: DoverC = Stardist / c.
>
>Now combine that with your definition of travel time: t = distance /
>c(1+Yone).
>
>Hmm.
Hmm indeed. Yone is expressed as a fraction of c....eg 0.00001
So it has to be multiplied by c to make it km/s
>Let's examine Yone: Yone = vone * velocity(r) * Sin(Vangle(r) + piyaw).
>
>Huh? You have Yone that has units of [velocity]^2.
No eric. 'velocity(r)' is stored as a fraction of the maximum peripheral speed.
It is a pure number....eg 0.27763766747
>So we have a situation of you adding 1 to something that has units of
>(L/T)^2. Are you sure that's intentional?
no eric...but I'm sure you're delusional
>Now let's look at the overall equation for time. You have distance divided
>by c times 1 + something of units (L/T)^2. How is that supposed to give you
>time, exactly?
Time = distance /speed. L/(L/T) = T
.........pretty basic really
>Where's the material that you claim is worth a dozen PhD's?
I don't want another one...They are boring.
>Because this
>stuff would make you fail an undergraduate computational physics course.
>
>>
>> Have a look at what Yone is.
>
>Let's do that.
>
>You define Yone in terms of vone, which you do not derive. It is an input
>condition, so your claim that you simulate orbits is a bit of a lie.
Increasing orbit velocity or distance has the same effect on the brightness
curve magnitude change. So if neither velocity or distance are known
accurately, which is often gthe case, i don't really care much about either. It
is their product that matters. ...and of course velocity automatically includes
pitch angle.
Basic curve shapes are determined solely by eccentricity and yaw angle.
>Didn't I point out to you - a few times now - that spectrographic Doppler
>allows you to accurately determine the velocities (at least projected
>components of) of stars?
Yes, I know that...and they also include the orbit pitch angle. Androcles
cannot understand that either.
>>>You try using that
>>>assumption in the calculation of time lag, but you don't use it in the
>>>calculation of the distance to the star which then propagates into how you
>>>find time.
>>
>> You are raving again. You don't have a clue what the program does.
>
>I have a reasonably good idea even though you admitted only posting a small
>fraction of it.
You have at least made an effort...which is a lot more than some.
>> The star distance is selected in a combo box.
>
>And you've repeatedly opined about how you can't trust the work of
>astronomers. So how do you know the star distance?
I don't always. I generate the curve then look at the product of distance x max
velocity. If it doesn't comply roughly with published data, I can assume some
unification might have occured. Distances, if diffrent are always lower than
Hipparcos ones. Hpwever, because of ADoppler, which is likely to dominate over
VDoppler, we cannot be sure that the spectrally determined velocities are
anywhere near correct...so the unification solution might not be necessary.
>>>> where theta is the angle between the velocity vector
>>>> at a particular emission point and the LOS.
>>>
>>>Which you document as about as well as it is used.
>>
>> The angles, wrt the minor axis, for all ~30000 equi-temporal points around
>> the periphery are stored in an array.
>>
>>>> In other words, the pulses' speeds towards us changes continuously.
>>>> That casues them to bunch up and rarify as they travel through space,
>>>> giving us the impression that the star is changing brightness.
>>>>
>>>> The process is blatantly obvious in the program.
>>>
>>>No, it is not. You posted a fraction of your code, and what made it
>>>through is poorly documented and not formatted correctly.
>>
>> Your comments are crap.
>
>They'll be even more crap once you read what I wrote above.
You haven't come up with any legitimate criticism so far.
>> Writing the program to do what it should was extremely difficult. Whether
>> or not the actual code is perfect is of no significance.
>
>In light of the GLARING freshman errors in unit analysis above, this
>sentence of yours is especially funny.
You haven't come up with any legitimate criticism so far.
I wouldn't make a fool of myself any more if I were you.
>[snip rest]
eric gisse
> On Sat, 02 Jan 2010 18:52:45 -0800, eric gisse <jowr.pi...@gmail.com>
> wrote:
>
>>..@..(Henry Wilson DSc) wrote:
>>[...]
>
>>> Computers can similate REAL
>>> situations, you know. I generate ellipses in the same way that a planet
>>> actually does...using F= -GMm/r^2. With double precision numbers and
>>> lots of iterations the method works perfectly for the purpose.
>>
>>Yes, I've seen your implementation before. You used Euler's iterative
>>method which is known to be quite poor for simulating orbits.
>
> hahaaahhaha! Have a look at the ellipses. they are bloody nearly
> perfect...definitely close enough for this purpose.
Really? Quantify it.
How do you define 'distortion'? How much error accumulates per orbit? How
does that error translate into brightness? Why did you pick Euler over
Runge-Kutta or some other method?
>
>>> ven quite large
>>> variations from perfect ellipses make little difference to he brightness
>>> curves anyway. I spent a good deal of time checking that by deliberately
>>> distorting my orbits.
>>
>>So the nature of the orbiting binary doesn't really change the brightness
>>curves? That's extremely odd, wouldn't you say?
>
> I didn't say that. Don't make an even bigger fool of yousel.
"ven quite large variations from perfect ellipses make little difference to
he brightness"
So what does that mean if not what I said?
>
>>I wonder how you calculate brightness.
>
> i told you ...but it is probably tooo difficult for you to understand.
No, I want to see how you do it in your program. What you say and what you
do are not always the same.
>
>>> My method is very convenient and takes only about half a second on my
>>> pretty ordinary HP laptop.
>>>
>>> If you want to criticise Newton's equation then you will have to explain
>>> why it has given very precise predictions and results for many
>>> centuries....but you obviously enjoy making an absolute fool of
>>> yourself...so don't hesitate to try.
>>
>>Sure. Post the code.
>
> You have the code already
I have, according to you, only 10% of the code. What you posted does not
contain the part that simulates orbits fully.
>
>>>>So why DO you think you can calculate the velocity of a binary star
>>>>system with an arbitrarily defined ratio of velocities? Why DO you think
>>>>you can use force for circular motion in elliptical orbits? Etc.
>>>
>>> What the fuck are you talking about?
>>
>>It would be clear if you actually read my comments, but clearly that's too
>>much to ask.
>>
>>Code:
>>
>>If velratio = 0 Then Vtwo = 1 Else Vtwo = vone * velratio
>>
>>Gosh, that looks rather arbitrary to me. You then use the Vtwo variable to
>>calculate the position of the star and the lag time with the following
>>code snippets:
>>
>>Ytwo = velocity(r) * Vtwo * Sin(Vangle(r) + piyaw)
>>Tbt(r) = (DoverC / (1 + (velocity((r + Xlag) Mod (points -1)) * Ylag *
>>Vtwo))) + (PP * r)
>>
>>You then later in the circlebright function define the velocity of the
>>second star the EXACT SAME WAY:
>
> I already told you. I have a separate section for circular orbitsbecasue
> they are much simpler to use.
Which is a really stupid way to do things, but wasn't the point of my
comments. Your definition of vtwo has no basis in physical fact, which IS
the point of my comments.
>
>>Vtwo = vone * velratio
>
> yes. simple isn't it..
Yeah, and how do you justify it?
>
>>> The force my program uses is GM/r^2 in the direction of the current
>>> radius vector, the length of which changes with every iteration.
>>
>>Ah, and you are sure your code generates stable output is what, exactly?
>>
>>By the way, do you think scientists are misguided because they don't use
>>visual basic like you do?
>
> It doesn't matter what program produces the results, dopey, they will all
> be the same. Even a Androcles gets the same curves with a very different
> program and method..
>
>>> Accept it eric, you are a novice...a raw beginner...... I have been
>>> doing this kind of thing for many years and know a hell of lot more
>>> about it than you do.
>>
>>"Never argue with an idiot, they drag you down to their level and beat you
>>with experience."
>
> Well I wont waste much more time on you. that's for sure.
Don't be daft. I'm one of the handful of people who actually talks with you,
you won't ignore me just like you continue to not ignore Paul or Inertial.
>
>>>>> As the star moves around its (edge on) orbit
>>>>
>>>>Gosh didn't I make a comment or five about that?
>>>
>>> That is explained very neatly. In your total ignorance, you even
>>> confused pitch with YAW. Why don't you read something about the topic.
>>>
>>> If an edge on orbit is rotated about an axis normal to the LOS, then ALL
>>> radial velocities around the orbit are multiplied by the same cos(pitch)
>>> factor.
>>
>>Which you do not do.
>
> eric, you're as dumb as Andro. what star velocities do gratings detect?
What the hell do you think?
>
>>> In case you don't know, 'radial velocity' is the components of
>>> peripheral velocity in the Earth's direction.
>>>
>>>>> , its light travels to Earth
>>>>> at c + v(cos(theta)),
>>>>
>>>>Which does not show up in any of the code you gave me.
>>>
>>> crap.
>>> TaT = DoverC/(1+Yone) .....
>>
>>So when theta is equal to 90 degrees, light travels at c with respect to
>>the observer? Really? That's 'ballistic theory' ? Are you sure?
>
> For face on orbits, all light travels at c wrt the star over the whole
> orbit.
> The program ignores proper speeds because they don't affect the
> brightness curve shapes at all.
How do you know? Lots of things don't seem to affect brightness curves.
Methinks you aren't doing them correctly.
>
>>Why isn't it (c+v)cos(theta)? I mean, that's exactly how velocities are
>>projected upon a direction in Newtonian mechanics. Aren't you always
>>saying how Newton is right?
>
> No eric, the star is moving at v cos(theta) wrt earth. Its light leaves
> the star at c wrt the star. So I'll leave it to you to recognize your
> mistake.
It would be (c+v)cos(theta) with respect to Earth according to ballistic
theory.
If you can imagine forcing light to travel at c, congratulations you
understand relativity.
>
>>
>>Let's examine your definition of DoverC closely: DoverC = Stardist / c.
>>
>>Now combine that with your definition of travel time: t = distance /
>>c(1+Yone).
>>
>>Hmm.
>
> Hmm indeed. Yone is expressed as a fraction of c....eg 0.00001
Which is not explained in code.
This is another terrible coding practice. You are mixing systems of units
and not differentiating in code. I wonder if you've managed to trip yourself
up yet.
That choice is also terrible too, since star velocities tend to be tens to
hundreds of a thousandth c. That means you are going to be introducing
rounding errors by repeatedly multiplying and dividing by c for no reason.
Good job.
>
> So it has to be multiplied by c to make it km/s
>
>>Let's examine Yone: Yone = vone * velocity(r) * Sin(Vangle(r) + piyaw).
>>
>>Huh? You have Yone that has units of [velocity]^2.
>
> No eric. 'velocity(r)' is stored as a fraction of the maximum peripheral
> speed. It is a pure number....eg 0.27763766747
Sure. Mix it up - lots of variables with units, no units, and different
units. Then wonder why people don't understand.
>
>>So we have a situation of you adding 1 to something that has units of
>>(L/T)^2. Are you sure that's intentional?
>
> no eric...but I'm sure you're delusional
>
>>Now let's look at the overall equation for time. You have distance divided
>>by c times 1 + something of units (L/T)^2. How is that supposed to give
>>you time, exactly?
>
> Time = distance /speed. L/(L/T) = T
>
> .........pretty basic really
That's the first equation I've been you write in a few years.
>
>>Where's the material that you claim is worth a dozen PhD's?
>
> I don't want another one...They are boring.
Another?
Where did you get your first one? What year? In what subject? What was your
thesis about?
>
>>Because this
>>stuff would make you fail an undergraduate computational physics course.
>>
>>>
>>> Have a look at what Yone is.
>>
>>Let's do that.
>>
>>You define Yone in terms of vone, which you do not derive. It is an input
>>condition, so your claim that you simulate orbits is a bit of a lie.
>
> Increasing orbit velocity or distance has the same effect on the
> brightness curve magnitude change. So if neither velocity or distance are
> known accurately, which is often gthe case, i don't really care much about
> either. It is their product that matters. ...and of course velocity
> automatically includes pitch angle.
So you don't know velocity or distance too well...but you know their
product? And if you get the answer you want that makes it OK?
Science doesn't work that way, Henri.
> Basic curve shapes are determined solely by eccentricity and yaw angle.
Really?
"ven quite large variations from perfect ellipses make little difference to
he brightness"
Sounds to me that you don't really know how the curves are generated.
[...]
>>
>>And you've repeatedly opined about how you can't trust the work of
>>astronomers. So how do you know the star distance?
>
> I don't always. I generate the curve then look at the product of distance
> x max
> velocity. If it doesn't comply roughly with published data, I can assume
> some unification might have occured.
Wow, what an admission.
So you generate the brightness curve THEN look at the actual orbital data,
and if you get nonsense you assume 'magic' happens?
> Distances, if diffrent are always
> lower than Hipparcos ones.
So you are always wrong but still manage to rationalize it away?
> Hpwever, because of ADoppler, which is likely
> to dominate over VDoppler, we cannot be sure that the spectrally
> determined velocities are anywhere near correct...so the unification
> solution might not be necessary.
So basically you make curves up, then throw your hands up in the air because
you have no idea how to jive what your program creates and what reality
says.
And you expect me to believe you have a PhD. hah.
[...]
Inertial
BTW: You've got to love Henry's latest foot-in-mouth in the 'Moving
Mirror.." thread. Did you know that according to Henry, the light from a
moving vertical light-clock does NOT follow a diagonal path in the
stationary frame? It is a vertical path moving sideways instead .. as Henry
says.
"NO LIGHT BEAM moves diagonally in the moving frame .. A vertical beam in
one frame is a vertical beam moving sideways in another"
BAHAHHAHA. That how Henry refutes the simple illustration of gamma factor
in length contraction. The light travels the same distance in both frames.
BAHAHAHAHA. Where's VDM when you need him to immortalize THAT fumble !!
eric gisse
[...]
> BAHAHHAHA. That how Henry refutes the simple illustration of gamma factor
> in length contraction. The light travels the same distance in both
> frames.
> BAHAHAHAHA. Where's VDM when you need him to immortalize THAT fumble !!
His refutations always seem to amount to 'nuh-uh!'
PD
> hundred experiments cannot prove me right”. The experiment to prove
> Einstein wrong was the 1887 interferometer experiment of Michelson &
> Morley (MMX). This experiment was expected to produce a measurable
> outcome due to the interference of two light beams. When the predicted
> fringe shift could not be observed, Lorentz proposed in 1905 that the
> null result of the experiment could be explained by the length of the
> parallel arm of the interferometer contracting according to the
> formula L' = L*sqrt(1-vv/cc). It also was accompanied by a slowing
> down of time and an increase of mass, all proportionally to the speed
> of the equipment through space.
>
> The Lorentz transformation formulas for length, time and mass can be
> replaced by one formula, the Riedt Anisotropic Light Formula (RALF)
> c' = c*1/sqrt(1-vv/cc) where the speed of the source is slightly
> increasing the speed of light from 299792458m/sec to 299792459.5m/sec
> but only in the direction of motion, aligned to the parallel arm.
>
> Michelson and Morley write in the American Journal of Science
> 203/1887, describing their MMX interferometer experiment: ”The
> distance travelled (by light to the end of the parallel arm of the
> interferometer and back) is 2D(1+vv/cc), and the length of the other
> path (across the perpendicular arm and back) is evidently 2D(1+vv/
> 2cc)”.
>
> Using Michelson's formula 2D(1+vv/cc) we get
> 22.000000217450100000000000000m for the light path distance of the
> parallel arm (dpar) and using 2D(1+vv/2cc) we get
> 22.000000108725000000000000000m for the light path distance of the
> perpendicular arm (dper). (D=11m, v=29805m/sec, c=299792458m/sec).
>
> Calculating the time for the transit of light across the parallel
> light path using the formula
> dpar/c' = 22.000000217450100000000000000m/299792459.5m/sec we get
> 0.000000073384101306261100000sec for tpar and
> calculating the time for the transit of light across the perpendicular
> light path using the formula
> dper/c = 22.000000108725000000000000000m/299792458m/sec we get
> 0.000000073384101306261100000sec for tper.
>
> As the transit times for the two light paths are identical, the null
> result has been resolved by increasing the SPEED OF LIGHT on the
> parallel arm due to the speed of the source rather than by the Lorentz
> transformations which (incorrectly) reduced the LENGTH of the parallel
> arm, dilated the TIME relating to the experiment and increased the
> MASS of the object in line with its speed.
>
> The orbital speed of the earth around the sun varies from a maximum of
> 30287m/sec to a minimum of 29292m/sec with an average speed of 29805m/
> sec. I have used the average speed in the above example but using
> either of the three speeds in my formula will produce identical
> transit times for the perpendicular and parallel arms.
>
> Peter Riedt
Peter, I think you're forgetting that the experiment was repeated in
different runs, with the interferometer rotated 90 degrees from run to
run (so that the two arms changed perpendicular and parallel roles),
at different times of the day (so that the interferometers orientation
with respect to the flow of a supposed aether would change) and from
month to month (so that the Earth's motion relative to the flow of a
supposed aether would change), and any *changes* in the fringes were
noted.
Your model only works if light knows somehow which way the
interferometer is facing from run to run, from hour to hour, and from
month to month, and somehow conspires to *follow* the little
interferometer around, so that the faster light is always along one
arm of the device, regardless which direction the device happens to be
facing.