mircea_popescu: so im trying out being 70s, what. do you want me to go in unaware, end up surprised by it ?

diana_coman: http://btcbase.org/log/2017-10-07#1722059 <- yes, I got that as part of my previous log combing on this

a111: Logged on 2017-10-07 00:26 asciilifeform: http://btcbase.org/log/2017-09-16#1715214

shinohai: http://archive.is/4Jc5B <<< Imagine the Furher parents must have felt .....

asciilifeform: '“the year is 1935 and you have been tasked with creating a mascot to represent the Nazi party at its political rallies.” “Think about all of the information you have learned about Hitler and the Nazi party,” the assignment directed. “You will create a COLORFUL illustration of the mascot. Give the mascot a NAME. You will also write an explanation as to why the mascot was chosen to represent the Nazi party.”'

asciilifeform: lol!

asciilifeform: '...I think a formal apology should be handed out, and the teacher involved should be reprimanded,” he added. '

BingoBoingo: !~ticker --market all

jhvh1: BingoBoingo: Bitstamp BTCUSD last: 4350.03, vol: 5177.09336958 | Bitfinex BTCUSD last: 4359.5, vol: 16987.47514348 | BTCChina BTCUSD last: 4229.3316, vol: 0 | Kraken BTCUSD last: 4359.5, vol: 2319.21013539 | Volume-weighted last average: 4357.49756913

mircea_popescu: anyone came up with inflatable clitler ?

BingoBoingo: You mean http://www.spencersonline.com/product/inflatable-hillary-bop-bag-12-inch/128370.uts?Extid=sf_fqntra

BingoBoingo: brb

asciilifeform: in other puzzlers, http://wotpaste.cascadianhacker.com/pastes/6l4uH/?raw=true << mod6 et al

asciilifeform: ^ this 'upper half only' karatsuba works, but the answer is always off by 0 to 3, because the carries from the bottom halves are ( recursively ) lost. somehow gotta be finessed.

asciilifeform: http://wotpaste.cascadianhacker.com/pastes/TgRkm/?raw=true << ordinary karatsuba, for convenient comparison.

asciilifeform: ( Karatsuba_Term is same for both )

asciilifeform: now! this procrusted-karatsuba is only used for the barrettron, so theoretically could compensate for that 3 with 3 additional subtractor-muxes. and still win ~4x speedup vs last night's . but this is mega-ugly.

asciilifeform: ( if it isn't obvious from where the error comes : observe the 3 Karatsuba_Term additions. in ordinary K., they walk over the upper half of XYLo ( lower half of result.) but in TopOnly K. we lose XYLo, so that carryolade is lost. )

asciilifeform: ... could even live with this, if i had a hard proof that it's never moar than 3.

asciilifeform: heya hanbot

asciilifeform: hanbot: wanna try yer hand at ^ puzzler ?

deedbot: http://trilema.com/2017/friday-night-or-las-moiras-revisited/ << Trilema - Friday night, or Las Moiras revisited.

mod6: <+asciilifeform> in other puzzlers, http://wotpaste.cascadianhacker.com/pastes/6l4uH/?raw=true << mod6 et al << /me looks

mod6: btw, do you have a simple test harness setup for this just to assert some known output values?

asciilifeform: mod6: i've been using (unreleased) 'p' as the tester.

mod6: ah. gotcha.

mod6: i think ima make a quick one for myself just so i can see what youre sayin on stuff like that.

asciilifeform: mod6: you should have one already, the factorial thing

asciilifeform: ( it will need a small adjustment in re http://btcbase.org/log/2017-10-02#1719728 but otherwise oughta work )

a111: Logged on 2017-10-02 19:31 asciilifeform: note also that the calling style from early versions will not work, there is no longer a .Z , FZ is not a struct any moar, it is just a word array

mod6: aha, one similar to that. although, indeed, that works too.

mod6: i'd like to also maybe make some unit tests around your procedures/functions.

asciilifeform: i've been holding off on releasing the p-interpreter because there are several quite broad changed in the way that it worx, in the pipeline, and i'd rather folx not get used to the old form.

asciilifeform: *changes

mod6: im basically going to have to do this anyway -- this helps "fitting in mod6

mod6: 's head"

asciilifeform: mod6: unit tests will work as pcode known-good in/out pairs

asciilifeform: currently i generate them with a pyturd

mod6: ah, ok. and yah, no need to let p out of the garage until ffa is pretty much "there".

asciilifeform: it is tempting, because currently i suspect that ~nobody is actually running my pastes

mod6: mainly, I read through them. because, there's still a lot for me to grok here. and it's easy to fool oneself into groking if you treat it like a blackbox instead of actually reading the code.

mod6: (other than the ffa-fact, which i use sometimes to try new, whole, ffa parts out)

asciilifeform: mod6: http://wotpaste.cascadianhacker.com/pastes/0k78K/?raw=true << example from asciilifeform's torture room, of what his test looks like

*mod6*

*looks*

asciilifeform: ^ the 'two second' item, modexp

mod6: niiice.

mod6: yeah, something simple like this is a good starting spot.

asciilifeform: mod6: http://wotpaste.cascadianhacker.com/pastes/H4UGn/?raw=true << for comparison, py script computing same arithm problem

asciilifeform: you can run it, get same answer.

asciilifeform: ( interestingly, it takes 3.8 sec on my box )

asciilifeform: this is even though python uses a c bignumatron internally.

*mod6*

*looks*

asciilifeform: phun phakt, this calculation is taken from the gpg autopsies last summer, when asciilifeform was chasing imaginary rng boojum after somebody found a real one

mod6: sweet. is pretty interesting tho.

mod6: ahh, right. i recal.

mod6: *recall

asciilifeform: in ffa, unlike in the python example, elongating the 0x10001 to full ffawidth will not change the required time.

asciilifeform: ( nor will anything else. )

mod6: :]

mod6: super-cool

asciilifeform: out of curiosity, how long the py item takes on mod6's box ?

mircea_popescu: and in other curiosities, did http://trilema.com/2015/okcupidcom-the-dating-site/#comment-116639 ever come to anything as far anyone knows ?

mod6: <+asciilifeform> out of curiosity, how long the py item takes on mod6's box ? << was just saving... lemme give it a try here. want me to try it on the i5/8gb box ?

mod6: running...

mod6: ok here 'tis:

mod6: grabbed 3 runs for good measure

phf: (3s on python, 9s on cmucl, 1.2s on sbcl)

shinohai: Python - 0m3.720s for me

mod6: (fwiw, that machine I just ran it on has Python 2.7.9)

mod6: im gonna try it on the build-donkey box, core2duo/4gb

shinohai: (same)

asciilifeform: phf: now try same width exponent !

mod6: and same version of py there too. ok just a sec.

asciilifeform: betcha it won't be 1.2s nomoar

asciilifeform: on heathentron

*asciilifeform*

*bbl : meat.*

mod6: ok here it is:

mircea_popescu: sbcl is actually the champ ?!

shinohai: Anyone have the lisp version handy?

phf: asciilifeform: wait, that seems like a cheap sleight of hand. obviously increasing number of iterations in an iterative algorithm that you gave is going to increase run time

phf: shinohai: http://p.bvulpes.com/pastes/ZqN4y/?raw=true

shinohai: ty phf

mircea_popescu: phf his point is that if you're going to compare fixtime with something else, better make sure you get a long case in there too.

phf: mircea_popescu: well he either has a constant time algorithm in ffa, in which case if the goal is to compare speed specifically we should be comparing fixtime ffa and fixtime something else. otherwise he has a variable time algorithm running at worst case constant time, in which case the comparison is between base operation speed, which is still going to come out on top

phf: i guess the point of this exercise is to show that iteration sizes further leak timing information

mircea_popescu: you're not having any of this new fangled "constant time ~= fixedtime ie, variable time running at worst case" ?

phf: well, it's conveniently two strategies: closed form solutions and constant iterators. if you don't have a closed form solution, you have to iterate, which you simply do at the upper bound constraint by a data type size. i don't see how theoretically it can be anything else

mircea_popescu: myeah

shinohai: I get 0m1.236s using sbcl (i5)

phf: i suspect that ffa's take on expmod is to iterate over every bigit of the exponent, which will have to perform base operations no matter what the numeric size is, but that's a guess.

mircea_popescu: why guess, tis published.

phf: i'm trying to figure it out from first principles :) (i haven't had time to look at the recent, i.e. past month, versions yet)

mircea_popescu: my guess is that it's as close to closed form solutions as possible, hence all the barrett fucking etc, but then again i'm a weak programmer and a very dubious mathematician.

shinohai: http://archive.is/iDKq8 <<< Damned Gypsies!

asciilifeform: http://btcbase.org/log/2017-10-07#1722372 << in fact we have closed form.

a111: Logged on 2017-10-07 16:49 mircea_popescu: my guess is that it's as close to closed form solutions as possible, hence all the barrett fucking etc, but then again i'm a weak programmer and a very dubious mathematician.

asciilifeform: http://btcbase.org/log/2017-10-07#1722358 << point was exactly to compare like items. i.e. heathendom does NOT get to 'win' by 'oh hey the hamming weight of exponent is only 2, not 4096, so we only do 4 modexps and not 8192'

a111: Logged on 2017-10-07 16:26 phf: asciilifeform: wait, that seems like a cheap sleight of hand. obviously increasing number of iterations in an iterative algorithm that you gave is going to increase run time

asciilifeform: the interesting imho discovery is that heathen bignumtrons don't win much (or even any!) speed by normalizing the ints being added/subtracted

asciilifeform: i also suspect that they are in fact slower for maxhammingweight case of exponentiation and modulus, vs ffa.

asciilifeform: slow and broadcasting seekritz for miles around, whatsnottilike!!111

asciilifeform: 'старый и злой -- чем не жених!' (tm)(r)

asciilifeform: and incidentally my base cases are ultra-slow, in theory

asciilifeform: 0 asm

asciilifeform: so a word mul is actually five MULs

asciilifeform: because gotta get upper word somehow

asciilifeform: http://btcbase.org/log/2017-10-07#1722376 << modmuls, not exps

a111: Logged on 2017-10-07 19:28 asciilifeform: http://btcbase.org/log/2017-10-07#1722358 << point was exactly to compare like items. i.e. heathendom does NOT get to 'win' by 'oh hey the hamming weight of exponent is only 2, not 4096, so we only do 4 modexps and not 8192'

shinohai: !!up apeloyee

deedbot: apeloyee voiced for 30 minutes.

apeloyee: thanks shinohai

shinohai: np!

apeloyee: !~later tell trinque I put the key at http://p.bvulpes.com/pastes/oRT3V/?raw=true

jhvh1: apeloyee: The operation succeeded.

apeloyee: asciilifeform: turns out a simple, ffa-suitable O(N^2) algorithm exists for GCD. This is adapted from GMP docs with one extra operation in the loop: http://p.bvulpes.com/pastes/oupUJ/?raw=true . Note: the code as posted is likely wrong, but I'm sure the idea can be made to work.

apeloyee: http://btcbase.org/log/2017-10-07#1722289 << and the point of doing karatsuba is? you do 2 recursive calls to Mul_Karatsuba_TopOnly and one to Mul_Karatsuba. should've simply calculated upper_part(XLo*YHi), upper_part(YLo*XHi) and XHi*YHi

a111: Logged on 2017-10-07 15:17 asciilifeform: in other puzzlers, http://wotpaste.cascadianhacker.com/pastes/6l4uH/?raw=true << mod6 et al

apeloyee: the multiply-by-approximate quotient in barrett's also needs only the lower part (plus 2 extra bits to the left), and lower part of product can be computed exactly (since rounding is not a problem)

shinohai: !!up apeloyee

deedbot: apeloyee voiced for 30 minutes.

apeloyee: http://btcbase.org/log/2017-10-05#1721485 << i thought bernstein's "how to find smooth parts of integers" suggests a remainder tree, not gcd?

a111: Logged on 2017-10-05 19:38 asciilifeform: want to gcd(candidate, biggestprimorialthatfitsintheffabitness)

apeloyee: http://btcbase.org/log/2017-10-05#1721485 << alternatively, can *construct* numbers which don't have very small factors. pick a nonzero remainder mod 2, mod 3, ... mod largest-prime-fit-in-your-primorial and find what number of primorial is congruent to it using chinese remainder theorem

a111: Logged on 2017-10-05 19:38 asciilifeform: want to gcd(candidate, biggestprimorialthatfitsintheffabitness)

apeloyee: *what number has such remainder from division by 2,3, ...

apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval

ben_vulpes: danielpbarron: wouldja mind sharing that stage3 you build your eulora gentoos with?

ben_vulpes: meanwhile, found a 20160728.tar.bz2

phf: http://btcbase.org/log/2017-10-07#1722379 << this is probably true but only because ffa mutates an array of bigits, where's any language level bignum system produces a whole new one for each operation

a111: Logged on 2017-10-07 19:30 asciilifeform: i also suspect that they are in fact slower for maxhammingweight case of exponentiation and modulus, vs ffa.

phf: a whole new bignum that is

phf: http://btcbase.org/log/2017-10-07#1722374 << >> http://btcbase.org/log/2017-10-07#1722376 << this seems contradictory, because the python thing posted is not closed form

a111: Logged on 2017-10-07 19:26 asciilifeform: http://btcbase.org/log/2017-10-07#1722372 << in fact we have closed form.

a111: Logged on 2017-10-07 19:28 asciilifeform: http://btcbase.org/log/2017-10-07#1722358 << point was exactly to compare like items. i.e. heathendom does NOT get to 'win' by 'oh hey the hamming weight of exponent is only 2, not 4096, so we only do 4 modexps and not 8192'

BingoBoingo: Trilema re-read of the day http://trilema.com/2014/how-i-was-wrong-cuckolding-or-a-story-about-sigmas/

mircea_popescu: http://btcbase.org/log/2017-10-07#1722405 << this may actually be a better check than any miller-rabin, and at any rate a good complement. gcd with primorial.

a111: Logged on 2017-10-07 21:53 apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval

*asciilifeform*

*finally eaten log...*

asciilifeform: http://btcbase.org/log/2017-10-07#1722394 << this looks very , very painful to prove correctness of. i'ma come back to it.

a111: Logged on 2017-10-07 21:09 apeloyee: asciilifeform: turns out a simple, ffa-suitable O(N^2) algorithm exists for GCD. This is adapted from GMP docs with one extra operation in the loop: http://p.bvulpes.com/pastes/oupUJ/?raw=true . Note: the code as posted is likely wrong, but I'm sure the idea can be made to work.

asciilifeform: http://btcbase.org/log/2017-10-07#1722395 << compute and then what ? gotta multiply

a111: Logged on 2017-10-07 21:14 apeloyee: http://btcbase.org/log/2017-10-07#1722289 << and the point of doing karatsuba is? you do 2 recursive calls to Mul_Karatsuba_TopOnly and one to Mul_Karatsuba. should've simply calculated upper_part(XLo*YHi), upper_part(YLo*XHi) and XHi*YHi

asciilifeform: http://btcbase.org/log/2017-10-07#1722397 << i don't see anything that only wants ~lower~ half... whatcha talking about

a111: Logged on 2017-10-07 21:25 apeloyee: the multiply-by-approximate quotient in barrett's also needs only the lower part (plus 2 extra bits to the left), and lower part of product can be computed exactly (since rounding is not a problem)

asciilifeform: http://btcbase.org/log/2017-10-07#1722400 << bernstein's gcd method is neither here nor there, i certainly don't need anything of the kind in ffa, and quite likely it fundamentally does not ffaize

a111: Logged on 2017-10-07 21:28 apeloyee: http://btcbase.org/log/2017-10-05#1721485 << i thought bernstein's "how to find smooth parts of integers" suggests a remainder tree, not gcd?

asciilifeform: http://btcbase.org/log/2017-10-07#1722402 << this is a fundamentally wrong way to generate cryptographic primes. we had a thread about it, http://btcbase.org/log/2017-08-14#1697562

a111: Logged on 2017-10-07 21:48 apeloyee: http://btcbase.org/log/2017-10-05#1721485 << alternatively, can *construct* numbers which don't have very small factors. pick a nonzero remainder mod 2, mod 3, ... mod largest-prime-fit-in-your-primorial and find what number of primorial is congruent to it using chinese remainder theorem

a111: Logged on 2017-08-14 16:14 asciilifeform: ( tldr : superiority of the FUCKGOATS-enabled approach, of get-new-N-bits-from-rng-then-primalitytest-until-done, vs the kochian get-N-bits-then-increment-until-passes-millerrabin )

asciilifeform: the ONLY correct method of generating cryptoprimes, is to 1) get N bits from FUCKGOATS 2) determine, in fixed spacetime every single time, whether that string of bits constitutes a usable prime.

asciilifeform: all other methods leak info via timing , amperage, rf noise.

asciilifeform: http://btcbase.org/log/2017-10-07#1722405 << in no case can the 'cheap initial primality test' primorial exceed the size of current ffa width. thinkaboutit.

a111: Logged on 2017-10-07 21:53 apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval

asciilifeform: http://btcbase.org/log/2017-10-07#1722408 << you might consider reading the code ? it has all been posted.

a111: Logged on 2017-10-07 22:39 phf: http://btcbase.org/log/2017-10-07#1722379 << this is probably true but only because ffa mutates an array of bigits, where's any language level bignum system produces a whole new one for each operation

asciilifeform: http://btcbase.org/log/2017-10-07#1722411 << 1 ) ffa is closed form. i.e. it CAN be written as a number of nand gates, with a 'funnel' at the top, to which you present a,b,c, e.g. 4096bit, numbers, and at the bottom in a little cup you get a^b mod c , and with NO UPWARDS FEEDBACK FLOW of information , i.e. answer comes after same interval of time always, and with strictly downwards signals.

a111: Logged on 2017-10-07 22:44 phf: http://btcbase.org/log/2017-10-07#1722374 << >> http://btcbase.org/log/2017-10-07#1722376 << this seems contradictory, because the python thing posted is not closed form

asciilifeform: but 2 ) the python example is of course not closed form, and it is imho meaningless to even attempt to write the closed form item in a language like python or cl

asciilifeform: ( where there is no assurance of not consing and not branching )

asciilifeform: http://btcbase.org/log/2017-10-07#1722415 << if you have a comp the size of jupiter, you could ~maybe~ have such a thing as a 128bit primorial.

a111: Logged on 2017-10-07 23:50 mircea_popescu: http://btcbase.org/log/2017-10-07#1722405 << this may actually be a better check than any miller-rabin, and at any rate a good complement. gcd with primorial.

asciilifeform: but certainly not 129.

asciilifeform: so no, nobody is replacing miller-rabin with gcd(primorial, x).

asciilifeform: ( certainly not even for as large a number as 64bit... much less 4096 )

asciilifeform: i proposed primorial strictly as an initial winnowing to replace the idiot trial divisions koch et al used.

asciilifeform: phf, mod6 : funnily enough i went and tried the 'fair fight' max(4096b) a^b mod c in python, http://wotpaste.cascadianhacker.com/pastes/GHATB/?raw=true , but it... bombs

asciilifeform: with eggog:

asciilifeform: OverflowError: Python int too large to convert to C long

asciilifeform: for the obvious reason.

asciilifeform: if somebody wants to make the physically possible version of this, to see what happens on max hammingweight...

asciilifeform: oh ffs, here goes,

asciilifeform: http://wotpaste.cascadianhacker.com/pastes/0A6fb/?raw=true << python 'fair fight' ver

asciilifeform: ( and skips unused hammings... )

asciilifeform: 0.018s on this box.

asciilifeform: http://wotpaste.cascadianhacker.com/pastes/saynG/?raw=true << all1s. 0.028s. tho i do suspect it shortcuts internally.

asciilifeform: ( mainly, i suspect, by recognizing masses of 0 in karatsuba and returning 0 when they get mul'd )

asciilifeform: tldr : initial py snippet i had lying around was braindamaged.

asciilifeform: http://btcbase.org/log/2017-10-07#1722367 << i gotta ask if this figure included sbcl load time !?

a111: Logged on 2017-10-07 16:42 shinohai: I get 0m1.236s using sbcl (i5)

asciilifeform: because if it did, it is meaningless

asciilifeform: ( see phf's http://btcbase.org/log/2017-07-03#1678660 , or even naggum's, re why )

a111: Logged on 2017-07-03 14:46 phf: i think ascii already made that point, that if you're profiling lisp with the vm startup, then you should also profile c machine from boot time. at the very least the vm should be warmed up by loading all the dependencies into the core, doing save-lisp on it, and then making sure that your foo.lisp has an up to date fasl. inside lisp though to achieve the optimizations you run variants of your function inside (time ...) until you bring it within the ra

asciilifeform: ( orig., iirc, thread : http://btcbase.org/log/2017-07-02#1678490 )

a111: Logged on 2017-07-02 12:50 asciilifeform: http://btcbase.org/log/2017-07-02#1678460 << how about we roll the boot time ( to shell!! ) of your cmachinekernel, how about?

*asciilifeform*

*bbl*

mats: l0l an amzn frontend engineer friend has to work all through christmas week, got his vacation request denied by upper mgmt

mats: he put it in almost four months in advance and still can’t take a few days off

BingoBoingo: Well, he works in the retail industry. What should he expect?

mircea_popescu: http://btcbase.org/log/2017-10-08#1722429 << your chances of generating a random int that is also prime at that sort of length aren't so great.

a111: Logged on 2017-10-08 00:16 asciilifeform: the ONLY correct method of generating cryptoprimes, is to 1) get N bits from FUCKGOATS 2) determine, in fixed spacetime every single time, whether that string of bits constitutes a usable prime.

mircea_popescu: having a primorial at the ready to exclude a large number of common (ie, low) factors in one single gcd likely speeds this up significantly.

mircea_popescu: http://btcbase.org/log/2017-10-08#1722442 << not altogether, hold on to your horses.

a111: Logged on 2017-10-08 00:24 asciilifeform: so no, nobody is replacing miller-rabin with gcd(primorial, x).

mircea_popescu: recall diana_coman 's trick of "multiply by 6" ? pretty much the inverse of the same idea.

asciilifeform: http://btcbase.org/log/2017-10-08#1722468 << quite acceptable, 1 in few thou

a111: Logged on 2017-10-08 01:34 mircea_popescu: http://btcbase.org/log/2017-10-08#1722429 << your chances of generating a random int that is also prime at that sort of length aren't so great.

asciilifeform: ( try it )

mircea_popescu: yes, but then would you rather 999 r-m or 995 primorial gcd and 4 r-m ?

asciilifeform: http://btcbase.org/log/2017-10-08#1722470 << is why i suggested it to begin with, zaps items with factors up to 16bit or so quickly

a111: Logged on 2017-10-08 01:35 mircea_popescu: having a primorial at the ready to exclude a large number of common (ie, low) factors in one single gcd likely speeds this up significantly.

mircea_popescu: so then what exactly is the argument about.

asciilifeform: http://btcbase.org/log/2017-10-07#1722415 looked like a 'who needs miller-rabin'

a111: Logged on 2017-10-07 23:50 mircea_popescu: http://btcbase.org/log/2017-10-07#1722405 << this may actually be a better check than any miller-rabin, and at any rate a good complement. gcd with primorial.

mircea_popescu: yeah well.

asciilifeform: ( where first suggested , ftr : http://btcbase.org/log/2017-08-14#1697598 )

a111: Logged on 2017-08-14 17:15 asciilifeform: idea is, for pre-millerrabin litmus, take gcd(candidate, Qw) where Qw is largest primorial that fits in the ffawidth

asciilifeform: worxgreat

mircea_popescu: incidentally, if looking for 4096 bit prime wouldn't the correct approach be to take 4094 bits of rng and glue 1 on either end ?

mircea_popescu: as no 0 led or 0 terminated string will ever pass anyway

asciilifeform: primes >2 are odd, noose at 11

mircea_popescu: aha. get some free bits that way, fwiw.

asciilifeform: ( yes you set the low bit to 1 )

asciilifeform: http://www.loper-os.org/?p=568&cpage=4#comment-18272 << in other strange.

shinohai: Lol asciilifeform got a brony

shinohai: Oh wait, name is "Tina"

asciilifeform: i have deeply nfi

asciilifeform: in other lullies, http://www.loper-os.org/pub/nsawagenhoneypot.jpg << found on washington metro train today

shinohai: TOP KEK "Anonymous access through tor browser"!!!!

shinohai: They even bothered to vanitygen a custom tor addy

asciilifeform: ads on these trains, ftr, not cheap. ( and certainly not 'to allcomers' )