Gå til innhold

ProgrammeringsBaren! Småprat, om det du elsker!


Anbefalte innlegg

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 av torbjørn marø
Lenke til kommentar
Videoannonse
Annonse

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 :p tidlig på morgen.

Lenke til kommentar

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 :p 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

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 av GeirGrusom
  • Liker 1
Lenke til kommentar
Gjest Slettet+9871234

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

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 :p 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 av peterbb
Lenke til kommentar

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

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 av peterbb
Lenke til kommentar

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

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 av OldMan
Lenke til kommentar
Gjest Slettet+9871234

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 :ph34r: :

 

http://www.kjellbleivik.com/images/Python25.jpg :roll:

 

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 av Slettet+9871234
Lenke til kommentar

 

 

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

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 av vebbiii
Lenke til kommentar

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

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

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

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...