On Fri, Sep 24, 2004 at 10:24:32PM -0400, Aaron Sherman wrote: > On Fri, 2004-09-24 at 16:58, Edward Peschko wrote: > > > Ok, ok, I'll give you that point ... lets call them 'intimately related' and > > leave it at that... if you say "3 foo" and your algorithm goes: > > > > "3 foo" => 3 => "2" > > > > then you know something is desperately wrong. > > Yes, and you know that because the definition of number-to-string > conversion is such that 3 becomes "3". I think the point being made was > that it's not so much about reversability (the Unicode example was an > excellent point there), but about matching an arbitrary set of rules for > each (seperate) operation.
fair enough.. but *my* point is that the two are related, and even though the algorithms in going from string to integer, and from string to integer are totally different, they can be used to proof/debug each other. > Why, for example does 3 not become "11"? Is base 10 superior for some > reason? Nope, it's just an arbitrary choice based on the prefernces and > compatibility needs of the language designers. Yes, but say that you had two separate calls to the string/int/string routine, and you got 3 foo => 3 => 11 4 foo => 4 => 22 Now you *know* something is out of whack. In fact, no I take that back - if you are dealing in base 3, then 3 foo should turn into 11 not into 3, in the first place. So they *have* to be related in this way, if not directly reversible. You could even say that in the chinese case that if you have "?$B#3" --> 3 --> "3" that's a bug. It had *better* turn back into "?$B#3" when you do the int to string conversion. That's a internationalization snafu if you don't. Anyways, all this is beside the point - the point being that you could use a generator to debug a regex engine, and vice versa. And I regret my inverse/reversibility analogy because I think it caused more confusion than anything else. Ed
