Actually, since the quaternion math is fairly well understood, the difficulty of implementing a generic user type support might be higher than implementing quaternion support. [Both because it would be doing something more general, and because it would not be safe to ignore cases that can be ignored for a quaternion implementation.]
That said, the payoff would be different: a user type support facility could be used as a staging ground and perhaps a set of implementation guidelines for both this and other projects (both useful and spurious). Thanks, -- Raul On Fri, Nov 2, 2018 at 5:42 PM Don Guinn <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
