Scoping affects how we control modes.

Let's say we were not using Mathematica or some other language with built-in intervals. How hard would it be to get a language to ``do the right thing''?

Here we use the setting of the rounding mode as a prototype to illustrate the language options.

sine of 1.0 radians is 0.841470984807...

A reasonably rounded answer to single precision is 0.841471. We might also find it useful to compute a lower and an upper bound on sin(1), to single precision (as we just illustrated, for interval arithmetic).

How could we accomplish this in your favorite language?

What happens when you utter the equivalent of:

set Rounding_mode to ToNEGV;
compute sin(1.0) ?

Your intention is to obtain an answer like 0.814709 or some other nearby but distinctly lower bound on sin(1) .

What does your system provide?

Your system might

• (static, restore) just ``save the rounding mode.'' Compute the sine function normally say round to nearest, and return the same old usual value, say 0.841471. then ``restore the rounding mode,'' in this case, back to ToNEGV.

  OR

• (static, sticky) It might return the same normal value and also reset the rounding mode to ToNEAR. (``unstructured''- Only programs explicitly meant to change such modes should return with modes altered from the caller's settings.)

  OR

• (dynamic) It might just execute the sine routine with the rounding mode set to ToNEGV, and the result would likely be some number quite close to 0.841471, but not necessarily smaller.

  OR

• (static, compile-time) It might just execute the sine routine with the rounding mode set to whatever was in force at compile time, perhaps in a compiler command line (probably but not necessarily ToNEAR).

  (DEC Alpha compilers might do this since the rounding mode by default is part of the fp op-code. Use of an optional compile flag says to generate fp code that looks in control word.)

• (static, default, post-round) It might just execute the sine routine with default rounding, and then give it a little flick up or down as you seem to have requested (RealJava suggestion).

• Making sense of scope
• Complications
• Implementation issues