*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
>> > 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
>> > 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
