ProgrammeringsBaren! Småprat, om det du elsker!

[asicman]

Jeg hadde nok hatt problemer om jeg kun hadde hatt hele øre i I/O (database) også,

 

Jeg tenker input og output til applikasjonen, f.eks. inn fra betalingstermainal og ut til faktura. Det vil som reglel være i hele øre. Hvis det er snakk om mellomlagring i databaser så kan det være f.eks. Common Lisp objekter (eller f.eks. pickle i Python) som inneholder rasjonale tall dersom det er hensiktsmessig for applikasjonen.

[MailMan13]

Så du har egentlig påstått og argumentert for noe du ikke bruker i det heletatt da?

 

Hva som skal ut i eksterne grensesnitt er definert i grensesnittet, blande det sammen med hvordan man gjør det i sin egen aplikasjon er ikke særlig relevant.

[asicman]

Så du har egentlig påstått og argumentert for noe du ikke bruker i det heletatt da?

 

Jeg har brukt øre representert som heltall i noen applikasjoner. Common Lisp har støtte for store tall og bruker rasjonale tall i mellomregninger osv. Common Lisp objekter som representerer disse data (og mange andre data) blir lagret i en database, selv om man ikke ser så mye til den. Jeg har også sett kode skrevet av andre som bruker liknende metode. Det samme ville være mulig i f.eks. Python.

 

Hva som skal ut i eksterne grensesnitt er definert i grensesnittet, blande det sammen med hvordan man gjør det i sin egen aplikasjon er ikke særlig relevant.

 

Det som er definert i grensesnittet er i de tilfellene jeg har vært borti vært definert i hele øre eller hele kroner. Det gjelder både input (f.eks. aksjekurser osv.) og output (utskrift, GUI o.l.).

[asicman]

Jeg har som sagt gjort dette i Common Lisp. Det samme ville være mulig i Ptyhon, selv om jeg ikke har gjort det i Python. Jeg ville da fortsatt argumentere for denne metoden i Python selv om jeg ikke har gjort det i Python. Jeg ser ikke noe problem i å argumentere for det, hvis det er hva du mener. Jeg forstår ikke hvorfor du tar opp dette og hva det har noe med saken å gjøre.

[MailMan13]

Da forstår jeg ikke hvorfor du sier "I dag bruker man som oftest integer (med støtte for store tall) til finansielle kalkulasjoner" når noen påstår at man bruker desimale typer for det.

 

Det er jo sistnevnte man faktisk i all hovedsak bruker. .NET, Java, Python, Ruby og sikkert flere har alle 128bits flyttall med desimale mantisser, BCD aritmetikk og 30+ signifikante siffer, og det er dèt man som oftest bruker.

 

Bruk ihvertfall eksempler som er relevante for det du argumenterer for. At Lisp regner riktig med rasjonale tall er ikke et argument for å regne med integers i Python når Python har en desimal type tilgjengelig.

Endret 10. juli 2010 av MailMan13

[asicman]

Da forstår jeg ikke hvorfor du sier "I dag bruker man som oftest integer (med støtte for store tall) til finansielle kalkulasjoner" når noen påstår at man bruker desimale typer for det.

 

Det er basert på min observasjon. Men jeg er selvsagt farget av at jeg bruker Common Lisp. Jeg jobber med chip design og ikke finansielle programmer så jeg har helt klart ikke sett store deler av verdens finansielle kode. Det tror jeg ikke de fleste her heller har, selv om mange sikkert har sett mer enn meg, inklusive deg. Jeg vil nesten anta at den største andelen finansiell kode er skrevet i COBOL, hvor BCD aritmetikk var vanlig så det er nok vanlig av den grunn. Men jeg har sett at nyere kode har en tendens til å bruke eksakt heltalls aritmetikk. Så det er mer riktig å si «ofte, dersom som man bruker et språk som har støtte for eksakte beregninger» i stedet for oftest.

 

Ut i fra din diskusjon så vil jeg anta at du er farget av Java e.l. bakgrunn hvor man ikke har direkte støtte for rasjonale, spesielt når du sier:

 

Akkurat derfor "I dag bruker man som oftest integer" er galt. Det er kanskje enkelte som gjør man fordi man ikke vet bedre, eller fordi man koder javascript, eller noe som kanskje ikke har alternativer.

 

Her virker det som om du forsøker å si at jeg ikke vet bedre. Jeg forstår denne problematikken. Men det virker som du ikke forstår dette med eksakte heltalls beregninger, når du kommer med en slik uttalelse etter at jeg har vist hvordan man får eksakt resultat med Common Lisp kode.

 

Det er jo sistnevnte man faktisk i all hovedsak bruker. .NET, Java, Python, Ruby og sikkert flere har alle 128bits flyttall med desimale mantisser, BCD aritmetikk og 30+ signifikante siffer, og det er dèt man som oftest bruker.

 

Bruk ihvertfall eksempler som er relevante for det du argumenterer for. At Lisp regner riktig med rasjonale tall er ikke et argument for å regne med integers i Python når Python har en desimal type tilgjengelig.

 

Jo det er relevant. Python har støtte for store heltall og omregninger som innebærer divisjon kan gjøres med rasjonale tall som vil gi eksakte resultater.

 

Floating point og fixed point datatyper vil ikke gi eksakte beregninger, selv om det er mange som bruker det.

 

De fleste heltalls operasjoner vil bli utført i 64-bit (ca 9223372036854775808 øre) heltalls domene som er veldig effektivt på en moderne CPU. Blir tallene større vil kompilatoren selvsagt håndtere det.

[MailMan13]

Hvis du baserer deg på at dine resultater ikke skal kunne regnes videre på av noen, da har du forsåvidt rett i at det ikke trenger mer enn øre-presisjon. Det er ikke en antagelse jeg synes man kan ta uten videre.

 

Løsningen din på alle problemene som kan oppstå med denne strategien synes å være å ikke bruke det, og bruke øre for rasjonale tall i stedet for, så hvorfor la denne løsningen eksistere? Hvorfor sitte å bestemme på forhånd hva som skal kunne beregnes på og hva man ikke kan basere seg på senere? Det koker ned til ett eneste bruksområde; å eksponere det i grensesnitt som krever akkurat denne representasjonen.

 

Vet ikke hva du legger i "finansiell beregning", men hvis du ser på en enkel en: 100000,- avskrives over 50 terminer med 1% rente per termin. Du regner ut terminbeløpet til 2255127 øre. Når regnskapssystemet ditt er ferdig å avskrive denne står det 12 øre på kontoen fordi 0.309 øre forsvant når du lagret svaret ditt. Ved å endre ett nøkkelord i koden fra int til decimal forsvinner problemet helt for beregninger under 20-30 siffer, og ingenting annet endrer seg i koden.

 

Finansielle beregninger er ikke anerledes enn annen mattemetikk, har ikke mer presisjon enn i det svakeste leddet. Det gir ikke mening med 8 siffer i ett beløp og noe annet i dem andre, uavhengig av hvilke side av desimaltegnet dem står på. Fixed point er like uegnet for resulteter i finansielle beregninger som for vitenskapelige.

 

Hvis man har verktøyene for å gjøre ting med full/høy presisjon, hvorfor ikke bruke dem, i stedet for å trunkere svaret inn i en egendefinert fixed-point type?

 

Men det virker som du ikke forstår dette med eksakte heltalls beregninger, når du kommer med en slik uttalelse etter at jeg har vist hvordan man får eksakt resultat med Common Lisp kode.

Du har vist hvordan det blir et eksakt resultat når du lar lisp velge datatyper for deg, det er riktig. Det du har vist er et godt og gyldig argument for å bruke rasjonale tall i stedet for øre i integers. Endret 10. juli 2010 av MailMan13

[asicman]

Hvis du baserer deg på at dine resultater ikke skal kunne regnes videre på av noen, da har du forsåvidt rett i at det ikke trenger mer enn øre-presisjon. Det er ikke en antagelse jeg synes man kan ta uten videre.

 

Jeg baserer meg ikke på an slik antakelse.

 

Vet ikke hva du legger i "finansiell beregning",

 

 

Jeg tenker på beregninger som har med penger å gjøre og typisk ikke innebære irrasjonelle tall og tall med stor dynamikk. Verdiene vil hovedsak ligger innenfor +/-9223372036854775808 øre. Om de utenfor så fikser kompilatoren det. Som sagt så vil en moderne CPU behandle dette meget effektivt.

 

 

Du regner ut terminbeløpet til 2255127 øre

 

Nei,nei,nei det er er nok akkurat her du ikke forstår hva jeg mener. Dette er en mellomregning for å komme fram til den totale betalingen som innbærer divisjon og det vil blir representert som et rasjonalt tall. Det er helt analogt med momsberegningen tidligere.

 

En gang til: Pengeverdiene representeres i heltall som øre. Alle mellomregninger som innebærer divisjon kan gi rasjonale tall som er eksakte.

 

 

Finansielle beregninger er ikke anerledes enn annen mattemetikk,

 

Ingen har vel påstått noe annet.

 

Hvis man har verktøyene for å gjøre ting med full/høy presisjon, hvorfor ikke bruke dem,

 

Akkurat, det er poenget mitt!!! Det er det jeg har forsøkt å argumentere for hele tiden. Hvorfor skal man bruke unøyaktig floating point når man kan bruke eksakt heltalls aritmetikk i de tilfellene det er mer effektivt.

 

i stedet for å trunkere svaret inn i en egendefinert fixed-point type?

 

Det er det ingen som har foreslått

 

Du har vist hvordan det blir et eksakt resultat når du lar lisp velge datatyper for deg, det er riktig.

 

Man kan bruke denne samme metoden i Python og de fleste andre spåk, selv om det ikke er så elegant som i Common Lisp hvor det er innebygget i språket.

[MailMan13]

Jeg baserer meg ikke på an slik antakelse.

Hvis du returnerer et svar i hele øre, det være seg intern eller eksternt grensesnitt, så sier du implisitt at denne verdien ikke er egnet å regne videre på, hverken nå eller i fremtiden.

 

Det har skjedd mer enn en gang jeg har måttet legge til "PriceExact" ved siden av "Price" i datamodeller, fordi dem som skrev den opprinnelige koden trodde dem hadde det endelige resultatet, og returnerte avrundet i hele kroner eller øre.

 

Nei,nei,nei det er er nok akkurat her du ikke forstår hva jeg mener. Dette er en mellomregning for å komme fram til den totale betalingen som innbærer divisjon og det vil blir representert som et rasjonalt tall. Det er helt analogt med momsberegningen tidligere.

Hvis jobben til ditt program er å regne terminkostnad og jobben til regnskapsystemet er å avskrive investeringen med terminbeløpet ditt, da er ikke øre som integer godt nok som datatype for output i ditt program. Da blir det avvik et eller annet sted nedover verdikjeden.

 

Hvis du sitter å koder i en helt lukket verdikjede og vet med 100% sikkerhet at det ikke kommer til å endre seg kan du gjøre som du sier, regne ut alt og legge resultatet i en integer. Jeg kjenner ikke mange miljøer som er slik.

 

Akkurat, det er poenget mitt!!! Det er det jeg har forsøkt å argumentere for hele tiden. Hvorfor skal man bruke unøyaktig floating point når man kan bruke eksakt heltalls aritmetikk i de tilfellene det er mer effektivt.

Det du ikke skal bruke er integer i øre, om du bruker rasjonale tall i øre, supert!

 

Det er ikke rasjonale tall jeg angriper, det har jeg aldri gjort, men jeg skjønner du mener jeg gjør det.

 

Det er "integer i øre" jeg mener er uheldig og gir feil. Jeg sier decimal fordi jeg er vant til å ha 96-128bits desimale typer tilgjengelig, er det rasjonale typer tilgjengelig, så "power to you".

[worseisworser]

Dere snakker om "rasjonelle tall" mer spesifikt (eller, vel, ikke), eller? I CL er både RATIO og INTEGER subtyper av RATIONAL;

 

CL-USER> (sb-pcl:class-direct-subclasses (find-class 'rational))
(#<BUILT-IN-CLASS RATIO> #<BUILT-IN-CLASS INTEGER>)

 

 

http://static.nostdal.org/hyperspec/Body/t_ration.htm

 

"In mathematics a rational number is any number that can be expressed as the quotient a/b of two integers, with the denominator b not equal to zero. Since b may be equal to 1, every integer is a rational number. "

( http://en.wikipedia.org/wiki/Rational_number )

Endret 10. juli 2010 av worseisworser

[asicman]

Hvis du returnerer et svar i hele øre, det være seg intern eller eksternt grensesnitt, så sier du implisitt at denne verdien ikke er egnet å regne videre på, hverken nå eller i fremtiden.

 

Jeg tror ikke du vil forstå hva jeg mener. Vennligst les meldingen min en gang til. Les paragrafen som starter med «Nei, nei, nei». Jeg forstår ikke hvorfor du hele tiden insisterer på å ødelegge presisjonen på de interne beregningene. Forsøk å glemme C og Java, ikke la det ødelegge tenkesettet ditt og tenk deg et språk (eller bibliotek) som lar deg gjøre eksakt aritmetikk med heltalls verdier som representerer øre.

 

Da blir det avvik et eller annet sted nedover verdikjeden.

 

Nei ikke hvis man bruker eksakt heltalls aritmetikk. Les det jeg har skrevet og prøv å forstå hva jeg mener.

 

Det er "integer i øre" jeg mener er uheldig og gir feil. Jeg sier decimal fordi jeg er vant til å ha 96-128bits desimale typer tilgjengelig, er det rasjonale typer tilgjengelig, så "power to you".

 

Det man leser inn i fra en ordre o.l. er typisk en ASCII streng i kroner. Når man leser inn denne så lagres denne i et heltall som øre. Jeg forstår ikke hvorfor du har så vanskeligheter med dette. Beregningene som blir gjort etter det er eksakte. Evt. avrunding som skal gjøres har man full kontroll over. Det som skrives ut er øreverdier (eller man setter på komma for å få det i kroner i utskriften).

 

Du sier deg selv i mot når du først argumenterer for å bruke mest mulig presisjon og deretter argumenterer for floating point over eksakte heltalls aritmetikk.

[asicman]

Jeg tror ikke du vil forstå hva jeg mener

 

 

Jeg tror grunnen til at du ikke vil forstå dette har med tilnærmingen din til denne diskusjonen.

 

A) Du har ikke lest forløpet til diskusjonen. Den startet med en kommentar fra meg at skulle man ha det moro så programmerte man i Common Lisp. Deretter ble det som vanlig en liten language war. Jeg kritiserte Python for at semantikken endrer seg med versjonene og dette gjaldt spesielt bruken av rasjonale tall, hvorpå jeg viste litt om rasjonale tall i Common Lisp.

 

Deretter blir det en diskusjon hvor jeg sier at floating point ikke er nøyaktig, men det er rasjonale tall. SNIPPSAT kommer med en kommentar at decimal modulen i Python skal brukes til eksakte beregninger, noe jeg mener er helt feil fordi det er en modul med floating og fixed point kalkuleringer (selv om man kan velge presisjonen så blir det aldri eksakt). Jeg viser et eksempel med desimal modulen som gir ikke er eksakt. Jeg viser hvordan man kan bruke fraction modulen i Python for rasjonale tall. Så er det enda noe mer diskusjoner og mer om rasjonale tall i Common Lisp fra min side. Så kommer SIPSAT tilbake med decimal modulen og sier igjen «For finansielle kalkulasjoner bruker man ikke float,men decimal modulen.» Noe som jeg fortsatt mener er ikke er optimalt når det gjelder nøyaktighet fordi det er snakk om fixed og floatingpoint beregninger. Les:

 

http://docs.python.org/library/decimal.html

9.4. decimal — Decimal fixed point and floating point arithmetic

 

Denne har en del egenskaper som gjør den bedre enn vanlig IEEE 754 format, men forsatt ikke eksakt som jeg viste lenger opp i tråden. Til det må man bruke fractions, eller rasjonale tall.

 

Jeg sier at man heller bør bruke heltall representert som øre for pengeverdier.

 

Jeg presiserer litt senere til GeirGrusom

 

«Jeg snakker ikke om 32-bit interger o.l. selv om for noen beregninger kan det brukes 32-bit og 64-bit internt. Jeg snakker om integer med støtte for store tall. Divisjon med 3 osv. er rasjonale tall og vil holde full presisjon.»

 

Jeg sier feilaktig at dette brukes oftest, som jeg senere retter til at jeg i den senere tid har sett kode som behandler pengeverdier som heltall på denne måten.

 

B) Du kommer inn i diskusjonen, sannsynligvis uten å ha lest noe om diskusjonen som til nå har dreid seg om presisjon at man må bruke rasjonale tall og ikke floating point og decimal modulen hvis man skal ha nøyaktighet. Når du ser ordet integer (heltall) så er tankegangen din begrenset av et språk hvor alle mellomregningene på heltallsøre og alle operasjoner må trunkeres. For meg så blir det som om jeg ville tro at alle floating point beregningene du gjør er noe som:

 

  R = ...bla..double.bla...;

 sprintf(str,"%10.2lf",R);
 sscanf(str,"%lf",&R);

 før du regner videre med R

 

Denne tanken vil du ikke gi opp. Selv ikke etter momseksemplet langt opp i tråden hvor jeg viser en mellomregning som er eksakt selv om øreverdien er et heltall.

[MailMan13]

For meg så blir det som om jeg ville tro at alle floating point beregningene du gjør er noe som:

  R = ...bla..double.bla...;

 sprintf(str,"%10.2lf",R);
 sscanf(str,"%lf",&R);

 før du regner videre med R

Det er en vesensforskjell mellom double og en .NET decimal eller en java BigDecimal (eller tilsvarende).

 

Det er riktig at dem ikke er 100% nøyaktige under alle omstendigheter, men desimale tall med mindre enn 20-30 siffer holder dem eksakt siden det er svært stor mantisse og desimal eksponent (ingen mismatch ift hva som kan representeres binært). 10.21 vil være eksakt representert. Dersom man prøver seg med 10.212313534676453512453563456756 vil de par siste sifferet kanskje ikke komme med. Kanskje ikke teoretisk "rent", men mer enn nok til å bevare den presisjonen man mottar.

 

 

Denne tanken vil du ikke gi opp. Selv ikke etter momseksemplet langt opp i tråden hvor jeg viser en mellomregning som er eksakt selv om øreverdien er et heltall.

Kunnskapen om hva som er en mellomregning og hva som er et endelig resultat er en luksus jeg aldri har. Er det produksjonskode er det alltid en konsument, og hva denne konsumenten er (oftest et reskontro system) og vil gjøre med mine tall nå eller i fremtiden kan jeg ikke legge føringer for, derfor må jeg alltid mitt resultat på en form som tar vare på den presisjonen som kommer inn til meg. Sånn sett er all produksjonskode, for meg, det du kaller en "mellomregning". Derfor "ser jeg litt rødt" når du vil definere noe som "mellomregning". Da impliserer du også at du har noe som ikke er "mellomreging" som har en annen presisjon.

 

Hvis du har hatt intrykk av at det er rasjonale tall jeg har argumentert mot beklager jeg, det var ikke meningen, da har jeg ikke vært presis nok. Hvis du scanner input i øre for å gi noe effektivitetsgevints i typesystemet ditt så er det ingen problemer i det. Hvis definerer sluttresultatet i hele øre, så har vi en potensiell hodepine ett eller annet sted.

Endret 11. juli 2010 av MailMan13

[asicman]

Det er en vesensforskjell mellom double og en .NET decimal eller en java BigDecimal (eller tilsvarende).

 

Men, det er akkurat det jeg har sagt i meldingen du kommenterer! Konsulter gjerne IEEE 754 floating point spesifikasjonen og linken til Python decimal modulen jeg oppga i meldingen.

 

Men det er ikke poenget. Poenget er å vise at du reduserer presisjon i en kalkulering hvor det kan være påkrevd å ha større eller full presisjon. Det er det du har vist eksempler på hele tiden når du har tatt utgangspunkt i en heltallsverdi som representerer et pengebeløp i øre og insistert på å trunkere presisjon under mellomberegningene.

 

Kunnskapen om hva som er en mellomregning og hva som er et endelig

resultat er en luksus jeg aldri har.

 

Intermediate calculations. Mellomregning er alle mindre kalkuleringer for å komme fram til et resultat. Er det påkrevd at det er full presisjon så bruker man det i alle mellomregninger hele veien.

 

Et eksempel er momsberegningen din. Her er kalkuleringen av moms på en stk vare en mellomregning. Det totale beløpet for 100 stk er resultatet. Men du instisterer hele tiden på å trunkere denne mellomregningen.

 

Hva som er resultatet vil være applikasjonsavhenging.

[MailMan13]

Et eksempel er momsberegningen din. Her er kalkuleringen av moms på en stk vare en mellomregning. Det totale beløpet for 100 stk er resultatet. Men du instisterer hele tiden på å trunkere denne mellomregningen.

Da har du misforstått.

 

Hva du gjør med "mellomregningen" din er ikke interessant. Det som er interessant er hva du gjør med resultatet. Resultatet er også nesten alltid en "mellomregning". Mulig momseksempelet er for enkelt til å få frem poenget, siden det normalt falle innenfor samme beregning, men annuitetseksempelet er absolutt relevant der amortisering og avskriving nesten aldri vil skje på samme sted.

 

Men hver gang jeg sier at det ikke er lurt å legge resultatene sine i hele øre kommer det masse støy om heltalls aritmetikk og mellomregninger som gjør det veldig vanskelig å forstå hva det egentlig er du argumenterer for.

Endret 11. juli 2010 av MailMan13

[asicman]

 

Da har du misforstått.

 

Nei. Du forstår ikke hva jeg mener her. Eller nå begynner jeg å lure på om du troller for å få meg til å kaste bort tiden min.

 

Hva du gjør med "mellomregningen" din er ikke interessant.

 

Jo, det er det. Hvis du trunkerer mellomregningen får du feil resultat.

 

Det som er interessant er hva du gjør med resultatet.

 

Hvis applikasjonen er å regne ut moms for 100 stk varer som ble bukt i eksemplet tidligere så er man ferdig der.

 

Er applikasjonen å summere moms for flere slike varer så er det ikke det endelige resultatet og man må beholde presisjon dersom det er påkrevd. Det ser ut som om du ikke forstod «Hva som er resultatet vil være applikasjonsavhenging».

[asicman]

Er applikasjonen et regnskapsystem som kjøres fram til selskapet oppløses så beholder man presisjonen hele veien om det er påkrevd. Hvorfor insisterer du hele tiden på å trunkere verdier som skal brukes videre?

[asicman]

Er det noen som vet hva den store annonseringen Knuth skulle komme med under TUG-2010?

 

Jeg ser det er en del forslag på nettet som:

bildelink

og bildelink

 

 

Det var også rykter om en ny bok om kompilatorteknikk.

 

Men hva var den egentlige annonseringen?

 

[edit: fikk ikke img til å funke]

 

Det ser ut som om det som var annonsert som "An earthshaking announcement" inneholdt mye humor:

 

http://media.river-valley.tv/conferences/tug-2010/Don-Knuth-flv.php

[student_1]

Hei. Forstyrrer kanskje litt midt opp i den voldsomme diskusjonen, men føler at denne tråden kunne være meg til stor hjelp. Har tenkt til å begynne å studere informatikk, og trenger da en ny laptop til studie. Hvilke spesifikasjoner burde laptopen ha? Windows pc eller mac?

[Senyor de la guerra]

Windows pc eller mac?

Linux