You have to ask your questions about t.c before I can answer them :)
Is this a fair summary: I think t- and d-primitives are insufficient to
the task and should never have been defined; you think they have
limitations but perform a useful subset of the problem domain and should
be reinstated: if for no other reason, then for documentation value?
You have a reasonable position, but J has often been changed when our
view of what the language should be has changed, and that's what I think
has happened here. The J community has a stake in this and I welcome
further comment.
Henry Rich
On 4/2/2022 10:21 AM, Raul Miller wrote:
On Sat, Apr 2, 2022 at 9:18 AM Henry Rich <henryhr...@gmail.com> wrote:
I oppose this, I think strongly.
.. and .: should never have been defined. They do very little and take
up valuable codepoints.
I am on the fence about these.
From a language perspective, I would be most concerned about if and/or
where they are being used.
Anyways, although I listed them first (I pulled the list from the j901
release notes), I would prefer to focus on the other primitives.
The mathematics primitives come from a period where J was trying to
compete against Mathematica IIUC. The problem with them is that the job
to be done is a little too big for the syntax suggested for them:
I am not sure about that.
In any event, these are useful primitives and they have been used.
Moving their implementations into library code seems like the right
decision, but that's a different issue.
Maclaurin series are of interest, but not nearly as much as general
Taylor series; but the two-operand t-functions do not admit specifying a
point.
This distinction seems moot.
For example, under j807:
%@(-&1)t.i.5
_1 _1 _1 _1 _1
The calculus functions are OK for differentiation, maybe, but
insufficient for integration where definite integrals are important.
Contour integration in the complex plane is part of the problem domain.
Isn't that language (and/or library) extension territory?
Computers are finite and have limitations. But we do not, for example,
remove the use of floating point numbers because of their (well
documented) limitations.
Anyways, for the t. and d. families, it seems like using a library
implementation and retaining primitives which call into those
libraries is the right approach. This supports older content while
opening the door a bit wider for future improvements.
Raul: I can answer your questions about t.c, either privately or in this
forum.
I am all ears.
Thanks,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
