# 240 volts

| Michael A. Terrell wrote: |> VWWall wrote:
|>> |>>> Back when I was in junior high school, without the aid of any calculator
|>>> or computer, I pondered the meaning of the frequency 3.58 MHz as it related |>>> to the TV broadcast standards (which at the time I "knew" to be 15,750 Hz |>>> horizontal and 60 Hz vertical. But I found a book in the school library |>>> that gave the value as 3.579545 MHz. Just that much information allowed |>>> me to "reverse engineer" this number to determine it came from 5 MHz times |>>> 63 divided by 88, and really had "454545" repeated (3579545.45[45..] Hz), |>>> and that the horizontal frequency was really 15734.265734[265734..] Hz, |>>> and that the vertical frequency was really 59.940059[940059..] Hz. All |>>> that semantic understanding came out of just getting 4 more digits of |>>> precision. Over a decade later I found that the FCC broadcast rules |>>> actully defined the value the same way, as 5 MHz times 63/88. It is still |>>> identifiable as 3.58 MHz. But if I want to compare it to something else |>>> semantically, I need a much more precise value. Would you recognize it |>>> as the NTSC color subcarrier frequency if I called it 3.6 MHz? or 4 MHz? |>> If you do a bit more reading, you'll find it's never exactly 5,000,000 * |>> 63/88, but is whatever the phase lock loop in the receiver set it to. |>> This is determined by the color burst sent by the transmitter, which is |>> nominally derived from a 3.58 MHz xtal. It's still NTSC, (never the |>> same color), in spite of the inaccuracy of the frequency. |> |> |> Every TV broadcast sync generator I've used had a 4X burst crystal. |> (14.31818 MHz for the US NTSC system.) | | According to Phil, that should be 14.31818182 MHz. :-)
14.31818181818181818181818181818181818181818181818181818181818181818181818...
or 5000000*63/22
| You're correct. For practical circuits, the higher frequency xtal has a | better form factor and can be more easily "pulled" to exact frequency. | I believe it's easier to get an AT, (flat temperature), cut at that | frequency.
That and easier to derive quadrature phases.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
| snipped-for-privacy@ipal.net wrote: | |> Back when I was in junior high school, without the aid of any calculator |> or computer, I pondered the meaning of the frequency 3.58 MHz as it related |> to the TV broadcast standards (which at the time I "knew" to be 15,750 Hz |> horizontal and 60 Hz vertical. But I found a book in the school library |> that gave the value as 3.579545 MHz. Just that much information allowed |> me to "reverse engineer" this number to determine it came from 5 MHz times |> 63 divided by 88, and really had "454545" repeated (3579545.45[45..] Hz), |> and that the horizontal frequency was really 15734.265734[265734..] Hz, |> and that the vertical frequency was really 59.940059[940059..] Hz. All |> that semantic understanding came out of just getting 4 more digits of |> precision. Over a decade later I found that the FCC broadcast rules |> actully defined the value the same way, as 5 MHz times 63/88. It is still |> identifiable as 3.58 MHz. But if I want to compare it to something else |> semantically, I need a much more precise value. Would you recognize it |> as the NTSC color subcarrier frequency if I called it 3.6 MHz? or 4 MHz? | | If you do a bit more reading, you'll find it's never exactly 5,000,000 * | 63/88, but is whatever the phase lock loop in the receiver set it to.
What the carrier frequency _actually_ is and what the _definition_ is are two different things. The FCC allows (or at least used to) a tolerance of plus/minus 10 Hz. Broadcasters generally get a LOT closer than that with atomic clock oscillators. They are as pedantic as I am, it seems :) But there are good reasons, too.
| This is determined by the color burst sent by the transmitter, which is | nominally derived from a 3.58 MHz xtal. It's still NTSC, (never the | same color), in spite of the inaccuracy of the frequency.
The receiver locks to the received signal subcarrier frequency. Using a crystal to do that keeps it nice and stable during the lock. But even if the crystal is tuned off a little, it will still lock and still be stable. So the accuracy of the receiver subcarrier oscillator is the same as the transmitter. And in the case of network affiliate broadcasters, that is likely locked on to the network much of the day, and certainly during network air time.
This will be moot for full power broadcasters in less than a year.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
snipped-for-privacy@ipal.net wrote:

Many frequency standards are now derived from GPS signals. Of course these are synchronized to atomic standards. It's easier than having your own atomic clock.
I once saw a proposal to determine the listeners to each TV channel by using a mobile van with a narrow band receiver tuned to the horizontal frequency radiated by each active TV receiver. By comparing the frequency/phase and the arrival azimuth of the intercepted signal, one could determine to which station each set was tuned. It got a poor reception, (sic), from the broadcasters who wanted to know more demographics than just the time/location of the receivers.

P.S.: Have you got your FCC Registration Number? It's needed for license renewals and general access to the FCC site.
--
Virg Wall

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
| I once saw a proposal to determine the listeners to each TV channel by | using a mobile van with a narrow band receiver tuned to the horizontal | frequency radiated by each active TV receiver. By comparing the | frequency/phase and the arrival azimuth of the intercepted signal, one | could determine to which station each set was tuned. It got a poor | reception, (sic), from the broadcasters who wanted to know more | demographics than just the time/location of the receivers.
I thought it would be easier to do the color subcarrier. But maybe this proposal was before color?
|> This will be moot for full power broadcasters in less than a year. | | P.S.: Have you got your FCC Registration Number? It's needed for | license renewals and general access to the FCC site.
Yes, I have an FRN. It has 10 digits of precision :-)
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
snipped-for-privacy@ipal.net wrote:

The point is the horizontal deflection is applied at a high level to relatively unshielded coils on the CRT. Although this falls off rather rapidly, it's still large enough for a narrow band receiver to detect at a distance.

I got cheated! Mine has two leading zeros; it has only 8 digits of precision. :-(
--
Virg Wall, K6EVE

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
| snipped-for-privacy@ipal.net wrote:
I counted the leading 0 digits because of the nature of a finite format index number that it is. Just because the assignments are sequential does not mean any are more or less precise than any other. But if you really feel that the leading 0 digits do not count toward precision, then I guess you can feel good about having gotten 8 digits of precision as under that concept, I got only 7.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

Funny, I thought the usual system was to pick up stray radiation from the IF oscillator. You know exactly what channel the set's tuned to that way
--
Stuart Winsor

From is valid but subject to change without notice if it gets spammed.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Stuart wrote:

I assume you mean the local oscillator. This can vary considerably from set to set, depending on where the actual IF is, requiring a relatively wide-band receiver. It's radiation is also required to be below specified limits to comply with FCC regulations.
The horizontal frequency is within a few cycles. Off-the-air "samples" of all the local TV transmitters can be used to compare. Also, a loop antenna will give a precise azimuth as well as considerable gain.
It might be useful to do some calculations using both methods, but stray TV set radiation numbers is probably hard to come by!
--
Virg Wall

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
| Stuart wrote:
|> |>> I once saw a proposal to determine the listeners to each TV channel by |>> using a mobile van with a narrow band receiver tuned to the horizontal |>> frequency radiated by each active TV receiver. By comparing the |>> frequency/phase and the arrival azimuth of the intercepted signal, one |>> could determine to which station each set was tuned. It got a poor |>> reception, (sic), from the broadcasters who wanted to know more |>> demographics than just the time/location of the receivers. |> |> Funny, I thought the usual system was to pick up stray radiation from the |> IF oscillator. You know exactly what channel the set's tuned to that way | | I assume you mean the local oscillator. This can vary considerably from | set to set, depending on where the actual IF is, requiring a relatively | wide-band receiver. It's radiation is also required to be below | specified limits to comply with FCC regulations.
Virtually all TVs were made with the same IF frequency. The FCC channel allocations were made with this in mind to avoid channels bleeding in as images on the other side of the LO.
| The horizontal frequency is within a few cycles. Off-the-air "samples" | of all the local TV transmitters can be used to compare. Also, a loop | antenna will give a precise azimuth as well as considerable gain.
Early in TV broadcasting, that might have worked, with each station being a little different in frequency. Now days, they are all locked tight to very good references.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
snipped-for-privacy@ipal.net wrote:

Yes, most sets use the same IF, but the actual frequency varies depending on how the set was aligned. If you've ever done TV service, you would see this. Since most present day sets use "intermod" sound, at 4.5Mhz, they can get away with this variation. This may be only a KHz or so, but it is real. You can identify the channel by the LO frequency, but you would need a relatively wide band receiver to accommodate the variations.

The fact that the frequencies are so close allows for a receiver with a very low noise bandwidth. The received signals are compared in phase as well as frequency to the "sample" received frequencies for each transmitter. A simple PLL can do this easily with the off-the-air "samples" as reference.
Maybe a Scott-Tee transformer would help! :-) (Actually, one might be used in the rotating antenna servo!) ;-)
--
Virg Wall

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
VWWall wrote:

I lived way out of the city limits a few years ago. The nearest house was a half mile away, and the owner would go to sleep with his TV on. the horizontal sweep drifted all over the place, and would wipe out my WWVB 60 KHz receiver. I had about two volts out of the loop antenna for WWVB, and over 8 volts from his TV, when viewed on my Tektronix scope. To add insult to injury, he was almost in a direct line with the transmitter in Colorado. (less than 5 degrees.)
--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

Oops, yes, you're right I was thinking
136. * sqrt(3) = 236.

120 * sqrt(3) = 210 120. * sqrt(3) = 209.
Point is, no matter how well you know the precision of one factor (sqrt(3)), if the other factor is only known to two or three significant digits, any product of the two can really only be known to two or three significant digits.

And if you only measure the initial 120 volts to the nearest ten volts, I agree. And that's pretty much my point. If you measure it to the nearest volt, (120. with the decimal point), then you can tell the difference.
<snip>

But with all your 'refinements', you're still starting from '5 MHz'. And just how accurate is the 5 MHz crystal considering the ambient temperature of the crystal is pretty much uncontrolled? At the broadcast studio, I'm sure their's are more precise. But the one in the TV set? If I'm not mistaken, that's why they use a PLL circuit.
You've assumed the '5 MHz' is exact, and therefore the 3.58 MHz is wrong.
Why couldn't it have been.....
5,000,634.92063 Hz * 63/88 = 3,580,000 Hz
(see, you're not the only one with an arbitrary precision calculator :-)
You're not trying to blow smoke and claim that the color burst frequency in an old TV is derived from multiplying 5,000,000.000 Hz times exactly 63/88 ??? Like to see the analog circuit that produces such exact multiplication. Sure wasn't in my old RCA set that I tore into a couple of times :-)

Yes I do quite a bit of programming thank you very much. Since most floating point numbers are already an inexact representation of 'real' numbers, they can be inherently flawed (hint, use 'doubles', there are more significant digits). Yes, you point out correctly (as anyone who has studied "Numerical Methods" can tell you) that when adding floating point values of widely different decades, the exact order of operations can have an effect on the exact outcome. In general, the more floating operations you go through, the fewer and fewer significant digits you can rely on.
That's why there are BCD and 'arbitrary precision' techniques.
By the way, if you use something other than base 10 for your fractional representation (or base 2 as used in IEEE-754 floating point format), you can represent some numbers more precisely.

But again, you can take as much precision of a mathematically defined value as you want. When you multiply / divide it into something that is measured to only two significant digits and try to claim the result is 207.8461 and is 'more accurate' than 208, you've wasted a lot of everyone's time.
To claim.... 120 * sqrt(3) = 207.8461
Is pure nonsense. You cannot possibly improve upon the accuracy of the original measurement. Yet that is what this sort of statement is claiming. "I measured the voltage to the nearest ten volts (120), and thus I know the accuracy of the line-line wye voltage to the nearest ten-thousandth of a volt (207.8461)."
Now, if you had said....
120 * sqrt(3) = 207.8461 plus or minus 17.3205
I would agree with that. And everyone would see that the 'answer' is not that well known (could range from about 190 to 220). But look at what all your 'accuracy' has accomplished.
I see this a lot when doing unit conversions as well. If you go to a definitive source for the conversion from one set of units to another, you'll find that some conversion factors are given as *exact*, while others are approximations to some number of significant digits. For example, an inch is defined by NIST as *exactly* 25.4 mm. So a foot is *exactly* 304.8 mm or 0.3048 m. But 1 meter is only *approximately 3.28083989501 feet.
daestrom
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
wrote:
| Point is, no matter how well you know the precision of one factor (sqrt(3)), | if the other factor is only known to two or three significant digits, any | product of the two can really only be known to two or three significant | digits.
That is true. Just be careful not to add to the error of the lack of precision by prematurely reducing the precision of the well defined constant. Otherwise the product ends up with more error than either of the multiplicands.
120 * 1.7320508075688772935274463415058723669428052538103806280558 = 208
Of course, this example is extreme precision. This is not a boundary case. If it were a boundary case, a precise value of the square root of three enough to avoid the boundary issue, would be wise to use. I typically use more precision than just 1.732. If I have to type in this value by hand, I use 1.732050807568877 because I have that much memorized, unless I feel lazy in which case I just go with 1.7320508 :-)
|> Back when I was in junior high school, without the aid of any calculator |> or computer, I pondered the meaning of the frequency 3.58 MHz as it |> related |> to the TV broadcast standards (which at the time I "knew" to be 15,750 Hz |> horizontal and 60 Hz vertical. But I found a book in the school library |> that gave the value as 3.579545 MHz. Just that much information allowed |> me to "reverse engineer" this number to determine it came from 5 MHz times |> 63 divided by 88, and really had "454545" repeated (3579545.45[45..] Hz), |> and that the horizontal frequency was really 15734.265734[265734..] Hz, |> and that the vertical frequency was really 59.940059[940059..] Hz. | | But with all your 'refinements', you're still starting from '5 MHz'. And | just how accurate is the 5 MHz crystal considering the ambient temperature | of the crystal is pretty much uncontrolled? At the broadcast studio, I'm | sure their's are more precise. But the one in the TV set? If I'm not | mistaken, that's why they use a PLL circuit. | | You've assumed the '5 MHz' is exact, and therefore the 3.58 MHz is wrong. | | Why couldn't it have been..... | | 5,000,634.92063 Hz * 63/88 = 3,580,000 Hz
Or 5,047,213.114754 Hz * 61/86 = 3,580,000 Hz
The thing is, none of these had any particular meaning. But once I had that value of 3,579,545 Hz, the resultant 4,999,999.365 became a lot more relevant. Then it became clear that the value most likely came from the exact 5 MHz reference. For a while, though, I called it 315 MHz / 88.
| (see, you're not the only one with an arbitrary precision calculator :-)
There are plenty around. Knowing how to use them correctly can elude some.
| You're not trying to blow smoke and claim that the color burst frequency in | an old TV is derived from multiplying 5,000,000.000 Hz times exactly 63/88 | ??? Like to see the analog circuit that produces such exact multiplication. | Sure wasn't in my old RCA set that I tore into a couple of times :-)
No. The _definition_ is. It might be more practical, if you wanted to produce it from a WWV locked oscillator, to use 15 MHz * 21 / 88. A cheap receiver only needs to be close enough to get a lock and stay stable enough to keep the color reasonably consistent. A broadcaster didn't even need to, as getting a crystal in an oven to stay within 10 Hz of 14318181.818 Hz would good enough. It could be tested or calibrated by doing a phase comparison at 315 MHz between the the 21st harmonic of 15 MHz and the 22nd harmonic of 14.318181818 MHz.
|> Do you do any computer programming? If so, do you just add up a long |> list of floating point values in the order given, or do you sort them |> so you accumulate the sum by adding the lowest values first? | | Yes I do quite a bit of programming thank you very much. Since most | floating point numbers are already an inexact representation of 'real' | numbers, they can be inherently flawed (hint, use 'doubles', there are more | significant digits). Yes, you point out correctly (as anyone who has | studied "Numerical Methods" can tell you) that when adding floating point | values of widely different decades, the exact order of operations can have | an effect on the exact outcome. In general, the more floating operations | you go through, the fewer and fewer significant digits you can rely on. | | That's why there are BCD and 'arbitrary precision' techniques. | | By the way, if you use something other than base 10 for your fractional | representation (or base 2 as used in IEEE-754 floating point format), you | can represent some numbers more precisely.
Indeed. I have used base 16 for that, as well as scaling numbers to get all the digits I want to have as integers.
And I use the GMP package in my Mandebrot fractal program to take my zooms to extreme levels.
| |> |> How many digits do you want for the square root of three expressed as a |> ratio of two integers with a precision in digits equal to or greater than |> the SUM of the digits in the numerating AND denominator? |> |> Anyone can just say: |> 17320508075688772935274463415058723669428052538103806280558069794519330169088 |> divided by: |> 10000000000000000000000000000000000000000000000000000000000000000000000000000 |> but that is only 77 digits of precision for 154 digits expressed. |> |> But if I give you: |> 81637354237035839875406774706916734691676867556988461166524491402570869800626 |> divided by |> 47133348444681477624409145446409554706879415291771528507046516487702731598175 |> then you can be sure you have 154 digits of precision. Try it. |> |> Remember 355/113 for the value of PI? I have way better fractions. You |> won't _need_ them, of course. But I have them. |> | | But again, you can take as much precision of a mathematically defined value | as you want. When you multiply / divide it into something that is measured | to only two significant digits and try to claim the result is 207.8461 and | is 'more accurate' than 208, you've wasted a lot of everyone's time.
I use 208 or 207.846 or 207.84609690826527522329356 for different purposes.
| To claim.... | 120 * sqrt(3) = 207.8461 | | Is pure nonsense. You cannot possibly improve upon the accuracy of the | original measurement. Yet that is what this sort of statement is claiming. | "I measured the voltage to the nearest ten volts (120), and thus I know the | accuracy of the line-line wye voltage to the nearest ten-thousandth of a | volt (207.8461)."
I disagree ... depending on the context of use. If the multiplication is done to an actually measured value, I'll keep the product at the same level of precision as the measured value (as scaled by the multiplication).
123 * sqrt(3) = 213
123.1 * sqrt(3) = 213.2
| Now, if you had said.... | | 120 * sqrt(3) = 207.8461 plus or minus 17.3205 | | I would agree with that. And everyone would see that the 'answer' is not | that well known (could range from about 190 to 220). But look at what all | your 'accuracy' has accomplished.
Plus or minus 10 in the original measurement, if that is a measurement by a voltmeter, is not that accurate at all. That voltmeter sucks.
OTOH, that could well be the allowable range of the voltage provided by a utility or derived from a generator. So:
120 +/- 10 * sqrt(3) = 207.8460969 +/- 17.32050808
But at that point, given in definition accuracy, precision in the final expression really is pointless. So:
120 +/- 10 * sqrt(3) = 208 +/- 17
Still, in cases where I would have to calculate the values, I would use a lot of digits of sqrt(3), well more than the measured L-N voltage, then round the L-L voltage.
| I see this a lot when doing unit conversions as well. If you go to a | definitive source for the conversion from one set of units to another, | you'll find that some conversion factors are given as *exact*, while others | are approximations to some number of significant digits. For example, an | inch is defined by NIST as *exactly* 25.4 mm. So a foot is *exactly* 304.8 | mm or 0.3048 m. But 1 meter is only *approximately 3.28083989501 feet.
The numeric base system we use and/or the units of measure we use do have an impact. It is basically a quantization effect. Given the same level of meter accuracy, but instead, doing the work in base 2 instead of base 10, changes things "a round a bit".
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
daestrom wrote:

Mass is the only "constant" that is not defined by a physical entity. It is defined by the standard kilogram, kept in Paris.
This is why 1 cubic centimeter does not equal 1 milliliter, even though NIST tried to legislate it to be, (approximately), true.
A handy reference: (And fun to read!)
http://www.unc.edu/~rowlett/units/index.html
It's time for a pfiff!
--
Virg Wall

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

Au contraire...
A milliliter, derived from liter is a unit of volume. This is a derived unit of measure from the more basic unit of measure length. It is not NIST legislation that defines 1 mL = 1cc, it comes from the very definition of a litre.
There are only a few 'basic units'. Length, time, mass, current, mole, temperature and luminosity. All the others, including many in the metric system are derived from these (e.g. Newtons are derived from length, time and mass)
daestrom
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
daestrom wrote:

The liter was originally defined to be the volume occupied by a kilogram of water, and the gram as the mass of a cubic centimeter of water. This would make the liter equal to exactly one cubic decimeter, that is, to the volume of a cube 0.1 meter (or 10 centimeters) on a side.
Unfortunately, the physical objects constructed to represent the meter and kilogram disagreed slightly. As measured by the standard meter and standard kilogram, the standard liter turned out to be about 1.000 028 cubic decimeters. This discrepancy plagued the metric system for a long time. In 1901 an international congress accepted the discrepancy and formally defined the liter to be exactly 1.000 028 dm.
The liter has since, (1964), been re-defined to be exactly 1.000 000 dm.

And the only one not defined by "natural" constants is mass....
--
Virg Wall

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
snipped-for-privacy@ipal.net writes:

But then the lady a mile up the road flips on a nightlight, causing the MV voltage to sag a tiny bit, and your 120.00000000 volts is no longer that, so the zillion digit precision calculation of the line-line voltage is no longer accurate...

As I understood it, the 3.579545 figure was deliberately chosen so to NOT be a multiple of either the V or H frequency, or the audio offset frequency so that the color signal would not interfere with/be interfered with any of the other signals, and 3.579545 was THE definition. Certainly there were tons of dirt-cheap crystals of that frequency (and 14.31818 MHz), no reason to divide down 5 MHz frequency. That number of digits made perfect sense in the definition since crystals could be cut to VERY precise frequencies (and in receivers were PLL'ed to the transmitter) Also, there was a common chip that divided the colorburst frequency down to 60 Hz (intended to use a common cheap crystal as a time base for digital clocks). In order to work correctly the colorburst xtal had to really be 3.579540 MHz. (it divided by 59659)

As the definition was to a very high standard that was also met in real life, 3.579545 MHz is the correct term, as a TV whose color frequency was running at 3.6 MHz or 4 MHz (or even 3.58 MHz) would not display colors correctly at all!

I do computer programming and would add the numbers in the order given. If the required precision of the result exceeded that of the computer's "float" precision, I'd use "double" (or higher) and add in the order given.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
writes:

Well, the point that 'phil-news' was trying to make is that sometimes just adding in the order given can cause some problems. If the first has a value that is so much larger than the second that the second has to be shifted 24 bits to the right before adding, then its value is lost (in 'single precision' IEEE-754 format, 24 bits are used for the mantissa). So if you have a lot of 'small' numbers to add to a 'big' number, it is best to add all the 'small' numbers together first so that you have a 'medium' number to add to the 'big' number.
Similar problems occur with simple matrix solution methods. Re-arranging the rows such that relatively 'large' values are along the major diagonal minimize the errors. Of course you have to keep track of this so that you can 'un-re-arrange' the solution vector when done :-)
daestrom
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

I know. My point was that if the order of addition affected the answer enough to affect the outcome (at the needed precision), you simply need more bits of precision in the variables. Like going from 24 bit "float" to "double". Otherwise there will be some combination of inputs that will bite you hard with the wrong answer.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
On Sun, 2 Mar 2008 04:21:29 +0000 (UTC) Michael Moroney
|
|> |>> |>>>Do you do any computer programming? If so, do you just add up a long |>>>list of floating point values in the order given, or do you sort them |>>>so you accumulate the sum by adding the lowest values first? |>> |>> I do computer programming and would add the numbers in the order given. |>> If the required precision of the result exceeded that of the computer's |>> "float" precision, I'd use "double" (or higher) and add in the order |>> given. |>> | |>Well, the point that 'phil-news' was trying to make is that sometimes just |>adding in the order given can cause some problems. If the first has a value |>that is so much larger than the second that the second has to be shifted 24 |>bits to the right before adding, then its value is lost (in 'single |>precision' IEEE-754 format, 24 bits are used for the mantissa). | | I know. My point was that if the order of addition affected the answer | enough to affect the outcome (at the needed precision), you simply need | more bits of precision in the variables. Like going from 24 bit "float" | to "double". Otherwise there will be some combination of inputs that will | bite you hard with the wrong answer.
Given that you have a finite precision to work with, sorting the values from smallest to largest is the most practical way. If infinite precision does happen to be available, then you can use that.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |