Puzzles/2147483647

Problem

Provide a sentence whose result is 2147483647.

Constraints

The following constraints are listed in order. That is, sentences which satisfy constraint N equally are selected from by constraint N+1. All sentences must satisfy constraints 0, 1, and 2.

0. Sentence must produce 2147483647. That is, satisfy 2147483647&-:@:".. This constraint is absolute.

1. The result must be guaranteed (predicted, fully supported) by the Dictionary. To put it another way, you may not leverage bugs in the implementation (but you may leverage bugs in the documentation). This constraint is absolute.

2. Assume you're running under $jconsole -jprofile: that is, you may not depend on any sentence having been executed before your own (but see the section "Note on display"). Put another way, do not rely on the names normally defined by the J standard library. This constraint is absolute.

3. Among sentences that satisfy the preceding constraints equally, those with the minimum number of characters composing nouns are preferred. That is, minimize +/@:(#&> * 0: = 3 : '4!:0 {.;:''u''[". ::0:''u=.'',y.'&>)@:;:.

4. Among sentences that satisfy the preceding constraints equally, those with the smallest number of words are preferred. That is, minimize #@:;:.

5. Among sentences that satisfy the preceding constraints equally, those the smallest number of total characters are preferred. That is, minimize #.

Note on display

Note that, in the default J configuration, integer 2147483647 displays in full, but floating point 2147483647 does not. If your sentence produces a floating point result, you may have to increase your print precision to see this value.

To do so, use 9!:11]16. You may assume that sentence has been run prior to your solution sentence, and that it does not count as part of your sentence.

Alternatively, you may append a single trailing x to one numeric noun in your sentence, and that character will not count as part of your sentence; it will be treated as if it were not there. That is, it does not count towards the number of characters composing the noun, nor towards the total number of characters in the sentence, nor towards any other constraint.

Spoiler Alert!

Solutions

See also

• Puzzles/170141183460469231731687303715884105727.

Further thoughts

Guidelines

I do not wish to break the standing solutions. But in retrospect, the following would have been constraints. Consider them guidelines.

0. Sentences should convey something meaningful or unique about 2147483647. This could never have been a constraint, as it cannot be defined rigorously. But, as examples, the number is:

   • The highest signed 32-bit IEEE integer: 2147483647 -: #. 0 , 31 # 1. 32-bit IEEE signed integers are a very common format as of this writing.

   • Prime: 1 -: # q: 2147483647

   • A Mersenne prime: 2147483647 -: <: 2 ^ p: 10.

   • An iterated Mersenne prime: 2147483647 -: <: 2 ^ <: 2 ^ p: 2 or 2147483647 -: (2&(<:@:^) p:) 2.

1. The challenge could be tightened with "minimize repetitions of primitives; that is, minimize >./@:(#/.~)@:;:". Put another way, given an arbitrarily long string of J verbs and a single digit number, any integral value could be calculated. The simplest example is: +/(],],], ... )1 using the appropriate number of repetitions of ,]. Though such solutions would lose out to versions using fewer verbs, they still evade the spirit of the challenge. Don't submit them.

2. Perhaps the nouns themselves should be minimized. That is, where two solutions which satisfy the other constraints equally, but one mentions only 2 where the other mentions 5, the former is preferred. But much thought would have to be given forms such as __ and 'literal', etc.

3. Given the display issue, perhaps the datatype of the output could be considered. That is, where two solutions which satisfy the other constraints equally, but one outputs an integer and the other a float, then the former is preferred.

Discussion

• The gerund idea is damn clever, Roger! -- DanBron 2006-05-16 16:32:25

• Can anyone come up with a solution that leverages the gerund idea and the facts: u ^: v y ↔ u^:(  v y) y and u^:(   v1`v2)y ↔ u^:(v1 y) (v2 y)? That is, u ^: ] f`g ↔ u^:(f`g) f`g ↔ u^:(f f`g) g f`g. Dyadic invocations u^:]~ f`g provide even more possibilities. Avoid using & because you may end up creating an infinite loop and crashing J (reported on System/Interpreter/Bugs).

• <:@^^:(2:`2:`5:)~2:`2:`5: works. Do you suppose <:@^^:]~2:`2:`5: would work according to the dictionary? -- BJonas 2006-05-17 10:43:08

  • Yes, this is a bug. I reported it yesterday. Check out System/Interpreter/Bugs

• I've changed the verb in rule 3 to +/@:(#&> * 0"_ = 3 : '4!:0{.;:''u''[".''u=.'',y.'&>)@:;: so that it work with j504 but it still has some problems, notably if the command contains NB. or =:. Thus I've now changed it to an entirely new verb. -- BJonas 2006-05-17 10:14:41

  • Hey, changed constraint 3 again: this version keeps the same meaning as the original, but it'll work in J5. -- DanBron 2006-05-17 13:50:13

  • "but"? What's the difference in meaning from my +/@:((3 :'1[3 :y.0'::0: * #)@>)@:;:? -- BJonas 2006-05-17 14:02:32

  • The rule is meant to be read and used by people. While 3 :y. does the right thing, 4!:0 says what the right thing is. To put it another way: if you wanted to change constraint 3 to enforce the minimization of characters that compose verbs, how would you modify your verb? I would change 0: to 3:.

  • Ok, that's right, it is more readable. However, wouldn't it be possible to say <''u'' instead of {.;:''u''? Also, for me, it was a bit confusing that the original verb used u as a regular variable but y as a magical variable containing the verb argument. I probably wouldn't have composed an assignment an evaluate it with ". because I have a strong feeling against evaluating strings even though that feeling shouldn't be applicable to J. I'd have done this: #@:;@:(#~ 0: = 3 :'try. t=.a:1 :y. catch. _3 return. end. 4!:0<''t'''@>)@:;: and here you can replace the 0: with whatever word class you want, except that new words are counted as verbs. -- BJonas 2006-05-17 21:00:30

  • Yes, <'u' would work properly. However, as a matter of pratice, I "say what I mean" rather "say what works". In this case, what I mean is "the name u". A name is a token, and monad ;: is the tokenization function. I read 4!:0 {.;:''u'' as "nameclass of the first word in the string 'u'". This future proofs me: notice how I can still use ;: in the suggested constraints below (and note that -. (<'u') -: {.;:'u').
    
    I share your distaste of monad "., but it's the lesser of two evils here (try. ? Bleh!). And I see you dislike the repetition of &>. I do too, but there are certain cases where I've gotten in the habit, due to performance issues (not that performance is relevant in this situation).
    
    How do the following strike you?

    • ([: +/ #&> * 0: = 3 : '4!:0 {. (;: [ ". ::]) ''name=.'',y.'&>)@:;:

    • ([: #@; ] #~ 0: = 3 : '4!:0 {. (;: [ ". ::]) ''name=.'',y.'&>)@:;:

    -- DanBron 2006-05-17 22:20:14

• By the way, congrats on your 16! I had tried <:(#^".){.&>3:`1: but it wasn't an improvement, so I didn't post it. But o2147483647` is clever!

  • That's nice, and it can be combined with 6 to get the better #.*i.".{.&>3:`2:. Much better than the riddiculous #.*i.(3:u:{:){:>?.`? I thought of. -- BJonas 2006-05-17 13:59:28