I can't see the logic in that !
, for temperature the base would have to be Kelvin.F/C = ((C/F + 40) * K) - 40
Lou Pellegrini wrote:
Richard's and Junilu's posts about reciprocals are more about units than the mathematical definition of reciprocals, which produced correct results in one direction only.
(Value / fromMks) = units, then (units * toMks) yields the correct results in both directions.
Lou Pellegrini wrote:But I think for Winston's suggestion to work,
, for temperature the base would have to be Kelvin.F/C = ((C/F + 40) * K) - 40
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Not sure what you mean by that first part. Dimensional analysis aside, reciprocals are a pretty straightforward concept. Unless you tried to use multiplication both ways (thus yielding a correct result in only one direction), you should get correct results both ways using the same number: multiply by it one way, divide by it going the other way.
Lou Pellegrini wrote:Hi Junilu,
That's exactly what I meant - trying to use reciprocal multiplication in both directions.
Using units allowed for the input to decide when to do the conversion and provided correct results in both directions with a single process.
Less code = less stink!
Lou Pellegrini wrote:That's exactly what I meant - trying to use reciprocal multiplication in both directions.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:as you've seen above °K→°C is not a multiplication, it's an offset
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Kelvin is a system or "scale". Its unit (1 "degree") is the same as Centigrade, but its start point is different.
Junilu Lacar wrote:Actually, assuming the wikipedia entry is accurate, the Kelvin IS the unit of measure.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Maybe you could show your proposed XML for defining the factors you'd use for converting Fahrenheit to Celcius and vice versa. What about the XML for converting Kelvin, Rankine, and all the other temperature scales listed here: http://en.wikipedia.org/wiki/Comparison_of_temperature_scales#Comparison_of_temperature_scales? Then, when you have that, show some sample code that would use the objects you deserialize from that XML. Would that code have a lot of conditional statements and checks for specific classes of conversions? If it does, then it's smelly, brittle code. That would be my point. Hope this helps clarify my ramblings a little.
Please DontWriteLongLines. It makes your thread very hard to read.
1. Do some research on double checked locking. Start here: http://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java . Again, I have to question why you even have to worry about things like lazy initialization at this point. This is premature optimization. Try to stop doing it. It's the root of all evil (per Donald Knuth).
2. Converter class violates the Single Responsibility Principle. You mix concerns of converting with concerns of formatting. Leave formatting out of it.
3. Code is not very object-oriented. Note that if you follow advice in #2, you will be left with no "internal state" for the Converter class. And all the "knowledge" about conversions is actually kept outside of the Converter class. This code is leaning more towards Functional Programming than Object-Oriented Programming.
Lou Pellegrini wrote:Hi Junilu,
3. I agree the converter is a function. Servlets are coming.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |