I understand. I shouldn't have said "not be difficult". But compared to implementing something like quaternions into the J interpreter which would be very difficult. What I am suggesting is perhaps a tool be added to J where possible extensions can be tried out and J primitives could be used as if implemented in the interpreter.
On Fri, Nov 2, 2018 at 3:31 PM Raul Miller <[email protected]> wrote: > Please be careful with phrases like "it would not be difficult" when > it's something you have never done. > > I mean, sure, it's not difficult for you when someone else does the > work. But... well... maybe I have just heard people throw around that > kind of suggestion a few too many times? > > Thanks, > > -- > Raul > > On Fri, Nov 2, 2018 at 5:21 PM Don Guinn <[email protected]> wrote: > > > > When I built my quaternion calculator I soon found that I really needed > to > > be able to write J expressions and not use special calls. So I found > that I > > could write a tool to rewrite a J statement and replace the desired > > primitives with a call to my code. It was not a solid approach, but was > > sufficient. I didn't have a special data type, so I assumed that a box > > containing a list of 4 numbers was a quaternion. It was not hard, if > > dyadic, to make sure perform the calculation as would be expected. > > > > When allowing for new data types, is this to put into J a new data type, > > like quaternions, fully integrated into J? That would be extensive. But > it > > would not be difficult to provide a way for trying out a new data type > for > > users to experiment. If it proves out to be useful and worth the effort > to > > integrate it into J, then it could be done. > > > > It would not be difficult to provide a tool to experiment for verb > > extensions, not modifiers. Add a new data type and a primitive verb to > > convert a noun to the data type. This would be work like x: or u: . Then > > add to global parameters a user name like Immex Phrase that is called if > > either argument to a primitive verb is this experimental data type. That > > phrase would be an adverb, monadic or dyadic, with the primitive verb > > encountering the data type as its argument. It would perform the > > calculation and return the result or an error, as the adverb chooses. > > > > Say the primitive to convert to the data type is called maybe "z:" with > > infinite rank. First, the user assigns the experimental phrase, then z: > > would no longer be an error, but cause the phrase to be run where it > would > > assign what a cell is and return the noun in desired form by running the > > phrase with a verb argument of "z:". Then, in a similar fashion, any > other > > primitive where a the cell of either argument is this experimental data > > type would run this experimental phrase on the cells. > > > > It wouldn't be efficient. But it wouldn't require work throughout the > > interpreter. > > > > For quaternions. z: would invoke the experimental phrase which would have > > to define the cell as 4 numbers, expand each number in the argument to 4 > > numbers or whatever form one wants. So "z: 2j3 4" would return a noun > with > > the experimental data type and the "2j3 4" to "2 0 3 0,:4 0 0 0" or > > possibly "2 0 3 0;4 0 0 0", assuming the form to be n, i, j, k. The boxed > > form would be less efficient, but would mean that no additional checking > is > > required in the interpreter as the data type internally would be "boxed" > > and the data types of the numbers within each box is preserved. Cells > would > > still be cells for rank processing as before in the interpreter and the > > numbers within the box could be integer, float or even extended integers, > > whatever the user wants. > > > > There would need to be changes to "do" (".) and the display of the noun > to > > invoke the experimental phrase, "do" when it encounters an error and when > > the name is displayed, call the experimental phrase to make the > conversion > > for display. That should be about it. > > > > Okay, I'm a nutcase. But it would be nice to have a way for users to try > > new data types without involving J development. Much of existing code > would > > accept the experimental data type without modification. It would be an > easy > > tool to try things easily and not involve the J internals. If it looks > > worth it, then the big job of integrating it into J could be done. > > > > In the meantime, for quaternions, the library would still be needed for > > efficient calculations. Just like LAPACK and other utility libraries. > > > > If you want, I could make it a formal proposal. But I just wanted to toss > > it out first to see what others thought. > > > > > > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
