diana_coman: asciilifeform, hm, I can't say that I have a very clear idea of ALL potential implications but atm I don't see some specific downside to that; I suppose the alternative would be to raise an error on gcd(0,0)?
asciilifeform: i'ma leave it permitted for nao, and if somebody has persuasive arg why to prohibit, will listen.
diana_coman: other than that the "reason" I can see is that otherwise in principle you need an additional check each time you call gcd (i.e. to make sure you don't step even if once in a blue moon) on this particular rake
a111: Logged on 2019-01-09 14:14 diana_coman: my trajectory in hitting walls on this was precisely that: make it static -> surprise, no adainit exported/included, checked the .a file and everything, went nuts; make it dynamic -> ugh, need -lgnat and whatnot; rtfm again and again, there is this calo-magar
diana_coman: but now I'm confused on whether *that* is enough or not (standalone thingie claims it takes care of everything needed for elaboration, correctly)
asciilifeform: diana_coman: if your 'main' is a c/cpp proggy , you gotta trigger the elaborator 'by hand', regardless of which type of lib your ada coad is in, afaik.
diana_coman: asciilifeform, yes, but is the one generated for static lib the same? or wtf is with the encapsulated-shit then?
diana_coman: because in the docs it's claimed that non-ada main should be with the encapsulated-lib version, ugh
asciilifeform: last time i touched the subj with own hands, i concluded that elaborator isn't even permitted in static ada lib.
asciilifeform: but i cannot yet say conclusively. diana_coman is at the bleeding edge of this q.
diana_coman: so far it certainly feels like bleeding, dunno about edge
asciilifeform: diana_coman: what i meant was, my proggy has no elaborator, and yours -- has, so i am not qualified to say 'here's how to fix elaborator in static lib' of yet.
asciilifeform: diana_coman: if you're utterly stumped, i can allocate some cycles to the problem tomorrow -- with mircea_popescu's permission ( i swore to him that i will not embroil meself in matters euloric , recall )
asciilifeform: ... or i suppose if yer still stumped next friday night, then.
asciilifeform: would still be handy if someone knew of a smaller bound for s, but not burning q.
asciilifeform: btw per asciilifeform's chalkboard, the physical cost of constanttime m-r is ~equal to that of (2 modexps of the given width) x (number of witnesses) .
asciilifeform: this means that the use of gcd litmus very muchly wins.
asciilifeform: take for example diana_coman's system , where 16 witnesses are used. ( i'd use moar, but let's go with the example. ) so if we're generating 2048b primes (for 4096b rsa mod), per ch.14b timings on asciilifeform's iron this costs ~2.9s per modexp, and thereby ~93sec per m-r procedure.
asciilifeform: per the ffa plan, 'P' command will take two numbers from the stack, a candidate integer and a witness. author of pcode tape determines how many witnesses to use, he iterates by generating witnesses and calling P repeatedly as many times as he wants
asciilifeform: ( in each invocation, P returns 1 if m-r didn't 'go bang' and a 0 if did. )
asciilifeform: presently looping is prohibited in pcode, in later ch. will be introduced. (but i am spoiling things..)
asciilifeform: the only 'magic number' in ffa is the concession that all FZ must be at least 256bits long
asciilifeform: and this was forced by the irons ( it's evenly divisible by all known bus widths )
asciilifeform: ( re 'how many witnesses', see diana_coman's article, it reviews the necessary maffs, i.e. P(yer prime aint a prime and you die) == (1/4)^n, where n is # of witness )
asciilifeform: observe that by this scheme, we also avoid hardcoding primorials for 'G' test. author of tape is responsible for including a primorial ~for his chosen ffawidth~ if he intends to use G litmusing.
asciilifeform: consider from pov : there is no particular reason for enemy to know precisely ~how~ you baked the primes for yer privkey.
asciilifeform: a 'graduate' of ffa (i.e. fella who ~read~ the thing, as it was intended to be read, and fit-in-head) will have no trouble writing his particular variant of correct prime generator for his particular type of key.
asciilifeform: i'ma include a few obvious approaches as example tapes, but it is NOT the intention that anyone use'em as-found.
asciilifeform: 'peh' is intended as a working, weaponized demonstration of the 'specificity of diddling' principle. (but perhaps this was obvious to errybody.)
a111: Logged on 2019-01-11 16:49 asciilifeform: diana_coman: if you're utterly stumped, i can allocate some cycles to the problem tomorrow -- with mircea_popescu's permission ( i swore to him that i will not embroil meself in matters euloric , recall )
diana_coman: so far I can tell that the static lib has the huge disadvantage that one needs then to link with it everything but the kitchen sink to bring in all it needs from ada runtime
diana_coman: so that'd be at least the "encapsulated" part explained
asciilifeform: diana_coman: plz dun see the orig statement as ' asciilifeform presumes that diana_coman is dummkopf and problem is trivial, asciilifeform can do it with 1 hand '. i simply dun like to see people sitting stuck, is all.
asciilifeform: and ftr i'm surely doomed to run into diana_coman's puzzler myself, when i go to write a threaded proggy (e.g. adaized trb)
diana_coman: asciilifeform, I know, no worries at all! onth I'm not going to *sit* stuck, no - digging at it
a111: Logged on 2019-01-11 17:48 asciilifeform: ( re 'how many witnesses', see diana_coman's article, it reviews the necessary maffs, i.e. P(yer prime aint a prime and you die) == (1/4)^n, where n is # of witness )
asciilifeform: err, nm, lol, they're same thing, asciilifeform prolly oughta go to bed