[racket] slow g^x=h mod p meet in the middle code
În data de Thu, 27 Feb 2014 17:04:51 +0200, Neil Toronto
<neil.toronto at gmail.com> a scris:
> On 02/27/2014 07:55 AM, Jens Axel Søgaard wrote:
>> 2014-02-27 15:23 GMT+01:00 Cristian Baboi <cristian.baboi at gmail.com>:
>>> Hello,
>>>
>>> I recently used racket for a math assignment in a crypto class because
>>> of
>>> big numbers support. Others used python, java, haskell and bragged with
>>> short execution times. Is there anything I can do to speed up the
>>> following
>>> code or is my computer too old ?
>> First make sure you use the same algorithm. Post it!
The same algorithm as the algorithm scheme was described in the assignment.
Minor details can be different.
>> Second: (modulo (* l gm1) p) looks inefficient.
>> If l and gm1 are large, then it is more efficient
>> to reduce modulo p first, then multiply, then reduce
>> again.
Well, gm1 and gB are already reduced modulo p ...
The only one who is not is l which is lower than B which is lower than p.
>> Since all your calculations are modulo p, you can use with-modulus and
>> mod*.
Makes no difference.
>> Third: When benchmarking turn off display and use racket (not DrRacket).
Why? I don't print much.
>> Fourth: Use Racket hash tables rather than rnrs ones. (I haven't
>> looked, so
>> I am unsure how they are implemented - maybe they are slower - maybe
>> they
>> are the ok)/
I don't know how. What keywords should I search for in the documentation ?
>> Without changing the algorithm, I get this:
>>
>> #lang racket
>> (require math)
>> (require rnrs/hashtables-6)
>> (define p
>> 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084171)
>> (define g
>> 11717829880366207009516117596335367088558084999998952205599979459063929499736583746670572176471460312928594829675428279466566527115212748467589894601965568)
>> (define h
>> 3239475104050450443565264378728065788649097520952449527834792452971981976143292558073856937958553180532878928001494706097394108577585732452307673444020333)
>> (define B (expt 2 20))
>>
>> (with-modulus p
>> (define gB (modexpt g B))
>> (define gm1 (modular-inverse g p))
>> (define (mx x0 x1) (+ (* B x0) x1))
>>
>> (define (hash n ht l x1)
>> (cond
>> [(> n 0) (hashtable-set! ht l x1)
>> (when (< x1 10) (displayln (list x1 l)))
>> (hash (- n 1) ht (mod* l gm1) (+ x1 1))]
>> [else (hashtable-set! ht l x1)
>> ht]))
>>
>> (define (htbl) (hash (- B 1) (make-eqv-hashtable B) h 0))
>> (define (gol) (make-eqv-hashtable B))
>>
>> (define (caut n ht l x0)
>> (cond
>> [(> n 0) (define x1 (hashtable-ref ht l -1))
>> (when (< x0 10) (displayln (list x0 l)))
>> (if (eqv? x1 -1)
>> (caut (- n 1) ht (mod* l gB) (+ x0 1))
>> (cons x0 x1))]
>> [else (define x1 (hashtable-ref ht l -1))
>> (if (eqv? x1 -1)
>> (cons -1 -1)
>> (cons x0 x1))]))
>>
>> (define run (caut (- B 1) (htbl) 1 0))
>> (define x (mx (car run) (cdr run)))
>> (displayln x))
>
> I'm not sure what the hash tables are for, but they're apparently the
> culprit. When I removed them, I got 1048575 in a few seconds. (I had
> `hash' return `x1', which I passed to `caut' instead of a hash table.)
They are for "meet in the middle". The "caut" stops when a match is found.
hash compute one "hash" table and "caut" use it.
> For this algorithm, is it necessary to keep all the intermediate values
> computed by `hash' in a hash table?
Yes! The correct answer is 375374217830.
Your changes give the same running time as my version: ~ 3 min on my
computer in DrRacket.