PS Код отображается некорректно (по крайней мере у меня в браузере), обрезается по горизонтали. Нужно скопировать и вставить в блокнот или посмотреть код страницы.
Это тезис, который вы задачей хотели подтвердить. Неудачно, потому что надуманная претензия.
А что тут надуманного? Excel не может в управление содержимым, из этого следуют ограничения, из-за который в плане вычислений (возможностей решения определённых задач) Excel жёстко ограничен.
не требует авторастягивания формул
Она сама себя продублирует без скриптов и вмешательства пользователя?
вы тупо не можете взять и вбить в эксель его, дабы понять, м?
Зачем вбивать формулы, которые мало того что не рабочие, а вторых примитивны для понимания того, что в них нет ничего чтобы решить поставленную задачу, в которой, напоминаю, фигурирует тезис «неизвестным заранее объёмом данным».
как питон справится с задачей вывести в удобном интерфейсе несколько миллионов строк
Ну во-первых речь идёт не о интерфейсе, а о вычислениях и данных, а во-вторых — легко. Для этого уже существуют если ещё не сотни, но с десяток точно различных модулей. Конечному-же пользователю/компании нужна готовая компьютерная программа под его задачи, не связанная по рукам и ногам ограничениями электронных таблиц. И я молчу о интерфейсе, а касаюсь только самих вычислений.
куча новых инструментов на старом железе тоже нихрена работать быстро не будут. Вы тупо проекты в визуалстудио не скомпилируете, например, вместо нескольких минут расчетов — они будут идти часами. Но это же проблема экселя, угу
Одной программы, написанной под конкретные задачи с неизвестным заранее объёмом данных и скомпилированной всего один раз (релиз-версия), написанной под старое железо — будет более чем достаточно, она будет работать с данными намного быстрее как минимум благодаря строгой типизации и не нужно будет вмешиваться в исходных код дабы отодвинуть ограничитель в виде числа строк, как в экселе это делается раз за разом. Я имел дело с инженерными расчётами, и считать физику в экселе — это просто боль, боль постоянных правок не исходных данных (входных значений), как это должно быть, но и нескольких десятков формул по туче вкладок, т.к. их приходится постоянно растягивать, вчера у тебя максимальная высота столба 8 метров, среди всех столбов что ты до этого считал, сегодня 10 метров, а завтра 100, а послезавтра 500.
Причем учтите, если ваш пример на питоне не сможет в подобие интерфейса экселя, то вы именно тролль.
Если в питон засунуть интерфейс экселя — то он и станет экселем (+VBA по-дефолту), а зачем это? Это тонна лишних функций. А насчёт не сможет — гуглите: «PyQt table», или смотрите прямо на ютубе. И при этом не будет ограничений в числе строк.
миллионом строк в вашей задаче, которые должен каким-то образом человек просмотреть и из этих данных что-либо путное глазами получить
А кто говорил про смотреть? Я это где-то упоминал? Задача поставлена «вычислять». Вы сами добавляете условия и сами же к ним придираетесь, и всё больше и больше переходите на личности, что на данном ресурсе — недопустимо. Но даже так — то в конечном продукте/программе — предусмотрена система отчётов, благодаря которой не нужно обязательно просматривать миллионы строк данных. И если, к примеру, что-то где-то «проседает» — это сразу видно на графиках или ещё проще можно добавить индикатор, который бы один раз пробежался по этим данным (не исключено что прямо во время подсчёта) и проверил бы их по условию (например последующее значение должно быть больше предыдущего и так для каждой строки, иначе exception&break с выводом номера строки), всё время обновляя своё значение, для экселя бы в таком случае потребовалась бы очень длинная формула (которая может не влезть в ячейку), либо ещё лишний столбец или столбцы, и то не факт что при всех случаях это вообще возможно. А насчёт посмотреть — «PyQt table».
Как человек, занимавшийся автоматизацией производства и навозившийся с экселями
А вот это очень интересно, вы сможете обновлять таблицу поступающими данными с сохранением предыдущих без VBA и без лишних телодвижений? Т.е. грубо говоря вести статистику методом: «вбил число+дату и нажал на кнопку», дабы потом эти данные обрабатывались в куче формул и так-же сохраняли свои результаты для вынесения определённых решений/корректировок/итд… (про графики и отчёты с прочей GUI'шной составляющей я молчу) Вам просто придётся постоянно двигать и растягивать формулы, постоянно скроллить, и всё это будет тормозить. Доверить такое действие (вбил-нажал) человеку — не проблема, а вот доверить ему правку формул — уже другое, опять же нужен будет VBA. Если у вас всё хорошо — то вы просто не сталкивались с достаточно большим объёмом данных. Рано или поздно вы задумаетесь: «а может всё-таки проще написать скрипт!?»… но это уже за рамками концепции электронных таблиц как таковых. Если таки жизненно необходим эксель за счёт интерфейса — то его можно спаять с питоном, модули для этого уже есть.
Но вы можете посмотреть на работников наса, которые на луну посылали ракеты с помощью перфокарт и об экселе даже не мечтали.
И пользовались они не только перфокартами, многие действия/вычисления они производили вручную, перфокарты предыдущие записи со склада не достанут, и в случае отклонений данные не скорректируют (а это всё те же вычисления), в отличии от современного ПО, данный пример лишь демонстрирует ограниченность электронных таблиц, ибо они тоже на такое не способны без сторонней помощи. А вот современные контроллеры (имеется ввиду ещё прошивка, не только хард), несмотря на все свои ограничения как по аппаратной части (это к примеру про современные часы), так и по размеру используемой памяти (ОЗУ), на такое способны.
И может хватит переходить на личности!? На данном ресурсе это недопустимо.
вы пеняете на инструмент, который чего-то не умеет
Он не умеет автоматически контролировать содержимое своих же мест хранения данных (ячеек), для этого нет стандартных функций, для этого приходится задействовать языки программирования. И из этого вытекает просто «тонна» практических ограничений.
Если бы в Excel была стандартная функция "=если_то_изменить_ячейку" (не сторонние скрипты), например: =ЕСЛИ_ИЗМ(if;ячейка_которую_нужно_изменить;новое_содержимое)
… то я бы ни слова не сказал.
Например для конкретно поставленной задачи: A1=5,41 //новое значение
B1=2,31 //старое значение
C1='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)>ОКРУГЛВВЕРХ(B1;0);СМЕЩ(A2;0;0;ОКРУГЛВВЕРХ(A1;0));"новое_содержимое") //заполнение
D1='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)<ОКРУГЛВВЕРХ(B1;0);СМЕЩ(ОКРУГЛВВЕРХ(A1;0)+2;0;0;ОКРУГЛВВЕРХ(B1;0)-ОКРУГЛВВЕРХ(A1;0);"") //стирание
E2='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)<>ОКРУГЛВВЕРХ(B1;0);B1;A1) //копирует содержимое
А чтобы был определённый порядок выполнения замен — можно поместить условие в условие через «или». Триггеры срабатывания через те же условия, как например сравнение в E2.
… и всё, не нужно ничего растягивать. Миллионы ситуаций геморроя отпадают. Появится возможность реализовывать бесконечные циклы (с временем на сон между итерациями разумеется), и миллионы других конечных примеров, невозможные вычисления с бесконечным потоком данных станут возможными. А про текущие шаблоны — они станут более универсальными, конечному пользователю практически не придётся вмешиваться в формулы. А простота данной функции — это не геморрой со скриптами и строками лишнего кода в виде эндифов.
Возможно я отстал от жизни, и некое подобие данной функции уже есть и я тут зря распинаюсь, но меня заверили что нет.
в вашей исходной задаче нет ничего, чтоб требовало автоматического растягивания формул
Разве? А это тогда что?
как к примеру реализовать в Excel вычисления с неизвестным заранее объёмом данным? Как реализовывать списки (List) с переменным количеством значений/элементов?
далее мы видим, что интерпретируемын языки не нужны, ибо на калькуляторах тормозят, а под встраиваемые системы так вообще писать невозможно
А питончик с такой задачей и такими рамками справится, как и куча других интерпретируемых языков.
плюс прочие аргументы с двиганьем ворот
Я всё это изначально говорил. Просто вы не понимаете изначального условия, а я вам досконально расписываю.
слив аргумента
Я не пытаюсь холиварить, а говорю по делу про ограничения.
про инт путем привязке к строкам… банальном суммировании двух больших чисел, главный бич кодеров
Я про структуры, это совершенно разные вещи. А с добавлением измерений в итоге не будет никаких проблем в адресации. На содержимом ячеек это никак не скажется, она и в данный момент избыточна.
любой инструмент имеет ограничения, мозги же вам даны их обходить
Молоток не стеклорез. Excel очень сильно ограничен в вопросе вычислений.
но по вашим сообщениям понятно, что человечество не могло полететь в космос, высадиться на луну, вообще достичь прогресса, ибо у всех инструментов есть ограничения и пользоваться ими, следовательно, нельзя
Для этого нужны разные инструменты, для решения разных задач, и да, с одним только Excel'ем на Луну не улетишь. И я бы посмотрел на работника NASA, который просчитывает всю физику в электронной таблице.
если же вам докажут, что можно — превратим задачу в фарс путем ее раздувания до бессмысленных масштабов
Дело не в масштабах, а в неизвестных заранее объёмах данных. Пример с большим объёмом данных был для того, чтобы вам стало понятно, что невозможно предугадать сколько всего потребуется, а если делать по-максимуму (пределу Excel) — то никаких аппаратных ресурсов не хватит. Но вам, я как я вижу, этого просто не понять.
Вопрос, куда еще растягивать формулу, если на листе всего 1048576 строк?
Дело не в бесконечном растягивании, а в автоматическом, без вмешательства пользователя.
Дано: программист/бухгалтер/инженер/итд… (опытный эксельщик который пишет шаблон) и бухгалтер/обычный пользователь (который в экселе не понимает вообще ничего больше вбивания обычных цифр в определённые ячейки).
Задача первого — написать универсальный шаблон, которым будет пользоваться второй, а второй даже о Ctrl+V не знает. Плюс ещё у второго калькулятор уровня целерон-2000 с потолком ОЗУ 512Мб (которые до сих пор встречаются).
О каком миллионе строк (на все случаи жизни) может идти речь?
Насколько мне известно изменять содержимое ячеек (не отображаемое, а саму формулу) невозможно без скриптов, что накладывает жёсткие ограничения на возможности Excel.
Претензия уровня возможного переполнение Int при складывании двух больших чисел. Выкидываем все языки программирования, ибо думать надо?
А если рассмотреть другую возможность, то даже имея мощный компьютер, но при наличии более масштабной задачи, то лимита в миллион строк — очень мало. Что касается ограничения Int, то Int64 (или даже Int32) — не миллион строк, даже близко, плюс в многих языках есть структуры, благодаря которым мы можем добавлять измерения, буквально до бесконечности и никаких ограничений, а с правильным алгоритмом ввода-вывода на хард проблем с лимитом ОЗУ не возникнет, даже на старом калькуляторе запашет. А что Excel!? Ну продублировали мы эту бесконечную таблицу из 2х колонок с ~миллионом строк на всю остальную часть листа, сколько там будет, ~миллион на ~16тыс? ~16777216? Больше, но не на много. И как в таком случае ограничивать? По всем столбцам прыгать и Ctrl+V делать? А если этого будет мало? Создавать клоны-листы? А что с ОЗУ случится? Допустим каждый символ закодирован в UTF-16*2^15(символов в ячейке)*16777216=1 терабайт ОЗУ на лист, и это только чисто содержимое ячеек, без учёта остальных данных (разграничение, связи, итд...), и вряд-ли Excel предусматривает частичный ввод-вывод.
И это даже игнорируя то, что при количестве используемых ячеек, число которых на несколько порядков меньше, Excel умудряется махать ручкой уже на практике, ну да ладно, не будем рассматривать баги самой программы…
Есть конечно чудесные аналоги, авторы которых с улыбкой смотрят на строковые ограничения софтины от мелкомягких, но возвращаясь к изначальной проблеме управления ячейками — даже там нету управления содержимым (по крайней мере я не видел), ибо в этом сама суть электронных таблиц.
Практически и теоретически, электронные таблицы не подходят для всех вычислений, далеко не для всех.
Так я и говорил о кастрированности. Проблема как раз в том, что посреди вычислений требуется вмешательство человека, например растянуть если число строк оказалось недостаточным.
Я просто конкретизирую вопрос используя пример: допустим у нас есть столб неопределённой высоты (высота — вводимое значение), столб делится на сектора длиной 1м и массой 1кг, нужно подсчитывать число секторов (это элементарно) и нагрузку сверху на каждый сектор. Т.е. создать таблицу, в которой будет номер сектора и нагрузка на него сверху, сделать это используя практически любой язык программирования — элементарно, самый обычный список. А теперь вопрос: как реализовать это в Excel, при условии что мы не можем до бесконечности заполнять строки формулами под всевозможные габариты столба!? Если бы в Excel была возможность по условию редактировать из одной ячейки содержимое другой ячейки — без использования скриптов и макросов — тогда бы эта задача была реализуема, но насколько мне известно — такой функции нет.
Это конечно с виду необыкновенно круто, и демонстрирует отличную изобретательность, но, с реальными задачами фраза: «любые вычисления можно выполнить в любом языке программирования, даже через формулы электронной таблицы» не особо вяжется с реальной практикой. Хотя не отрицаю, что где-то 99,9% вычислений более-менее реализуемы.
Когда у нас есть ограниченные ресурсы, ограниченный (и тем более заранее известный) объём данных — это хорошая демонстрация, но как к примеру реализовать в Excel вычисления с неизвестным заранее объёмом данным? Как реализовывать списки (List) с переменным количеством значений/элементов?
Вот и получается, что Флэш может замедлять время, но только в отношении собственной системы отсчета по отношению к земной.
Выходит, что способности Барри Аллена, он же Флэш, не противоречат законам физики, а значит могут быть вполне реальны.
Тогда Флеш скорее себя замедлит, и всё вокруг для него будет быстрее чем он сам. Это уже будет АнтиФлеш. Сам он будет двигаться быстро, но для него всё будет ещё быстрее, и ему не хватит скорости реакции чтобы увидеть ближайший столб.
На самом деле хорошо, что занимаются этим вопросом. То Плутон у них планета, то нет, то снова планета.
То определение, что было принято в 2005, с условием диаметра больше 2000км — кажется очень грубым и ошибочным, не должно быть цифр для условий классификации, ведь вселенная огромна и теоретически можно встретить как очень большие исключения из правил (гелиевые планеты), так и очень маленькие (карлики, вращающиеся вокруг коричневого карлика).
Нужно разработать универсальное определение, использующее существующие в природе физические константы, как например условие принятое в 2003, и ограничивающее максимальную массу планеты, согласно которому объект является планетой, когда его масса менее граничной массы, необходимой для синтеза дейтерия. Да, условие не идеальное, и от него уже отказались, но сама концепция использования природных физических констант, явно лучше чем та, согласной которой Плутон не до конца выкидывают из списка планет, но и астероидом назвать не могут и вводят никому не нужный термин карликовых планет.
С дефолтными пресетами в программах-затычках — конечно. Но открою вам кое-что интересное: настройки можно крутить сторонним ПО. И в итоге получить достойное качество с большей скоростью.
Стримерам нужен аппаратный кодировщик, как например NVENC или Quick Sync, а там уже плевать будет на остальные характеристики.
В идеале им нужна плата видео захвата.
Характеристики процессора, памяти ОЗУ и постоянной, интерфейсы ввода-вывода обычного ПК, но без всяких GPIO и подобных интерфесов (ну большинству для домашнего сервера и подобного это не нужно).
Вот просто покажите эту кучу китайцев, я бы себе прикупил, а то мой Cubieboard (аналог землянички) мягко говоря бесполезен во многих задачах из-за ARM процессора, а там где работает — без тормозов не обойтись, годен только для примитивного WEB-сервера.
Отличная железка, жаль дорогая.
Для чего нужна?
1) Для приложений-серверов, которых нет под ARM.
2) Для относительно быстрой работы Java-серверов, которые есть под ARM, но там они очень дико тупят в плане скорости.
3) Можно сделать свой портативный неттоп, с блэкджеком и…
4) Можно превратить в некое подобие роутера, с PHP/SQL/DATA/итд… сервером на борту.
5) Использовать как основу для мощного умного дома.
Много чего можно с микрокомпьютерами можно сделать, а на x86 так вообще разгуляться можно.
Раз вы CPU от APU не отличаете, и не можете в достоверные источники банально заглянуть (в которых и указана модульность на схеме в отношении 2 ALU к одному FPU) — ваша проблема.
>>как 4/8 на 3,7 ГГц сравнимы с 4/4 на 4,7 ГГц — этого вы явно стараетесь не замечать.
Извините что вы фигню брякнули, а я её проигнорировал.
Ну чтож отвечу.
Первый случай: приложение не отличает реальные ядра от виртуальных потоков и пытается использовать всё, в результате конвейер часто сбрасывается. Производительность с HT идёт в минус.
Второй случай: приложение различает ядра и потоки, но не обладает алгоритмами, которые получают выигрыш от HT, в таком случае что 4/4, что 4/8 разницы вообще никакой.
Третий случай: приложение отличает ядра от потоков и обладает алгоритмами, совместимыми с HT. Однако и тут есть варианты.
Может быть ~5% прироста — чаще всего, оптимизации под HT нет, но алгоритмы совместимы, процессор с загоном справился сам.
~15% прироста — при хорошей оптимизации, чаще всего увидишь именно такой прирост в оптимизированных под HT приложениях.
~30% прироста — это идеальная оптимизация, встречается в играх крайне редко (первый эталон Crysis 3), в основном в конвертерах и компиляторах.
~49,999%… сугубо в синтетическом тесте для тестирования работы HT, больше нигде.
Ядра не панацея, их тупое наращивание ни к чему хорошему не приведут. Как и потоки не дадут геймеру заветные 30% прироста. Проц с HT геймеру не так нужен, как проц с более высокой тактовой частотой, ибо тактовая частота это гарантия, а HT — лотерея, часто для игр — неудачная.
Цитируя Datasheet: в процессоре Jaguar 4 ядра, в каждом находится 1 FPU и 2 ALU.
А теперь касательно ваших бредней с подачи маркетологов на 8 ядерную консоль или точно цитируя вас 8 ядерный Jaguar. В PS4 используется APU Jaguar (это не CPU), в APU Jaguar составляющей частью CPU являются только 4 ядра в сумме с 8 блоками ALU и 4 FPU, другой модуль Jaguar не является основным центральным процессором, а является мостом между основным CPU с памятью и подсистемой графики и обслуживает 18 ядер GPU, т.к. в отличии от видеокарты сами по себе ядра GPU в APU Jaguar не умеют работать с общей памятью, которая в консоли монолитна. Для компьютерной игры консоль (APU Jaguar) именно 4х ядерная, остальные 4 ядра второго CPU предназначены для выполнения других задач, а именно быть виртуальным мостом, отделяя графическую память от оперативной в монолитном пуле памяти. В персональном компьютере с полноценным GPU такого не требуется из-за наличия видеопамяти на борту видеокарты, поэтому CPU занят чисто своей задачей.
Смотрите патент APU Jaguar, там и про модули внутри процессора, и в общем с чем каждый CPU работает в системе: https://www.google.com/patents/US20120162234
Итог:
CPU Jaguar — 4 ядра, 4 FPU, 8 ALU.
APU Jaguar — CPU = 4 ядра ЦП, GPU = 4 ядра управления подсистемой GPU и 18 самих ядер GPU.
То, что модульность реализована на другом уровне — не исключается факта половинчатого обрубка, что на уровне APU, что и на уровне рассматриваемом внутри ядра из-за неуравновешенности ALU и FPU, да и вообще фанатиков наращивания ядер.
Она сама себя продублирует без скриптов и вмешательства пользователя?
Зачем вбивать формулы, которые мало того что не рабочие, а вторых примитивны для понимания того, что в них нет ничего чтобы решить поставленную задачу, в которой, напоминаю, фигурирует тезис «неизвестным заранее объёмом данным».
Ну во-первых речь идёт не о интерфейсе, а о вычислениях и данных, а во-вторых — легко. Для этого уже существуют если ещё не сотни, но с десяток точно различных модулей. Конечному-же пользователю/компании нужна готовая компьютерная программа под его задачи, не связанная по рукам и ногам ограничениями электронных таблиц. И я молчу о интерфейсе, а касаюсь только самих вычислений.
Одной программы, написанной под конкретные задачи с неизвестным заранее объёмом данных и скомпилированной всего один раз (релиз-версия), написанной под старое железо — будет более чем достаточно, она будет работать с данными намного быстрее как минимум благодаря строгой типизации и не нужно будет вмешиваться в исходных код дабы отодвинуть ограничитель в виде числа строк, как в экселе это делается раз за разом. Я имел дело с инженерными расчётами, и считать физику в экселе — это просто боль, боль постоянных правок не исходных данных (входных значений), как это должно быть, но и нескольких десятков формул по туче вкладок, т.к. их приходится постоянно растягивать, вчера у тебя максимальная высота столба 8 метров, среди всех столбов что ты до этого считал, сегодня 10 метров, а завтра 100, а послезавтра 500.
Если в питон засунуть интерфейс экселя — то он и станет экселем (+VBA по-дефолту), а зачем это? Это тонна лишних функций. А насчёт не сможет — гуглите: «PyQt table», или смотрите прямо на ютубе. И при этом не будет ограничений в числе строк.
А кто говорил про смотреть? Я это где-то упоминал? Задача поставлена «вычислять». Вы сами добавляете условия и сами же к ним придираетесь, и всё больше и больше переходите на личности, что на данном ресурсе — недопустимо. Но даже так — то в конечном продукте/программе — предусмотрена система отчётов, благодаря которой не нужно обязательно просматривать миллионы строк данных. И если, к примеру, что-то где-то «проседает» — это сразу видно на графиках или ещё проще можно добавить индикатор, который бы один раз пробежался по этим данным (не исключено что прямо во время подсчёта) и проверил бы их по условию (например последующее значение должно быть больше предыдущего и так для каждой строки, иначе exception&break с выводом номера строки), всё время обновляя своё значение, для экселя бы в таком случае потребовалась бы очень длинная формула (которая может не влезть в ячейку), либо ещё лишний столбец или столбцы, и то не факт что при всех случаях это вообще возможно. А насчёт посмотреть — «PyQt table».
А вот это очень интересно, вы сможете обновлять таблицу поступающими данными с сохранением предыдущих без VBA и без лишних телодвижений? Т.е. грубо говоря вести статистику методом: «вбил число+дату и нажал на кнопку», дабы потом эти данные обрабатывались в куче формул и так-же сохраняли свои результаты для вынесения определённых решений/корректировок/итд… (про графики и отчёты с прочей GUI'шной составляющей я молчу) Вам просто придётся постоянно двигать и растягивать формулы, постоянно скроллить, и всё это будет тормозить. Доверить такое действие (вбил-нажал) человеку — не проблема, а вот доверить ему правку формул — уже другое, опять же нужен будет VBA. Если у вас всё хорошо — то вы просто не сталкивались с достаточно большим объёмом данных. Рано или поздно вы задумаетесь: «а может всё-таки проще написать скрипт!?»… но это уже за рамками концепции электронных таблиц как таковых. Если таки жизненно необходим эксель за счёт интерфейса — то его можно спаять с питоном, модули для этого уже есть.
И пользовались они не только перфокартами, многие действия/вычисления они производили вручную, перфокарты предыдущие записи со склада не достанут, и в случае отклонений данные не скорректируют (а это всё те же вычисления), в отличии от современного ПО, данный пример лишь демонстрирует ограниченность электронных таблиц, ибо они тоже на такое не способны без сторонней помощи. А вот современные контроллеры (имеется ввиду ещё прошивка, не только хард), несмотря на все свои ограничения как по аппаратной части (это к примеру про современные часы), так и по размеру используемой памяти (ОЗУ), на такое способны.
И может хватит переходить на личности!? На данном ресурсе это недопустимо.
Он не умеет автоматически контролировать содержимое своих же мест хранения данных (ячеек), для этого нет стандартных функций, для этого приходится задействовать языки программирования. И из этого вытекает просто «тонна» практических ограничений.
Если бы в Excel была стандартная функция "=если_то_изменить_ячейку" (не сторонние скрипты), например:
=ЕСЛИ_ИЗМ(if;ячейка_которую_нужно_изменить;новое_содержимое)… то я бы ни слова не сказал.
Например для конкретно поставленной задачи:
A1=5,41 //новое значение
B1=2,31 //старое значение
C1='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)>ОКРУГЛВВЕРХ(B1;0);СМЕЩ(A2;0;0;ОКРУГЛВВЕРХ(A1;0));"новое_содержимое") //заполнение
D1='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)<ОКРУГЛВВЕРХ(B1;0);СМЕЩ(ОКРУГЛВВЕРХ(A1;0)+2;0;0;ОКРУГЛВВЕРХ(B1;0)-ОКРУГЛВВЕРХ(A1;0);"") //стирание
E2='=ЕСЛИ_ИЗМ(ОКРУГЛВВЕРХ(A1;0)<>ОКРУГЛВВЕРХ(B1;0);B1;A1) //копирует содержимое
А чтобы был определённый порядок выполнения замен — можно поместить условие в условие через «или». Триггеры срабатывания через те же условия, как например сравнение в E2.
… и всё, не нужно ничего растягивать. Миллионы ситуаций геморроя отпадают. Появится возможность реализовывать бесконечные циклы (с временем на сон между итерациями разумеется), и миллионы других конечных примеров, невозможные вычисления с бесконечным потоком данных станут возможными. А про текущие шаблоны — они станут более универсальными, конечному пользователю практически не придётся вмешиваться в формулы. А простота данной функции — это не геморрой со скриптами и строками лишнего кода в виде эндифов.
Возможно я отстал от жизни, и некое подобие данной функции уже есть и я тут зря распинаюсь, но меня заверили что нет.
Больше чем Excel, но меньше чем Access?
Ну так описанная мной выше функция присутствует?
Я всё это изначально говорил. Просто вы не понимаете изначального условия, а я вам досконально расписываю.
Я не пытаюсь холиварить, а говорю по делу про ограничения.Я про структуры, это совершенно разные вещи. А с добавлением измерений в итоге не будет никаких проблем в адресации. На содержимом ячеек это никак не скажется, она и в данный момент избыточна.
Молоток не стеклорез. Excel очень сильно ограничен в вопросе вычислений.
Для этого нужны разные инструменты, для решения разных задач, и да, с одним только Excel'ем на Луну не улетишь. И я бы посмотрел на работника NASA, который просчитывает всю физику в электронной таблице.
Дело не в масштабах, а в неизвестных заранее объёмах данных. Пример с большим объёмом данных был для того, чтобы вам стало понятно, что невозможно предугадать сколько всего потребуется, а если делать по-максимуму (пределу Excel) — то никаких аппаратных ресурсов не хватит. Но вам, я как я вижу, этого просто не понять.
Дано: программист/бухгалтер/инженер/итд… (опытный эксельщик который пишет шаблон) и бухгалтер/обычный пользователь (который в экселе не понимает вообще ничего больше вбивания обычных цифр в определённые ячейки).
Задача первого — написать универсальный шаблон, которым будет пользоваться второй, а второй даже о Ctrl+V не знает. Плюс ещё у второго калькулятор уровня целерон-2000 с потолком ОЗУ 512Мб (которые до сих пор встречаются).
О каком миллионе строк (на все случаи жизни) может идти речь?
Насколько мне известно изменять содержимое ячеек (не отображаемое, а саму формулу) невозможно без скриптов, что накладывает жёсткие ограничения на возможности Excel.
А если рассмотреть другую возможность, то даже имея мощный компьютер, но при наличии более масштабной задачи, то лимита в миллион строк — очень мало. Что касается ограничения Int, то Int64 (или даже Int32) — не миллион строк, даже близко, плюс в многих языках есть структуры, благодаря которым мы можем добавлять измерения, буквально до бесконечности и никаких ограничений, а с правильным алгоритмом ввода-вывода на хард проблем с лимитом ОЗУ не возникнет, даже на старом калькуляторе запашет. А что Excel!? Ну продублировали мы эту бесконечную таблицу из 2х колонок с ~миллионом строк на всю остальную часть листа, сколько там будет, ~миллион на ~16тыс? ~16777216? Больше, но не на много. И как в таком случае ограничивать? По всем столбцам прыгать и Ctrl+V делать? А если этого будет мало? Создавать клоны-листы? А что с ОЗУ случится? Допустим каждый символ закодирован в UTF-16*2^15(символов в ячейке)*16777216=1 терабайт ОЗУ на лист, и это только чисто содержимое ячеек, без учёта остальных данных (разграничение, связи, итд...), и вряд-ли Excel предусматривает частичный ввод-вывод.
И это даже игнорируя то, что при количестве используемых ячеек, число которых на несколько порядков меньше, Excel умудряется махать ручкой уже на практике, ну да ладно, не будем рассматривать баги самой программы…
Есть конечно чудесные аналоги, авторы которых с улыбкой смотрят на строковые ограничения софтины от мелкомягких, но возвращаясь к изначальной проблеме управления ячейками — даже там нету управления содержимым (по крайней мере я не видел), ибо в этом сама суть электронных таблиц.
Практически и теоретически, электронные таблицы не подходят для всех вычислений, далеко не для всех.
Когда у нас есть ограниченные ресурсы, ограниченный (и тем более заранее известный) объём данных — это хорошая демонстрация, но как к примеру реализовать в Excel вычисления с неизвестным заранее объёмом данным? Как реализовывать списки (List) с переменным количеством значений/элементов?
Тогда Флеш скорее себя замедлит, и всё вокруг для него будет быстрее чем он сам. Это уже будет АнтиФлеш. Сам он будет двигаться быстро, но для него всё будет ещё быстрее, и ему не хватит скорости реакции чтобы увидеть ближайший столб.
То определение, что было принято в 2005, с условием диаметра больше 2000км — кажется очень грубым и ошибочным, не должно быть цифр для условий классификации, ведь вселенная огромна и теоретически можно встретить как очень большие исключения из правил (гелиевые планеты), так и очень маленькие (карлики, вращающиеся вокруг коричневого карлика).
Нужно разработать универсальное определение, использующее существующие в природе физические константы, как например условие принятое в 2003, и ограничивающее максимальную массу планеты, согласно которому объект является планетой, когда его масса менее граничной массы, необходимой для синтеза дейтерия. Да, условие не идеальное, и от него уже отказались, но сама концепция использования природных физических констант, явно лучше чем та, согласной которой Плутон не до конца выкидывают из списка планет, но и астероидом назвать не могут и вводят никому не нужный термин карликовых планет.
В идеале им нужна плата видео захвата.
Вот просто покажите эту кучу китайцев, я бы себе прикупил, а то мой Cubieboard (аналог землянички) мягко говоря бесполезен во многих задачах из-за ARM процессора, а там где работает — без тормозов не обойтись, годен только для примитивного WEB-сервера.
Для чего нужна?
1) Для приложений-серверов, которых нет под ARM.
2) Для относительно быстрой работы Java-серверов, которые есть под ARM, но там они очень дико тупят в плане скорости.
3) Можно сделать свой портативный неттоп, с блэкджеком и…
4) Можно превратить в некое подобие роутера, с PHP/SQL/DATA/итд… сервером на борту.
5) Использовать как основу для мощного умного дома.
Много чего можно с микрокомпьютерами можно сделать, а на x86 так вообще разгуляться можно.
>>как 4/8 на 3,7 ГГц сравнимы с 4/4 на 4,7 ГГц — этого вы явно стараетесь не замечать.
Извините что вы фигню брякнули, а я её проигнорировал.
Ну чтож отвечу.
Первый случай: приложение не отличает реальные ядра от виртуальных потоков и пытается использовать всё, в результате конвейер часто сбрасывается. Производительность с HT идёт в минус.
Второй случай: приложение различает ядра и потоки, но не обладает алгоритмами, которые получают выигрыш от HT, в таком случае что 4/4, что 4/8 разницы вообще никакой.
Третий случай: приложение отличает ядра от потоков и обладает алгоритмами, совместимыми с HT. Однако и тут есть варианты.
Может быть ~5% прироста — чаще всего, оптимизации под HT нет, но алгоритмы совместимы, процессор с загоном справился сам.
~15% прироста — при хорошей оптимизации, чаще всего увидишь именно такой прирост в оптимизированных под HT приложениях.
~30% прироста — это идеальная оптимизация, встречается в играх крайне редко (первый эталон Crysis 3), в основном в конвертерах и компиляторах.
~49,999%… сугубо в синтетическом тесте для тестирования работы HT, больше нигде.
Ядра не панацея, их тупое наращивание ни к чему хорошему не приведут. Как и потоки не дадут геймеру заветные 30% прироста. Проц с HT геймеру не так нужен, как проц с более высокой тактовой частотой, ибо тактовая частота это гарантия, а HT — лотерея, часто для игр — неудачная.
А теперь касательно ваших бредней с подачи маркетологов на 8 ядерную консоль или точно цитируя вас 8 ядерный Jaguar. В PS4 используется APU Jaguar (это не CPU), в APU Jaguar составляющей частью CPU являются только 4 ядра в сумме с 8 блоками ALU и 4 FPU, другой модуль Jaguar не является основным центральным процессором, а является мостом между основным CPU с памятью и подсистемой графики и обслуживает 18 ядер GPU, т.к. в отличии от видеокарты сами по себе ядра GPU в APU Jaguar не умеют работать с общей памятью, которая в консоли монолитна. Для компьютерной игры консоль (APU Jaguar) именно 4х ядерная, остальные 4 ядра второго CPU предназначены для выполнения других задач, а именно быть виртуальным мостом, отделяя графическую память от оперативной в монолитном пуле памяти. В персональном компьютере с полноценным GPU такого не требуется из-за наличия видеопамяти на борту видеокарты, поэтому CPU занят чисто своей задачей.
Смотрите патент APU Jaguar, там и про модули внутри процессора, и в общем с чем каждый CPU работает в системе: https://www.google.com/patents/US20120162234
Итог:
CPU Jaguar — 4 ядра, 4 FPU, 8 ALU.
APU Jaguar — CPU = 4 ядра ЦП, GPU = 4 ядра управления подсистемой GPU и 18 самих ядер GPU.
То, что модульность реализована на другом уровне — не исключается факта половинчатого обрубка, что на уровне APU, что и на уровне рассматриваемом внутри ядра из-за неуравновешенности ALU и FPU, да и вообще фанатиков наращивания ядер.