Can I have a hint? Let's say we want to convert to hexadecimal instead. Will we still get a value of zero for C? The syntax makes sense, in COBOL it would be similar, (C = X#5 / X#9 * (F - X#20).

For hex in C or Java (C does not support binary, which is a shame) it would be

C = 0x5 / 0x9 * (F - 0x20);

And, yes, the the value for C will still be zero.

Here's a couple of hints.

Let's assume that C and F are floating point variables. In most languages (don't know about COBOL) it would still evaluate to zero. However, if it is rewritten slightly as

C = 0x5 * (F - 0x20) / 0x9;

it will evaluate as you would like it to.

 

Oh boy, a test! What's next? Order of operations?

And here's another hint... Yes.

 

Here is another hint.

It doesn't matter if you write the numbers down in binary, decimal, or hexadecimal.

The value is still the same and is stored in binary in the computer.

 

For hex in C or Java (C does not support binary, which is a shame) it would be

C = 0x5 / 0x9 * (F - 0x20);

And, yes, the the value for C will still be zero.

Here's a couple of hints.

Let's assume that C and F are floating point variables. In most languages (don't know about COBOL) it would still evaluate to zero. However, if it is rewritten slightly as

C = 0x5 * (F - 0x20) / 0x9;

it will evaluate as you would like it to.

Wait, so it IS about order of ops after all? Very clever response . But I still don't get it. At first I thought we needed to add a line to our code and do something like declare a data type (float, double, etc), or somehow otherwise specify a significand so we can truncate our floating point value to something we can manage. But all you did in the last equation was change the order of ops with simple laws of algebraic manipulation. On paper, you can solve it either way. Are you saying that even with the FPUs on today's post IEEE 754 chips, they only know one way to manipulate FP numbers?

 

Wait, so it IS about order of ops after all? Very clever response . But I still don't get it. At first I thought we needed to add a line to our code and do something like declare a data type (float, double, etc), or somehow otherwise specify a significand so we can truncate our floating point value to something we can manage. But all you did in the last equation was change the order of ops with simple laws of algebraic manipulation. On paper, you can solve it either way. Are you saying that even with the FPUs on today's post IEEE 754 chips, they only know one way to manipulate FP numbers?

No, but you are circling in on the issue.

Here's another big hint. Regardless of what data type the variables C and F are declared to be, the other three numbers in that expression are integer literals.

 

No, but you are circling in on the issue.

Here's another big hint. Regardless of what data type the variables C and F are declared to be, the other three numbers in that expression are integer literals.

This is more of a computer science problem than a math problem, right? (If those terms can be held mutually exclusive for the sake of this problem). If (F) was actually an integer, it seems there wouldn't be a problem. But the natural world never gives us integers as raw data, so now this is an integer division vs floating point division problem. You can't do both in a single equation I guess? Now I think I see where Mr. Chips was trying to take me with the integer arithmetic problem, but I still don't see why we get 0 in your first example and an actual value in the second.

I don't know, man. Maybe this isn't my thing. I can always go back to my FMS and marvel at its wonders. Or get myself into formal Compsci courses. Thanks guys.

 

It is partially mathematics and partially computer science. A lot of math is logic. A lot of compsci is also logic.
Thus if you want to excel when working with computers you need a solid foundation in both logic and mathematics.

A lot of people trying to be programmers are not well grounded in logic and math and hence run into trouble. We take for granted too many things that need to be reframed when working with computers.

We may naturally think that ¼ = 0.25
On a computer you have to rethink the situation.
1 / 4 = 0 with integer arithmetic, and so is 5 / 9.

Yes, order of calculation makes a world of difference.

if F = 104

5 / 9 * (F - 32) = 0

5 x (F - 32) / 9 = 40

Hence, these are testing your knowledge of mathematics when applied to real computers.

 

It is partially mathematics and partially computer science. A lot of math is logic. A lot of compsci is also logic.
Thus if you want to excel when working with computers you need a solid foundation in both logic and mathematics.

A lot of people trying to be programmers are not well grounded in logic and math and hence run into trouble. We take for granted too many things that need to be reframed when working with computers.

We may naturally think that ¼ = 0.25
On a computer you have to rethink the situation.
1 / 4 = 0 with integer arithmetic, and so is 5 / 9.

Yes, order of calculation makes a world of difference.

if F = 104

5 / 9 * (F - 32) = 0

5 x (F - 32) / 9 = 40

Hence, these are testing your knowledge of mathematics when applied to real computers.

But it makes the assumption a person knows how a computer handles integers and floating points. I don't remember enough about BASIC or any applied programming to instinctively know the computer will give me 0 if I divide 5 / 9, though I understand WHY it does that now. I'm sure I must have worked with fractions like these in BASIC, but I don't remember having problems. Anyway, I don't want to excel, I just want my weather robot. Cheers!

 

This is more of a computer science problem than a math problem, right? (If those terms can be held mutually exclusive for the sake of this problem).

Yes. Good job, since one of the first -- and often hardest -- things that must be done in order to solve a problem is to understand the nature of the problem.

If (F) was actually an integer, it seems there wouldn't be a problem.

I don't follow this. Even if F were required to be an integer, it would still always be zero.

But the natural world never gives us integers as raw data, so now this is an integer division vs floating point division problem.

Now you have identified the specific issue.

You can't do both in a single equation I guess? Now I think I see where Mr. Chips was trying to take me with the integer arithmetic problem, but I still don't see why we get 0 in your first example and an actual value in the second.

I don't know, man. Maybe this isn't my thing. I can always go back to my FMS and marvel at its wonders. Or get myself into formal Compsci courses. Thanks guys.

At this point, finding the answer involves learning something that you don't know -- you may have run across it when you learned COBOL, since as far as I know it is an issue in that language as well, but you have since forgotten it or, like many programmers, it went in one ear and out the other. It would be a very rare person that could figure out the answer without doing a bit of research and I'm pretty confident that, if it were important to you, you would be able to track the answer down in reasonably short order.

So here's the answer. I don't know how much programming is in your future, but this is a very good thing to be aware of if there is going to be any at all.

You already know that there are two fundamentally different ways of representing numerical values in a computer -- as integers or as floating point values. The hardware in the computer only knows how to do arithmetic within the same type (or, in some cases, only how to do integer arithmetic and floating point-arithmetic is emulated in software using integer arithmetic).

So what happens when we try to do mixed-mode arithmetic? Assuming the language allows it, it has to convert one of the values into the other type -- usually known as "casting" or "coercing" (the exact terminology depends on the language as this is something that must be defined in the language specification), most languages will coerce the integer into a floating point value so that the floating-point arithmetic is performed and the result of that operation is a floating point value.

In integer arithmetic, the result of an operation is always an integer. When the result should ideally be a non-integer, the language specifies how to obtain the integer result. Integers are closed under addition, subtraction, and multiplication (on paper, but not in a computer -- more on that later), but division isn't. Most languages specify either that the result of integer division is the nominal value rounded towards zero or toward negative infinity -- the distinction only matters when the result is negative. That means that any positive integer divided by any larger positive integer, such as 5 / 9, yields zero.

Now, combined with knowledge of order of operations, we are ready to solve the problem.

So let's look at our equations (and just use decimal for convenience):

C = 5 / 9 * (F - 32);

Applying order of operations (which is technically language dependent, but nearly all languages are consistent in this regard for the basic operations) we have

C = (5 / 9) * (F - 32);

If F is a floating point value, then (F - 32) is first coerced to (F - 32.0) (i.e., the 32 is coerced to a floating point representation) since this expression is a mixed-mode expression.

But (5 / 9) is purely integer arithmetic, and so it yields a value of 0. We then have

C = 0 * (floating-point value);

which is always zero.

Now let's look at the other equation:

C = 5 * (F - 32) / 9;

Applying order of operations on this we have

C = (5 * (F - 32)) / 9;

As before, this first becomes

C = (5 * (F - 32.0)) / 9;

But now the second operation to be performed is the multiplication and it is now a mixed-mode expression, so the 5 must be coerced to a floating point representation.

C = (5.0 * (F - 32.0)) / 9;

Once that is evaluated, the division operation is now mixed-mode, so another coercion results.

C = (5.0 * (F - 32.0)) / 9.0;

And our final result is a floating point value that is stored in the variable C. If C was an integer data type, the floating point result would be coerced to an int, but it would now be the largest integer that is no larger than the result of the expression -- i.e., rounded down.

Even if F had been an integer data type and all of the operations had been done using integer arithmetic, the results of the two expressions would have been different. The first would have still always resulted in zero while the second would have yielded the correct result (rounded down). This highlights the fact that, in a computer, arithmetic operations are not necessarily commutative or associative the way they are on paper.

As a programmer, this issue is not some minor thing that might cause a problem only is some oddball situation. It is, in fact, a very common source of bugs in programs that haunts programmers from day one. If you are aware of it, then you can adopt programming style guidelines that can avoid the problems in almost every situation. The easiest one is to always explicitly make your expressions single-mode by performing your own casts -- in other words, like The Force, don't let the compiler control your actions, but rather force it to obey your commands. So write that first equation as

C = 5.0 / 9.0 * (F - 32.0);

Each of those three values is intrinsically a real number that just happens to be equal to an integer value. But since they ARE real numbers, enter them into your expressions as the real numbers that they are.

Now, I had mentioned earlier about addition, subtraction, and multiplication on integers being closed operations on paper but not in a computer. That's because in a computer an integer has a fixed-width representation -- it's 8 bits or 32 bits or whatever. If it's an 8-bit signed integer, then the range of values is from -128 to +127. So what happens if we add 125 + 10? On paper we get 135, but in a computer, we get -121 because it overflows and "wraps around". Technically, it is still "closed" in that it is still an integer within the same range, but it is "wrong" in the normal sense.

This behavior can either get you in big trouble, or be extremely useful because it can be exploited in a number of common circumstances. But to either avoid the problem or exploit the opportunity requires that you understand the issue.

 

But it makes the assumption a person knows how a computer handles integers and floating points. I don't remember enough about BASIC or any applied programming to instinctively know the computer will give me 0 if I divide 5 / 9, though I understand WHY it does that now. I'm sure I must have worked with fractions like these in BASIC, but I don't remember having problems. Anyway, I don't want to excel, I just want my weather robot. Cheers!

That is one of the points I am trying to make. Most of us just want to get from point A to point B and we don't care how we get there. We make assumptions that the tool or vehicle we use will get us there with no effort required from us. We don't care if the vehicle uses fossil fuel or electricity. We didn't bother to check that it can only go 100 miles on one charge or can only carry 100 lbs at a time.

The same goes with computers. If you are building a weather station, you need to know something about the range of temperatures and resolution it can handle. Suppose you found out that your thermometer can only measure from 0°F to 100°F with 1-degree readout, would that be suitable for your purposes?

As we say, the devil is in the details.

In other words, we learn enough about something to be dangerous.

 

But it makes the assumption a person knows how a computer handles integers and floating points. I don't remember enough about BASIC or any applied programming to instinctively know the computer will give me 0 if I divide 5 / 9, though I understand WHY it does that now. I'm sure I must have worked with fractions like these in BASIC, but I don't remember having problems. Anyway, I don't want to excel, I just want my weather robot. Cheers!

You are correct that answering a problem like this makes the assumption that a person knows how a computer (programming language) handles integers and floating point representations. But where you are wrong is in the implicit claim that you only need to know this in order to excel as opposed to just wanting to make your weather robot. If this robot is going to involve any programming, then you are very likely to run into problems because of this issue sooner or later. It is NOT some subtle, fine-point issue that you are not likely to encounter in the real world.

More to the point, your entire thread was asking what kind of math you need in order do the kinds of things you want to do. Well, this is probably FAR more important to those ends than learning calculus or differential equations.

 

Yes. Good job, since one of the first -- and often hardest -- things that must be done in order to solve a problem is to understand the nature of the problem.

Thanks for taking me through all that, I really appreciate your help, gentlemen. Understand 100% now. Actually, I never learned COBOL. I just spent a couple hours frantically looking up examples of programming syntax with respect to conversions of binary and hex, and learning a little about how the floating point vs binary computer problem came about. Not too bad for a couple hours of work, eh? Give me 6 months...

 

Another important message and lesson that a large percentage of programmers are not aware of, floating-point mathematics are riddled with pitfalls. We take our calculations for granted and we expect the calculations to give us correct results.

Floating-point numbers are not exact. They, for the most part, are approximations for what we think is exact.

1 / 3 is an exact ratio, but how do you represent 0.333333333... on a computer?

 

1 / 3 is an exact ratio, but how do you represent 0.333333333... on a computer?

The ratio may be exact, but how do you represent 0.333333.... as an exact VALUE anywhere? It's still an approximation. Is there a way to solve the FP problem... is it best solved through hardware technology or software abstraction?

A bit off topic, but I was wondering if it were possible to have a "multiple state" switch. I know that a digital transistor, for example, has only two states... on or off... or, you interpret it as 1 or 0 if it exceeds or falls below certain voltage thresholds, respectively. What if you could define multiple voltage limits and come up with more possible values than just 1 and 0, within a single transistor? Is this possible and would there be any advantage gained (like reducing the number of required transistors)? I imagine this is silly, but I love silly questions.

 

A bit off topic, but I was wondering if it were possible to have a "multiple state" switch. I know that a digital transistor, for example, has only two states... on or off... or, you interpret it as 1 or 0 if it exceeds or falls below certain voltage thresholds, respectively. What if you could define multiple voltage limits and come up with more possible values than just 1 and 0, within a single transistor? Is this possible and would there be any advantage gained (like reducing the number of required transistors)? I imagine this is silly, but I love silly questions.

Of course it's possible: look up "ternary logic" or "ternary computer". To see an example from someone who has actually played with such stuff (albeit with horrible soldering skills), check out this page. And for some theoretical background, try this.

 

What if you could define multiple voltage limits and come up with more possible values than just 1 and 0, within a single transistor? Is this possible and would there be any advantage gained (like reducing the number of required transistors)?

Yes, it has been proposed, It's called multilevel logic.
But the complexity in the circuitry required to detect different voltage levels, means its no simpler than binary logic for a given number of bits, so it's not used in any comercial processor being made.

It is used in certain specialized applications such as the 8VSB modulation for US digital television.
It generates 8 analog levels in the carrier to represent 8 bits.

 

I don't know, man. Maybe this isn't my thing. I can always go back to my FMS and marvel at its wonders. Or get myself into formal Compsci courses. Thanks guys.

Don't let the math worry you. For a lot of circuits, basic math will be all that you need. If you come across situations where you need more, you can learn it as you need it.

 

The ratio may be exact, but how do you represent 0.333333.... as an exact VALUE anywhere? It's still an approximation. Is there a way to solve the FP problem... is it best solved through hardware technology or software abstraction?

In base three, 1/3 is represented as 0.1 -- exactly.

In our normal base ten, we think of 1/10 as being exactly representable, which it is. But in binary it is not. Hence if you were to do the following in most computer languages (with x and y being declares as floating point data types)

x = (1.0 / 10.0) * 10.0;
y = 1.0;

if (x == y) ....

The test will fail.

Thus, from a practical standpoint, testing for equality between two floating point values requires some careful thought.

A bit off topic, but I was wondering if it were possible to have a "multiple state" switch. I know that a digital transistor, for example, has only two states... on or off... or, you interpret it as 1 or 0 if it exceeds or falls below certain voltage thresholds, respectively. What if you could define multiple voltage limits and come up with more possible values than just 1 and 0, within a single transistor? Is this possible and would there be any advantage gained (like reducing the number of required transistors)? I imagine this is silly, but I love silly questions.

Yes, it is entirely possible to implement multivalue (meaning more than just binary) logic. As with everything in engineering, there are advantages and disadvantages. With few exceptions, the disadvantages currently far outweigh the advantages.

One place where you do see widespread use of multivalued logic is in FLASH memory where transistors able to store up to four bits (sixteen distinct levels) are common.

 

Wouldn't it be cool if we could have 10-state circuits, reliably?

 

Why 10?
Base-10 is a human artefact.
Computers like base-2 for obvious reasons.
There has been base-8, 12, 16, 20, 24, etc, in human history.