Re: [Bug-apl] Strange domain error

[Elias Mårtenson]

As a related side-note, I've always thought that the Common Lisp way of handling numbers is brilliant, and that more languages should copy that. Big-integers together with support for rationals provide a way to get exact numbers in any number base (not just 10, which is what Java provides through the unwieldy BigDecimal class).

If GNU APL were to adopt improved number support, it could do a lot worse than to adapt the CL way.

That said, unless you have a compiler with good type inference, such method can be slow.

Regards,

Elias

On 11 June 2014 23:52, Blake McBride <address@hidden> wrote:

Thanks a lot, Juergen!  Disconnected from the standard, I fail to see how a clear integer can become a complex - especially in relation to code/decode.  I think there is something fundamentally wrong.  

I make the following comments just based on my own experience with numbers, and without experience with the GNU APL code.  I also think it is highly likely you know a lot more about this than I.  I just wanted to share, a perhaps ignorant, opinion.  I apologize in advanced.

Numbers have various representations including integer, floating point, and complex.  There are two ways (for the purposes of this commentary) of performing calculations as follows:

1.  Remember the exact type and perform the calculation based on the type or circumstances, i.e.

switch (number type) {

case INTEGER:  int_res = int_x + int_y;  break;

case: FLOAT:  float_res = float_x + float_y; break;

case: COMPLEX: complex_res = complex_x + complex_y; break;

}

2.  Do it generically:

res = x + y;

In other words, in all places in a C program, one can define all numbers to be double (generic math), and do all calculations on doubles.  The problem, of course, is the unfixable rounding errors in cases when only needing integer calculations.

It is a lot more work to remember the data types and keep the math at the simplest level than to generalize it as all just math in too broad a generic way.

Irrespective of any "standards", I fail to see operating on integers in an integer-only way can bypass reals and become complex numbers.  It seems like the math is being done way too generically.  If that is true, there is ultimately no  ⎕CT tweaking that will ever reliably fix the problem.

I think the system should incorporate rules.  Things like:

a.  integer plus/minus/times integer always equals integer

b.  integer divided by integer produces float but never complex

c.  float plus/minus/times/divide float/integer produced float and never complex

d.  etc.

It is not possible for ⎕CT to substitute for rules like these.  ⎕CT can only be used to minimize problems but never to eliminate them.  Although, there are many situations where there is utterly no fix, utilizing rules like these makes the system easy for the programmer to deal with - i.e. he knows when he's created a problem (like using division).

Just for grins, I tried the problem on IBM APL 2.  It had no problem with 200.  Is there a ⎕CT test I can do to determine if they are involving ⎕CT?

One serious fear is that APL uses 0 to represent false.  Conditional statements control the flow of a program.  What happens if we cannot rely on zero being zero?

With deep respect and appreciation for what you have done,

Blake

On Wed, Jun 11, 2014 at 7:54 AM, Juergen Sauermann <address@hidden> wrote:

Hi,

I have changed the code so that near-zero complex numbers in ⊤ are
demoted to integer 0, see SVN 319. This isn't quite in line with the standard
who says that ⎕CT is not used in ⊤, but makes more sense to me.

/// Jürgen