Felix currently supports limited mixed mode integer arithmetic
via the MixedInt module.
Mixed mode is a bit of a pain, because it generalises the
types for select operations such as addition. The selectiveness
may be surprising. The generalisation may interfere in weird
ways with typeclasses (which don't support mixed mode arithmetic).
[I find all this confusing myself even though I wrote the code
the algorithm is pushed to the limits in the simplest cases
precisely because they involve overloads in the 'top level'
namespace]
Now I am providing tutorial examples for complex numbers,
there are more use cases for consideration.
Signed integers are basically local approximations to \Z.
Whether or not there are overflow checks, there's no mathematical
basis for distinguishing the various sizes of them. Unfortunately
with pointers this isn't the case even in C. However for value
calculations it doesn't make sense that
1 + 2s
fails. This is NOT the case for 'unsigned integers' for two
reasons. First, as a mathematical construction these are modular
types where operations like addition cannot overflow.
The case for a modular type is somewhat weakened by the fact
division doesn't work correctly (division isn't well defined
unless the base is prime, which it never is for C unsigned ints).
Second, bitwise operations are also dependent on the number of bits,
in particular, complement. Note that in Felix, signed integers
do not support bitwise operations (however shifts are well defined
as multiplications by powers of 2).
So for unsigned integers, the case for 'promotion' is much weaker,
since the 'modular' type represented is 'silently' changed by
a promotion or demotion. Casting to throw away high order bits
is a really messy way to do that operation!
Now, if we go up to floats, there is a different case.
Floats are approximations to real numbers, but they're not
local, i.e. not compact: higher precision floats primarily
provide better resolution, but cover the same territory
(although exponents might get larger too).
In this case the 'type' approximated is, similarly to signed
integers, a single type, in this case \R.
It is not clear it is safe, however, to automatically 'promote'
floats to higher precision, because in fact they are not real
numbers but exactly approximations. A simplistic calculation
may work fine with a promotion, but an algorithm designed by
a numerical analyst may not.
So now, we come to more cases where there are mathematical
injections: complex numbers and then perhaps quaternions and
octonions (and other indeed, more generally any module/ring like
type generated by a finite group and scalar field).
Most mathematicians would be very bored having to cast
some real approximation to the corresponding complex approximation.
Still, we have 'generic' functions like 'sqrt' which fail on
reals, but succeed on the same value injected into the complex
field. The truth is that the function is:
fun sqrt: real -> complex;
and should be used like
let ?r = sqrt x in
if imag r != 0.0
then fail[double] ()
else real r
endif
but we provide
fun sqrt: real -> real;
with these semantics instead .. however this means that the
injection real -> complex is not transparent. In reality we
should provide instead:
fun fsqrt: real -> real
fun csqrt: complex -> complex
because these are different functions. In particular, fsqrt
then produces the same result when embedded in the complex
field, which is a requirement for the embedding to be a
functor.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
