158400+ entries in 0.101s
mircea_popescu: 2. a fine example of how "i work for
the web man" rots
the brain, is
that in an implementation of
the above discussed mod-distributiver,
the "common" consensus impulse would be
to add a
test, make sure
the list elements respect
the condition of <modulus.
this however is very much
the wrong
thing ; and it is a
tmsr-graduate level question
to explain why and wherefore.
☟︎ mircea_popescu: 1. if you actually want metal kbd, your choice of steel is probably ill advised. i'd
try silver instead. heuristicallyt
there's a reason gunsmiths and silversmiths were ~the same people i nthe early modern period ; moreover silver has better properties in
the range sough.
☟︎ mircea_popescu: anyway,
three points since i got a blowjob and apparently
this inspires me.
phf goes
to sleep instead
phf:
http://btcbase.org/log/2017-09-12#1712367 << i've went
through many layout modifications, but i finally settled on just having () and [] switched around. it's convenient both for prose and lisp (not so much heathen languages
though)
☝︎ phf:
http://btcbase.org/log/2017-09-12#1712362 << i actually use
this one pretty frequently when i
type for identifiers, abbreviations and section headers in notes. really any
time i need
to
type more
than 2 capitalized letters in a row..
☝︎ mircea_popescu: asciilifeform im pretty sure i read
the whole knuth as a
teen, so it's likely just memory at work.
mircea_popescu: but
that inconvenience is not
the same as
the "Same number of cycles" claim.
mircea_popescu: i'll
take your word for it if you say so ; i've not looked at
them closely in comparison.
mircea_popescu: this holds for arbitrarily large numbers, and i suspect will be faster
than classical.
mircea_popescu: if you want constant
time, you feed
the list 9, 0,0,0,0,8,0,0,1. it will do 18, 1, 18, 1, 18, 1, 18, 1 etc.
mircea_popescu: ok. ima just
take
the 137
tail cuz lazy. 137 is 10001001. we have precalculated
that 128 mod 17 is 9, and
that 8 mod 17 is 8, and
that 1 mod 17 is 1
mircea_popescu: asciilifeform if
this is
true,
then
the above method should be way faster.
mircea_popescu: whether
this approach is actually faster
than
the current mod of 97 as implemented via knuth is open
to discussion, i guess.
mircea_popescu: consider
the number 97. is is 1100001.
they do mp_mod (2^6, 2^5, 2^0) ; you can do (2^6, 2^5, 0* 2^4, 0* 2^3,0* 2^2,0* 2^1,2^0).
the list method will sitll work, but
this
time in constanttime.
mircea_popescu: it's not automatically bad just for being a list ; you don't have
to pare it down.
mircea_popescu: but
the important point re
that, is
that whenever
they use a reduced matrix we can STILL use
the ufll matrix!
mircea_popescu: this may or may not be cheaper ; but in general you would build a list of
the pre-calculated mods of all
the powers of 2 up
to your bitness and save
that
to save on work.
mircea_popescu: it is also extensible in
the sense
that if you wish
to compute
the mod of a 512 bit number, you can cut it up into as many powers of
two as
there are 1's, feed it into
this, and get a modulus.
mircea_popescu: asciilifeform well, modulus bitness sum as opposed
to N bitness sum. but sure.
mircea_popescu: but
the original idea was
that it is indeed cheaper
to mod
the parts
than
the whole sum.
mircea_popescu: well, i dunno how expensiuve addition is and how much it adds
to
the mod.
mircea_popescu: in any case : you run it until same length list ; smallest int on it will be
the correct mod. always
terminates, always constat
time etc.
mircea_popescu: you feed into my above function
the list 6, 9, 15. it adds
them : 30. it
then writes down 30 -17 ie 13. it
then writes down 13 + 17 = 30. it has peroduced a list as long as
the original (3 elements), among which
the SECOND is
the modulus of 1433293 +7926803 +9266137
mircea_popescu: let's
take fucking numerical examples already. a = 349087340 ; b = 1209843095 ; c = 753059056. mod = 17. << final!
mircea_popescu: you can ALSO do : 349087340 mod 7 = 0 holy motherfucking crap omfg what is
this.
mircea_popescu: let's
take fucking numerical examples already. a = 349087340 ; b = 1209843095 ; c = 753059056. mod = 7.
mircea_popescu: let's
take fucking numerical examples already. a = 349087340 ; b = 1209843095 ; c = 753059056. mod = 5.
mircea_popescu: will necessarily have
the modulus of
the sum.
this entire procedure is constant
time.
mircea_popescu: alrigthy, so. you
take a list of numbers. you add
these numbers. you write
the result down. you compare
this result with
the modulus. if
the result is smaller
than
the modulus, you add
the modulus
to it and write it underneath ; if larger, you substract
the modulus and write it underneath. you repeat
this step until you have a list of added/substracted moduli
to
the result AS LONG as
the original list of elements. in it, you
mircea_popescu: alright.
then let me
tell you how
to do it, and if you fucking say you did it in july ima buy a plane
ticket and hang you by
the
tallest petard.
mircea_popescu: is it
true or is it false
that you understand how
to make modulus calculations distributive wrt addition ?
mircea_popescu: now back
to
the issue. 1. is it
true or is it false
that currently sums are calculated before
the modulus of
the result is calculated ?
mircea_popescu: asciilifeform is
the plan here
to just keep adding reading material paper over fire ?
mircea_popescu: well, let's
try and salvage
this nonsense
through
the mafgic of yes and no questions.
mircea_popescu: <mircea_popescu> "it" in 3 is mod ? or what ? asciilifeform> aha mod asciilifeform> i was speaking specifically of
the division algo
mircea_popescu: but, what you say on
this
topic is in some proportion not
true.
mircea_popescu: and congrats, you've closed
the liar circle on yourself.
the only
task remaining is
to establish whether alf lied when he claimed
that mp's distributive-mod algo is already in his ffa since july ; or rather he lied when he claimed distributive mod would actually be useful ; or at some other juncture.
jhvh1: shinohai:
The operation succeeded.
mircea_popescu: "have you
thought about what'll you do about lingerie ?
TRIBAL GIRLS CANT WEAR ANY!"