Avoidance of complex numbers in financial calculations.

[Phil Last]

The help explaining new features in version 13 states that the APL_COMPLEX_AS_V12 parameter can be used to suppress the creation of complex numbers by primitives given real arguments. But:

Note that this feature is provided to simplify the transition of older code to Version 13.0. It does not prevent the generation and use of Complex Numbers using features new to 13.0 (such as explicitly specifying a Complex Number literal), and it will be removed in a future release of Dyalog APL.

The emphasis is mine but the sentiment signals to me that the described feature is something to be avoided.

I do want to suppress that creation but without signalling any new error and in such a way that individual elements that would be complex are returned as zero. So what I need is a function "real" that returns a one for each real number and a zero for each complex number in the argument. I can then define:

      noncompex←{⍵×real ⍵}

or derive:

      noncomplex←×∘real⍨

to clean my data.

The following functions serve where:

      ⎕ML←3 ⋄ ⎕IO←0 ⋄ _COMPLEX←⎕DR 1J1

Global _COMPLEX avoids the scattering of arbitrary numeric constants around the code and its dynamic assignment avoids the outcome of a change of heart over those constants' arbitrary values.

      real0←{
        1<≡⍵:∇¨⍵
        _COMPLEX≠⎕DR ⍵:⍵=⍵
        _COMPLEX≠⎕DR¨⍵
      }
      real1←{
        {(1=⍵)∨(0=⍵)∨¯1=⍵}×⍵
      }

We can shorten real1 by ignoring the zero case because:

      ∀⍵: (0=×⍵) ≤ ⍵=0

i.e. signum ⍵ is zero implies that ⍵ is zero:

      real2←{
        {(1=⍵)∨¯1=⍵}×⍵
      }

real2 is thus incorrect for zero values but we want zero anyway.

Given that real2 is quicker in all circumstances than real0 I have no trouble in deciding which of the above to choose. But it crossed my mind that someone out there might know of a really obvious (to a mathematician) scalar method to extract the imaginary part of a complex number, let's call it i. Then all I need is

      real3←0∘=∘i

which would probably be twice as fast as real2.

[Dick Bowman]

I suspect I'm missing the point here, but would 9○⍵ and 11○⍵ not serve your purpose?

[Phil Last]

No indeed. It was my omission. I had no idea. So all I need for the entire task is:

      {⍵×0=11○⍵}

Thanks Dick.

[Phil Last]

Sorry Dick.

It's only 30% quicker, not 50%.

(Good try though.)

[giangiquario]

A warning:

1e400J1
1.797693135E308J1

1J1e400
SYNTAX ERROR
1J1e400

[AndyS|Dyalog]

Logged as 009310: Numbers such as 1e400j1 truncates to 1e308j1, rather than generating a SYNTAX ERROR

The fix will be available in the next set of DSS patches. The fix will also impact ⎕VFI.

(Note, my first post said DOMAIN ERROR. Sorry for the confusion)

[Phil Last]

First post? Never mind.

It seems to me that:

      1j1e308
1J1E308
      1j1e309
SYNTAX ERROR
      1j1e309
     ∧

given the only difference between the two above is a single digit that it should be a domain error rather than syntax.

[Geoff|Dyalog]

I could see an argument for LIMIT ERROR. However, the choice of SYNTAX ERROR was imposed because of existing behaviour for, say,

      1e8192
SYNTAX ERROR

The numeric constant is outside of the set of possible numeric constants in the same way as ⎕KITCHENSINK is outside of the set of possible system names.

The alternative, which we used to do, is to map such a number to the nearest value within the set.

[Phil Last]

I think you'll find that APLX version 6.2 has a new recursive packing utility called ⎕KITCHENSINK