Promoting to Complex
wknight8111 at gmail.com
Mon Sep 27 17:12:41 UTC 2010
I'm fine with the idea of not automatically promoting to "bigger"
types in general, but that's not really consistent with what Parrot
already does. As Paul pointed out, Float already promotes to BigNum
and Integer already promotes to BigInt where required. Integer also
autopromotes to Float in some occasions.
I would be perfectly happy removing autopromotion behaviors to
BigInt/BigNum from Parrot, and have mentioned such at several times.
However, we should be consistent in whatever we do. If there is an
expectation of core types autopromoting to other core types, it makes
sense that sqrt(-1) should autopromote to complex. If there is no such
expectation, we can return NaN and allow the user to use subclasses of
Float to get the expected behavior.
On Mon, Sep 27, 2010 at 1:01 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Mon, Sep 27, 2010 at 11:34:37AM -0400, Paul C. Anagnostopoulos wrote:
>> At 9/27/2010 11:09 AM, Patrick R. Michaud wrote:
>> On Sun, Sep 26, 2010 at 01:58:13PM -0400, Paul C. Anagnostopoulos wrote:
>> > Folks,
>> > Should PMC functions with partial complex ranges promote their result to
>> > Complex? For example, should sqrt(negative Float) produce a Complex?
>> > This issue does not pertain to native numbers, since we never promote
>> > them to PMCs.
>> I would tend to vote "no" here. Most languages would expect
>> sqrt(negative Float) to throw an exception, and if a language
>> wants the possibility of a complex result it's trivially simple
>> to promote a Float to a Complex prior to calling the function.
>> Throw an exception, or return NaN? Right now most math functions return NaN or
>> garbage on range errors or on complex domains.
> Returning NaN is fine. I'm just wary of having Parrot auto-promote into an
> entirely new class of objects (with different behaviors) -- otherwise someone
> might be very surprised to have a bill or check created with "0+2i dollars".
More information about the parrot-dev