From: Rudolf Polzer Date: 2002-12-01T09:00:54+09:00 Subject: Re: Ruby ++, the one element and generators Scripsit ille aut illa MikkelFJ : > "Rudolf Polzer" wrote: > > Scripsit ille aut illa MikkelFJ : > > [...] > > > 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. That's why I named Z_p. Even Z_n would work (addition modulo n, eg if n = 6, 4 + 5 = 9, 9 MOD 6 is 3, therefore 4 + 5 _=_ 3 (mod 6)), but if you are using the normal operations modulo a prime number, you can even divide: 5/4 _=_ x (mod 7) 5 _=_ 4x (mod 7) 5 = 4x + 7q Euclidean Algorithm: 7 = 4*0 + 7*1 4 = 4*1 + 7*0 3 = 4*(-1) + 7*1 1 = 4*2 + 7*(-1) Multiply with 5: 5 = 4*10 + 7*(-5) 5 _=_ 4*10 (mod 7) 5/4 _=_ 10 (mod 7) _=_ 3 (mod 7) So in Z_7 5 divided by 4 is 3. 3*4 is 12, the remainder after division by 7 is 5, so 3*4 _=_ 5 (mod 7). The problem in Z_p is that there isn't a lowest element. There is a multiplicative zero, but there is no first element - Z_p is cyclic, you can reach every element from every element by just adding 1. > 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. And that's the IMHO best reason for '++'. In C++ it's also used for more than adding one to an integer: it can, for example, iterate over tree nodes of a . > > 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". I'd say: 2 + "3" -> 2.+("3") -> error if Fixnum.+ is declared as a commutative operator (for the sake of simplicity, commutativity requires equal types) *OR* 2.+("3") is executed and commutativity is just ignored if types are inequal, but a warning is issued -> error, 5 or 23, depending on type coercion rules > Strings and integers would have to agree to ensure the expected behavior, > even if + is not commutative for strings and it is for numbers. That's why I wrote it would be better if each type can have its own operator behaviour. > Of course, there have yet to be invented a clean solution to type coercion > in any language. Easy: there is none. Both Modula-2's and Perl's type system have their pros and cons. There are people who want the strict system of Modula-2 that doesn't even let you convert a INTEGER to a FLOAT implicitly (so you have to write "f / 2.0" instead of "f / 2") and there are people who want Perl's system which is anything but stongly typed. -- REPLACE The ZOO must replace an item that is used by the monkey during typing activities. The item to be replaced may be TYPEWRITER, PAPER, RIBBON, CHAIR, TABLE, or MONKEY. RFC2795