Сметки с пари

[Stilgar]

Смятайте пари с типове с плаваща запетая да видите един ден кви майтапи ще станат:)

[wuser]

Аз още преди много време, четох някъде някаква дебела глава да казва винаги и само винаги, и никога другаде да се смятат пари с int. После на още места го видях. Даже видях и на български някъде. Още не мога да се начудя, защо Ц НЕ МОЖЕ да смята. Кой е направил тази историческа грешка? Но не спирам да се чудя и как да смятам целочислено стотинки? Направо акъл не ми го побира, а точно финансов проект се каня да подема.

[Stilgar]

Виж ся то пари ако не знаеш как се смятат просто не трябва да смяташ. Те парите не са като другите числа.

Сега ще ти обясня защо компютрите не могат да смятат с пример. Представи си, че си кръчмар и имаш тетрадка, в която можеш да записваш само десетични дроби (не можеш да пишеш обикновени дроби). Сега си представи, че трябва да си запишеш в тая тетрадка, че с Пешо, Гошо и Тошо са пили по равно бира за 10 лв. обаче нямат пари сега и ще платят другия път и трябва да запишеш на всеки по 10/3 лв. дълг в тетрадката, в която не можеш да пишеш друго освен десетични дроби. К'во ще правиш?

[wuser]

Вярно не са като другите, от тия числа сме пряко зависими, но още не увирам все пак какда стане. За тоя пример благодаря, изясни ми се. Ами тогава ФОРТРАН и този новия (нов, нов, колко да е нов) Хаскел, как са направени? За тях съм чел, че са математически точни. А най-новия FORTRAN от преди година е даже на Жаба машина качен?

И ще съм ти изключително благодарен, даже Каменица ще ти купя (нали си ми майна) ако извадиш някоя от твойте златни връзчици, как аджеба да ги смятам пустите стотинки.

За сега простата ми глава е родила две еднакво тъпи и налудничеви решения. Едното е да ги съхранявам в отделна променлива и като минат сто да си измисля алгоритъм да трупна еденица или обратното, ако намалеят.  Струва ми се безумно сложно. Другото още по-налудничево е, когато ги представям на пича да ги деля на сто. Тоест той ще вижда 1 лев и 43 стотинки, а действителната стойност ще е 143 например. Ама и така ми трябват допълнителни променливи и едни ужасни сметки, че не знам.

[Stilgar]

Не знам какво си чел за Fortran и Haskell. От първото нямам никаква идея от второто съвсем малко и то не в тая посока. Допускам, че може да имат типове за работа с обикновени дроби и чрез отлагане на изпълнението да успяват да опростят израза и да направят само едно изчисление накрая. Всичко това е постижимо и с другите езици, но може би в Haskell и Fortran има някакви улеснения по въпроса. Haskell например вътрешно и естествено прави всичко с отлагане на изпълнението. Това обяснение е мое предположение и не съм проверявал как стоят нещата.

Принципно сметките с float/double са по-проблемни от другите щото точността мърда. Има типове (BigDecimal в Java, decimal в C#) които смятат с десетична точност (като тетрадката). При плаващата запетая проблемът е, че сметките реално са двоични което значи, че 1/5 не може да се представи точно, а в десетична бройна система това си е точно 0,2 и от там някакви очаквания се чупят щото на хората им е странно, че 1/5 е криво число, а им е съвсем естествено, че 1/3 е криво нищо, че кривината им е абсолютно еднаква. За пари се ползва десетичен тип за да може лесно да се виждат проблемите от хора и да се оправдаят очакванията на хората. Това е ОК за един магазин, но за една банка нещата стават още по-сложни и има начини за закръгляне като банкерско закръгляне ( http://en.wikipedia.org/wiki/Banker%27s_rounding#Round_half_to_even ) и прочие правила зависещи от бизнеса. Нещата хич не са прости затова обяснявам, че не трябва да го прави човек дето не е учил как се прави. Всъщност ти не беше ли счетоводител? Ти трябва да ни ги обясняваш тея неща не аз.

[wuser]

Ами аз точно щото съм счетоводител. За туй се хванах и за пустото Ц++ преди година почти. Оказа се, че няма свясна счетоводна програма, а за ГНУ/Линукс версия и да не се надявам. Половината си съхраняват данните в текстови файлове, другите в дибейс. Тук таме има със SQL, ама искат Оракул или М$ от тоя дето пари струва. Или пък се казва САП. Има една (Микроинвест) с mysql, ама той е платен за такива нужди. Шах и мат. На всичкото отгоре се оказва, че са кът програмите ползващи транзакции, което значи, че баланса не ти е верен, дебита не е равен на кредита, а това е почти невъзможно да откриеш къде е грешката при по-голям документооборот. Дебит и крредит са най-общо приход и разход от оня тефтер. Не е точно и е по-сложно, ама така за яснота. Боже как може да правиш счетоводна програма без транзакции и без истинска СУБД?

Благодаря за връзчицата, ще я погледна, но все повече ми идва на акъл, че няма да ме бъде и програма няма да си напиша. Умствения багаж ми е малко.

[Stilgar]

Да напишеш сериозна такава програма е много работа сякаш, а Ц++ съвсем не е най-удобната технология. Ако на един C#/Java може да си полезен след 1 година учене на C++ си полезен след 5.

[wuser]

Попрочетох връзчицата за закръглянията, ама не разбрах как се прави това програмно. Няма ли някъде нещо, моля?

[Stilgar]

Е как... пишеш един if в който сравняваш предишната цифра и готово. Разбира се това е често срещана операция и обикновено го има на готово в стандартните библиотеки. Например: http://msdn.microsoft.com/en-us/library/ms131274.aspx

[echeveria]

Разправям му аз на Гошко за С++ да не се занимава ама кой да слуша -  все пак сме 21 век бе!

[intel]

Работата с парите, няма как да се проумее ако човек не знае как борави компютъра с цифрите(нарочно споменавам цифри, а не числа). Всичко започва с това как компютъра съхранява и разчита дадена цифра.
Еч беше дал линк към едни лекции за програмиране от университета Станфорд - на втората или третата лекция, лектора съвсем целенасочено набляга на това как компютъра борави с цифрите( а не с парите! ).

Както знаете процесорите ползват двоично представяне на информацията - под информацията в случая имаме предвид цифрите. Само те ни интересуват защото чрез тях правим операциите с парите.

Сега, много е важно да не смесвате и  да не припознавате парите с цифрите! В програмирането забравяте за това нещо. Просто си знайте че парите са едно лице(личност) представяна от друго лице(личност) - в случая от цифри. Така че по пътя на логиката няма как две лица(личности) да са едно и също нещо

Защо ви го казвам това. Ами защото когато работим с пари, ние не ползваме съвсем същите правила за броене/делене/умножение/събиране/изваждане като с цифрите. И за да не се омотаете, веднага давам пример( Подобен на този споделен от Стилгар).

Примерно имаме двете цифри 1 и 3. Когато искаме да разделим цифрата 1 на цифрата 3 или да съберем цифрата 1 с цифрата 3, това е напълно нормално нали така? А примерно когато имаме 1лв и 3лв и ако ви кажа да се опитате да разделите 1лв на 3лв, какво ще кажете, а?
А ако ви накарам да съберете 1лв. с 3лв., тогава става нали?
И какво се получава - парите са представени от цифри, но самите пари нямат същите свойства като цифрите.
Ето тука идва големия проблем. Когато се опитваме да представяме една единица(лице/личност) със свойствата на друга единица(лице/личност).

Затова не можем директно да работим с парите в компютрите. Защото компютрите не виждат пари, ами цифри(макар и представени двоично)
И много хора бъркат двете неща и от там попадат в задънена улица.

А относно начина за представяне на парите с цифри - ами сложно е но не е невъзможно.
За да постигнеш целта си, първо трябва да си направиш списък на всички възможни операции/свойства на парите.
След това има едно много просто правило - парите винаги имат една най-малка единица.
Остава да имплементираш всички тези операции/свойства на парите като код и този код да работи с най-малката единица. Ако схващаш логиката ще се запиташ - ама защо трябва да работя точно с най-малката единица (на прост език казано - защо трябва да обръщам всичко в стотинки!).
Отговора ще бъде много дълъг и затова ще кажа само едно - логиката е същата като при компютрите(процесорите). Задайте си въпроса, защо и при тях ползват възможно най-простата бройна система(двоичната), м?

Така че, дръж нещата прости. Наистина се налага да направиш собствен абстрактен слой(имплементиране на горните правила за парите и техните свойства) чрез който да стане връзката с цифрите. Естествено че ще станат много големи сметки, и данните ще костват по-голям overhead/обем от място, но това е положението.
Парите винаги са били сложно нещо и ще си останат сложно нещо, защото човек има "различно" разбиране/отношение към тях. 


PS: Ето го линка за лекциите от Станфорд: http://academicearth.org/courses/programming-paradigms
Много е препоръчително да ги видите, или поне да проумеете как работи компютъра с цифрите, ако искате да няма проблеми със сметките с пари при компютрите