Note that there don't seem to be any tests, for example, against something like:
$P1 = new .Float
$P1 = 1.2
$N1 = cosh $P1
op/trans.t tests some of these math ops, but only against N registers. There
are tests for the
complex PMC, but not Float.
Add tests for all math opcodes for Float
# New Ticket Created by Will Coleda
# Please include the string: [perl #38896]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38896
There are many math ops that work on Float PMCs but not Integer PMCs.
e.g.:
% cat
On Tue, Apr 11, 2006 at 07:05:33AM -0700, Will Coleda wrote:
P1 = new .Float
P1 = 123
The assignment of 123 autoconverts the float to an integer, which
doesn't support the 'exp' method that's defined in the Float pmc.
(Change the 123 to 123. and it works fine.)
Given the morphing
On Tue, Apr 11, 2006 at 08:30:09PM +0100, Nicholas Clark wrote:
On Tue, Apr 11, 2006 at 07:05:33AM -0700, Will Coleda wrote:
P1 = new .Float
P1 = 123
The assignment of 123 autoconverts the float to an integer, which
doesn't support the 'exp' method that's defined in the Float pmc.
On Apr 11, 2006, at 23:15, Patrick R. Michaud wrote:
Just to add a me too of sorts -- I didn't really notice it when
most everything was using Perl* PMCs, but now that we've separated
things out into base types the behavior seems very odd, unexpected,
and somewhat undesirable.
This isn't
On Apr 11, 2006, at 21:30, Nicholas Clark wrote:
I can see value in a type .Number, which changes internal
representation and
vtable as and when necessary, but I'd still expect it to report
Number
when asked what type it is
[ ... ]
Was this built in morphing the cause of the problems
