On Thu, 11 Aug 2016 09:32:31 -0700, zef...@fysh.org wrote:
> > "-0".Num.perl
> 0e0
>
> It's surprising that that's producing a floating-point positive zero,
> rather than the negative zero that is also available:
>
> > (-("0".Num)).perl
> -0e0
>
> -zefram
Thanks for the report. Are you able to describe any usecases where the string
cast resulting in a positive zero as opposed to negative zero creates a problem?
The reason we have a negative floating point zero at all is more due to
underlying implementations at whose level such zeros are used to signal various
exceptions. But such usage isn't needed on Perl 6 level.
Looking at the current implementation, fixing the described issue would involve
special-casing the .Num string
conversion AND special-casing the negative zero numeric case. This would result
in extra maintenance burden and performance loss in a very hot spot of the
codebase, so I'm trying to see what the justification for that is.
-----
As for what's happening: "-0" gets converted to Numeric under the hood, and the
containing numeric is an Int, and there's no Int negative zeros, so you end up
with a plain 'ol zero that then gets converted to a Num, without the
negative sign.
In the second case you present, the string coersion ends up with an Int, which
then is converted to a Num; when
you apply the prefix minus, it gets converted to a negative zero, since those
exist in Nums.
So this issue gives us first special-casing: that we need to notify the Numeric
conversion that we explicitly want a Num at the end.
Now, if you try, you'll notice that '-0e0' also results in a positive zero.
This is because that Numeric conversion parses the string in parts, each part
being an Int and is parsed using radix_I nqp op, and Ints ain't got negative
zeros, so even though the code asks the radix_I op to negate the result if we
have a minus, we still end up with a positive zero.
So this is the second special case, where we have to check whether we've got a
minus and a zero result and we explicitly want a Num as the end result.
-----
So considering the impact of the end result that fixes this bug, I'm willing to
sacrifice minor inconsistency of string casts never resulting in negative
zeros, for the sake of clearer and more performant code, but perhaps I'm
missing some viable usecase where string cast to numeric losing the sign of the
zero is a problem at the high level that Perl 6 operates in?
