From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-12-01T06:40:19+09:00
Subject: Re: Ruby ++, the one element and generators


"Rudolf Polzer" <AntiATField_adsgohere@durchnull.de> wrote in message
news:slrnauia8l.f7j.AntiATField_adsgohere@www42.durchnull.de...
> Scripsit ille aut illa MikkelFJ <mikkelfj-anti-spam@bigfoot.com>:
> [...]
> > In algebraic terms, there is no 'one' element for Real numbers, while
> > natural numbers (integers) do have a one element. Furthermore it is not
> > within the realms of Ruby to redefine the natural numbers, thus no next!
> > method.
> [...]
>
> You are referring to an algebraic 'group' (is it called like that in
> English?).
It's called so in the direct Danish translation. I'm not sure this is the
correct Englis term.

 A 'group' doesn't necessarily have a one element. But a
> N and Z_p do have a 'next' operation.

I don't recall the exact criterias anymore, but it's clear the Z can't be
generated by adding one, as you'd have to start at negative infinity.
I think perhaps its helpful to just think it terms of a generator such as
next, as suggested by Daniel Carrera. It still won't generate all values but
it will generate the next value, which is suffient for our purposes, as we
are not really trying to make an objects state space equivalent to a group
or a similar construct.

> Additionally, some other things might be a usable debugging help:
> properties of operators that can be defined:

This pin-points some of the problems I have with pure OO approach. I feel
like operations should work on an arbtrary number of objects symmetrically -
I believe this is multimethods? Nonetheless, the Ruby abstraction of the
world is mostly a good one, and if you keep in mind the precise mathematic
definitions suchs as cummutitavity (i.e. order of factors do not matter), it
shouldn't be a problem in practice - but since you can mix types
arbitrarily, there are no guarantees:
For example 2 + "3" vs. "3" + 2. Do you get error, 5 or "32".
Strings and integers would have to agree to ensure the expected behavior,
even if + is not commutative for strings and it is for numbers.
Of course, there have yet to be invented a clean solution to type coercion
in any language.

Mikkel