Simon -- It used to be that the 'mod' op was the mathematically "correct" (in the Knuth sense) op, and the 'cmod' op was 'mod' per the C implementation used to compile Parrot (which are two very different things, it turns out). I wrote the Knuth-mod op originally, and proposed having both versions.
It looks to me like core.ops still has the simple cmod (x % y) and the distinct mod (Knuth-style) ops when it comes to the non- PMC versions. Since it is likely that much numeric work will occur via PMC ints and nums, I'd rather see PMCs have the same mod / cmod distinction as exists with INTVALs and NUMVALS, which as you point out does not seem to be the case. In general, I'd expect that we want Parrot to support all INTVAL, NUMVAL and STRING op semantics with related PMC vtable methods, and you point out a lack in that regard that I think should be remedied by adding vtable methods. Note that the Knuth-style mod can be useful for things like calendrical calculations. Regards, -- Gregor On Thu, 2003-07-10 at 19:54, Simon Glover wrote: > The PMC version of this op (ie cmod_p_p_p) is identical in > implementation to the plain mod op (mod_p_p_p), which seems rather > pointless. Would anybody object if we just got rid of it? > > Simon > -- Gregor Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
