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" <eric.b.iver...@gmail.com> wrote: > 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 trivial benchmarks. But made no difference for a real > application. As always, it matters where you put your effort. > > On Mon, Feb 26, 2018 at 3:15 PM, james faure <james.fa...@epitech.eu> > wrote: > > > Apparently this discussion should be in the beta forums: > > http://jsoftware.com/pipermail/beta/2018-February/009056.html< > > http://jsoftware.com/pipermail/beta/2018-February/009056.html> > > > > ________________________________ > > From: Source <source-boun...@forums.jsoftware.com> on behalf of Vijay > > Lulla <vijaylu...@gmail.com> > > Sent: Monday, February 26, 2018 8:28:57 PM > > To: sou...@jsoftware.com > > Subject: 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 sorry > > that my post came across as criticizing J. > > Cordially, > > Vijay. > > > > > > On Mon, Feb 26, 2018 at 2:14 PM, Raul Miller <rauldmil...@gmail.com> > > wrote: > > > > > *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 have to be built with support for this type in > > > all primitives that currently take numeric arguments. > > > > > > That's quite a lot of work (to get an idea of the magnitude of this > > > effort, note that support for sparse arrays has been stalled "in > > > progress" for over a decade). So what is the benefit? You wind up > > > implementing a behind-the-scenes algebra (similar to tacit verbs, in > > > the general case, though supporting only a scalar addition and an > > > index vector is an obvious subset of that) which gets executed "as > > > necessary", > > > > > > The biggest benefit I can see is better cpu cache management for a few > > > calculations involving large arrays. But it seems to me that: > > > > > > [a] The obvious cases where this is a significant benefit tend to be > > > trivial, and > > > > > > [b] The non-trivial cases where this is an actual help might benefit > > > more from the programmer structuring the computation to fit in L2 (or > > > L3) cache. [Note that this is similar to what you do when you don't > > > have enough memory for intermediate results.] > > > > > > But, also, identifying why it is good can help with the specification > > > process (the nature of that behind-the-scenes algebra which is a > > > necessary part of the implementation of this proposal). > > > > > > Thanks, > > > > > > -- > > > Raul > > > > > > > > > On Mon, Feb 26, 2018 at 2:01 PM, Vijay Lulla <vijaylu...@gmail.com> > > wrote: > > > > 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 really clever things with '+ - * %' when i. is not > > executed. > > > > For e.g., below is an example of my Julia session explaining what > James > > > is > > > > getting at: > > > > > > > > ---- Julia REPL ---- > > > > julia> x = 1:2:15 > > > > 1:2:15 > > > > > > > > julia> x > > > > 1:2:15 > > > > > > > > julia> collect(x) > > > > 8-element Array{Int64,1}: > > > > 1 > > > > 3 > > > > 5 > > > > 7 > > > > 9 > > > > 11 > > > > 13 > > > > 15 > > > > > > > > julia> x*2 > > > > 2:4:30 > > > > > > > > julia> collect(x*2) > > > > 8-element Array{Int64,1}: > > > > 2 > > > > 6 > > > > 10 > > > > 14 > > > > 18 > > > > 22 > > > > 26 > > > > 30 > > > > > > > > julia> dump(x) > > > > StepRange{Int64,Int64} > > > > start: Int64 1 > > > > step: Int64 2 > > > > stop: Int64 15 > > > > > > > > julia> dump(collect(x)) > > > > Array{Int64}((8,)) [1, 3, 5, 7, 9, 11, 13, 15] > > > > > > > > julia> > > > > ---- End Julia REPL ---- > > > > > > > > The main thing to notice is that only when you "collect" a "range" > > object > > > > is the actual space allocated (used?). > > > > > > > > > > > > On Mon, Feb 26, 2018 at 1:37 PM, Raul Miller <rauldmil...@gmail.com> > > > wrote: > > > > > > > >> 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 is two unrelated > > > >> proposals making talking about either of them likely to bring in the > > > >> other unrelated topic. > > > >> > > > >> Thanks, > > > >> > > > >> -- > > > >> Raul > > > >> > > > >> > > > >> On Mon, Feb 26, 2018 at 1:32 PM, james faure < > james.fa...@epitech.eu> > > > >> wrote: > > > >> > 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 had both python and j print the result of '! y', > which > > > >> should favor j even, since it only writes the first 256 digits, > whilst > > > >> python prints the entire number. > > > >> > > > > >> > James Faure > > > >> > > > > >> > ________________________________ > > > >> > From: Source <source-boun...@forums.jsoftware.com> on behalf of > > Raul > > > >> Miller <rauldmil...@gmail.com> > > > >> > Sent: Monday, February 26, 2018 7:08:31 PM > > > >> > To: Source forum > > > >> > Subject: 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 1e7 > > > >> > > > > >> > and > > > >> > 1 + i. bind 1e7 > > > >> > > > > >> > and J will faithfully not perform the indicated calculations, > quite > > > >> > yet (but still stashes them so that if you later change your mind > it > > > >> > can instead perform them). > > > >> > > > > >> > And, yes, the current extended precision implementation is slow > for > > > >> > multiplications (though fast for display). It's a design tradeoff, > > and > > > >> > perhaps one which should be reconsidered. (Though memory > management > > > >> > and cross platform stability and support are critical issues which > > can > > > >> > take precedence over mere performance.) Or at least: that's how I > > > >> > understand this issue... > > > >> > > > > >> > Thanks, > > > >> > > > > >> > -- > > > >> > Raul > > > >> > > > > >> > On Mon, Feb 26, 2018 at 12:48 PM, james faure < > > james.fa...@epitech.eu > > > > > > > >> wrote: > > > >> >> 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 vars: 'start end > > > step'. > > > >> In this way, '+ - * %' and indeed any linear combination of linear > > > >> operations can be executed on only 3 variables rather than #y . > > besides > > > the > > > >> immediate speed and memory improvements here, other operations (on > i. > > > >> objects), like '+/ */ e. i.' etc.. can now be found by direct > > > calculation, > > > >> without ever spawning a physical array! Another fascinating > > possibility > > > >> becomes available: 'i._'. Thus something like '*/ x * y ^ - i. _' is > > now > > > >> able to return the result of the infinite geometric series. In fact > in > > > >> general it may be very profitable to use virtual arrays only, unless > > > forced > > > >> otherwise. Another concrete example: when searching for the first > > > number to > > > >> satisfy a certain property, one could use 'i.@u seq i. _' rather > than > > > >> some likely inefficent variation of ^: or while. . Perhaps this > 'array > > > only > > > >> when forced' approach may even void the need for special > > combinations, a > > > >> concept which feels suspicious to me. > > > >> >> > > > >> >> Secondly: operations on extended precision numbers are > unbelievably > > > >> slow... The most direct example: '! 100000x' takes 50 (!) times > longer > > > than > > > >> python3's math.factorial(100000). It should be well worth looking > into > > > >> llvm's APInt and APfloats http://llvm.org/doxygen/ > > > classllvm_1_1APInt.html, > > > >> or perhaps Cpython's bigint's https://github.com/python/ > cpython/blob/ > > > >> 65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c, I > > > wouldn't > > > >> think it's necessary to write another custom library. > > > >> > [https://avatars2.githubusercontent.com/u/1525981?s=400&v=4 > > ]<https:// > > > >> github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e > > > >> 5347065f27/Objects/longobject.c> > > > >> > > > > >> > python/cpython<https://github.com/python/cpython/blob/ > > > >> 65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c> > > > >> > github.com > > > >> > cpython - The Python programming language > > > >> > > > > >> > LLVM: llvm::APInt Class Reference<http://llvm.org/ > > > >> doxygen/classllvm_1_1APInt.html> > > > >> > llvm.org > > > >> > Class for arbitrary precision integers. APInt is a functional > > > >> replacement for common case unsigned integer type like "unsigned", > > > >> "unsigned long" or "uint64_t", but ... > > > >> > > > > >> > > > > >> >> > > > >> >> James Faure > > > >> >> ------------------------------------------------------------ > > > ---------- > > > >> >> For information about J forums see http://www.jsoftware.com/ > > > forums.htm > > > >> > J Forums<http://www.jsoftware.com/forums.htm> > > > >> > www.jsoftware.com<http://www.jsoftware.com> > > > >> > Forums. The J forum mailing lists give life to the J community. > They > > > are > > > >> the best way to get help, help others, report bugs, and share your > > > interest > > > >> in J. > > > >> > > > > >> > > > > >> > ------------------------------------------------------------ > > > ---------- > > > >> > For information about J forums see http://www.jsoftware.com/ > > > forums.htm > > > >> > J Forums<http://www.jsoftware.com/forums.htm> > > > >> > www.jsoftware.com<http://www.jsoftware.com> > > > >> > Forums. The J forum mailing lists give life to the J community. > They > > > are > > > >> the best way to get help, help others, report bugs, and share your > > > interest > > > >> in J. > > > >> > > > > >> > ------------------------------------------------------------ > > > ---------- > > > >> > For information about J forums see http://www.jsoftware.com/ > > > forums.htm > > > >> ------------------------------------------------------------ > > ---------- > > > >> For information about J forums see http://www.jsoftware.com/ > > forums.htm > > > >> > > > > > > > > > > > > > > > > -- > > > > Vijay Lulla, Ph.D. > > > > > > > > Assistant Professor, > > > > Dept. of Geography, IUPUI > > > > 425 University Blvd, CA-207C. > > > > Indianapolis, IN-46202 > > > > vlu...@iupui.edu > > > > > > > > <http://vijaylulla.com> > > > > http://vijaylulla.com > > > > ------------------------------------------------------------ > ---------- > > > > 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 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
