Dear Juergen,
Thank you very much for your explanation. Whatever you did, it certainly
fixed the problem. I am sure as time goes on there will be optimizations.
As far as I can tell, the system is working really great.
Thanks!
Blake
On Wed, Jun 11, 2014 at 11:58 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> GNU APL normally chooses the generic way. The reason is simple: there are
> 3x3 = 9 combinations of INT REAL and COMPLEX arguments
> of a dyadic functions (or 3×3×3=27 if you also count the axis). With 24 or
> so scalar functions this would give more than 200 cases
> - too much for a lazy guy like me.
>
> Another problem is that real arithmetic can lead to complex results, eg.
> ¯1⋆.5.
>
> What GNU APL does is checking of the result type (INT, REAL, or COMPLEX)
> rather than the argument types,
> and to demote complex near-real results to real and real near-int values
> to int.
>
> Contrary to your opinion below, the most generic number type in GNU APL is
> not *double* but *complex<double>*.
> And that causes the failure that was fixed in SVN 219. The internal 0J0
> result was not properly recognized as near-real, so it was left as is.
>
> Type specific functions are only used if:
>
> 1. they have considerably better performance than a generic variant, and
> 2. they are frequently used with large arguments
>
> That was not the case for Encode.
>
> So the clear integer 0 was 0J0 (to be generic) and was not converted back
> to 0 by mistake.
>
> There is a serious problem with ⎕CT as such. ⎕CT is 1E¯13 by default but
> our numbers can be as small
> as 1E¯308. So we cannot simply set everything small (say < 1E¯13) to 0, or
> make complex numbers with small
> imaginary parts real, because we would loose precision when doing so. The
> strategy of GNU APL is to keep
> internal precision as long as possible and to demote only if absolutely
> necessary. This decision is on a per-primitive
> base. Encode was actually demoted, except that demotion of 0J0 did not
> result in integer 0.
>
> I would also say that your rules below are implemented in GNU APL to the
> extent that they are correct.
> They are not, though, since Integer + Integer can be double if the maximum
> integer is exceeded (and so on...).
>
> /// Jürgen
>
>
>
> On 06/11/2014 05:52 PM, Blake McBride 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
>>
>>
>>
>
