[David Cooper]

I gave you numbers, such as 904km/s for the tail applying for 11 hours to get to the right location to conform to the correct length contraction acting on the ship.

My object never moves that fast.  Show where the separation is wrong at any point along its length at time X.  You're seemingly claiming that it takes 11 hours for one atom to catch up with the nearly stationary one right in front of it.

The 11 hours (which relates to a low-end guess at the amount of contraction over the whole ship once the back end starts moving) is for how long that rear atom has to move at double the speed it's supposed to be moving at before your ship begins to be the right length. It was the right length before the gun when the whole thing was stationary, but as soon as the back end started moving (and not just the back end, because most of the ship instantly starts moving), it's no longer the right length for the contraction which should be applying to it. A simulation would make that clear, but I don't have time to write one for it now and would rather wait until I have built the right tools to be able to build it in a fraction of the time. All I'm trying to do in the meantime is point out places where your ship isn't functioning in accordance with the rules you claim it conforms to. No one will die though if you don't want to recognise that until there's a simulation that makes it plain, so it isn't important.

As soon as it starts moving, it is still essentially still stopped everywhere except possibly the tail (depending on how far back that arbitrarily close point is).  It has no contraction except at the hind-most bit.  So it hardly has changed in overall length, and doesn't need to because it is almost entirely still stopped.

I didn't think it was only the back of the ship that you're moving. You have the back moving at 452 and the front at 0, so I assumed the middle would be doing some speed in between the two and moving at the same seed as that at the finish. When does the middle start and stop moving? Most of the contraction that I'm guessing will apply to the ship will apply towards the back end where the speed is highest, and I still think it will likely involve 11 hours to get the rear atom into the right place with it moving at double speed to get there. That is a significant issue. It may be a small change in overall length, but with your ship spread out across a hundred lightyears, it adds up to a big difference for the sections at the back which span multiple lightyears.

We're talking in air as you say.  I see it always being the exact correct length.  It's not like I'm the first one to do the mathematics behind it.  Where do you think that picture came from?

I would assume that you've taken the idea from a place where it doesn't start with the whole thing stationary and then suddenly have the back end moving at speed with the wrong length contraction on it.

[David Cooper]

I have no associations with science organizations. You might submit your work to an established research center to make them aware of your models.

I considered writing it up for a science journal, but I assumed I would just be ignored due to my lack of the right qualifications and the difficulty of showing things on paper without software, so I've simply communicated directly with people on science forums where I have discussed things with dozens of professional physicists (who are universally irrational when it comes to Einstein's models). However, I looked into it carefully a couple of years ago and found that they don't actually have to see who you are, and you can include software, so it is an option, but I still have every expectation that they simply wouldn't bother to look at it as soon as they see what is claimed, which means preparing a new text for them and versions of the software that don't run in JavaScript or in machine code on top of my own operating system would be a terrible waste of effort, and a costly one in terms of delays to something much more important.

[Halc (OP)]

The 11 hours (which relates to a low-end guess at the amount of contraction over the whole ship once the back end starts moving)

If only the back end is moving at any significant speed, only the back end needs to contract.  The rest is still essentially stopped, and it would be quite the strain if it were to contract at that point already.

You seem to be under the impression that I'm accelerating all parts equally.  You know that you can't do that with a rigid object.

as soon as the back end started moving (and not just the back end, because most of the ship instantly starts moving)

Moving, yes, but still at zero speed to an awful lot of digits.  You've given no time, so I'm taking the moment in time that the rear finishes acceleration and has hit 452 km/s.  At that moment, any point not at the absolute rear is still stationary to arbitrary precision, depending on how close you put D.  At zero speed, it requires zero contraction.

A simulation would make that clear

Indeed it would.

All I'm trying to do in the meantime is point out places where your ship isn't functioning in accordance with the rules you claim it conforms to.

You haven't done that.  You're claiming that a stationary object needs to contract which is just plain wrong. If you think it isn't stationary (to arbitrary precision), then you haven't applied or understood my acceleration curve of c²/D. Only the very rear is moving, and thus only that rear arbitrarily small segment needs to contract a tiny bit, which it does when the rear moves.

I didn't think it was only the back of the ship that you're moving. You have the back moving at 452 and the front at 0, so I assumed the middle would be doing some speed in between the two and moving

As I suspected, you didn't apply my rule at all.  You just assume wrong things.  If we make D a meter behind the object (we can put it a lot closer), then the rear accelerates at c²/D or 9e16 / 1 = 9e16 m/sec² so it takes about 5e-12 seconds to get up to max speed.  The front accelerates at 9e16 / 9.5e17 = 0.095 m/sec or a bit less than 1% of a g.  After that tiny fraction of a second, it is still stopped to over 20 digits.  The middle accelerates at 9e16 / 4.7e17 or a bit less than 2% of a g.  It is also stopped still, not at all moving at some pace half way between the front and rear as you assumed.
How about a point almost at the rear, say 1km in?  That would accelerate at 9e16 / 1000 = 9e13 m/sec² which is some pretty impressive acceleration until you do it for only 5e-12 seconds and find that its speed is 452 m/sec and has moved about a nanometer.  That last km of object has contracted by somewhat more than 1 micron.
The contraction for a km object moving at 452 m/sec is about 1.1 nm, but the object is moving faster than 452 in points between.  So 1 microns is between the bound of 1.1 nm and the 1.1 mm contraction needed if the whole km segment was moving at full speed.  If you want to compute the contraction more accurately than to the millimeter, cut the km into smaller segments and integrate your way through it.  Or put D a bit further back.

When does the middle start and stop moving?

All points start at the same time, and finish at the same time.  Not so with the caterpillar method.
I computed the acceleration rate of the middle above.  That acceleration commences immediately.

I would assume that you've taken the idea from a place where it doesn't start with the whole thing stationary and then suddenly have the back end moving at speed with the wrong length contraction on it.

It assumes the whole thing stationary, and all parts accelerating continuously forever.  I had to make modifications to get it to stop at the desired place.  It doesn't specify how far away the rear is from D.  It doesn't matter.  For the back to move suddenly at speed, it needs to be right next to D (the point at lower left in the picture).


I am running into all sorts of troubles with the wave method using lots of small waves.
Sure, the thing gets faster with smaller waves, but it also approaches the 55 day solution.
So I went back here in search of an error:

Code: [Select]

...
  while (speedK < speedK10)
  {
    speedC = speedK / 300000.;      // Compute speed as fraction of c
    factorD = sqrt(1 - speedC * speedC);   // Lorentz contraction
    tDmov = kmLH / speedK / SpD;    // Days to move 1 LH at that speed
    tDwav = 36500 * (1. - factorD); // Wave time: 36500 light day ship len
...


Oopsie:  That last line is supposed to compute wave time.  The 36500 converts 100 LY to light days, but it computes distance, not time.  So I'm calculating the time it takes light to move the contraction distance, not the time it takes the object (moving at speedK) to move that distance.

The whole wave thing is back on the floor.  I don't think it is competitive with the original 55 day method.

A simulation would make that clear

Mind you, I have yet to run any sort of simulation.  I've computed times and answers to some of your questions, but never using a simulation.  The 55.3 day time was a pretty trivial computation and did not involve iteration or simulation.  Just one Lorentz calculation.

Updated calculation for the single-wave method of moving the object, which involves a singularity.
I corrected the code in post 55 as far as I can tell, but nobody found the first bug, so nobody is probably going to find bugs with this new version.

Code: [Select]

// Time units in hours.
// Input speed in km/sec, but calculations take place as fraction of c
#include <stdio.h>
#include <math.h>
#define SoL 299792.46    // speed of light, km/sec
#define lenLH 876600.    // hours in a century, len of object in LH
int main(int ac, char **av)
{
  double factorD,        // lorentz factor (down)
         speedC,         // speed as fraction of c
         speedK,         // input speed in km/sec
         speedK10, step, // range limit km/sec
         tHmov, tHwav;   // time in hours
  sscanf(*++av, "%lf", &speedK);  // km/sec, but we convert to hrs
  sscanf(*++av, "%lf", &speedK10);
  step = (speedK10-speedK)/10.0;
  speedK10 += step/3;
  while (speedK < speedK10)
  {
    speedC = speedK / SoL;                // Compute speed as fraction of c
    factorD = sqrt(1 - speedC * speedC);  // Lorentz contraction
    tHmov = 1. / speedC;                  // Hours to move 1 LH at that speed
    tHwav = lenLH * (1. - factorD) / speedC; // Hours to move contraction len
    printf("S %.2f T %.9f W %.9f = %.9f \n", // Print in km/sec, days
           speedK, tHmov/24, tHwav/24, (tHmov+tHwav)/24);
    speedK += step;
  }
  return 0;
}
The sweet spot is still near 450 km/sec, same as the continuous acceleration optimal speed.
Interestingly, it takes half the time to move the object at that speed, and the other half of the time for the wave to move the 100 light years.  Here is one run:

Code: [Select]

> caterpillar 350 550
S 350.00 T 35.689578571 W 21.321007134 = 57.010585706
S 370.00 T 33.760412162 W 22.539351300 = 56.299763462
S 390.00 T 32.029108974 W 23.757695620 = 55.786804594
S 410.00 T 30.466713415 W 24.976040097 = 55.442753511
S 430.00 T 29.049656977 W 26.194384738 = 55.244041714
S 450.00 T 27.758561111 W 27.412729556 = 55.171290667
S 470.00 T 26.577345745 W 28.631074559 = 55.208420304
S 490.00 T 25.492556122 W 29.849419750 = 55.341975873
S 510.00 T 24.492848039 W 31.067765143 = 55.560613182
S 530.00 T 23.568589623 W 32.286110742 = 55.854700364
S 550.00 T 22.711550000 W 33.504456555 = 56.216006555Fastest time is at 452.83 km/sec, taking about 55 days and 4 hours, shorter by a smidge than the inertial method.
Perhaps this is because I used a more correct speed of light than the round 300000 figure, but slower light speed would seem to make things a bit slower, not faster.