Thanks, Bill.
Any comments on the apparently current failure of jbreak.bat to interrupt
a deep loop in beta-d, at least in JQt?
eg this loops unless killed in task manager.
jbreak.bat is not effective for this toy function...
loop =: 3 : 0
n =. 1
while. n =. >: n do.
q =. ''
end.
''
)
OK - I can break it in Jconsole with ctrl-C in the terminal screen, and
also in JHS with ctrl-C in the JHS 901 console. But I mainly use JQt.
Spasibo,
Mike
On 01/05/2019 16:50, bill lam wrote:
using binary built from master branch,
showdetail_jpm_ 'moves'
recorded all lines
used and max record count: 23 17,856
Time (seconds)
+--------+--------+---+-----------------------------------------+
|all |here |rep|moves |
+--------+--------+---+-----------------------------------------+
|0.000001|0.000001|1 |monad |
|0.000006|0.000006|1 |[0] mn=./:~y |
|0.000006|0.000006|1 |[1] mv=.>:i.>./y |
|0.000018|0.000018|1 |[3] mv=.(,|."1),/@:(,."0 1(*/&0 1 2))mv |
|0.000016|0.000016|1 |[4] new=.(#~*/"1@:(>&_1))~./:~"1 mn-"1 mv|
|0.000047|0.000047|1 |total monad |
+--------+--------+---+-----------------------------------------+
Perhaps it is ok now.
The !^:_1 is another remaingin bug of removing terminated null,
This will be fixed in the next beta. Thank you for the clear report.
Wed, 01 May 2019, JBeta написал(а):
Thanks. NB - there's a second, strange and peculiar, problem lurking below
my
discussion of the JPM one!
0) And before I ask about those two, should Jbreak.bat still work? I was
unable to
break some occasions of inadvertent infinite loops earlier today.
1) JPM
Yes, flpa was executed - I didn't quote the line, but it was something like
flpa 200.
Anyway, here's an example, with a simpler function, moves, which is
examining
the Nim game in Euler Project problem 665, at
https://projecteuler.net/problem=665,
not that I'm asking for help there.
load'jpm'
start_jpm_ 1000000
17856
moves 3 1
0 3
0 2
0 1
1 2
1 1
showdetail_jpm_ 'moves'
recorded all lines
used and max record count: 23 17,856
|length error: usage
| lvl=.mbgn usage mend
Here's "moves":
moves =: 3 : 0
mn =. /:~ y
mv =. >:i.>./ y
NB. echo mn;
mv =. (,|."1) ,/@:( ,."0 1(*/&0 1 2 ))mv
new =. (#~*/"1 @:(>&_1) ) ~. /:~"1 mn -"1 mv
)
2) Strange Problem:
In looking for something for you to get your teeth into, I encountered
this:
decode"0 ]4 15
|spelling error
| 3 :'(-(2&!-y"_)%1e_3&* 2&!"0 D:1 ])^:_[2&<@|@{:}2,:2%:y*!2',�م
| ^
| n=.<:<.2 !inv y
whereas (!?):
decode 4 15
|open quote
| 3 :'(-(2&!-y"_)%1e_3&* 2&!"0 D:1
])^:_[2&<@|@{:}2,:2%:y*!2',�م��,�مR@ n'>
| ^
| n=.<:<.2 !inv y
decode =: 3 : 0 NB. the "offending" code
n =. <:<.2 ! inv y
m =. y - 2 ! >: n
m,."1 n
)
I couldn't find the explicit function using "find in files" in my user
folder,
nor in ~system ...
Before you ask, the above behaviour (in both cases) was in a fairly newly
started session in JQt. So I don't think there was a lot of junk lying in
wait
in memory from earlier in the session.
Version, In case it's relevant,
JVERSION
Engine: j901/j64/windows
Beta-d: commercial/2019-04-21T12:38:39
Library: 9.01.03
Qt IDE: 1.8.2/5.12.2
Platform: Win 64
Installer: J901 install
InstallPath: c:/d/j901
Contact: www.jsoftware.com
Thanks,
Mike
On 30/04/2019 18:53, Henry Rich wrote:
Perhaps flpa was never executed and this is what happens in that case?
I won't be much help unless you can give me a failing testcase.
JPM was not changed for 9.01, nor was the code for logging PM events.
What WAS changed was the code that checks to see whether debug/pm/other
special stuff is active. This was streamlined to make the case of
nothing active as fast as possible. I could imagine that the first or
last PM log record might be missing; nothing else comes to mind as
probable.
It would be great if you could figure out what's going on.
Henry Rich
On 4/30/2019 1:34 PM, 'Mike Day' via Beta wrote:
Latest difficulty, in beta D despite my mislabelling earlier:
showdetail_jpm_ 'flpa'
recorded all lines
used and max record count: 54,375 1,785,713
|length error: usage
| lvl=.mbgn usage mend
As far as I could see, both mbgn and mend were empty, in that:
# every mbgn;mend
0 0
I have seen this sort of thing in earlier J versions, but on this
occasion,
the error doesn't arise in J807 (JQt)
Thanks again for any help,
Mike
On 30/04/2019 09:22, 'Mike Day' via Beta wrote:
Thanks.
Noone else has commented apart from Bill Lam, so perhaps this
utility isn't used much,
but might you find time to suitably modify the script, pm.ijs,
in later beta versions?
Cheers,
Mike
On 30/04/2019 01:13, Henry Rich wrote:
The times that are connected are session times which
typically will be some
thousands of seconds with the important information down in the
nanoseconds. It would be a textbook example of how to lose
precision EXCEPT
that most of the time the positive and negative values alternate.
I remember now that I started by subtracting the starting
time from the
time values and with that change the !.1e_12 worked. Better
just to remove
the assert.
Henry Rich
On Mon, Apr 29, 2019, 7:16 PM bill lam <[email protected]> wrote:
some all and her displayed equal, however may be now in
901, sum of parts
can be larger than the whole because accumulating
floating point rounding
errors. The original pm expected a very high floating
point accuracy which
no longer holds in j901, eg j901 assumes + is
associative to make better
utilization of multiple ALU.
A possible fix is to give allowance factor like,
assert. *./ all > 0.9*her
On Tue, Apr 30, 2019, 6:33 AM 'Mike Day' via Beta
<[email protected]>
wrote:
Thanks - your suggested replacement didn't work:
load'jpm'
start_jpm_ 1000000000
17857142
f 1000
117002
showdetail_jpm_ 'flp'
recorded all lines
used and max record count: 3,765 17,857,142
|assertion failure: assert
| assert*./all>:!.1e_12 her
However, commenting out the assert did the trick.
Thanks
Mike
On 29/04/2019 22:26, Henry Rich wrote:
The assert. is invalid because of floating-point precision, and it
shows up in J901 because of order of operations. For a quick fix
either delete it or replace it with
assert*./all>:!.1e_12 her
Henry Rich
On 4/29/2019 1:54 PM, 'Mike Day' via Beta wrote:
I think the "also" paragraph in my earlier
message, below, might have
been overlooked.
I quite often use jpm to check performance
line by line. I can't say
it doesn't work in any
circumstances in J901 beta-d, but it does seem to have got more
unstable:
For example, in J807:
JVERSION
Engine: j807/j64/windows
Release-d: commercial/2019-03-18T13:21:35
Library: 8.07.25
Qt IDE: 1.7.9/5.9.6
Platform: Win 64
Installer: J807 install
InstallPath: c:/d/j807
Contact: www.jsoftware.com
load'jpm'
start_jpm_ 100000000
1785713
f 1000
117002
showdetail_jpm_ 'f'
recorded all lines
used and max record count: 3,767 1,785,713
Time (seconds)
+--------+--------+---+----------------------------------+
|all |here |rep|f |
+--------+--------+---+----------------------------------+
|2.045513|0.000030|1 |monad +/@:,@:((] #~ >:) +/"1@:flp)|
+--------+--------+---+----------------------------------+
showdetail_jpm_ 'flp' NB. I've removed several lines!!!
Time (seconds)
+--------+--------+---+-------------------------------------------------------+
|all |here
|rep|flp |
+--------+--------+---+-------------------------------------------------------+
|0.000002|0.000002|1
|monad |
|2.045486|0.376456|1 |[0] y flp~(;~)0
2$0 |
|2.045488|0.376458|1 |total
monad |
| // | // | |
// |
|0.000002|0.000002|
1|dyad |
|0.000772|0.000772|233|[10]
l=.l,next |
| // | // | |
// |
|0.001721|0.001721| 1|[14]
/:~l |
|2.045466|1.601660| 1|total
dyad |
| // | // | |
// |
|2.045488|1.601682|2 |total
definition |
+--------+--------+---+-------------------------------------------------------+
while, in J901:
JVERSION
Engine: j901/j64/windows
Beta-d: commercial/2019-04-21T12:38:39
Library: 9.01.03
Qt IDE: 1.8.2/5.12.2
Platform: Win 64
Installer: J901 install
InstallPath: c:/d/j901
Contact: www.jsoftware.com
load'jpm'
start_jpm_ 100000000
1785713
f 1000
117002
showdetail_jpm_ 'f' NB. OK - it does work for this cover fn
recorded all lines
used and max record count: 3,765 1,785,713
Time (seconds)
+--------+--------+---+---------------------------------+
|all |here |rep|f |
+--------+--------+---+---------------------------------+
|1.930585|0.000020|1 |dyad +/@:,@:((] #~ >:) +/"1@:flp)|
+--------+--------+---+---------------------------------+
showdetail_jpm_ 'flp'NB. the one I'm interested in!!!
|assertion failure: assert
| assert*./all>:her
I imagine that the record count isn't a problem
Is "jpm" deprecated now?
Thanks,
Mike
On 25/04/2019 17:51, Mike Day wrote:
Thanks. I wondered whether limits had changed. Is there any
user-control available re recursion? I usually try to avoid it,
but if I’m using someone else’s code...
Also - I can’t give chapter and verse right now as away from J901
with this iPad: I recently tried to use jpm to check timings on
lines of code but kept hitting an error when invoking
showdetail_jpm_ , no matter how large
the argument to start_jpm_ ,
Thanks
Mike
Please reply to [email protected].
Sent from my iPad
On 24 Apr 2019, at 19:32, Henry Rich
<[email protected]> wrote:
It did indicate trouble elsewhere. Thanks for the report.
The code still gives stack error in
J901. The recursion limit has
been reduced.
Henry Rich
On 4/24/2019 3:28 AM, 'Mike Day' via Beta wrote:
Another problem, (in Beta c as I'd rolled back) - not too
important in itself but might
indicate trouble elsewere
J Wiki Essay
https://code.jsoftware.com/wiki/Essays/Partitions#The_Number_of_Partitions
The/memo/adverb M.can be used to advantage here.
pn =: -/@(+/)@:($:"0)@rec ` (x:@(0&=)) @. (0>:]) M.
rec=: - (-: (*"1) _1 1 +/ 3 * ]) @ (>:@i.@>.@%:@((2%3)&*))
pn 1000
24061467864032622473692149727991
But:
pn 1000
|stack error: rec
| pn 1000
pn 100
190569292
JVERSION
Engine: j901/j64/windows
Beta-c: commercial/2019-04-03T11:03:34
Library: 9.01.03
Qt IDE: 1.8.2/5.12.2
Platform: Win 64
Installer: J901 install
InstallPath: c:/d/j901
Contact: www.jsoftware.com
whereas it worked in J8:
pn 1000
24061467864032622473692149727991
JVERSION
Engine: j807/j64/windows
Release-d: commercial/2019-03-18T13:21:35
Library: 8.07.25
Qt IDE: 1.7.9/5.9.6
Platform: Win 64
Installer: J807 install
InstallPath: c:/d/j807
Contact: www.jsoftware.com
Thanks,
Mike
---
This email has been checked for viruses by Avast antivirus
software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
---
This email has been checked for viruses by AVG.
https://www.avg.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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
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
