I guess this is not lazy evaluation, but a problem of reference, in the
sentences b=: a or b=: a;c
there is no value-copying at this point, only the reference count of
data block of a or c increases and header of b points to that data. Normally
when a is updated eg, a=: a+1, then the tie between a and b will break. The
reported bug seems to be related to the inability to detect a has been
changed and the old data block is no long valid.
a=: 2 ]/\ i.4
smoutput a
0 0 7995393
NB. a reference to the data block of i.4 which has been released
a=: 2 ]/\ b=: i.4
smoutput a
1 2 3
NB. no error since data block pointed by b is still valid
b=: i.4 NB. change memory address of data block
smoutput a
0 0 6356993
NB. same error
a=: a:{ 2 ]/\ i.4
smoutput a
1 2 3
NB. no error because a is copy-by-value using a:{
Втр, 17 Май 2011, Ian Shannon писал(а):
> Roger,
>
> From the example below, it appears that the correct processing is being done,
> it is just when assigning a name to the results that your special code runs
> into trouble, OR the J system is doing some lazy evaluation.
> "In certain cases, instead of explicitly doing }:y and }.y, the code
> constructs headers which point to the same data, thereby saving time and
> space."
>
> Does J do lazy evaluation, that is delaying a calculation until needed with
> the potential of not doing a calculation if the result is not used?
>
> Playing around with 2 infix below has given me a bit more insight into J.
>
>
> 1 load '~temp/3.ijs'
> NB. Script showing infix2 problem and exploring what happens
> NB. when you do nothing.
> NB. Running from a script using
> NB. 1 load 'script_file.ijs'
> NB. can produce vastly different "wrong" values, and the second set
> NB. of a, b and c are all not identical.
> NB. Entering the sentence 'c =: 0 + b =: a' at the keyboard
> NB. produced identical results for a, b and c
>
> JVERSION
> Engine: j701/2011-01-10/11:25
> Library: 7.01.048
> Platform: Win 32
> Installer: j701a_win.exe
> InstallPath: r:/j701
>
> NB. simple expression which produces the error.
>
> c =: 0 + b =: a=: 2 ]/\ i. n =: 8
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> b NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> c NB. correct
> 1 2 3 4 5 6 7
> NB. adding 0 produces the correct answer
> NB. But if we use the value a without the infix calculation
> c =: 0 + b =: a
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> b NB. same wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> c NB. same wrong @ keyboard, maybe different wrong from script
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> NB. My guess is "c" values are normalised floating point values
> NB. and "a" and "b" are un-normalised floats.
>
> NB. My conclusion is that it is the assignment and not the calculation
> NB. introducing the error. J 'knows' what the answer should be so
> NB. it uses Roger's quick headers, but carries the calculated value
> NB. along and when asked to add 0 it produces the correct value
> NB. for the calculated value to put into "c"
>
>
> NB. instead of adding 0 try identity verb between "a" and "b"
> c =: 0 + b =: ] a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> b NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> c NB. correct
> 1 2 3 4 5 6 7
> NB. Doing identity (ie nothing) makes no difference.
> NB. Same result when doing nothing a finite number of times
>
> c =: 0 + b =: ]^:25 a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17728352 16001920
> b NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17728352 16001920
> c NB. correct
> 1 2 3 4 5 6 7
>
> c =: 0 + b =: ]^:1e6 a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> b NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17745504 16001920
> c NB. correct
> 1 2 3 4 5 6 7
>
>
> NB. or even doing the inverse of nothing
> c =: 0 + b =: ]^:_1 a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17728352 16001920
> b NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17728352 16001920
> c NB. correct
> 1 2 3 4 5 6 7
>
> NB. however doing something zero time gives different results
> c =: 0 + b =: *~^:0 a=: 2 ]/\ i. n
> a NB. wrong
> 23860120 16144024 16003072 16139800 23817168 16003136 16144024
> b NB. correct
> 1 2 3 4 5 6 7
> c NB. correct
> 1 2 3 4 5 6 7
>
> NB. as does doing nothing an infinite number of times
> c =: 0 + b =: ]^:_ a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17728352 16001920
> b NB. correct
> 1 2 3 4 5 6 7
> c NB. correct
> 1 2 3 4 5 6 7
>
> NB. or the inverse of nothing an infinite number of times
> c =: 0 + b =: ]^:__ a=: 2 ]/\ i. n
> a NB. wrong
> 23816912 23860120 16144024 16003072 16003072 17726304 16001920
> b NB. correct
> 1 2 3 4 5 6 7
> c NB. correct
> 1 2 3 4 5 6 7
>
>
> NB. Neville Holmes in the days of the Sydney APL user group
> NB. gave a very entertaining talk on "nothing" in APL
> NB. ( Where are you now Neville! )
> NB. demonstrating how well array languages (that is APL)
> NB. handled arrays of zero rank and zero length.
> NB. J's power conjunction provides me with more delights.
>
> NB. Further exploring this shows that the inverse of the
> NB. "do nothing verb" applied more than once does affect
> NB. the value transferred.
> NB. Hence the conclusion that (for current J system) there
> NB. is somehow a difference between doing nothing and
> NB. doing the inverse of nothing when applied more than once!
>
> NB. Some defined verbs for doing nothing will do exactly that
> NB. - maintaining the same state - and
> NB. others return the correct value which shows they are
> NB. collecting the calculation and not being effectively bypassed.
>
>
>
>
>
>
> Ian
> Ian Shannon
> Landscape Modelling & Decision Support
> Scientific Services
> Office of Environment and Heritage
> Department of Premier and Cabinet
> PO Box A290
> Sydney South
> NSW 1232
> T: +61 2 99 955 490
> E: Ian.Shannon Environment nsw gov au (you add in 'dot's and 'at')
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This email is intended for the addressee(s) named and may contain
> confidential and/or privileged information.
> If you are not the intended recipient, please notify the sender and then
> delete it immediately.
> Any views expressed in this email are those of the individual sender except
> where the sender expressly and with authority states them to be the views of
> the Office of Environment and Heritage, NSW Department of Premier and Cabinet.
>
> PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
