@Henry – that's exactly the approach I'm playing with. And have been for
most of this century, in one form or another (as browsing my old scripts on
apposite keywords reveals to my shocked eyes).
A recent insight is as follows. Assuming the basic test expression:
assert Result -: trialExpression
for most purposes this is good enough:
assert ApparentResult -: ": trialExpression
and (ApparentResult) is a darn sight easier to rip from an exploratory
session log.
Sure it needs extra (trialExpression)s with ($) and (L.) in them. But the
fun in writing a test script is not in the first draft, but touching-up
later. Sometimes MUCH later.
BTW it needs something slicker than ": to handle the general case of
emulating session log output in immediate mode, but you'll get the idea.
The problems typically rear their ugly heads months later, maybe years
later, when you're deep into pondering something else. The last thing you
want then is to have go debugging an obsolete testing apparatus, or
puzzling out an arcane test expression. I've learned to prize the simplest
of test scripts which rest on the firmest of foundations: J primitives
(ideally). No, not even on stdio, which can change in the course of a
decade.
Another approach, with maybe more future, is to generate test expressions
which are closer to "tautologies" as mathematical logicians think of them:
a chain of verbs (typically a branching one!) which ends up with the
original result. In other words make a test script consisting solely of
verbs equivalent to (]) over some domain of validity. The problem then
reduces to one of exploring the boundaries of the said domain.
It's easy then to hurl random input at it -- or more sensibly an
ever-growing rogues' gallery, such a stable of empty inputs… ('') (0$0)
(i.0) (i.0 0) (a:) (0$<' ') …etc, etc.
It's worth bearing in mind that your tautological verb may not only fail to
map input onto input but may often crash… and you have to puzzle out why.
At 5 AM – with a deadline at 8.
For those few of us who wonder if I'm making a mountain out of a molehill,
I admit that most of what I write can be tested on loading in one easy
line, and I even neglect to do that. Problems only arises when you maintain
a decades-old kluge with multiple and increasing modes of operation which
must respond sensibly to whatever the user cares to throw at it -- the
imbecile user, with genius inventiveness, who doesn't even know it's there.
Example: the addon: math/uu.
MORAL: never work on anything mission-critical.
Ian
On Sat, Jun 16, 2018 at 2:06 PM, Henry Rich <[email protected]> wrote:
> Certainly, J doesn't do math. The question is, Is the executable notation
> mathy enough that you can reason mathematically about the computations? I
> haven't been able to, but maybe someone could find a set of transformations
> that is enough for progress in this area.
>
> On your session-log problem: how about a script to take the session log,
> find the lines beginning with 3 spaces, treat the rest as results, and
> either create the assertions automatically or execute the sentences and
> compare them against the results?
>
> Henry Rich
>
>
> On 6/16/2018 7:18 AM, Ian Clark wrote:
>
>> Thanks, Henry.
>>
>> Yes… it's all very much not obvious to me too.
>>
>> I was going to mention NuVoc:
>> http://code.jsoftware.com/wiki/Vocabulary/ampdot — but I felt ignorance
>> would suit me better.
>>
>> How to present theorems (propositions?) in J would be good to standardize.
>> How to prove them (run them?) even better.
>>
>> Right now I'm writing test scripts and I'm bog-eyed with typing out assert
>> (".phrase) -: (result) over and over again in multifarious forms from an
>> extensive session log. Every six months I devise a new solution to this
>> perpetual problem – and six months later I reckon it's a dog!
>>
>> Until that's sorted, I can't pretend to myself J does math. J does
>> calculations.
>>
>> Ian
>>
>> On Sat, Jun 16, 2018 at 3:35 AM, Henry Rich <[email protected]> wrote:
>>
>> It's a theorem:
>>>
>>> [x] >@(f each) y
>>>
>>> [x] >@(f&.>) y
>>>
>>> [x] >@((<@:f)&>) y
>>>
>>> [x] (>@(<@:f)&> y
>>>
>>> [x] (>@:<)@:f&> y
>>>
>>> [x] f&> y
>>>
>>> [x] (f every) y
>>>
>>>
>>> Some of these steps are very much not obvious IMO. And you have to get
>>> the rank of each right, that is, use the NuVoc definition of &. rather
>>> than
>>> the Dictionary one.
>>>
>>> Henry Rich
>>>
>>>
>>> On 6/15/2018 8:30 PM, Ian Clark wrote:
>>>
>>> I've checked Chapter 1 off, but that's only to say I've checked out the
>>>> code and verified it gives the results claimed. I didn't see it as my
>>>> job
>>>> to rewrite the treatment to make it clearer – which I can't do anyway
>>>> without being sure what the author is trying to convey.
>>>>
>>>> I must confess that first section completely baffles me. I cannot see
>>>> how
>>>> to relate the "general rule" to actual examples of J code, although the
>>>> article goes on to do just that … it seems. Does the "rule" represent
>>>> real
>>>> working J code? – even in a generic sense? Is it even true? (Theorems
>>>> have
>>>> to be true, but rules only have to be obeyed.) If it isn't always true,
>>>> am
>>>> I to understand it as a rule-of-thumb?And if it is in fact universally
>>>> true, what procedure must I, the novice reader, follow in order to
>>>> convert
>>>> the "generics" into "specifics" to verify the fact?
>>>>
>>>> I'd be grateful for someone to cast light on the matter. Failing which,
>>>> maybe I ought to remove my green checkmark, stand aside to let someone
>>>> else
>>>> scratch their head over it.
>>>>
>>>> On Sat, Jun 16, 2018 at 12:41 AM, David Lambert <[email protected]>
>>>> wrote:
>>>>
>>>> 50 Shades of j chapter 1 now says that rule is completely general. I'm
>>>>
>>>>> somewhat weak on j transformations and proofs, although what was there
>>>>> was
>>>>> incorrect because of a counterexample:
>>>>>
>>>>>
>>>>> every=.&> NB. uses compose
>>>>> each=.&.> NB. uses under
>>>>> rule =: (f every) -: >@(f each)
>>>>>
>>>>> NB. Is completely general?
>>>>>
>>>>>
>>>>> thank you, Dave
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> 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 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
