On 26/06/2012, at 10:56 AM, john skaller wrote:
>
> Note that in the loop we MUST coerce the integer indices
> to the correct index types. Support for iterating through
> finite sum types will be discussed shortly.
Ok, so here's my vague thinking: a sum type like 3 has three cases
but we cannot currently increment and so we can't write loops
or implement maps and folds etc.
We can of course do this: lift the sum to integer, add 1,
then coerce back to the sum type. Currently that forces a
range check, so there'd be a (stupid) check every increment.
Of course we could fix that with an "unsafe" cast instead of
a proper coercion.
But there's another solution which begins to appeal:
use modular arithmetic. In other words:
case 1 of 3 + 1 -> case (1 + 1) % 3 of 3
In other words regard type 3 as Z_3, the additive cyclic group
or order 3. in that case we never need bounds checks, we cannot
get an exception or error on an operation. This has some nice
properties (of course, since its based on maths!).
one nice thing is that 0 .. -1 is the extent of an index, since -1
is always the biggest value. So the "backwards indexing" works
naturally. Obviously circular buffers drop out automatically too.
Some operations become much easier to write: for example
its really easy to calculate the determinant of a matrix if your
indices wrap around automatically.
The downside is for some incorrect calculations we get the
wrong answer instead of an error.
Another issue is that if you start getting into division .. you get
into some quite complicated group theory.
But there's an interesting generalisation: using ANY group
as an array index, not just cyclic groups. Or even more generally
a finite R-module.
OK .. so the second issue raised in the previous email is what kind(s)
of reshaping to allow. It's "safe" to do any reshaping that doesn't use
more memory, but only in a SEGFAULTy kind of way. We really don't
want to make the conversion from
T ^ 2 ^ 3 -> T ^ (2 * 3)
have the same status as a conversion from array of 2 arrays of length 3
to an array of length 5 :)
The purpose of the core isomorphism is simply to compose or split
up array functors .. not to actually change the dimensions.
Still, there's a clear use for at least one exception: converting to
and from a simply indexed linear array.
Perhaps the safe way is: support only the core isomorphism to start,
and when users complain they have to use too many casts have
another look.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
