tr eo gu en en en en en hbs_lat fr en en en en eo eo eo eo eo eo en eo eo eo eo eo eo eo eo eo eo en eo pl eo eo eo eo eo eo en eo en pl eo eo eo eo eo eo eo en eo eo eo eo hbs_lat eo eo eo en eo eo eo eo it en vi en en en en en en kn en kn eo it en en tr kn eo en pl eo eo eo eo eo eo eo eo eo en eo en en eo eo en es eo eo eo eo eo en pl en it en en en en en en en en en en en en uk en en en en en en en en en en en en ru en en en en en en en en en en en en de en en en en en en en en en en en en it en en en en en en en en en en en en en en en en en en en en en en en en en
Do, la malfeliĉa novaĵo venu unue.  Antaŭ monato kaj duono mia nova edzino, kaj la patrino de mia filo, lernis ke unu el ŝiaj haŭtmakuloj fariĝis kancera.  Tiu ja estis streĉo sen kiu ni povus vivi.  Sed, estas la vivo, ĉu ne?  Feliĉe, ŝi havis ĥirurgion kiu forprenis larĝan, longan kaj relative profundan parton de ŝia femuro, kaj post laboratoria analizo konkludiĝis ke la kancero ne disvastiĝis, kaj ne plu restas en ŝia kruro.
Ni estas esperoplenaj ke tiu estos la lasta fojo kiam ni aŭdos pri la afero.
Hieraŭ vesperon ni havis amikojn en nia domo por vizito kaj vespermanĝi.  Ni iom diskutis la kanceron inter aliaj diversaj temoj.  Mi menciis ke ni provas igi ŝian patrinon ankaŭ viziti la kuraciston por ke li kontrolu ŝiajn haŭtmakulojn.  Estas tre evidente ke la genetiko por tia haŭto venas de ŝia patrino, kaj eĉ pli antaŭe de ŝia patrina avino.  Do mi diris al amiko nia, ke la statistika probablo ke oni havas haŭtmakulon kiu kanceriĝos multe pligrandiĝas se li aŭ ŝi havas proksiman parencon kies haŭmakulo kanceriĝis.
Li tuj ekpensis pri ĉu tiu diraĵo mia estas vera.  Kaj li rakontis al mi pri situacio kiam Stephen Gould havis kanceron kaj la statistiko pri li mem ne estis en la mezo de la ĝenerala statistiko.  Kaj tiu ja estas la tikla punkto rilate al statistiko ĝenerale.  Statistiko nur donas probablecon kiu anstataŭas informon, ofte kiam vera informo ne haveblas.  Ekzemple, statistiko ekzistas por la ŝanco ke iu fumanto ekhavos gorĝan kanceron.  Mi ne scias la nombrojn, sed ni diru simple por la diskuto, dudek kvin procento de tiuj kiuj fumas po unu aŭ pli da pakaĵoj de cigaredoj tage, antaŭ la aĝo de sesdek jaroj, ekhavos iaspecan pulmsisteman kanceron. Do, se vi mem estas vivlonga fumanto, kiu fumas tiom multe, ĉu tiu signifas ke VI havas dudek kvin procentan ŝancon?  Tiu dependas.  Se vi estas adoptita, kaj vi scias nenion kaj ne havas kapablon scii ion ajn pri viaj veraj gepatroj kaj parencoj, nu jes, la statistiko estas utila en la foresto de alia scio.  Se vi konas viajn parencojn bone, tamen, kaj vi scias kiel fakton ke ili ĉiuj fumas la tutan vivon kaj neniu el ili iam ajn ekhavis ian ajn formon de kancero, nu, nun vi havas apartan informon kiu efikas al vi specife, kaj plej verŝajne via propra ŝanco estus malpli granda ol la nacia averaĝo.
Por reveni al la temo de mia edzino kaj ŝia patrino, ili ja estas parencaj, ili ja ambaŭ havas multajn kaj relative grandajn haŭtmakulojn.  Antaŭ 3 monatoj, neniu el ili havis unu el ili fariĝi kancero, sed nun unu el ili ja havas.  Do, en la foresto de aliaj informoj, la patrino de mia edzino povas supozi ĝuste ke ŝia persona probablo estas pli granda ol ŝi povus supozi antaŭ tiu ĉi okazis.  Kaj, fine, la amiko nia plene konsentis.
Aug 31, 2012 1 note
#sano #statistiko #ĝenerala #esperanto #kancero #cancer
Naiva programado malhelpas. Ĉu vere?weiqigao.com
La ligilo estas tre malnova, de la jaro 2003.  Tamen, la temo restas tre nuntempa.  Mi, kiel ĉefprogramisto en malgranda firmao, renkontas kaj devas pritrakti la malbonajn praktikojn de malpli spertaj programistoj je ĉiu tago.
La koncepto pripensinda estas la diferenco inter “naiva programa kodo” kaj “altrendimenta programa kodo” je la alia kontraŭa flanko.  La blogo estas en la angla, do mi ĉerpos kaj tradukos por la avantaĝo de miaj legantoj.
“La malo de {glata} kodo estas naiva kodo.  Kaj ni verkas tian ĉiutage.  Kaj ni faras tiun en la nomo de objektemeco, en la nomo de ŝablonoj, en la nomo de korporaciaj kodaj normoj, en la nomo de {kadraj bibliotekoj}, en la nomo de la plej freŝaj frapvortoj, en la nomo de fleksebleco.
Kaj ni scivolas pri kial niaj sistemoj estas tiel @#$%-e malrapidaj.
Ĉu vi povas verki funkcion kiu kalkulas la sumon de ĉiu malpara entjero de 1 al 2n+1?"
* la krampoj indikas eble malprecizajn tradukojn.
Mi ne estes matematikisto, sed mi programadas dum multe da jaroj, kaj mi forte malkonsentas lian opinion.  La lastan demandon li faris estas tre bona, tre interesa demando.  Unue, mi tuj supozis ke la kialo por tiu specifa demando devus esti ĉar oni tre facile povus verki naivan funkcion por ĝin solvi, dum multe pli rendimenta solvo ekzistus.  Kaj fakte tiu ja estas la kazo.  Sed mi ne povis ekscii tiun per mi mem.
Do, por ludi lian ludon, mi verkis version de la funkcio, kiun oni devus nomi naiva.  Jen mia, naiva, versio:
function sumigiEntjeroj(n) { n = (2*n)+1; var sumo = 0; while(n>0) { sumo += n; n-=2; } return sumo; }
Due, pensinte ke la demando devas esti duona artifiko, mi demandis al kolego mia, ĉe la laborejo, kiel oni povus verki malnaivan version por solvi la problemon.  Li elskribis per krajono kelkajn formulojn, kaj diris, ha, mi pensas ke estas nur n plus unu, kvadrata.  Mi rapide enfunkciigis tiun ĉi simplegan formulon por fari empiriajn testojn.  Laŭ la testoj, ŝajnis al mi ke ĝi estis ĝusta, ĉar kontraŭ ĉiu provita ekzempo ĝi redonis la saman rezulton kiel la naiva funkcio.  Jen la malnaiva versio:
function sumigiEntjeroj(n) { return (n+1)*(n+1); }
La kolego mia tamen ne estis tutcerta, kaj eĉ iomete konfuzis sin, kaj ne estis tute konvinkita pri ĝia ĉiama praveco.  Tiu problemo demetita, tamen, ni povas konsideri kelkajn aferojn.
La luda demando ja estas tre bona, ĉar ĝi estas tia por kia oni povas facilege verki naivan solvon, kiu tamen havas troveblan malnaivan solvon, kiu estas nekredeble pli rendimenta.  Kaj ju pli grandaj estas la valoroj por n, des multe pli la problemo de la naiva solvo evidentas.  Tiu verŝajne estas la ĉefa punkto kiun la originala aŭtoro volis rimarkigi.
Tio kion mi volas demandi estas, ĉu li estas ĝenerale prava, en la lumo de lia praveco rilate al la specifa demando kiun li lasis kun siaj legantoj?  Mia mallonga respondo estas, ne, ĝenerale li malpravas.  Sed mi volas ekspliki kial.
Mia ĉefa argumento estas ke programisto kredu-nekredu ne estas matematikistoj.  Programisto povas ankaŭ esti matematikisto, jes, kaj same programisto povas ankaŭ esti sciencisto, sed certe ne necese.  Programisto, kaj la problemoj de programado, ne samas la problemojn de matematikistoj.  Eĉ pli, rendimento ne estas la ĉefa problemo por la ĉiutaga programisto.  Por matematikisto povas esti ke sumigiEntjero() estas la plej interesa problemo en la mondo, sed al programisto, sumigiEntjero() ne estas la programo, ĝi estas unu, unuopa, malgranda programero, en vasta maro de tute aliaj problemoj.  Programistoj devas labori en grupoj, kaj do multaj programistoj devas prilabori la saman programon.  Kaj la specifoj de la programo sendube ŝanĝiĝos de la komenco de la projekto al la fino, kaj do la plej granda problemo por la programisto estas, kiel organizi la kodon, tiel ke multaj apartaj homoj povas ĉiuj kontribui al la sama programo, sen la enkonduko la cimoj kaj aliaj konfliktoj.  Tiam la problemo estas, kiam la specifoj ŝanĝiĝas, kiel facile estos por ŝanĝi la programon por kovri tiujn novajn neantaŭviditajn situaciojn?  La lertoj bezonataj por solvi tiajn ĉi problemojn estas malsamaj ol tiuj de matematikisto.
Dua problemo leviĝas de la fakto ke programistoj ne estas ĉekore matematikistoj.  De tempo al tempo funkcioj alvenas kiuj devas esti verkitaj kie rendimento gravas.  Tamen, en multaj kazoj (eble plej multaj) naiva solvo ne estas rimarkinde malpli rendimenta ol tiel nomata malnaiva solvo.  Sed, pro tio ke programistoj ne estas matematikistoj, ne estas facile scii kiuj funkcioj estos malrapidaj en realo, antaŭ ol oni rulas la programon kaj kontrolas empirie.  Do, se programisto dediĉas tempon al la problemo verki malpli naivan solvon, en la plimulto de kazoj, tiu estus senutila, kaj efektive malŝparus tempon.  Hodiaŭ, ekzistas bonaj iloj por analizi en kiu parto de la programo la procezilo pasigas la plimulton de sia tempo.  Estas multe pli efika verki naivan kodon, kiu estas klara al la kunprogramantoj, estas rapide kaj facile ŝanĝebla, havas malprobablan ŝancon perturbi la kodon de la kunprogramantoj, kaj tiel plu, kaj tiam simple uzi la programilojn por analizi kie estas la malrapidaj partoj.  Tiam, imagu ke oni malkovras ke lia sumigiEntjero()-a funkcio estas treege malrapida, nu, tiam li povas demandi al matematikema kolego, aŭ eĉ en la interreto, por kiel pli rendimente solvi tiun specifian problemon.
Li rikanas dum la diras "en la nomo de objektemeco, en la nomo de ŝablonoj, en la nomo de korporaciaj kodaj normoj, en la nomo de {kadraj bibliotekoj}, en la nomo de la plej freŝaj frapvortoj, en la nomo de fleksebleco."  Nur la t.n. plej freŝaj frapvortoj estas pririkanindaj.  Kodaj normoj, ŝablonoj, objektemeco, fleksebleco, ĉiuj ĉi tiuj estas gravegaj, helpegaj, detale elpensitaj solvoj al problemaro kun kiu programistoj, veraj, realmondaj, programistoj devas lukti ĉiutage.  Kaj la vero estas ke estas multe pli pri programado ol algoritma rendimento.
#komputiko #programado #opinia #esperanto #teorio #matematiko #javascript
#esperanto #sytycd #cyrus spencer #dancado
Saluton! Pri via "vicoA.komparuSenzorganteCxapeloj(vicoB)" mi volus rimarki, ke por la rusa, ekz-e, ekzistas almenaŭ 6 diversaj 8-bitaj signarojn kaj almenaŭ 3 malsamaj oficialaj transliterumaj sistemoj kaj kelkaj neoficialaj, do almenaŭ por la rusa apenaŭ eblas verki similan funkcion (aŭ ĝi estos tro komplika, ja unue necesos "kompreni" kiu signaro aŭ transliteruma sistemo estas?). Eĉ por Esperanto ja ekzistas 3-4 t.n. surogataj skriboj (Zamenhofa H-skribo, X-skribo kaj variaĵoj kun ^ k.s.)
Hej, resaluton. Dankon pro viaj rimarkoj.
Vi pravas ke la situacio kompleksigxas kiam oni devas trakti malsamajn skribsistemojn. Por tia problemo mi rekomendas blogan artikolon de la verkinto de simplavortaro.net. Mi bedauras ke ligilon mi ne havas cxemane.
Mia artikolo nur traktas kion fari kiam la litervicoj estas en unikodo. Unikodo estas ja bona maniero miksi la signarojn de cxiu lingvo en unu dosiero. Sed problemoj certe restas.
Mi uzas Makintosxon, kaj per gxi estas treege facile entajpi la esperantajn cxapelitajn literojn. Sed, de iPhone aux iPad, estas multe malpli konvena por mi, do mi uzas la X-sistemon, tiakaze. Tamen, ecx en la Makintosxo ne cxio cxiam estas kiel gxi estu, rilate al ordigo laux alfabeto. Do, ekzemple, mi nomas do dosierojn: cepo.txt kaj čapelo.txt. (pardonu la iom fusxitan cxapelon tie) la sistemo komparas ambaux “c"ojn kiel la sama litero, sed laux la dua litero "a” venas antaux “e”, kaj do fine gxi ordigas čapelo entute antaux cepo, sed en Esperanto ili estu renversaj.
Do, la solvo kiun mi trovis ne estas unu solvo por cxio, tamen ja estas bona eltrovo se vi volas, ekzemple, permesi ke la uzanto sercxu per “cap” kaj ankoraux trovu “čapelon”.
Aug 13, 2012 1 note
Mirinde ke mi ankoraŭ lernas pri lingvaj trajtoj de javaskripto
Mi ĵus lernis, kaj ĵus uzis la unuan fojon, lingvan trajton de javaskripto pri kiu mi tute ne sciis antaŭe.  Estas kelkaj interesaj aĵoj pri ĝia uzado, do mi volas montri tiujn nun.
Temas pri etikedoj por iteracioj, kaj kiel uzi ilin.
La jena kodo funkcias.  Poste mi klarigos kiel.
var kradObj = Object.create(null); kradObj['a'] = 1; kradObj['b'] = 1; kradObj['c'] = 1; kradObj['d'] = 1; kradObj['e'] = 1; eksterIteracio: for(var i=0; i 5 && kradIndekso > 'c') break kradIteracio; } } }
Baze, ni havas 3 ingitajn iteraciojn.  La meza estas iteracio tra kradObjekto, la aliaj du estas simplaj FOR-iteracioj, sed la speco vere ne gravas.  Mi nur uzas diversspecajn iteraciojn por montri ke la teĥniko validas por pli ol la FOR-specaj.
Ĉiu iteracio havas etikedon.  Notu bone ke la etikedo venas tuj antaŭ la komenco de la iteracio, kiun ĝi etikedas.  Sekve, vi povas rimarki ke la plej interna iteracio havas kondiĉon, kiu se vera vokos “break kradIteracio;”  Gravas kompreni, ke tiu break-instrukcio ne estas “GOTO”, kaj nepre ne funkcias kiel GOTO.  Ĝi ne sendas la programon al la loko de la kradIteracia etikedo.  Kion ĝi faras estas elirigas la programon el la meza, krada iteracio, t.e. el la specifita iteracio.  Do la programo, efektive, daŭros tuj post la fino de la specifita etikedita iteracio.
Ĉi-kaze nenio estas inter la fino de la kradIteracio kaj la fino de la eksterIteracio, do la programo tuj ripetos la eksteran iteracion kaj la nombrilo i alkrementiĝos.
#javascript #esperanto #programado #teĥniko #dumviva lernado
Mia javaskripto pli bonas ol tio de Hemingwaybyfat.xxx
Mi legis tiun cxi artikoleton, kaj gxi enhavis ekzemplon de tre konciza javaskripto, kiel supozeble verkus Hemingway, se li verkintus per javaskripto. La ekzemplo estis pri la fibonacci-a sinsekvo. Mi legis la kodon, kaj pensis: certe tiu ne estas tiel konciza kiel gxi povas esti!!
Jen lia, supozeble, versio:
var first = 0, second = 1, next, count = 2, result = [first, second];
return “the request was made but it was not good”
while(count++ < size) {
next = first + second;
var seq = [0,1];
while(seq.length < size) seq.push(seq[seq.length-1]+seq[seq.length-2]);
Mi preferas la mian.
#komputiko #programado #javascript #hemingway
Ne metu propraĵon sur objekto vi ne mastras.
Javaskripto, kiel lingvo, estas tre liberala pri en kiu objekto oni (la programisto) rajtas meti propraĵojn.  Tamen, tia liberaleco ne signifas ke ĉiam estas bona ideo meti propraĵojn ie ajn.  Mi eksplikos per kelkaj ekzemploj.
function MiaKlaso() { this.fuObjekto = new FuKlaso(); this.fuObjekto.miaProprajxo = 1; } MiaKlaso.prototype.montruProprajxon = function() { alert(this.fuObjekto.miaProprajxo); }; var a = new MiaKlaso(); a.montruProprajxon();
Ĉu vi povas vidi tion, kio estas la problemo?  Oficiale, tiu ĉi ne estas problemo, kaj oni povas laŭdi la flekseblecon de la lingvo.  Tamen, praktike, estas malbona teĥniko fari tiun ĉi.  La problemo estas jen: La klaso, MiaKlaso ne mastras la klason, FuKlason, sed ĝi metas sian propraĵon sur tiu klas-instanco.  Je la komenco, eble tiu ĉi skripto ne havas problemon.  Sed per tiu teĥniko la programisto enkondukas malfortecon en la kodon.  Li enkondukis kondiĉon kie la verkinto de FuKlaso ne plu estas libera aldoni siajn proprajn propraĵon senriske de kolizioj.
Ĉu vi povas vidi tiun?  La problemo estas ke nun, se la verkinto de FuKlaso decidas reiri al sia klaso, kaj aldoni pliajn kapablojn, se li uzas miaProprajxo por si mem, tiu rompos aŭ lian kodon, aŭ la kodon de MiaKlaso.  Tiel ĝi nomiĝu malforteco en la desegnaĵo.
function MiaKlaso() { this.fuObjekto = new FuKlaso(); this.miaProprajxo = 1; } MiaKlaso.prototype.montruProprajxon = function() { alert(this.miaProprajxo); }; var a = new MiaKlaso(); a.montruProprajxon();
Nu, kompreneble, la supraj ekzemploj estas elturnigitaj.  Realaj situacioj estos multe pli kompleksaj.  Tamen, la koncepto estu proksime pripensata.  Oni ĉiam atentu kiam ili metas propraĵon al fremda objekto.  Ĉiufoje ke oni faras tiun, li enkondukas malfortecon en la programon.  Kaj, ju pli da malfortecojn des pli probabla estas ke oni renkontos problemojn en la estonteco.
Aug 3, 2012 3 notes
#programado #komputiko #javascript #esperanto
“Michael Johnston is a Simperium co-founder. He described Simperium to Macworld as “a simple service for developers to move data among devices—like iCloud.” Even better, Johnston says, it “lets users access their data on their iPhone, iPad, and Mac, along with the Web and other devices, with full offline access as well—but it’s faster, more reliable, and gives developers more control than iCloud does.””—
Developers dish on iCloud’s challenges | Macworld
Mi konsentas ke ja estas disvolvantoj tie en la mondo kiuj ŝajnas preferi iun kiel Simperiumon.  Mi ankaŭ devas konsenti ke ĝi ofertas kelkajn trajtojn nehaveblajn per iCloud, ekzemple ke oni povas aliri la datumojn de aliaj operaciumoj aŭ la reto.
Tamen, mi havas malfacilecon akceptante ke ia servo kiel Simperiumo estas “pli rapida, pli fidinda” (“faster, more reliable […]”) ol iCloud.  Apple estas Apple, ili uzas la servon por siaj propraj aplikaĵoj, kaj ili devas havi enormajn servilojn.  Ili funkciigas iTunes Vendejon, kiu disdonas po multegajn datumojn ĉiusekunde.  Ĉu povas esti ke Simperiumo estas pli rapida nur ĉar neniu ilin uzas?
Aug 2, 2012 1 note
#Apple #iCloud #komputiko #servilo #iTunes #opinia
Fundamentaj problemoj kun softvara testado.
Mi laboris por kelkaj firmaoj softvaraj, nun ke mi estas en miaj tridekaj jaroj.  Ĉiu firmao donas apartajn nivelojn de atento al la demando de softvara testado.  Ĉe unu firmao por kiu mi iam laboris, ili dungis vastan teamon de testantoj.
En mia sperto, preskaŭ nenian avantaĝon estas gajnita per tia nivelo de testado.  La problemo ĝenerala pri la testado de softvaro, per neprogramistoj, estas ke la testantoj havas nenian vidon en kion okazas en la programo.  Do ĉiu problemo estas unuopa afero, anstataŭ kompleksa reto de interrilatatj problemoj.
Ekzemple, okazas ofte ke unu malgranda cimo enrampas programon, kaj tiuj estas neeviteblaj.  Nun la testanto testas la programon, kaj la cimo kaŭzas la programon halti.  Tiu signifas ke la plimulto de la programo ne uzeblas.  Sed, ĉu tiu signifas ke ĉiu ne alirebla parto de la programo devas esti listigita kiel rompita?  Kompreneble tiu estus absurda.  Do, bonaj testantoj sciu tion, kaj kiam ili renkontos la unuan problemon ili listigu tiun, kaj tiam atendu ĝis tiam kiam tiu unuopa cimo ne plu ekzistas.  Sed, kio okazas se tiu cimo NE estas grava ĉiohaltiganta problemo?  Se la testanto ne daŭras la testadon, li malŝparas sian tempon, kaj la monon de la dunganto.
Do, la fundamenta problemo kun softvara testado estas tio ke la testantoj, se ili ne ankaŭ estas la programantoj, laboras de blinda pozicio.  Ili havas nenian rimedon por eltrovi kian cimon ili renkontis.  Preskaŭ neeviteble, se la testanto ne estas la verkanto de la kodon, la plimulto de lia tempo estos malbone elspezita.