thray wrote:Spacetime controls the motion of matter. It is interactive.
Look -- if I could write a proof (and I'm not saying that I can) that Joy's framework is dead if Planck's constant does not go to zero, would you change your mind?
FrediFizzx wrote:thray wrote:Spacetime controls the motion of matter. It is interactive.
Look -- if I could write a proof (and I'm not saying that I can) that Joy's framework is dead if Planck's constant does not go to zero, would you change your mind?
I think you are taking Joy's framework too far. Why can't Planck's constant go to zero for Joy's framework but not for matter-energy?
Joy Christian wrote:FrediFizzx wrote:thray wrote:Spacetime controls the motion of matter. It is interactive.
Look -- if I could write a proof (and I'm not saying that I can) that Joy's framework is dead if Planck's constant does not go to zero, would you change your mind?
I think you are taking Joy's framework too far. Why can't Planck's constant go to zero for Joy's framework but not for matter-energy?
Tom, Fred,
The Planck constant need not go to zero in my framework either for spacetime or matter-energy. It can be absorbed into Planck time (which can of course be written in terms of hbar, G and c if we like), and the inverse of Planck time can then be taken to be the upper-bound on all possible frequencies, without compromising either of the relativity principles, which are necessary for maintaining the continuum Tom is talking about. See, for example, https://arxiv.org/abs/gr-qc/0610049. Thus we can have our cake and eat it too. There is no need to fight over Planck constant. Let us save our time-energy for fighting against all those fruitcakes who are opposing our ideas because of their own incompetence and stupidity.
***
FrediFizzx wrote:Joy Christian wrote:FrediFizzx wrote:thray wrote:Spacetime controls the motion of matter. It is interactive.
Look -- if I could write a proof (and I'm not saying that I can) that Joy's framework is dead if Planck's constant does not go to zero, would you change your mind?
I think you are taking Joy's framework too far. Why can't Planck's constant go to zero for Joy's framework but not for matter-energy?
Tom, Fred,
The Planck constant need not go to zero in my framework either for spacetime or matter-energy. It can be absorbed into Planck time (which can of course be written in terms of hbar, G and c if we like), and the inverse of Planck time can then be taken to be the upper-bound on all possible frequencies, without compromising either of the relativity principles, which are necessary for maintaining the continuum Tom is talking about. See, for example, https://arxiv.org/abs/gr-qc/0610049. Thus we can have our cake and eat it too. There is no need to fight over Planck constant. Let us save our time-energy for fighting against all those fruitcakes who are opposing our ideas because of their own incompetence and stupidity.
***
Yes, we have email discussed this in connection with the paper this thread is about and I agree. But I am still not sure where Tom is coming from about this.
In fact, Christoph Schiller was able to derive GR on the premise of an upper-bound on all possible frequencies which translates to an upper energy bound. Well, he used it as a maximum force but really the same thing.
.
thray wrote:
Well, guys, obviously I think that Einstein locality does not survive with two kinds of non-locality -- at classical and quantum scales. The notion of fermions as extended objects plays right into the Bell argument. I've got to go with " ... a function of the coordinates and time", which time dilation explains as point nodes and which Joy captures elegantly: " ... any linked object is a fermion." Excuse me now, as I shut up and calculate.
lkcl wrote:in essence: is there something fundamental that i missed, here? have i misinterpreted something which makes the question moot?
FrediFizzx wrote:lkcl wrote:in essence: is there something fundamental that i missed, here? have i misinterpreted something which makes the question moot?
Well of course what we have done is just an approximation as noted in the paper.
lkcl wrote:fredi, would you be willing to share the exact values for the constants that you used (or the sources from which you obtained them, such as NIST CODATA of which year) so that i can precisely confirm the calculations and do some experimentation myself with different values of G? i have a python arbitrary-precision floating point library so can use that.
sorry for being persistent, i am a software engineer, so from the well-known maxim "garbage in garbage out" i am trained (from bitter experience) to eliminate *all* possible sources of confusion, ambiguity and lack of clarity. so whilst my questions may seem "obvious", i can assure you that they most definitely are not [to an outsider with a software engineering background].
lkcl wrote:fantastic! will take a look.
lkcl@fizzy:~/src/quarks/fredifizzx$ python geometric_hierarchy.py
silver 2.4142135623730950488016887242096980785696718753769480731766784
1/fsc 137.03599913815450976591038346353016906084731063214207810651407
fsc 0.0072973525664000000000000000000000000000000000000000000000000016
mconst 1.2566370614359171895339856078726474123883302904344585237411884e-6
econst 8.8541878176203905963567355321089200835551595030757660882587037e-12
echarge 1.6021766208000000000000000000000000000000000000000000000000006e-19
G 6.6740800000000000000000000000000000000000000000000000000000000e-11
c 299792458.00000000000000000000000000000000000000000000000000000
planck 6.6260700399999999999999999999999999999999999999999999999999987e-34
reduced planck 1.0545718001391126922629619354404815545922399336102206671054682e-34
planck momentum 6.5250120816750455284963114635905098812718154479865987516601730
lp 1.6162283730808862021287476639962426842246894982002322870243828e-35
r_t 5.9438786538911823355262131542905913960971354300397206513312282e-34
work backwards to r_t 5.9438786534991421005904388454640615238911952600959551186301518e-34
reversed to lp 1.6162283729742846733983976727364706396340555823957261513823550e-35
lkcl wrote:http://hands.com/~lkcl/fredifizzx/
you'll need python2.7 and then to get python-bigfloat (which isn't available as a debian package so has to be obtained from source... ask me if you need help getting that set up). bigfloat is niiice - basically arbitrary precision, you can set it to anything you like (without zero-padding).
if you really really reaally don't want BigFloat, the fallback is to standard double precision (which is unlikely to be enough) which is... 64-bit i *think*...
anyway, here's the output, it differs at around the 8th decimal place probably because i have a different constant for one of h_bar (which i call h_pi in the constants.py source), G or alpha. most likely h_pi.
i have the constants.py module print everything out (re-using some code so ignore the other constants), it can get a bit annoying but is quite useful to double-check things as now.
ok edit: i added a function which is very very dumb it just uses binary search (and sometimes misses...) to find out what value should give a particular result, it looks for "1" so you have to write another function which subtracts the answer you're looking for, hence the weird "radius_target" function... anyway from the r_t you gave it worked out what lp _should_ have been rather than what it was calculated at... and we're looking at a 6.5957017625351e-11 discrepancy.... somewhere.
- Code: Select all
lkcl@fizzy:~/src/quarks/fredifizzx$ python geometric_hierarchy.py
silver 2.4142135623730950488016887242096980785696718753769480731766784
1/fsc 137.03599913815450976591038346353016906084731063214207810651407
fsc 0.0072973525664000000000000000000000000000000000000000000000000016
mconst 1.2566370614359171895339856078726474123883302904344585237411884e-6
econst 8.8541878176203905963567355321089200835551595030757660882587037e-12
echarge 1.6021766208000000000000000000000000000000000000000000000000006e-19
G 6.6740800000000000000000000000000000000000000000000000000000000e-11
c 299792458.00000000000000000000000000000000000000000000000000000
planck 6.6260700399999999999999999999999999999999999999999999999999987e-34
reduced planck 1.0545718001391126922629619354404815545922399336102206671054682e-34
planck momentum 6.5250120816750455284963114635905098812718154479865987516601730
lp 1.6162283730808862021287476639962426842246894982002322870243828e-35
r_t 5.9438786538911823355262131542905913960971354300397206513312282e-34
work backwards to r_t 5.9438786534991421005904388454640615238911952600959551186301518e-34
reversed to lp 1.6162283729742846733983976727364706396340555823957261513823550e-35
silver 2.4142135623730950488016887242096980785696718753769480731766784
1/fsc 137.03599913815450976591038346353016906084731063214207810651407
fsc 0.0072973525664000000000000000000000000000000000000000000000000016
mconst 1.2566370614359171895339856078726474123883302904344585237411884e-6
econst 8.8541878176203905963567355321089200835551595030757660882587037e-12
echarge 1.6021766208000000000000000000000000000000000000000000000000006e-19
G 6.6740800000000000000000000000000000000000000000000000000000000e-11
c 299792458.00000000000000000000000000000000000000000000000000000
planck 6.6260700399999999999999999999999999999999999999999999999999987e-34
reduced planck 1.0545718000000000000000000000000000000000000000000000000000001e-34
planck momentum 6.5250120808143056551084307926523992516299491112013859062369782
lp 1.6162283729742846979595557127906373378604482707569752879044620e-35
r_t 5.9438786534991421909171188068873185822097103847223969590914969e-34
work backwards to r_t 5.9438786534991421005904388454640615238911952600959551186301518e-34
reversed to lp 1.6162283729742846733983976709323885494275054157757999880496445e-35
relative discrepancy lp/rev: 1.5196588831477613240406002930663757187371967587145083604905404e-17
lkcl wrote:
- Code: Select all
silver 2.4142135623730950488016887242096980785696718753769480731766784
1/fsc 137.03599913815450976591038346353016906084731063214207810651407
fsc 0.0072973525664000000000000000000000000000000000000000000000000016
mconst 1.2566370614359171895339856078726474123883302904344585237411884e-6
econst 8.8541878176203905963567355321089200835551595030757660882587037e-12
echarge 1.6021766208000000000000000000000000000000000000000000000000006e-19
G 6.6740800000000000000000000000000000000000000000000000000000000e-11
c 299792458.00000000000000000000000000000000000000000000000000000
planck 6.6260700399999999999999999999999999999999999999999999999999987e-34
reduced planck 1.0545718000000000000000000000000000000000000000000000000000001e-34
planck momentum 6.5250120808143056551084307926523992516299491112013859062369782
lp 1.6162283729742846979595557127906373378604482707569752879044620e-35
r_t 5.9438786534991421909171188068873185822097103847223969590914969e-34
work backwards to r_t 5.9438786534991421005904388454640615238911952600959551186301518e-34
reversed to lp 1.6162283729742846733983976709323885494275054157757999880496445e-35
relative discrepancy lp/rev: 1.5196588831477613240406002930663757187371967587145083604905404e-17
bleuch!! h/2pi is a fixed constant.... which *loses accuracy* thanks to CODATA 2014 storing it to only the relative uncertainty of h instead of using the infinite number of dp of pi to *calculate* h/2pi and provide it to a very-very-very-large number of dp. bleuch!
... now you see why i fuss about these things as a software engineer?
so yes, we're down to 1.52e-17, now, which i am a bit happier with.
ok. so at line 33 you'll see i added on a way to multiply G up to its upper limit. thanks to the target_reverse function i was able to get a relative discrepancy for lp (given) and lp (calculated using G+1.47e-5 relative extra) of: 2.35e-5. maybe i should look up how to calculate absolute uncertainty from relative, again, hmm...
Return to Sci.Physics.Foundations
Users browsing this forum: No registered users and 75 guests