How to know the exact speed of a uniformly accelerated body according to
its position on a trajectory?

We simply set v/c=[1+c²/2ax]^-0.5

Note: the results are not at all those given by relativists with obviously
too high speeds, and which lead to a fundamental absurdity:
small speed segments are no longer locally compatible with small segments
of the same
instantaneous galileans speed.

R.H.

On Thursday, November 3, 2022 at 5:52:24 PM UTC-7, Richard Hachel wrote:
> How to know the exact speed of a uniformly accelerated body according to
> its position on a trajectory t = sqrt(x^2 + 2x/a)?

By simple grade school calculation, dx/dt for that trajectory is dx/dt = sqrt[1 - 1/(1+ax)^2].

Any other questions?

> ...which lead to a fundamental absurdity: small speed segments are
> no longer locally compatible with small segments of the same
> instantaneous speed.

Again, the absurdity you are describing is in your beliefs. That's why your beliefs imply 1=0, because the total elapsed time along a trajectory (according to your beliefs) does not equal the sum of the elapsed times along the small segments comprising the trajectory. We covered this before, and then you ran away. Remember?

Richard Hachel wrote:

> How to know the exact speed of a uniformly accelerated body according to
> its position on a trajectory?
>
> We simply set v/c=[1+c²/2ax]^-0.5

Hopeless.

PointedEars
--
A neutron walks into a bar and inquires how much a drink costs.
The bartender replies, "For you? No charge."

(from: WolframAlpha)

Le 04/11/2022 à 08:40, Thomas 'PointedEars' Lahn a écrit :
> Richard Hachel wrote:
>
>> How to know the exact speed of a uniformly accelerated body according to
>> its position on a trajectory?
>>
>> We simply set v/c=[1+c²/2ax]^-0.5
>
> Hopeless.
>
>
> PointedEars

Don't like my equation?

R.H.

Richard Hachel wrote:

>>> We simply set v/c=[1+c²/2ax]^-0.5
>>
>> Hopeless. PointedEars
>
> Don't like my equation?

never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5

Le 04/11/2022 à 13:39, Stefan Russo a écrit :
> Richard Hachel wrote:
>
>>>> We simply set v/c=[1+c²/2ax]^-0.5
>>>
>>> Hopeless. PointedEars
>>
>> Don't like my equation?
>
> never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5

If you want.

The equation will be no less exact.

v/c=[1+c²/2ax]^(-1/2)

R.H.

Richard Hachel wrote:

>>>>> We simply set v/c=[1+c²/2ax]^-0.5
>>>>
>>>> Hopeless. PointedEars
>>>
>>> Don't like my equation?
>>
>> never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5
>
> If you want.
> The equation will be no less exact. v/c=[1+c²/2ax]^(-1/2)

that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
exact.

Stefan Russo <ftfr@urstsoto.ee> wrote:

> Richard Hachel wrote:
>
> >>>>> We simply set v/c=[1+c?/2ax]^-0.5
> >>>>
> >>>> Hopeless. PointedEars
> >>>
> >>> Don't like my equation?
> >>
> >> never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5
> >
> > If you want.
> > The equation will be no less exact. v/c=[1+c?/2ax]^(-1/2)
>
> that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
> exact.

If you want 0.(3) to mean 0.333... , so 0.3 repeating, then it is exact.
0.333... is just another notation for 1/3,

Jan
(here we go again)

On Friday, November 4, 2022 at 6:04:35 AM UTC-7, Richard Hachel wrote:
> How to know the exact speed of a uniformly accelerated body according to
> its position on a trajectory t = sqrt(x^2 + 2x/a)?

By definition, for that trajectory we have dx/dt = sqrt[1 - 1/(1+ax)^2]. Any other questions?

> ...which lead to a fundamental absurdity: small speed segments are
> no longer locally compatible with small segments of the same
> instantaneous speed.

Again, the absurdity you are describing is in *your* beliefs. That's why your beliefs imply 1=0, because the total elapsed time along a trajectory (according to your beliefs) does not equal the sum of the elapsed times along the small segments comprising the trajectory. We covered this before, and then you ran away. Remember?

J. J. Lodder wrote:

>> >> never mix decimal point numbers in lemmas and theories. Use 1/2, not
>> >> 0.5
>> >
>> > If you want.
>> > The equation will be no less exact. v/c=[1+c?/2ax]^(-1/2)
>>
>> that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
>> exact.
>
> If you want 0.(3) to mean 0.333... , so 0.3 repeating, then it is exact.
> 0.333... is just another notation for 1/3,

you knownothing idiot, how can it be exact, when it NEVER converges to
1/3?? You never passed an Numerical_Analysis exam, you repeatedly
impertinent idiot.

Stefan Russo used his keyboard to write :
> Richard Hachel wrote:
>
>>>>>> We simply set v/c=[1+c²/2ax]^-0.5
>>>>>
>>>>> Hopeless. PointedEars
>>>>
>>>> Don't like my equation?
>>>
>>> never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5
>>
>> If you want.
>> The equation will be no less exact. v/c=[1+c²/2ax]^(-1/2)
>
> that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
> exact.

So, you are saying that a value can be exact in one base but inexact in
another?

FromTheRafters wrote:

>>>> never mix decimal point numbers in lemmas and theories. Use 1/2, not
>>>> 0.5
>>>
>>> If you want.
>>> The equation will be no less exact. v/c=[1+c²/2ax]^(-1/2)
>>
>> that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
>> exact.
>
> So, you are saying that a value can be exact in one base but inexact in
> another?

amazing the numbers of imbecile around here. Compare the decimal, for
instance, in a compiler, then you get a huge error.

On Friday, 4 November 2022 at 14:26:16 UTC+1, FromTheRafters wrote:
> Stefan Russo used his keyboard to write :
> > Richard Hachel wrote:
> >
> >>>>>> We simply set v/c=[1+c²/2ax]^-0.5
> >>>>>
> >>>>> Hopeless. PointedEars
> >>>>
> >>>> Don't like my equation?
> >>>
> >>> never mix decimal point numbers in lemmas and theories. Use 1/2, not 0.5
> >>
> >> If you want.
> >> The equation will be no less exact. v/c=[1+c²/2ax]^(-1/2)
> >
> > that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
> > exact.
> So, you are saying that a value can be exact in one base but inexact in
> another?

:) Why not? Why would any mathematical rule be more
true than Pythagorean theorem, shown false by your
idiot guru?

On Friday, November 4, 2022 at 9:17:54 AM UTC-4, J. J. Lodder wrote:
> Stefan Russo <ft...@urstsoto.ee> wrote:

> If you want 0.(3) to mean ...

DO NOT STROKE THE TROLLS.

You got got.

It happens that Stefan Russo formulated :
> FromTheRafters wrote:
>
>>>>> never mix decimal point numbers in lemmas and theories. Use 1/2, not
>>>>> 0.5
>>>>
>>>> If you want.
>>>> The equation will be no less exact. v/c=[1+c²/2ax]^(-1/2)
>>>
>>> that's the point, fractions ARE exact. 0.(3) is not exact, but 1/3 IS
>>> exact.
>>
>> So, you are saying that a value can be exact in one base but inexact in
>> another?
>
> amazing the numbers of imbecile around here.

ITYM number of imbeciles.

> Compare the decimal, for instance, in a compiler, then you get a huge error.

Who cares, the numbers' values aren't dependent upon compilers.

FromTheRafters wrote:

>>> So, you are saying that a value can be exact in one base but inexact
>>> in another?
>>
>> amazing the numbers of imbecile around here.
>
> ITYM number of imbeciles.
>
>> Compare the decimal, for instance, in a compiler, then you get a huge
>> error.
>
> Who cares, the numbers' values aren't dependent upon compilers.

the compilers are *physics* direct related to the hardware. Hence, the
*physics* is saying you are an idiot. This was the idea, given by the above
proof example.

rotchm wrote:

> On Friday, November 4, 2022 at 9:17:54 AM UTC-4, J. J. Lodder wrote:
>> Stefan Russo <ft...@urstsoto.ee> wrote:
>
>> If you want 0.(3) to mean ...
>
> DO NOT STROKE THE TROLLS. You got got.

keep you mouth shut, you stupid uneducated troll. You are the most
imbecilic troll this group here, if not on the entire usenet. Piss off,
troll. Get yourself an education, fool.

In sci.physics Stefan Russo <ftfr@urstsoto.ee> wrote:
> FromTheRafters wrote:
>
>>>> So, you are saying that a value can be exact in one base but inexact
>>>> in another?
>>>
>>> amazing the numbers of imbecile around here.
>>
>> ITYM number of imbeciles.
>>
>>> Compare the decimal, for instance, in a compiler, then you get a huge
>>> error.
>>
>> Who cares, the numbers' values aren't dependent upon compilers.
>
> the compilers are *physics* direct related to the hardware. Hence, the
> *physics* is saying you are an idiot. This was the idea, given by the above
> proof example.

Utter nonsense.

In a digital computer, anything other than an integer is generally an
approximation.

That means that while some numbers can be exact, i.e. 0.375 = 0.011,
most are not, i.e. 0.435 = 0.011011111....

Jim Pennino wrote:

> In sci.physics Stefan Russo <ftfr@urstsoto.ee> wrote:
>> FromTheRafters wrote:
>>
>>>>> So, you are saying that a value can be exact in one base but inexact
>>>>> in another?
>>>>
>>>> amazing the numbers of imbecile around here.
>>>
>>> ITYM number of imbeciles.
>>>
>>>> Compare the decimal, for instance, in a compiler, then you get a huge
>>>> error.
>>>
>>> Who cares, the numbers' values aren't dependent upon compilers.
>>
>> the compilers are *physics* direct related to the hardware. Hence, the
>> *physics* is saying you are an idiot. This was the idea, given by the
>> above proof example.
>
> Utter nonsense.
> In a digital computer, anything other than an integer is generally an
> approximation.
> That means that while some numbers can be exact, i.e. 0.375 = 0.011,
> most are not, i.e. 0.435 = 0.011011111....

that's exactly the point, fucking stupid. There are many levels of errors
in Numerical_Analysis. The limitation of the register in a computer is just
a one. But the proof is valid. The comparison is done on integers, not on
decimal numbers, the later being inexact. The former being exact. That why
1/3 IS exact, 0.(3) is not. What an idiot.

Stefan Russo wrote :
> Jim Pennino wrote:
>
>> In sci.physics Stefan Russo <ftfr@urstsoto.ee> wrote:
>>> FromTheRafters wrote:
>>>
>>>>>> So, you are saying that a value can be exact in one base but inexact
>>>>>> in another?
>>>>>
>>>>> amazing the numbers of imbecile around here.
>>>>
>>>> ITYM number of imbeciles.
>>>>
>>>>> Compare the decimal, for instance, in a compiler, then you get a huge
>>>>> error.
>>>>
>>>> Who cares, the numbers' values aren't dependent upon compilers.
>>>
>>> the compilers are *physics* direct related to the hardware. Hence, the
>>> *physics* is saying you are an idiot. This was the idea, given by the
>>> above proof example.
>>
>> Utter nonsense.
>> In a digital computer, anything other than an integer is generally an
>> approximation.
>> That means that while some numbers can be exact, i.e. 0.375 = 0.011,
>> most are not, i.e. 0.435 = 0.011011111....
>
> that's exactly the point, fucking stupid. There are many levels of errors
> in Numerical_Analysis. The limitation of the register in a computer is just
> a one. But the proof is valid. The comparison is done on integers, not on
> decimal numbers, the later being inexact. The former being exact. That why
> 1/3 IS exact, 0.(3) is not. What an idiot.

So, you're saying that integers are not decimal numbers now? Last I
knew there were ten symbols used in decimal.

FromTheRafters wrote:

>> that's exactly the point, fucking stupid. There are many levels of
>> errors in Numerical_Analysis. The limitation of the register in a
>> computer is just a one. But the proof is valid. The comparison is done
>> on integers, not on decimal numbers, the later being inexact. The
>> former being exact. That why 1/3 IS exact, 0.(3) is not. What an idiot.
>
> So, you're saying that integers are not decimal numbers now? Last I knew
> there were ten symbols used in decimal.

coma separated decimal, with an arbitrary number of decimals, are decimal
numbers. Float or double, etc. You are sticking you fingers in the shit,
instead of catching the point in context of the discussion. You are
useless.

Stefan Russo submitted this idea :
> FromTheRafters wrote:
>
>>> that's exactly the point, fucking stupid. There are many levels of
>>> errors in Numerical_Analysis. The limitation of the register in a
>>> computer is just a one. But the proof is valid. The comparison is done
>>> on integers, not on decimal numbers, the later being inexact. The
>>> former being exact. That why 1/3 IS exact, 0.(3) is not. What an idiot.
>>
>> So, you're saying that integers are not decimal numbers now? Last I knew
>> there were ten symbols used in decimal.
>
> coma separated decimal, with an arbitrary number of decimals

Shouldn't there be ten?

In sci.physics Stefan Russo <ftfr@urstsoto.ee> wrote:
> Jim Pennino wrote:
>
>> In sci.physics Stefan Russo <ftfr@urstsoto.ee> wrote:
>>> FromTheRafters wrote:
>>>
>>>>>> So, you are saying that a value can be exact in one base but inexact
>>>>>> in another?
>>>>>
>>>>> amazing the numbers of imbecile around here.
>>>>
>>>> ITYM number of imbeciles.
>>>>
>>>>> Compare the decimal, for instance, in a compiler, then you get a huge
>>>>> error.
>>>>
>>>> Who cares, the numbers' values aren't dependent upon compilers.
>>>
>>> the compilers are *physics* direct related to the hardware. Hence, the
>>> *physics* is saying you are an idiot. This was the idea, given by the
>>> above proof example.
>>
>> Utter nonsense.
>> In a digital computer, anything other than an integer is generally an
>> approximation.
>> That means that while some numbers can be exact, i.e. 0.375 = 0.011,
>> most are not, i.e. 0.435 = 0.011011111....
>
> that's exactly the point, fucking stupid. There are many levels of errors
> in Numerical_Analysis. The limitation of the register in a computer is just
> a one. But the proof is valid. The comparison is done on integers, not on
> decimal numbers, the later being inexact. The former being exact. That why
> 1/3 IS exact, 0.(3) is not. What an idiot.

The representation of the quantity of 1/3 is exact but the value of 1/3
is not no matter how you represent it.

BTW, does Numerical_Analysis (sic) have anything to do with numerical
analysis?

FromTheRafters wrote:

>>> So, you're saying that integers are not decimal numbers now? Last I
>>> knew there were ten symbols used in decimal.
>>
>> coma separated decimal, with an arbitrary number of decimals
>
> Shouldn't there be ten?

*I_fuck_your_ass*, fool!

https://www.mathsisfun.com/decimals.html
https://www.splashlearn.com/math-vocabulary/decimals/decimal

laughing at the dead of an innocent man. You cacapitalist cacamericans are
not humans.

Cackling Witch： Hillary Clinton Music Video
https://%62%69%74%63%68%75%74%65.com/%76%69%64%65%6f/uu66gbtIsnpF/

Le 04/11/2022 à 02:04, Stan Fultoni a écrit :

> Any other questions?

No.

The time To observable between 3 and 3.1 ly in the famous Tau Ceti
problem is not ΔTo=0.10295 but dTo= 0.1075

It is pure geometric evidence.

So your calculation is wrong.

And you correctly set v=Δx/ΔTo

But your "To" is wrong.

You then get speeds that are way too high for the whole course.

And my equation v/c=[1+c²/2ax]^(-1/2) seems absurd to you when it is the
correct one.

R.H.