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 <blake1...@gmail.com> 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 <
> juergen.sauerm...@t-online.de> 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
>>
>>
>>
