Re: [Jsource] Propositions

Actually, I think J has implemented support for VF=: 3 : '2+3*y.' You could also use VF=: 2 3 What we don't have, though, are "nouns" N where _ e. $ N is true. Perhaps we should? Might be some serious problems there, though, to be resolved. (For example, how would reshape work on that sort of

Re: [Jsource] Propositions

So, Roger's i._ and McDonnell and Shallit, " Furthermore, an infinite array may be stored as a function of its indices. For example, to store the infinite vector V=: 2+3*i._ we need only store the function VF=: 3 : '2+3*y.' . Then it is easy to see that (k{V) <-> VF k . Any particular

Re: [Jsource] Propositions

Note also that Haskell has a lot of things to keep you from trying to access anything more than a brief prefix of those infinite lists. (And this includes a rather extensive system of errors and an involved "pattern matching parser".) You would basically have to give up on J's syntax (and some of

Re: [Jsource] Propositions

> Another fascinating possibility becomes available: 'i._'... Two more cents... This was also contemplated more than a decade ago by none other than one of the designers of J [0]. You are in good company. :) Is it all academic? (My understanding is that Haskell supports infinite lists.) [0]

Re: [Jsource] Propositions

I thought one of the issues with GMP would be memory management, but it looks like it could hook into J's system: https://gmplib.org/manual/Custom-Allocation.html Another issue, of course, is programmer time - there's a good amount that would need to change. -- Raul On Mon, Feb 26, 2018 at

Re: [Jsource] Propositions

> Secondly: operations on extended precision numbers are unbelievably slow... The most direct example: '! 10x' takes 50 (!) times longer than python3's math.factorial(10). It should be well worth looking into llvm's APInt and APfloats, or

Re: [Jsource] Propositions

You can display thousands of extended and rational numbers. Use format (":), then reshape the output onto multiple lines. Output defaults to 256 characters per line. Spread the output onto multiple lines. Easier to read that way anyway. On Feb 26, 2018 1:20 PM, "Eric Iverson"

Re: [Jsource] Propositions

I worked on an APL implementation in 1972 that had exactly what you are proposing. We called them arithmetic progression vectors. The implementation was very successful. But at the end of the day, I decided that the code and complexity required was not justified. It made for many very impressive

Re: [Jsource] Propositions

Apparently this discussion should be in the beta forums: http://jsoftware.com/pipermail/beta/2018-February/009056.html From: Source on behalf of Vijay Lulla

Re: [Jsource] Propositions

​Raul, Your points are very valid and I agree with them. I like J the way it is and will continue using it however it evolves. J does extended precision and Sparse arrays better, and more coherently, than any other language. And the way it deals with edge cases is just beyond compare! I am

Re: [Jsource] Propositions

*Why* is this good, though? If "language x implements it" is all that is needed for something to be good, then no language can be good, because there are just too many gimmicks in too many languages. Restated: if we introduce a new primitive type (this range thing) then the interpreter would

Re: [Jsource] Propositions

The "range" idea that James is proposing is a good one! Julia implements range like this. And, if I recollect correctly this is also one of the fundamental changes between Python 2 and Python 3's range function behavior! And if I understand correctly what James is saying is that we can do some

Re: [Jsource] Propositions

I guess I'm not sure what you think the word "execution" means, in the context of this proposition. But it's also not clear to me why you think that all use of i. should require extra complexity which is already available through the use of bind. But there's an additional difficulty, here, which

Re: [Jsource] Propositions

Bind is not relevant here, since I'm talking about the execution of i., which must inevitably happen at some point to be of any use. Also, I don't see how there could possibly be a tradeoff between the time taken to write the results of a multiplication and evaluate it. In any event my tests

Re: [Jsource] Propositions

This is the "sweep it under the rug" design aesthetic - very useful when dealing with infinities and/or any other calculations which you really do not want to perform. That said, J already supports this kind of thing - albeit with slightly different syntax. For example, you can do: i. bind

[Jsource] Fw: Propositions

I have 2 major propositions: Recently, I (to my chagrin) demonstarted to a friend that '>: i.1e7' takes almost twice as long as 'i.1e7'. Of course I expected them both to execute instantly, not after a full second. So my suggestion: i. should return a 'range' (or 'i.') object containing three