User:Davjam2/Solutions/Numbers

Numeric Types
1.

These are initial thoughts on appropriate types. The precise requirements may indicate different types are needed.
 * 1) Physical measurements of room and furniture sizes are approximations and probably only accurate to 3 or 4 significant figures.   would be a good choice for an internal representation, storing the dimensions in some particular unit (e.g. metres). You could then round to centimetres, or convert to/from feet and inches, etc, for interaction with the user.
 * 2) Prime numbers are positive integers, and large prime numbers will be outside the limit of numbers that can be represented by an  .   or   would be good choices.
 * 3)   would be a good choice for most currencies (where the main monetary unit is divided into 100 subunits). If the program needs to deal accurately with other currencies (the Maltese Scudo is an extreme, and unlikely, possibility), other types may be required.
 * 4)   or   would be good choices. The fact that they perform modulo arithmetic (and don't give overflow errors) is advantageous here.
 * 5) Either   or , depending on the accuracy required. The hypotenuse of a triangle where the other two sides are both length 1 is $$\sqrt{2}$$, which can't be expressed exactly in any of the standard types. Returning a   would (incorrectly) suggest an accurate rational result. Given the result of the function will be a   or   approximation, the inputs might as well be approximations (to the same precision) too.

2.

3.

4.

5.

Probably not. It can't represent any more than  can (which already offers unlimited size and precision). And it can't represent e.g. $$\tfrac{1}{3}$$ exactly, unlike.

A better idea might be to write (or find) functions to format  numbers as exact decimals when possible or highlight recurring digits when not. (You might like to try this!)

What Numeric Means (The Num Class)
1.

You can check against the actual definition, for example:

being an  might be a bit surprising!

2.

will work with types that only represent integers and will return an integer result. There is also a function  that will return the remainder. (There's also a  that does both together).

will work with types also represent non-integer values, and will return the exact (for e.g. ) or a precise-but-not-exact (for e.g.  ) result of the division, with no concept of "remainder".

3.

Note you can now do any of the following:

Accuracy and Precision
1.

Interestingly, the  function takes an infinite list as a parameter and can return an infinite list as a result. Due to lazy evaluation, this all works fine.

Overflow
1.

y is a positive integer or zero ( is unsigned). Hence adding y to x should give a value greater than or equal to x. If it's less, overflow must have occurred. Is it possibl for overflow to occur yet the result be bigger than x? No: the biggest y can be is 255, and x + 255 is always one less than x (except when x is 0, when no overflow happens).

2.

3.

Here are two different solutions for, each illustrating some (mildly interesting) Haskell. The first uses a single  for two different guards:

The second shows a local function binding:

seems a bit easier with the second version:

Division by Zero
1.

or:

2.

Note that this is equivalent to:

If you're wondering why the y is not needed, read this.

Enumerations
1.

The  functions represent the different combinations of ,   etc. The start value must always be present. The next value and final value are optional, so there are four variations:,  ,   and.

2.

Try for yourself! BUT BE CAREFUL with. You might want to type

Note the rounding errors with  and how the results are consistent with the behaviour of.

3.

You can use it like this:

4.

It won't for the minBound, for example:

5.

You would need to specify the type:

For enumerations with more values than can be represented by an, "wrapping" may occur:

but:

is fine.

Type Classes
1.

Check for yourself!

2.

Note how this now has exactly the same class constraint as the  function that we use, which makes complete sense.

3.

4.

Probably:,  ,  , as well as  ,  ,   and.

5.

Probably:,  ,. Ideally also,   (though we may struggle to implement these).

( has a method   defined as "the rational equivalent of its real argument with full precision" which would be impossible to implement as stated. It would probably be appropriate to return a rational approximation to some stated precision.)

It can't be, since (for example) we can't represent $$\pi$$.