Поиск  Пользователи  Правила  Войти
Форумы "Планета Excel" » Вопросы по Microsoft Excel (архив)
Страницы: 1
RSS
-=Почему у функций есть ограничения?=-
 
#1
26.02.2012 15:16:29
Вопрос, собственно, в сабже.  
Что мешало разработчикам сделать больше уровней вложения ЕСЛИ или больше аргументов СУММ?  
Вопрос скорее для размышления, чем для каких-то действий, просто интересно, если кто знает...
 
 
 
#2
26.02.2012 17:14:46
А это не очевидно? "На каждую умную мысль неизбежно найдется свой дурак, который аккуратно доведет ее до абсурда." Ильф и Петров.  
Серж, сделай 300 вложений, кому-то будет и этого мало. Это тот самый баланс между ценой и производительностью. Ну сделали бы на вырост, таблица на 1000 строк 30 столбцов считалась бы полчаса. Лучше бы было? За все время работы в эксе(VBA) не помню случая, когда бы мне понадобилось 7 вложений If. В таких случаях нужно искать другой, более эффективный подход. А возможноси Экса и так чересчур избыточны. Возвращаясь к цитате - не хватало 16000 строк в 5-й версии, сейчас догнали до миллиона, что всем хватает? Как бы не так. Заставь дурака богу молиться... Вместо того, чтоб использовать специально для таких объемов предназначенный Access, насилуют Эксель, визжа на форумах, что долго грузится, считает, думает. Вот что это за таблица на 1000000 строк? База данных, да. Но таблица? Что в такой таблице считать?
Я сам - дурнее всякого примера! ...
 
 
 
#3
26.02.2012 17:40:56
Серёг, у СУММ() ограничение в 30 аргументов. Почему?  
Ты когда-нибудь пользовался хотя бы двумя?
 
 
 
#4
26.02.2012 17:47:14
А почему ВПР ищет только в первом столбце?  
 
##56243##
 
 
 
#5
26.02.2012 17:56:04
Хороший вопрос. Чем руководствовались разработчики, когда не дали пользователю выбора столбца? Оптимальностью кода? Не верю, мы на последней встрече долго обсуждали что ВПР "тормозная"...
 
 
 
#6
26.02.2012 18:04:30
Мне приходилось сталкиваться с недостатком аргументов, например при использовани поиска в таблицах расположенных в листах по месяцам (функция ВЫБРАТЬ()). В СУММ() определенно использовал более 2 аргументов, но 30 и более только в ответах в форумах. Excel 2007-2010 позволяют до 255 аргументов, но мне это врядли пригодится :) А вот больше миллиона строк я не против. Я уже проводил эксперименты в PowerPivot с 3.000.000 строк на 10 столбцов с 8Gb памяти, и результаты впечатляют. В очень скором времени различия между Excel и Access как front-end БД сгладятся, т.к. Excel все больше интегрируется с SharePoint и PowerPivot (как одной из связок с SharePoint) и позиционируется как ключевой инструмент BI для среднего бизнеса.
KL
 
 
 
#7
26.02.2012 18:22:01
{quote}{login=Serge 007}{date=26.02.2012 05:56}{thema=Re: }{post}{quote}{login=RAN}{date=26.02.2012 05:47}{thema=}{post}А почему ВПР ищет только в первом столбце?{/post}{/quote}Хороший вопрос. Чем руководствовались разработчики, когда не дали пользователю выбора столбца? Оптимальностью кода? Не верю, мы на последней встрече долго обсуждали что ВПР "тормозная"...{/post}{/quote}  
Чем руководствовались разработчики всего софт- и фирм-вера, когда использовали два знака для обозначения года? Они просто еще не могли себе представить, что может понадобиться другое, настолько оно было далеко и нереально, а ресурсы были ограничены :) Не знаю, на чем основано мнение о том, что ВПР "тормозная". В том, для чего эта функция предназначена, ВПР - самое быстрое, что можно себе представить на сегодня, нет ничего быстрее ее ни среди функций ни в VBA. Говоря о ВПР, мы говорим о всех 4-х функциях поиска: ВПР(), ГПР(), ПОИСКПОЗ(), ПРОСМОТР() использующих идентичный алгоритм. Эти функции можно назвать "тормозными" только в двух случаях:  
- при нецелевом использовании (поиск сам по себе ресурсоемкая задача)  
- при создании формул с избыточными пересчетами (т.е. когда возможна оптимизация засчет устранения повторных поисков, например: ВПР(v,table,1,0), ВПР(v,table,2,0) Vs. i=ПОИСКПОЗ(v,tablecolumn1,0), ИНДЕКС(tablecolumn2,i) ИНДЕКС(tablecolumn3,i)  
На всякий случай, скорость функции ПРОСМОТР нужно сравнивать со скоростью ВПР(), ГПР(), ПОИСКПОЗ() только в частном случае приблизительного поиска.
KL
 
 
 
#8
26.02.2012 18:43:15
И отвечая на главный вопрос (как владелец софтвер фирмы), для меня функциональные ограничения - есть ни что иное, как попытка примирить спрос потребителя, затраты на его удовлетворение, имеющиеся ресурсы и program robustness (не знаю, как перевести - русский забываю потихоньку). Если еще короче: оптимизация соотношения цены и качества. Чем больше открытых дверей, тем больше непредвиденных багов в них пролезет, тем больше расходы на поддержку неудовлетворенность массового пользователя (а не продвинутого меньшенства). Не следует также забывать, что у Excel нет достойных конкуррентов, а значит у MS - стимула беспредельно наращивать его мощь.
KL
 
 
 
#9
26.02.2012 18:43:32
{quote}{login=KL}{date=26.02.2012 06:22}{thema=Re: Re: }{post}Не знаю, на чем основано мнение о том, что ВПР "тормозная". В том, для чего эта функция предназначена, ВПР - самое быстрое, что можно себе представить на сегодня, нет ничего быстрее ее ни среди функций ни в VBA.{/post}{/quote}  
Спорить не буду, я не противник, но и не сторонник этой функции, однако Range Calc однозначно даёт разные результаты, не в пользу ВПР при сравнении её с ИНДЕКСПОИСКПОЗ. При любом поиске.  
 
Однако вопрос не в этом. Я спрашиваю - почему у функций есть ограничения?  
Что мешает функции СУММ суммировать более 30 аргументов (2003) без Union?  
 
ЗЫ ВЫБРАТЬ()= ВЫБОР()
 
 
 
#10
26.02.2012 18:49:30
{quote}{login=Serge 007}{date=26.02.2012 06:43}{thema=Re: Re: Re: }{post}Почему у функций есть ограничения? Что мешает функции СУММ суммировать более 30 аргументов (2003) без Union?  
{/post}{/quote}  
Обобщенный ответ я дал выше. Технический ответ оставлю ZVI, но в Excel практически все завязано на бинарные величины, т.ч. должны быть математические обоснования.
KL
 
 
 
#11
26.02.2012 18:52:26
{quote}{login=KL}{date=26.02.2012 06:49}{thema=Re: Re: Re: Re: }{post}...в Excel практически все завязано на бинарные величины, т.ч. должны быть математические обоснования.{/post}{/quote}Но 30 сюда никак не катит ;-)
 
 
 
#12
26.02.2012 19:51:25
Да ну? А 2^30 = 1.073.741.824 (одна из бинарных величин) ;)  
И потом, я конечно не силен в теории программирования, но почему, бы в порядке бреда, не предположить, что если тип Variant состоит из 16 bytes  
 
2 VarType  
6 Reserved  
8 Contents  
 
то для ParamArray действует что-то типа 2+6+30*8=248 и оставшиеся 8 до 256 byte используются для чего-то еще?
KL
 
 
 
#13
26.02.2012 20:08:45
{quote}{login=KL}{date=26.02.2012 07:51}{thema=}{post}...я конечно не силен в теории программирования...{/post}{/quote}Я тем более :-)  
Но 1024 знаю. И 30 сюда не прилепить. А ограничение фильтра в 10 000?  
 
Кирилл, спасибо за грамотную консультацию, наверное вопрос надо задавать неподсредственно мелкомягким :-)  
 
ЗЫ Для меня тему можно считать закрытой
 
 
 
#14
26.02.2012 20:39:41
Сергей,  
В том, что касается технического объяснения, мои потуги следует считать бредом, а никак не грамотной консультацией :).  
Для меня тема открыта в смысле технического обоснования.  
 
А почему именно 1024, а не  
16 - макс. кол-во уровней отмены в xl2003    
256 - макс. кол-во символов в именованной формуле, в текстовом аргументе, макс. кол-во столбцов в xl97 и т.д.  
8.192 - макс. кол-во несмежных областей в union  
16.384 - макс. кол-во строк в xl97 и столбцов в xl2007-2010  
32.768 - макс. кол-во символов в ячейке xl2003-2010  
65.536 - макс. кол-во строк в xl2003    
1.048.576 - макс. кол-во строк в xl2007-2010  
и т.д.
KL
 
 
 
#15
26.02.2012 20:46:13
Все эти числа делятся на 8 без остатка.  
30 и 10 000 не делятся.
 
 
 
#16
26.02.2012 20:58:19
"Все эти числа делятся на 8 без остатка."  
Все эти числа являются степенью двойки  
16=2^4  
256=2^8  
8192=2^13  
16384=2^14  
32768=2^15  
65536=2^16  
1048576=2^20
 
 
 
#17
26.02.2012 21:11:20
{quote}{login=MCH}{date=26.02.2012 08:58}{thema=}{post}  
Все эти числа являются степенью двойки  
{/post}{/quote}Сути это не меняет. 30 и 10 000 в данный ряд не укладываются.
 
 
 
#18
26.02.2012 21:26:53
а может быть, просто разные программисты у мелкомягких отвечали за разные количественные ограничения?  
 
кому-то больше нравится десятичная система, кому-то - двоичная... :)  
древние шумеры, говорят, ничего, кроме шестидесятиричной системы, не знали - и ничего, жили ведь (пока не вымерли:)
фрилансер Excel, VBA - контакты в профиле
"Совершенствоваться не обязательно. Выживание — дело добровольное." Э.Деминг
 
 
 
#19
26.02.2012 21:48:27
Похоже на то :-)  
 
Хорошо пусть будут шумеры ;-)  
Почему 30, а не 20 или не 40?
 
 
 
#20
27.02.2012 02:00:34
Память, занимаемая функцией = 1 Long для ссылки на результат + 1 Long для адреса функции + 30 Longs для аргументов  = 32 Longs = 2^5 Longs.  
 
Для процедур (Sub) ссылка на результат зарезервирована, но не используется.  
Процедура, это та же функция, только типа void в терминах языка C.  
   
Для быстродействия все 32 long-а загоняются в стековую память, обращение  к которой намного быстрее, чем к относительно безразмерной динамической памяти,  время на очистку стековой памяти тратить вообще не требуется. Но объем стековой памяти не может быть большим в силу аппаратных ограничений. В результате выбран компромисс.    
 
Отображение 10000  элементов в фильтре – из соображений здравого смысла.  
Для кого "common sense is not common", т.е те, кто за пределами этого смысла, "пролетают" ;-)
 
 
 
#21
27.02.2012 02:07:37
Отлично! Лаконично и точно. Спасибо.  
 
Только почему Long? Почему не Singl или Doudle? Аргументы могут быть немаленькими.  
Тот же компромисс?
 
 
 
#22
27.02.2012 02:09:15
МСН хорошо подметил, насчет степени :)
Киса, я хочу Вас спросить, как художник — художника: Вы рисовать умеете?
 
 
 
#23
27.02.2012 03:22:53
{quote}{login=vikttur}{date=27.02.2012 02:07}{thema=}{post}Только почему Long? Почему не Singl или Doudle? Аргументы могут быть немаленькими.  
Тот же компромисс?{/post}{/quote}Тип Long используется для адресации в 32-битных приложениях. А по Long-адресу (аргумента) могут храниться данные любого типа, в том числе, пользовательского типа, а также тексты, массивы и прочие артефакты.  
 
Более подробно про Long-указатели, например. есть текстовая переменная Txt:  
Dim Txt As String  
Txt = "Hi!"  
 
Должна же переменная чем-то идентифицироваться, поэтому под эту переменную в памяти приложения отводится Long-адрес, который вычисляется с помощью VarPtr(Txt), а значение, лежащее по этому адресу StrPtr(Txt) является ссылкой на адрес в памяти собственно фрамента текста в Unicode.  
А в 4 байта (один Long) до этого фрагмента еще записывается и размер в байтах текстового фрагмента.  
Во всем этом есть смысл глубокий, описанный в мудрых книжках.  
И в сказаниях: "нелегко с Кощеем сладить: смерть его на конце иглы, та игла в яйце, то яйцо в утке, та утка в зайце, тот заяц в сундуке, а сундук стоит на высоком дубу, и то дерево Кощей как свой глаз бережёт" :-)
 
 
 
#24
27.02.2012 03:54:59
Владимир, я правильно понял?  
 
1.    
вопрос: "почему 30?"    
ответ: "...объем стековой памяти не может быть большим в силу аппаратных ограничений. В результате выбран компромисс."?    
 
2.    
вопрос: "как 30 связано с бинарными величинами?"    
ответ:"1 Long для ссылки на результат + 1 Long для адреса функции + 30 Longs для аргументов = 32 Longs = 2^5 Longs"?  
 
Спасибо :)
KL
 
 
 
#25
27.02.2012 04:26:36
Кирилл, по пунктам вопросов:  
 
1. Да.  
Компромисс в том, что стековая память процессора хоть и очень быстрая, но малая по объему памяти из-за ограничений физической реализации в виде последовательно соединенных D-триггеров.    
 
2. Да.  
Вместо:  1 Long для адреса функции  
более точно:  1 Long адрес возврата, т.е. адрес, куда функция или процедура должна вернуть управление после своего завершения
 
 
 
#26
27.02.2012 05:40:43
{quote}{login=vikttur}{date=27.02.2012 02:07}{thema=}{post}Только почему Long?{/post}{/quote}В общем случае, данные разных типов могут быть записаны и в разные регистры. Для 32-битных приложений Windows есть несколько соглашений об организации вызовов функций, а для 64-битной Windows было принято достаточно жесткое решение избавиься от "рухляди" и ограничиться лишь одной спецификацией. В Win64 указатели стали не 4, а 8-байтными, но стековой памяти обычно требуется не в 2, а в раза 3 больше, чем в 32-битной операционке. Хотя иногда в Win64 стековая память даже экономится, это зависит от кода.
 
 
 
#27
27.02.2012 08:37:39
Спасибо
 
 
 
#28
27.02.2012 11:19:57
И от меня спасибо :)
 
 
 
Страницы: 1
Наверх