torbjørn marø Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Er det noensinne feil å bruke predikert and (altså ikke utføre uttrykket på høyre side dersom det venstre ikke er sann) i et boolesk uttrykk? Altså && vs. & i C språkene, AndAlso og And i BASIC. Å basere seg på slik oppførsel er skummelt fordi det ikke kommuniserer så godt. Men i noen kulturer (les: Common Lisp) tror jeg det er ganske vanlig. AT man f.eks. i stedet for å skrive: (if (and (some-test) (some-other-test)) (do-something)) ..skriver: (and (some-test) (some-other-test) (do-something)) Det du mener, ikke sant? Men det er ikke akkurat det du spør om. Tolker spørsmålet ditt som om man noen ganger trenger å bruke "and" som utfører alle predikatene uansett, og jeg kan se for meg det også, men synes det blir enda mindre leselig. Da ville jeg i stedet ha mappet over alle predikatene, og til slutt testet om alle var true (om du skjønner). F.eks. i Ruby: if [some_test(), some_other_test()].all? do_something() end Dette er nødvendig om testene har side effects som er nødvendige! Endret 15. februar 2012 av torbjørn marø Lenke til kommentar
GeirGrusom Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 Nei, ikke akkurat. Det er hva kompileren gjør. På et boolesk uttrykk: if(a and b) så vil uttrykket alltid være usant dersom a er usant, så det er ikke engang noe poeng i å evaluere b. Bare lurte på om det var noen tilfeller hvor dette ikke lenger stemmer... men det kan det umulig gjøre. Kall det en brain fart egentlig tidlig på morgen. Lenke til kommentar
torbjørn marø Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Nei, ikke akkurat. Oppdaterte svaret mitt etter at du så det Poenget mitt er altså: Hvis testene a og b har side effects som du vil skal skje så må de begge evalueres, men at dette er generelt dårlig design. Endret 15. februar 2012 av torbjørn marø Lenke til kommentar
tomsi42 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 Nei, ikke akkurat. Det er hva kompileren gjør. På et boolesk uttrykk: if(a and b) så vil uttrykket alltid være usant dersom a er usant, så det er ikke engang noe poeng i å evaluere b. Bare lurte på om det var noen tilfeller hvor dette ikke lenger stemmer... men det kan det umulig gjøre. Kall det en brain fart egentlig tidlig på morgen. Det kommer an på programmeringspråket. Noen språk (særlig de eldre - pascal f.eks*) evaluerer alltid begge to. Men ettersom det er to boolske utttrykk, så bør jo de kunne være logiske sammenligninger og ikke gjøre ting på si. Brain farts kommer gjerne om morgenen før man har fått nok kaffe *) Mener å huske at man i Turbo Pascal kunne sette en opsjon for å endre denne oppførselen. Lenke til kommentar
GeirGrusom Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Tester og side-effects er jo et godt poeng, skal huske på det til senere. Men i denne sammenhengen var det snakk om et egentlig funksjonelt språk i et rent miljø hvor side-effects ikke er mulig. Når det gjelder side-effects er det vel egentlig aldri mulig for en parser å gjenkjenne om dette faktisk vil skje, så en compiler optimalisering som sørger for andalso på et språk som baserer seg på side-effects vil vel aldri være fullstendig gyldig. edit: eller, det kan jo være gyldig, men compileren kan aldri garantere for at det resulterer i korrekt oppførsel. Eksempelvis hvis en i C++ skriver følgende: if(some_false_a() & extern_call_b()) så kan ikke compileren si "Oi her er det to booleske uttrykk, ikke evaluer b dersom a er usann" fordi b kan (og slik det er skrevet, skal) påvirke oppførselen til programmet. Selv om resultatet vil bli det samme, kan det påvirke oppførselen til programmet. I D kan en markere et uttrykk som "pure" som ville gjort antagelsen gyldig, og i C++11 kan en markere uttrykket som constexpr som også ville gjort optimaliseringen gyldig. Endret 15. februar 2012 av GeirGrusom 1 Lenke til kommentar
Gjest Slettet+9871234 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 Eksempelvis hvis en i C++ skriver følgende: Skriver man = istedet for == vil programmet kompilere uten problemer og det trenger ikke være trivielt å finne feilen. Programmet kan gi riktig resultat for noen tilfeller, men helt ville for andre. Litt mer interessant i denne tråden kan det være å diskutere professor Bjørn Kirkeruds temeaer: Kan datamaskiner "lære" reelle spill? Vil der komme dataprogrammer som slår de beste sjakkspillerne? Les mer http://www.articlenorway.com/ under overskriften: Is it possible to protect your content, is it still possible to identify copy cats? Lenke til kommentar
x871kx6167ss7 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Nei, ikke akkurat. Det er hva kompileren gjør. På et boolesk uttrykk: if(a and b) så vil uttrykket alltid være usant dersom a er usant, så det er ikke engang noe poeng i å evaluere b. Bare lurte på om det var noen tilfeller hvor dette ikke lenger stemmer... men det kan det umulig gjøre. Kall det en brain fart egentlig tidlig på morgen. Jeg er ikke helt sikker på hva du mener. Vi kan anta at vi snakker om et 100% «pure» funksjonelt program. Spørsmål: Gitt et program P, vil resultatet/verdien av programmet P være avhengig av hvorvidt man "shortcut'er" evalueringen av "and"-uttrykk? Dersom man har execptions/førsteklasses kontinuasjoner, så kan resultatene bli forskjellige. (call-with-current-continuation (lambda (k) (and #f (k #t)))) ;;; Resultat #f (define (functional-and a b) (and a b)) (call-with-current-continuation (lambda (k) (functional-and #f (k #t)))) ;;; Resultat #t Vet ikke hvor godt kjent du er med call-with-current-continuation, men du kan se på det som en mer generell setjmp/longjmp i C. Edit: Og selvfølgelig noe slikt som dette: boolean loop(int n) { if (n == 0) while (true) { /* nothing */ } return true; } boolean tmp = (x != 0 && loop(x)); Hva er resultatet av et program som ikke terminerer? Edit2: Men dersom vi har call-by-name/lazy/e.l. så vil det siste tilfellet ikke nødvendig vis bli feil igjen. Endret 15. februar 2012 av peterbb Lenke til kommentar
OldMan Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 I C++ er det veldig behagelig at ikke alle uttrykk evalueres: void someFunc( Object* pObject ) { while( pObject && pObject->parent() ) pObject = pObject->parent(); ... } Hvis pObject->parent() skulle bli evaluert uavhengig av om pObject er null ville det bli runtime krasj. Å skrive tilsvarende kode hvis alt ble evaluert ville gi mange flere nivåer i koden og vanskeligere lesbarhet. Lenke til kommentar
x871kx6167ss7 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Edit: Dette jeg sier under her blir feil. Når man gjør konverteringen, så må man også gi sin egen "implementasjon" av and, og der må man velge hviken semantikk man gir and, og den vil ikke være avhengig av semantikken av and i vertsspråket. Kan forsåvidt påpeke at man skrive om alle programmer med call/cc til et ekvivalent program uten call/cc, så det første eksemplet mitt viser vel da at man kan få forskjellig resultat i praktisk talt alle programmeringsspråk. Edit: Tror ikke nødvendig vis dette (denne posten) er riktig lenger (i forhold til problemstillingen). Skal tenke på det... Endret 15. februar 2012 av peterbb Lenke til kommentar
tomsi42 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 I C++ er det veldig behagelig at ikke alle uttrykk evalueres: void someFunc( Object* pObject ) { while( pObject && pObject->parent() ) pObject = pObject->parent(); ... } Hvis pObject->parent() skulle bli evaluert uavhengig av om pObject er null ville det bli runtime krasj. Å skrive tilsvarende kode hvis alt ble evaluert ville gi mange flere nivåer i koden og vanskeligere lesbarhet. Eller kan man si at denne konstruksjonen er et resultat av mangler i språket? For en som er godt kjent med C/C++ så er dette naturlig, men er det egentlig det for en utenforsående? Lenke til kommentar
OldMan Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 (endret) Eller kan man si at denne konstruksjonen er et resultat av mangler i språket? For en som er godt kjent med C/C++ så er dette naturlig, men er det egentlig det for en utenforsående? Tror ikke jeg ville valgt å kalle det en mangel i språket, det var ett helt bevist valg i designet av C, og gir programmerene en grei regel å forholde seg til. Så hvidt jeg vet er dette implementert likt i alle C baserte språk: C++, C#, Java osv. Andre språk har valgt andre implementasjoner og det er vel også greit, så lenge reglene er klart definerte. Hva man anser som naturlig tror jeg henger mye sammen med hvilket språk man lærte først/bruker mest. Oversikt over hvilke språk som støtter "short-circuit evaluation". Endret 16. februar 2012 av OldMan Lenke til kommentar
zotbar1234 Skrevet 15. februar 2012 Del Skrevet 15. februar 2012 Eller kan man si at denne konstruksjonen er et resultat av mangler i språket? foo = None if something: foo = MyObject() if foo and foo.somethingelse(): print "whee!" Språk_et_, sier du? Lenke til kommentar
Gjest Slettet+9871234 Skrevet 16. februar 2012 Del Skrevet 16. februar 2012 (endret) Språk_et_, sier du? Og nå er det tilbake til Python (muligens C++) fra php for en kortere periode, og da må man huske å ta av seg boksehanskene : http://www.kjellbleivik.com/images/Python25.jpg Prøver å lage noe web mining fra en Django https://www.djangoproject.com/ python drevet site. Første prioritet: http://shop.oreilly.com/product/0636920010203.do Fri oppdatert Kode her: https://github.com/ptwobrussell/Mining-the-Social-Web Og eventuelt "Financial Modelling in Python" der Python kombineres med C++. Den koden er bare tilgjengelig på CD. Ytterligere informasjon og resssurser i denne: http://www.oopschool.com/phpBB3/viewtopic.php?f=6&t=110 posten. Endret 16. februar 2012 av Slettet+9871234 Lenke til kommentar
Johan Skrevet 17. februar 2012 Del Skrevet 17. februar 2012 Veldig vanlig i CL med (and foo bar zot) og (or quux bang piff), spesielt inni loop(). Vet ikke helt om jeg liker det, men jeg har brukt det en del selv også, særlig når man binder variabler á la (let ((hax (or (zot) (quux)))) ...) Lenke til kommentar
vebbiii Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 (endret) Er det noen av dere som har erfaring med å ta jobber som programmerer under utdanningen? Jeg er kommet litt over halveis i som dataingeniør, og har et relativt stort prosjekt på gang, der jeg regner med at jeg kommer til å bruke ca 300 timer totalt. Egentlig funderer jeg litt på hvor mye jeg skal be om i betaling, og hvordan det gjøres skattemessig. Hovedsaklig tar jeg dette for erfaringen sin del, men det er selvsagt greit med litt penger også. Og i tillegg vil en erfaren programmerer antakelig bruke betydelig mindre tid enn det jeg vil gjøre. Det enkleste skattemessig blir vel å opprette et enkeltmannsforetak, og fakturere firmaet jeg skal lage programmet for? Hva ville vært en fornuftig betaling for dette prosjektet mener dere? Endret 20. februar 2012 av vebbiii Lenke til kommentar
Blåbær Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 Fakturer ja og enkeltmannsforetak er det enkleste både for deg og bedriften. men ta en enten fastpris eller timepris. Er kravspekken satt og det kommer endringer, så fakturerer du en fastsatt timepris som kommer itillegg til fastprisen. Lag en skikkelig kontrakt, eventuelt bruk standardkontrakter som ps2000/difi sitt. Og fakturerer firmaet ditt for mer enn 50k må selskapet momsregistreres. Lenke til kommentar
GeirGrusom Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 (endret) Over 120k mister du også retten til stipend. Endret 20. februar 2012 av GeirGrusom Lenke til kommentar
asicman Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 Veldig vanlig i CL med (and foo bar zot) og (or quux bang piff), spesielt inni loop(). Det er ikke så uvanlig med short circuit boolean operatorer. I shell scripter skriver man ofte: $ true && true && true && echo yes yes $ true && false && true && echo yes Det blir også ofte slik i CL også (and ptr (str ptr) (format nil "ptr contains ~A" (str ptr))) I C er det mest vanlig i forbindelse med if og iterasjon, men det er kanskje litt mer uvanlig å skrive: ptr && ptr->str && printf("ptr contains %s\n",ptr->str); I CL er det også vanlig å bruke some eller every hvis man skal mappe over en sekvens, every vil også stoppe dersom har funnet et nil resultat CL-USER> (some #'(lambda (n) (print n) (oddp n)) '(1 3 5)) 1 T CL-USER> (every #'(lambda (n) (print n) (oddp n)) '(1 3 5)) 1 3 5 T CL-USER> (every #'(lambda (n) (print n) (oddp n)) '(1 3 4 5)) 1 3 4 NIL Lenke til kommentar
vebbiii Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 Stipendet har jeg faktisk ikke tenkt på. Men det går vel kun på total brutto inntekt det året? Det er ikke noe annet om man driver et enkeltmannsforetak, er det? I så fall er grensen på ca 150k, ikke 120k. Jeg vurderer å utvikle for egen regning, og selge et ferdig produkt enkeltvis til de 4-5 bedriftene som er interessert, slik at jeg fortsatt "eier" kildekoden. Om jeg i stedet utvikler direkte for den ene bedriften og tar timebetaling vil vel de eie kildekoden, slik at jeg ikke kan selge den videre? Lenke til kommentar
Matsemann Skrevet 20. februar 2012 Del Skrevet 20. februar 2012 Det avhenger av kontrakten. Pass på å spesifisere og avtale dette. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå