add MMD bug in Integer PMC

Austin Hastings Austin_Hastings at Yahoo.com
Fri Oct 30 22:01:01 UTC 2009


FWIW, I don't think this is the bug.

As I understand it (which is dimly, at best), the MMD uses the left 
operand to dispatch, so

integer + float     ->    integer.add(float)

My further understanding is that the default case applies to pmcs that 
are neither Integer, Float, String, Complex, Bignum.

For example, if I try to add C<   10  +  $filehandle   >, the code would 
wind up in the default case.

I can understand the default being to use float, so as to avoid losing 
precision. That is, if whatever PMC is capable of returning 3.14159, and 
the default is to treat it as an integer, it would always get truncated.

(Conversely, I can see where always promoting to float is freaking 
stupid, since float ops are like 6.02E+23 times slower than int ops. Why 
wasn't the default set as "if you want float, TELL US?"

Anyway, my original problem came about when I defined a class with a 
get_string vtable, and a get_integer vtable. When I printed the object, 
I got the string version -- not unreasonable. So I printed C<  0  + 
$object >, figuring that would force an integer conversion. But it 
doesn't, apparently because it wants a float instead (so it goes through 
get_string, naturally. :-(

I'm pretty sure there's some wrongness here, but I don't think that the 
default integer add operation is where it's at. Here are some things 
that are wrong, weird, strange, or that beg explanation:

1. The MMD doesn't recognize "I have a get_integer vtable" as a hint 
about how to handle type conversion. http://nopaste.snit.ch/18505

2. Non-numeric objects appear to use get_string as a route to 
conversion, instead of get_integer.

3. There doesn't seem to be any real scenario, barring an explicit $I0 = 
$P0, that invokes get_integer on a PMC that isn't a subclass of a scalar 
type.

3a. In particular, this seems like a place where a role would be useful. 
"I can be a number" or "I can be an integer" might be good things to 
have in the MMD chain for operators. Of course, attaching "I can be a 
number" and "I can be a string" to the same class brings us back here, 
but surely there is some mechanism in C3, or whatever operator-mmd uses, 
for specifying precedence.

4. As shown in my second nopaste (http://nopaste.snit.ch/18506), there 
appears to be a fourth object involved in a $P0 = $P1 + $P2 operation. 
(I am printing the get_addr of the PMCs, and there are 4 different 
addresses.) So C< add > appears to create a temporary PMC.

5. The add would not succeed until I provided a C< set_number_native > 
vtable entry as well. Which suggests that you can't have a read-only 
object. :-(

The first couple of these I can see rolling up into a role discussion. 
(BTW: A month or two ago there was some discussion about the difference 
between the R*A and the F*A types, and in particular the PPSU opcodes. 
That, IMO, is also indicative of the need for some roles. In particular, 
the F*A types should "does array" while the R*A types should "does 
array, deque".) But if roles were used that way they would have to 
supplant types as the dispatch keys.

I'm somewhat concerned about #3. I know that WhiteKnight is working on a 
linear algebra package, and there's going to be lots of floating point 
there. But somehow Parrot seems to have forgotten that "ints are fast".

And #4 and #5 seem like bugs. Why would "add" need a temporary? Why 
write to it?

=Austin


Jonathan Leto wrote:
> Howdy,
>
> I think this is wrong and has been a long-standing bug in our code:
>
> The Integer PMC, in the default case of it's add MMD, treats values as
> Floats and returns a Float
>
> I would like to treat it as such and write a failing test for it, fix
> the bug, and then change the behavior. Is there any reason not to do
> this?
>
> Duke
>
> Backstory:
>
> 16:37:11 <@whiteknight> VTABLE_set_number_native(INTERP, dest,
> SELF.get_integer() + VTABLE_get_number(INTERP, value));
> 16:37:18 <@whiteknight> so that's the culprit right there
> 16:37:36 < Austin> Where is that?
> 16:37:52 <@whiteknight> src/pmc/integer.pmc:357
>
> 17:01:07 <@whiteknight> The bug is that the Integer PMC, in the
> default case of it's add MMD, treats values as Floats and returns a
> Float
> 17:01:25 <@whiteknight> I think Integer PMC should assume values are
> Integer, and should return an Integer in those cases
> 17:01:31 <@whiteknight> or, set a value as an integer
> 17:01:41 <@whiteknight> (Float PMC should act on Floats in the same way)
>
> 17:03:26 < dukeleto> whiteknight: can you write a failing test for
> that vtable bug?
> 17:03:38 <@whiteknight> Austin just posted two of them
> 17:03:56 <@whiteknight> the issue is that's it's not currently a
> "bug". This is the way it's always worked
> 17:04:04 <@whiteknight> so we should probably get some agreement that
> this is not how we want it to work
>
>   



More information about the parrot-dev mailing list