Which units of measurement do I use in the Lorenz equation (Time Dilation)?
ScottH, Sat Apr 29 2017, 03:11PMI know the formula, and I looked up examples online, but all I get is the formula being explained.
Whenever I plug in the percentage of light, the speed in miles/sec, or miles/hr, the equation comes out radically different, even though the ratio of v2 and c2 is always the same.
One site used whole numbers for the percent (50% c was listed as 50^2 and c was listed as 100^2). If I use actual percentages like .5^2 the results change vastly.
In the equation t'=t sqt (1-v2/c2) which units of measurement does the actual equation use?
186,400 mps^2 and 671,040,000 mph^2 are very different values. If I use the percentage of c in mph or mps, even if v to c ratio is the same, when plugged into the equation, differs by several orders of magnitude.
Re: Which units of measurement do I use in the Lorenz equation (Time Dilation)?
Sulaiman, Sat Apr 29 2017, 03:22PM
provided that you use the same units for V and C you can use any units
Sulaiman, Sat Apr 29 2017, 03:22PM
provided that you use the same units for V and C you can use any units
Re: Which units of measurement do I use in the Lorenz equation (Time Dilation)?
klugesmith, Sat Apr 29 2017, 07:10PM
Scott, please post a numerical example of the formula, including result, that is giving you trouble. Did you square both v and c, before the division? Or do the division first, then square the quotient.
Many exercises like that will go more smoothly after you learn how to use a spreadsheet calculator program.
klugesmith, Sat Apr 29 2017, 07:10PM
Scott, please post a numerical example of the formula, including result, that is giving you trouble. Did you square both v and c, before the division? Or do the division first, then square the quotient.
Many exercises like that will go more smoothly after you learn how to use a spreadsheet calculator program.
Re: Which units of measurement do I use in the Lorenz equation (Time Dilation)?
Dr. Slack, Sun Apr 30 2017, 04:27AM
You should use consistent units, what they are doesn't matter. Though SI is best from a purely practical point of view.
In fact, one necessary condition (not sufficient) for a formula to be valid is that it doesn't matter whether whether the quantities are in units of metres, feet or peppercorns, it always comes out the same way, as long as you are consistent. What physics undergraduate hasn't sat down with friends and some muscle relaxant at some point during their course, and converted all physical constants into CFF, the hundredweight, furlong, fortnight system, just for the heck of it.
When you use numbers, use numbers, not percentages. It may be convenient to talk about 50%, but always express that as 0.50 in a formula.
Having said it doesn't matter whether you use inches or metres, please, stick to SI units throughout. That's the set of units used in the literature, and flipping back and forth between furlongs and metres is going to cause errors. Work in SI, think in SI (at least, for science, I still do DIY thinking 'I need a 4" nail 3mm in diameter'). Even educated people contribute to having spacecraft crash into Mars, or their planes run out of fuel, when they introduce unnecessary conversion between units.
The obligatory XKCD.
As a tip, when I'm writing code, or doing spreadsheets, all variables used internally are in SI. That means I can just implement the formula as written, and this consistency makes debugging easier. At the user interface, I may display or accept mm or km, or even mph, but the conversion to/from SI happens at the edge, before they get even a sniff of a calculation. Similarly if I'm scribbling on the back of an envelope, calculator in hand, I'll write an intermediate quantity down as '3mSI', or '4.7kSI', where I know that SI is whatever dimension is appropriate for the type of quantity, so areas in m^2 (not mm^2), speeds in m/s.
Dr. Slack, Sun Apr 30 2017, 04:27AM
You should use consistent units, what they are doesn't matter. Though SI is best from a purely practical point of view.
In fact, one necessary condition (not sufficient) for a formula to be valid is that it doesn't matter whether whether the quantities are in units of metres, feet or peppercorns, it always comes out the same way, as long as you are consistent. What physics undergraduate hasn't sat down with friends and some muscle relaxant at some point during their course, and converted all physical constants into CFF, the hundredweight, furlong, fortnight system, just for the heck of it.
When you use numbers, use numbers, not percentages. It may be convenient to talk about 50%, but always express that as 0.50 in a formula.
Having said it doesn't matter whether you use inches or metres, please, stick to SI units throughout. That's the set of units used in the literature, and flipping back and forth between furlongs and metres is going to cause errors. Work in SI, think in SI (at least, for science, I still do DIY thinking 'I need a 4" nail 3mm in diameter'). Even educated people contribute to having spacecraft crash into Mars, or their planes run out of fuel, when they introduce unnecessary conversion between units.
The obligatory XKCD.
As a tip, when I'm writing code, or doing spreadsheets, all variables used internally are in SI. That means I can just implement the formula as written, and this consistency makes debugging easier. At the user interface, I may display or accept mm or km, or even mph, but the conversion to/from SI happens at the edge, before they get even a sniff of a calculation. Similarly if I'm scribbling on the back of an envelope, calculator in hand, I'll write an intermediate quantity down as '3mSI', or '4.7kSI', where I know that SI is whatever dimension is appropriate for the type of quantity, so areas in m^2 (not mm^2), speeds in m/s.
Re: Which units of measurement do I use in the Lorenz equation (Time Dilation)?
ScottH, Sun Apr 30 2017, 10:34PM
Since the small v (550mph) is a tiny decimal of c (when using percentages in the equation) it gets smaller when squared. I found if both v and c are whole numbers, it works. I tried the equation with mph and m/s and got identical results. Thanks for the help.
If v was 1mph, the m/s conversion would be a decimal. In that case the equation would fail using mph or m/s. 1^2=1 and 0.44704^2 (m/s) would be 0.19984476. Meanwhile, c would be a huge number when squared, either way. Correct me if I'm wrong.
ScottH, Sun Apr 30 2017, 10:34PM
Since the small v (550mph) is a tiny decimal of c (when using percentages in the equation) it gets smaller when squared. I found if both v and c are whole numbers, it works. I tried the equation with mph and m/s and got identical results. Thanks for the help.
If v was 1mph, the m/s conversion would be a decimal. In that case the equation would fail using mph or m/s. 1^2=1 and 0.44704^2 (m/s) would be 0.19984476. Meanwhile, c would be a huge number when squared, either way. Correct me if I'm wrong.
Re: Which units of measurement do I use in the Lorenz equation (Time Dilation)?
Dr. Slack, Mon May 01 2017, 05:40AM
Arithmetic works whether your base 10 numbers have a fractional part of 0 (whole numbers), or a non-zero fractional part (fractional numbers).
You haven't done what we asked, that is to post the numbers you are actually using (all digits, for results as well as inputs). 'Doesn't work' is not a good problem description, 'these are the numbers I got, and these are what I expected' is a better problem description. I used excel, and Kcalc, and my casio fx-99 with these numbers and got those, is an even better problem description.
So, we have to guess. Let's assume your computation system of choice makes some attempt at handling fractional numbers, and you haven't mis-keyed. Let's also guess what you think might be wrong.
When a computer uses floating point representation of numbers, the precision gets limited. Using the ubiquitous IEE754 floating point double, 56 bits are allocated to the mantissa of the number, which is about 16 decimal digits. If you do plain vanilla programming (C, python) or spreadsheeting (excel, libreoffice), then you only get about 16 decimal digits. Handheld calculators will usually give you less precision. Desktop calculators on many operating systems will often give you more. 'Bignum' maths packages will give you arbitrary precision (limited only by system memory and processing time).
So, if you try to calculate 1-(v/c)^2, and v/c is 1e-6, then (v/c)^2 will be 1e-12, and 1-(v/c)^2 will be 0.9999999999990000. If on the other hand, v/c is more like 1e-9, then (v/c)^2 is just fine at 1e-18, but when you subtract it from 1, the result has too many 9s to fit into the precision, and its value will be rounded up to 1 (exactly 1). A common way to express mathematical precision is what's the smallest number you can subtract from 1, and get a result different to 1.
There are other calculations with gotchas like this, where although an input number (1e-9) looks to be well within the range of precision we're using, an intermediate calculation raises it to a power, adds it to a number of very different scale, and the precision gets trashed. (FWIW, that's why filter books don't contain filter recipes for Linear Phase Passband with Stopband Zeroes beyond 8th order. The frequency of the highest zero (only in the order of 10) is raised to the 2*orderth power when flipping the impedance polynomial, and the precision goes down the toilet).
The result for small numbers will be that the Lorentz transformation appears to give exactly the same result as the Galilean/Newtonian transformation, rather than 0.9999..., which is kinda what you'd expect for very low speeds.
Dr. Slack, Mon May 01 2017, 05:40AM
Arithmetic works whether your base 10 numbers have a fractional part of 0 (whole numbers), or a non-zero fractional part (fractional numbers).
You haven't done what we asked, that is to post the numbers you are actually using (all digits, for results as well as inputs). 'Doesn't work' is not a good problem description, 'these are the numbers I got, and these are what I expected' is a better problem description. I used excel, and Kcalc, and my casio fx-99 with these numbers and got those, is an even better problem description.
So, we have to guess. Let's assume your computation system of choice makes some attempt at handling fractional numbers, and you haven't mis-keyed. Let's also guess what you think might be wrong.
When a computer uses floating point representation of numbers, the precision gets limited. Using the ubiquitous IEE754 floating point double, 56 bits are allocated to the mantissa of the number, which is about 16 decimal digits. If you do plain vanilla programming (C, python) or spreadsheeting (excel, libreoffice), then you only get about 16 decimal digits. Handheld calculators will usually give you less precision. Desktop calculators on many operating systems will often give you more. 'Bignum' maths packages will give you arbitrary precision (limited only by system memory and processing time).
So, if you try to calculate 1-(v/c)^2, and v/c is 1e-6, then (v/c)^2 will be 1e-12, and 1-(v/c)^2 will be 0.9999999999990000. If on the other hand, v/c is more like 1e-9, then (v/c)^2 is just fine at 1e-18, but when you subtract it from 1, the result has too many 9s to fit into the precision, and its value will be rounded up to 1 (exactly 1). A common way to express mathematical precision is what's the smallest number you can subtract from 1, and get a result different to 1.
There are other calculations with gotchas like this, where although an input number (1e-9) looks to be well within the range of precision we're using, an intermediate calculation raises it to a power, adds it to a number of very different scale, and the precision gets trashed. (FWIW, that's why filter books don't contain filter recipes for Linear Phase Passband with Stopband Zeroes beyond 8th order. The frequency of the highest zero (only in the order of 10) is raised to the 2*orderth power when flipping the impedance polynomial, and the precision goes down the toilet).
The result for small numbers will be that the Lorentz transformation appears to give exactly the same result as the Galilean/Newtonian transformation, rather than 0.9999..., which is kinda what you'd expect for very low speeds.
Print this page