Друже, не ешьте на ночь сырых помидор. Ну почему ближе к выходным и в течение их у дедов руборда крышу рвет?
* В Long хранятcя только целые числа
- Благодарю. Чем обязан столь важному напоминанию?
* К тому, что округлять дробные числа до целых в деньгах как-то не принято. А в Киеве дядька... хочется продолжить. Я спрашивал чем я обязан тому, что Вы меня носом тыкаете в азбучные истины. И потом, у кого не принято? У Вас? А у меня принято. Мы просто разные суммы считаем. Еще раз повторю - _я_ ничего еще не округляю и не считаю :)
* Это самое округление и проводится с разной точностью в зависимости от data type. Вы сами-то вслух читаете, то, что пишете? При чем здесь data type? Друже, научитесь отличать точность округления и точность, с которой хранится число. Что Вы на слово "точность" делаете стойку, тем более, вне контеста его использования, а потом еще и сами контексты перемешиваете?
* Непонятно, каким образом делая денежные расчеты, вас не интересует точность расчета. Снова повторю - не я делаю, а Zloy_Gelud. Денежные - это Ваша фантазия (сырые помидоры ?) и мое скромное предположение, на котором я, в отличие от Вас, не настаиваю с такой завидной упертостью.
* Опасаетесь currency, возьмите decimal. Ага. Не нравится красную, зае..ньте зеленую.
Я писал, что я "опасаюсь"? Нет. Я писал, что "... порекомендовать или наоборот не могу." С чего Вы решили, что я вообще нуждаюсь в той или другой? Еще раз напомню - я отвечал на вопросы Zloy_Gelud.
Если все таки отвлечься на currency и decimal, то, как же Вы можете рекомендовать то или другое, если Вы даже определения currency не знаете?! Вот я и предостерег Zloy_Gelud своим намеком.
* Но long здесь совершенно не к месту. Во-первых, где "здесь"? Вы уж потрудитесь среди нескольких переменных и двух строчек кода указать поточнее - какое "здесь" имеется ввиду.
А во-вторых, это дело хозяйское, какой дататип использовать. Я указал Zloy_Gelud на ошибки, несоответствия и возможные траблы? Указал. Он принял к сведению. Хозяин-барин, решит сам. На меня-то что Вы набросились со своими нравоучениями?
* Из-за не правильного data type у вас и округление идет неверное. Опять за рыбу деньги... How much the fish? У меня нет никакого округления! Где Вы его увидели?! Ткните пальцем. Тем более "Из-за не правильного data type". Повторюсь, - читайте вслух то, что пишете. Даже если предположить, что будет "правильный" тип, что правильного, согласно Ваши рекомендациям, появится в тех неявных округлениях, которые присутствуют в этом коде?! Читайте, друже, читайте внимательно тему. Вот, что я писал:
"... тут у тебя явный косяк будет с округлением ... Все равно надо явно приводить и правильно (!) округлять. Правильно, значит так как надо твоему главбуху..." * And (Not Cena > 14) выдаст такой же результат как и And Cena <= 14 Читайте тему. Внимательно читайте. И не вырывайте из контекста.
Вот мои слова:
"...вроде бы, все чисто, но, чтобы перебдеть: If (Cena > 3) And (Not Cena > 14) Then " * ...все равно в любом случае сравниваете дробное с целым... Но ужЕ не на равенство! И исключительно с целью "перебдеть".
* В целом, просто никому не нyжная операция, Никому... Вы, уже сединами убеленный мембер, с регалиями... Вас еще жизнь не научила не впрягаться за весь инет? Хотя, если Вы красным так вот запросто пишете...
Вы уже не помните, что ее избыточность я констатировал и аргументировал в момент ее предложения? Милый мой КО... :)
А если [more=серьезно], ответьте, плз, авторитетно и ответственно - даете фал на пятаки, что "выдаст такой же результат"? Бабками ответите? Впрочем, при Вашей некомпетентности и безаппеляционности суждений и рекомендаций я не удивлюсь, что Вы ответите "Да" :))
Поизучайте на досуге:
Цитата: При сравнении значения типа Single со значением типа Double, значение типа Double округляется до точности типа Single. Если значение типа Currency сравнивается со значением типа Single или Double, то значение типа Single или Double преобразуется к типу Currency. Аналогично, при сравнении значения типа Decimal со значением типа Single или Double, значение типа Single или Double преобразуется к типу Decimal. Для типа Currency любая дробная часть со значением, меньшим 0,0001 может оказаться потерянной. Для типа Decimal могут быть потеряны дробные части, меньшие 1E-28, или возникнуть ошибка переполнения. Потеря дробных частей может привести к тому, что числа, не являющиеся целыми, будут сравниваться как целые.
[/more]
* будет выпонено в 2 раза больше boolean операций. При одноразовом расчете просто ненужная мелочь. При расчете в цикле - дополнительное время. Тут Вы меня ужЕ определенно [more=достали]. Вам поумничать захотелось? Похоже на то. Покуражившись над currency, decimal и округлением, Вы решили, что Вам и этого мало. Взялись за оптимизацию кода? Тем более на ровном месте - ведь было оговорено, что лишняя операция предпринимается сознательно и именно "чтобы перебдеть". Более того, еще выше я писал про округление
"Если нужно быстродействие..." Я имею его, быстродействие, ввиду, имею...
Нет же, Вы все равно всунулись... Что ж. Назовите цифру. На сколько? Назовите мне задачу, где бы это было критично. Какие объемы данных гнадо при этом проворачивать? А? Может и назовете, только вот к вопросу Zloy_Gelud это можно будет привязать только в Вашем больном воображении. А, бзв, подскажу, что я именно такие объемы и ворочаю, считаю каждую операцию.
Вот, взгляните. Мсек - отсчет по GetTickCount, Микросек - отсчет по HRT.
Так вот. Разница даже еще не в полсекунды (!), а 0,373 сек возникнет только на 100-миллионном цикле. А на цикле в 1 млрд разница составит 4 сек (и то - без копеек)[/more]
И, [more=последнее:]
* Currency это как бы вариант decimal с точностью до 3 или 4(не помню сейчас точно) знаков после запятой. Пацталом... Вы вначале разберитесь со своим "как бы" и "не помню", а потом уж пытайтесь давать рекомендации и нравоучения. Я выше уже вежливо Вам намекал и обращал внимание на возможные нюансы использования этого типа. Вместо отсылания людей на левые ссылки типа
VBA Data Types, обратитесь лучше к первоисточникам:
Цитата: Currency Data Type
Currency variables are stored as 64-bit (8-byte) numbers in an integer format, scaled by 10,000 to give a fixed-point number with 15 digits to the left of the decimal point and 4 digits to the right. This representation provides a range of -922,337,203,685,477.5808 to 922,337,203,685,477.5807. The type-declaration character for Currency is the at sign (@).
The Currency data type is useful for calculations involving money and for fixed-point calculations in which accuracy is particularly important.
[/more]