You do not want to do reply='yes' because
'no'='yes'
|length error
You might want to do (3=#reply)*'yes'=3{.reply though that should
strike you as unnecessarily elaborate.
You probably want to do
'yes'-:reply
Or, perhaps
'yes' -: deb tolower reply
But let's take a couple steps back:
Generally speaking, when working with text, you need to be thinking
about two versions of the text - the normalized version and the
display or original version.
The normalized version tries to approximate the sorts of mental
shortcuts people will likely be using (most people don't quite
understand just how fussy computers really are). The other version
tends to be a more accurate representation of what was received or
what will be displayed.
Depending on what exactly you are doing, though, you will tend to have
different "normalized" representations in different parts of your
system. (Sometimes you might need a version which matches up
character-for-character with the display version, for example.)
It's the job of the programmer (and the designer, and occasionally
others) to understand and deal with these issues. And there's a
constant tension here where everyone winds up pulling in different
directions. So there's never a perfect approach, the best approach
keeps changing, many approaches are unacceptable and a smaller set of
approaches are at least tolerable.
So, anyways, another approach might be something like:
'y'={.response
Thanks,
--
Raul
On Fri, Jan 12, 2018 at 1:57 PM, Nick S <[email protected]> wrote:
> Hmm, is it better, in general to code that as
>
> *./ reply = 'yes'
>
> or
>
> */ reply = yes
>
> or
>
> reply -: 'yes'
>
> or maybe
>
> (<,tolower reply) e. (,'y');'ye';'yes'
>
> I know, my actual question is,
>
> When I work with booleans I always try to use and and and or to maintain
> boolean results.
>
> I have noticed in other people's code that they use ordinary arithmetic to
> get the same results - that is,
>
> */boolean and
>
> *./boolean
>
> will give the same result, while
>
> +/boolean
>
> and +./boolean
>
> will both give a non-zero result if anyone of the booleans are true.
>
> blahblah =. ? 100000 $ 2
>
> 5000 (6!:2) '*./blahblah'
> 5.05174e_7
> 5000 (6!:2) '+/blahblah'
> 3.18783e_5
> 5000 (6!:2) '+/blahblah'
> 3.13969e_5
> 5000 (6!:2) '+./blahblah'
> 6.88214e_7
> 5000 (6!:2) '+./blahblah'
> 6.90688e_7
> 5000 (6!:2) '*./blahblah'
> 6.73963e_7
> 5000 (6!:2) '*/blahblah'
> 7.35488e_7
> 5000 (6!:2) '*/blahblah'
> 6.72256e_7
> 5000 (6!:2) '*./blahblah'
> 7.08182e_7
>
> So it looks like there is little difference between */ and *./ while +/ and
> +./ are very different - perhaps +./ somehow shortcuts so that it can stop
> after it finds the first true. I wondered how much optimization there was
> for these common cases and I wondered whether about somehow getting around
> the optimizations:
>
> 5000 (6!:2) '+.`+./blahblah'
> 0.00992467
> +.`+./blahblah
> +.`+./blahblah
> 1
>
> Yeah, we had a long pause when I hit enter on my test case - there must be
> a huge amount of optimization on the normal case.
>
>
> Is this all a matter of using the right optimized cases? I like the fact
> that the nuVoc calls out some of the optimized cases.
>
> But certainly if you are not working with boolean data, the overhead of
> calculating the LCM and GCD of numbers when all you really care about is
> the zero or non-zero value really makes it important that you reduce the
> data to boolean using a simple test first:
>
> blahblahx =. ? 100000 $ 32000
> 5000 (6!:2) '+/blahblahx'
> 9.56426e_5
> 5000 (6!:2) '+/blahblahx'
> 9.69338e_5
> 5000 (6!:2) '+./blahblahx'
> 0.00655577
>
> 5000 (6!:2) '*/blahblahx'
> 0.000104107
> 5000 (6!:2) '*./blahblahx'
> 0.00610307
> 5000 (6!:2) '*/0 ~: blahblahx'
> 8.20438e_5
> 5000 (6!:2) '*./0 ~: blahblahx'
> 8.02292e_5
> 5000 (6!:2) '+/0 ~: blahblahx'
> 0.000109099
> 5000 (6!:2) '+./0 ~: blahblahx'
> 7.78428e_5
>
> I guess I am answering my own question by asking it. As a relative novice
> I find this interesting.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
