# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #59006]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59006 >
When generating PIR output (e.g., from the compiler tools), we
often need to convert a Float value into an equivalent representation
for PIR. Unfortunately, all of the mechanisms I've looked at for
doing this lose a lot of precision, which really isn't acceptable.
The prime candidate for this seems to be the C<get_repr> opcode,
which AFAICT is intended for this purpose. However, it appears to
provide only about 7 digits of precision.
The approaches I've tried thus far are simple stringification,
the get_repr opcode, and variations on sprintf formats. Here's
an example showing the difficulty:
$ cat x.pir
.sub 'main'
$N0 = exp 1.0
'as_pir'($N0)
.end
.sub 'as_pir'
.param pmc value
print "set_p_s : "
$S0 = value
say $S0
print "get_repr : "
$S0 = get_repr value
say $S0
print "printf %g: "
$P0 = new 'ResizablePMCArray'
push $P0, value
$S0 = sprintf '%g', $P0
say $S0
.end
$ ./parrot x.pir
set_p_s : 2.71828
get_repr : 2.718282
printf %g: 2.71828
By way of comparison, Perl 5 gives a far more reasonable result:
$ perl -e 'print exp(1),"\n"'
2.71828182845905
One approach might be to take whatever algorithm Perl 5 uses for
stringifying its floats (or something close to it), and adopt that
for get_repr and/or Float stringification.
The current situation blocks PCT's (and thus HLLs such as Rakudo)
ability to generate reasonably accurate PIR involving floating point
constants. Phrased another way: to get reasonable floating point
semantics HLLs are currently having to restrict themselves to
supporting floating point literal syntaxes that directly or easily
translate to PIR output and don't rely on actually computing the
float value.
Pm
