Gravity Meets Particle Physics

Foundations of physics and/or philosophy of physics, and in particular, posts on unresolved or controversial issues

Re: Gravity Meets Particle Physics

Postby thray » Tue Jan 24, 2017 8:08 am

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?
thray
 
Posts: 143
Joined: Sun Feb 16, 2014 6:30 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Tue Jan 24, 2017 11:19 am

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?
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby Joy Christian » Tue Jan 24, 2017 11:46 am

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.

***
Joy Christian
Research Physicist
 
Posts: 2793
Joined: Wed Feb 05, 2014 4:49 am
Location: Oxford, United Kingdom

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Tue Jan 24, 2017 1:44 pm

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.
.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby thray » Wed Jan 25, 2017 5:54 am

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.
.



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. :)
thray
 
Posts: 143
Joined: Sun Feb 16, 2014 6:30 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Wed Jan 25, 2017 10:53 am

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. :)


I don't think we can ignore all quantum effects because there is just too much evidence to support it. But Joy's framework plus this theory takes any possible non-locality down to near the Planck length. That is a significant achievement in my book. We will probably never know if there is in fact non-locality at such a small scale.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby thray » Mon Jan 30, 2017 6:11 am

Jay posted on RW:

"Here, the vectors a and b represent “configurations of matter” represented as functions of the human invention that we call space coordinates. In the above, we are now defining v(alpha) == alpha_i v_i and v(beta) == beta_i v_i to express 'configuration of matter as a function of space' rather than 'application of space coordinates to configuration of matter.' Both are valid, but conceptually, the later makes it easier to not to lose sight of the fact that we are always talking about configurations of matter as functions of the human invention we call space".

Make 'configuration of matter as a function of space', " ... function of spacetime" and one recovers Einstein's " ... a function of the coordinates and time", which time dilation explains as point nodes of a field.

["The law of heat conduction is represented as a local relation (differential equation), which embraces all special cases of the conduction of heat. The temperature is here a simple example of the concept of field. This is a quantity (or a complex of quantities), which is a function of the co-ordinates and the time."]
thray
 
Posts: 143
Joined: Sun Feb 16, 2014 6:30 am

Re: Gravity Meets Particle Physics

Postby lkcl » Tue Jan 31, 2017 8:20 am

http://physics.nist.gov/cgi-bin/cuu/Value?bg

hi fredi (and joy),

i was very excited to read your paper, particularly having read andrew worsley's extremely comprehensive mass-analysis work. i am very familiar with the nist.gov list of physical constants, particularly their relative standard uncertainty, because in any "numerical-only" statistical inference work, the relative uncertainty is *directly* the level of accuracy to which explorations may be made.

for example: in working with andrew to narrow down some of the studies we were doing to below 1e-7 accuracy, there was, quite obviously, absolutely no point in using *anything* which contained a fundamental constant that had a relative uncertainty of 1e-8 (i actually set the cutoff at 2 orders of magnitude lower than that, to 1e-10, so that i could reasonably argue a statistical correlation discrepancy of 1 in a 1000, and i wasn't really very happy about that low a correlation... but you get the point i am sure).

all of that is merely background to put into context the following question:

i assume that G (as used in the paper) is the "Gravitational constant" (if i am wrong about that please ignore this question entirely!) how can you justify the conclusions that you're making (particularly the calculations in the Appendix) which are to such extreme levels of accuracy (requiring arbitrary floating-point precision), and *particularly* when you appear to be subtracting two very large numbers to find a very very small one (a problem which any computer scientist will tell you is asking for trouble, but you have dealt with it very well by going to arbitrary-precision floating-point... *except*....) that the Gravitational Constant's relative standard uncertainty is (according to the link above) 4.7 x 10^-5 and i don't see _any_ indication in the paper that that's taken into account.

now, i may just be ignorant of many of the conventions under which papers are written, such that there are assumptions which i am simply not aware of, but my computer science background and training is making me jump up and down here with a huuuuge red flag :)

looking at these "rules" http://web.uvic.ca/~jalexndr/192UncertRules.pdf i note that even the square/cube (etc.) stuff, you can only get away with dividing the relative uncertainty by two (or three, or whatever the power is).

in essence: is there something fundamental that i missed, here? have i misinterpreted something which makes the question moot?
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby lkcl » Tue Jan 31, 2017 8:53 am

oo, oo, sorry i have to write this down before i forget. it's late here so please ignore it for now, this is note-form:

https://en.wikipedia.org/wiki/Torsion_tensor tells me what torsion is: it's the degree (speed) of rotation about the direction of travel. from reading randell mill's work and also from freund's work in optics, and also joy's work on the EPR-bell proof, and also the work of ido kaminer, a body of evidence is stacking up to support the hypothesis that particles are mobius elliptically-polarised loops of light.

thus in that context, "torsion" would be the degree (speed) of rotation as the light goes round its mobius path. thus, if we may reasonably assume only ONE twist in the mobius topology for ALL particles (which may not necessarily be true, particularly for superconducting electrons), "torsion" would be LARGE when the compton radius is SMALL (confirmed by what you say "the torsion field falls of as 1/r^6") and such a relationship would be the same for all particles.

so. the forces that need to be balanced are the "amount of energy needed to actually do the twisting stuff" vs the "amount of energy involved in maintaining the EM field"...

apologies for putting this in note-form late at night, but i didn't want to forget it.
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Tue Jan 31, 2017 9:24 pm

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.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby lkcl » Wed Feb 01, 2017 12:51 am

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.


ah! yes. understood. which is a very valid assertion to work under as the basis for the paper. so, i can thus conclude that i did not make my question clear enough. by way of clarification, my concern is best illustrated with the following question:

in the use of mathematica did you try putting different values of G into each of the equations, at the upper and lower limits of the relative uncertainty, to see what happens, and how it affects the result?

if it doesn't have any effect then that's a very very important result all on its own, and the paper's conclusions are significantly strengthened and validated.

if it *does* have an effect then it *might* be possible to use the equation to draw some very very important insights, such as dramatic improvements on the relative uncertainty of the Gravitational Constant, G.

either way i feel that it's very important.... does that make sense, or is there something that i've missed?
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby lkcl » Wed Feb 01, 2017 1:10 am

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
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Wed Feb 01, 2017 1:49 am

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].

All the values for the constants are from the following sources which are also listed in the references.

[21] P. J. Mohr, D. B. Newell, and B. N. Taylor, CODATA Recommended Values of the Fundamental Physical Constants: 2014,
Zenodo (2015).
[22] K.A. Olive et al. (Particle Data Group), Chinese Physics C 38, 090001 (2014); see also 2015 update.

However, we have some updated calculations based on using a quantum field theory evaluation for the electrostatic energy instead of using a semi-classical approach. I will try to post some of it tomorrow.

Thank you for your interest,

Fred
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby lkcl » Wed Feb 01, 2017 7:03 am

fantastic! will take a look.
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Wed Feb 01, 2017 4:12 pm

lkcl wrote:fantastic! will take a look.

Probably the first thing to do is to see if you get r_t to match up to,



For which the updated formula is,



With Mathematica the constant values have to be padded out with a bunch of zero to get the arbitrary precision. I have Python also so if you post the code I can try it out also. This is good as I was looking for a different way to check Mathematica.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby lkcl » Thu Feb 02, 2017 7:56 pm

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
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Thu Feb 02, 2017 11:10 pm

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

The reduced Planck constant from CODATA 2014 is,

1.054 571 800 x 10^{-34} J s

That is what I am using so try it with that to see what you get. I believe alpha(fsc), "c" and "G" are what I am using. I will try Python tomorrow.
.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby lkcl » Fri Feb 03, 2017 3:08 am

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...
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

Re: Gravity Meets Particle Physics

Postby FrediFizzx » Sat Feb 04, 2017 1:14 am

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...

So we have for r_t out to 24 significant figures,

5.94387865349914219091711 (Yours)
5.94387865349914242261972 (Mine)

Which are the same out to 16 significant figures. I think that is about the limit for machine 64 bit precision. So there may be a difference between how Mathematica and Python does arbitrary precision beyond machine precision. Sorry, busy day today so didn't get a chance to try Python on my end yet.

Probably unless there is a way to access machine 128 bit calculations, the only thing that matters is that one needs to be consistent in how they do the arbitrary precision. What do you think?
.
FrediFizzx
Independent Physics Researcher
 
Posts: 2905
Joined: Tue Mar 19, 2013 7:12 pm
Location: N. California, USA

Re: Gravity Meets Particle Physics

Postby lkcl » Sun Feb 05, 2017 6:32 am

i worked for a company called Aspex Semi, they created a massively-parallel processor based around a string of 4096 2-bit processors. i had to implement arbitrary (8192-bit) floating-point numbers on it. also, python i know has an arbitrary-precision "Long Integer" type and they use something called Karatsuba Multiplication to perform arbitrary-length multiplication using *whatever underlying machine precision is available* whether it be 32 or 64-bit.

basically if you are GENUINELY using a library that provides arbitrary floating-point (or integer) precision "as advertised by that library or system" then the underlying MACHINE precision is UTTERLY IRRELEVANT. 2-bit, 4-bit, 8-bit, up to 256 bit if you have a DSP that can handle that, it's *all* irrelevant.

the only exceptions to this were back in 1993 when Intel f*****d up on the implementation of their FP co-processor for the Pentium I, and again they f*****d up more recently and failed to conform to IEEE standards by calculating and responding with COMPLETELY the wrong damn answer for multiply and divide. this however is extremely well-known, and there were quickly put in place work-arounds which the developers of ALL software became quickly aware of as people complained that newer hardware was giving completely and utterly the wrong answer.

in essence: if Mathematica is TRULY saying "we do arbitrary precision" then there is absolutely NO WAY that the underlying machine precision should have ANY effect or influence on the answer. period. if it DOES provide the wrong answer and you can provide proof of that, you should write a complaint in the form of a bugreport to the suppliers of Mathematica.

the python bigfloat library can literally be told (using the "with precision(NNNNN)" statement that you can see, there), to use ANY length precision. it gets a little slow and unwieldy but regardless of whether the python executable is being used on a 32-bit, 64-bit or even a 128-bit architecture is GENUINELY and completely irrelevant as to the output and answer. it WILL be the same.

this should also hold true for Mathematica as well... otherwise they're in a lot of trouble.

what i would suggest trying is to put the answer r_t *back* into the equation and to see if it produces the same lp. if it doesn't, then that would indicate that there's a bug in the "solve" function of Mathematica. that it's *assuming* that 16 s.f. is sufficient for most purposes. you *might* find that there's a parameter (or option) to tell the "solve" function to use a higher number of decimal places.

i went for a bit of overkill in the target_factor function and asked it to go to something insane like 50dp before giving up on the binary-search and going "yeah 50dp is close enough, let's return the answer now". i suspect that the solve function of mathematica is doing "yeahhh 17dp is close enough, let's return the answer now" instead.

that can be confirmed by punching that answer back in to calculate lp and subtracting it from the _original_ lp. if they're out at the 16th s.f. then we've found the problem.
lkcl
 
Posts: 65
Joined: Wed Sep 28, 2016 6:15 am

PreviousNext

Return to Sci.Physics.Foundations

Who is online

Users browsing this forum: No registered users and 31 guests

cron
CodeCogs - An Open Source Scientific Library