плюс сейчас смотрю на то, что делает коллега (tts/stt обертка) - тоже на го можно было бы

hello world. кто делал выгрузку в excel. такой вопрос. можно ли оформить строки таким образом, чтобы они были раскрывающимися?

+ нажал - открылись и тд.

сам в экселе не разбираюсь, но задачу поставили. ищу данные, возможно ли это вообще

при клике ?

или это запроган сам в excel-е модуль, плагин и проч?

сам в экселе не разбираюсь, но задачу поставили. ищу данные, возможно ли это вообще

гугли

"excel collapse rows"

"excel collapse rows"

спасибо!

hello world. кто делал выгрузку в excel. такой вопрос. можно ли оформить строки таким образом, чтобы они были раскрывающимися?

$spreadsheet->getActiveSheet()->getRowDimension('5')->setCollapsed(true); $spreadsheet->getActiveSheet()->getRowDimension('5')->setVisible(false); https://phpspreadsheet.readthedocs.io/en/develop/topics/recipes/

да, благодарю. нашёл уже такое! надо попробовать

Недавно пришлось столкнуться вновь с PHPExcel, а эта зараза не выгружается композером, оказывается умер на гитхабе, пришлось наследником пользоваться

он вроде грузит но помечает что оно депрекейтед

PHPExcel last version, 1.8.1, was released in 2015. The project is no longer maintained and should not be used anymore. All users should migrate to its direct successor PhpSpreadsheet, or another alternative. In a few months, the GitHub project will be marked as archived, so everything will be read-only.

у меня уже не грузил) хотя мб композером нормально пользоваться не умею

какой есть наиэффективнейший способ сравнить 2 массива и убрать из первого те элементы, которые совпадают с элементами второго по двум свойствам

в пхп нет типа данных "элемент"

это объекты. в массиве. значит, элементы массива

никто кроме тебя об этом не знает array_filter

Могу ошибится, но зависит от кол-во элементов. Если их мало (100) то полным перебором норм (1000 операций не кросс для сабаки). Если дохера, то нужно построить временный индекс. Например, для каждого массива перестроить массивы так, чтобы индекс был вида $field_one.$field_two, а затем сравнить по этим ключам - будет многократно быстрее.

в каждом от 100 до 300 элементов

а индекс строить ты будешь не полным перебором? ;))

а индекс строить ты будешь не полным перебором? ;))

У тебя 2 массива N и M элементов. Построить индекс N+M операций (допустим конкатенация полей) конкатенации полей. Потом N*M операций обращения к array по ключу (что будет происходить через встроенный hashmap) Полный перебор: Тупо N*M операций сравнения вида $a->field_1 == $a->field_1 && $a->field2 == $b->field2

А если значения в полях не строки, а какие малые INT то можно вообще норм числовой индекс замутить.... ляпота получится

ну да, только зачем по второму то индекс... по первому индекс, по второму просто перебор с поиском по индексу

Кто-нибудь сталкивался с необходимостью сервера свои распологать на третьих серверах НЕ выдающих инфу властям РФ? нет, товарищ майор, мы не продаём оружие\наркоту\людей

которые можно будет оплачивать не отслеживаемым образом ? не знаю, битками мб)

Кто-нибудь сталкивался с необходимостью сервера свои распологать на третьих серверах НЕ выдающих инфу властям РФ? нет, товарищ майор, мы не продаём оружие\наркоту\людей

любая страна, кроме РФ, клала на властей РФ )

если уж очень нужно, любой абузоустойчивый

ну да, только зачем по второму то индекс... по первому индекс, по второму просто перебор с поиском по индексу

Смысл "самопальных" индексов в том, чтобы их сравнивать. значение в индексе - работает как хеш объекта для конкретной задачи - однозначно утверждающий, что объекты одинаковые, для одинаковых полей (в данном случае два поля). Поэтому нужны два индекса для двух массивов. array хранит значения в куче, а хешмапу в выделенном массиве, поэтому перебор ключей массива (и сравнение) должен быть многократно быстрее перебора объектов и выборки 2х полей (и сравнение).

с чего бы перебор хешей значительно быстрее перебора значений? ;)) а свойства - это тот же хешмап

тем более что у тебя нет "перебора хешей", у тебя есть только перебор значений вприори в языке... и все, что ты предлагаешь - заменить один цикл с выборкой двух ключей из хешмапа (получение двух ствойств из объекта) + поиск в индексе первого массива - на два цикла - первый с получением свойств (построение индекса) и второй - получение ключа массива для поиска в первом массиве

с чего бы перебор хешей значительно быстрее перебора значений? ;)) а свойства - это тот же хешмап

Например, потому что так устроен массив в php

с чего бы перебор хешей значительно быстрее перебора значений? ;)) а свойства - это тот же хешмап

а зачем хеши перебирать? ... isset($array1[$array2['val1'].$array2['val2']]); ...дальше уже пхп внутренними методами пусть перебирает

тем более что у тебя нет "перебора хешей", у тебя есть только перебор значений вприори в языке... и все, что ты предлагаешь - заменить один цикл с выборкой двух ключей из хешмапа (получение двух ствойств из объекта) + поиск в индексе первого массива - на два цикла - первый с получением свойств (построение индекса) и второй - получение ключа массива для поиска в первом массиве

Да все верно, выйгрышь будет за счет разницы во времени операций первого и второго варианта.

а зачем хеши перебирать? ... isset($array1[$array2['val1'].$array2['val2']]); ...дальше уже пхп внутренними методами пусть перебирает

Ну так я это и называю перебирать хеши. "перебирать хеши" и происходит внутренними методами :)

ну внутренними методами это должно происходить ощутимо быстрее

без построения индекса придется перебор на пхп писать, а это должно работать медленнее

плять, еще раз, для постоения индекса тебе нужно сделать перебор

если мне нужно по большому массиву поискать и память позволяет, я вообще стараюсь BST использовать

плять, еще раз, для постоения индекса тебе нужно сделать перебор

Не кипи, просто прочитай спокойно и внимательное, или уточни, с чем не согласен. Верно полный перебор, но переборы бывают разные, Мой вариант: N+M раз конкатенации плюс N*M быстрых операций сравнения. Вариант просто array_filter через $a->f1 === $b->f1 && $a->f2 == $b->f2 это N*M медленных операций. При значимом N и M первый вариант быстрее, при малом - второй

Не кипи, просто прочитай спокойно и внимательное, или уточни, с чем не согласен. Верно полный перебор, но переборы бывают разные, Мой вариант: N+M раз конкатенации плюс N*M быстрых операций сравнения. Вариант просто array_filter через $a->f1 === $b->f1 && $a->f2 == $b->f2 это N*M медленных операций. При значимом N и M первый вариант быстрее, при малом - второй

Проблем не будет с таким методом если значения в первом массиве не уникальны?

Проблем не будет с таким методом если значения в первом массиве не уникальны?

так они тогда и вовсе отсеятся

задача была убрать из первого массива все элементы, которые есть во втором

ну и соответственно, совпадения по двум полям проверять

Ну если построить индекс по второму массиву, а первый просто перебирать то проблем нет вроде бы

Короче это было просто FYI , пусть топикстартер решает надо ему или нет заморачиваться.

Не кипи, просто прочитай спокойно и внимательное, или уточни, с чем не согласен. Верно полный перебор, но переборы бывают разные, Мой вариант: N+M раз конкатенации плюс N*M быстрых операций сравнения. Вариант просто array_filter через $a->f1 === $b->f1 && $a->f2 == $b->f2 это N*M медленных операций. При значимом N и M первый вариант быстрее, при малом - второй

а мой вариант просто N+M без последующего N*M :)

а мой вариант просто N+M без последующего N*M :)

Честно говоря я не увидел от тебя "варианта". Перечитал еще раз, все-равно не увидел. Если распишешь вариант N + M будет действительно интересно

N - цикл для построения индекса первого массива, M - цикл по второму массиву со поиском по индексу первого... все... зачем индекс по второму массиву я не понимаю

N + M * N получается всё равно, ессли считать поиск перебором (хоть и внутренним). я так понимаю вот это M * N Сергей и подразумевал

ну а так да, второй индекс не нужен, я вовсе то сообщение упустил)

N - цикл для построения индекса первого массива, M - цикл по второму массиву со поиском по индексу первого... все... зачем индекс по второму массиву я не понимаю

признаю, для одного массива индекс можно не строить. Но @alexlcdee прав, у тебя все-равно получится M * N операций сравнений.

там не внутренний перебор, там хешмап + перебор по коллизиям

isset($index[$object->a . $object->b])

? черт, я почему-то был уверен, что топикстартеру нужно и для одного и для второго массива это сделать. Ок, я просто решал другую задачу

забавные заметки https://stackoverflow.com/questions/2473989/list-of-big-o-for-php-functions/2484455#2484455 Lookups: array_key_exists O(n) but really close to O(1) - this is because of linear polling in collisions, but because the chance of collisions is very small, the coefficient is also very small. I find you treat hash lookups as O(1) to give a more realistic big-O. For example the different between N=1000 and N=100000 is only about 50% slow down. isset( $array[$index] ) O(n) but really close to O(1) - it uses the same lookup as array_key_exists. Since it's language construct, will cache the lookup if the key is hardcoded, resulting in speed up in cases where the same key is used repeatedly. in_array O(n) - this is because it does a linear search though the array until it finds the value. array_search O(n) - it uses the same core function as in_array but returns value.

правда инфа уже старовата походу

да не, все так и остается, O(1) но худший случай O(n) - на это даже атаки есть, никак еще не пофиксенные в пхп

Привет, кто-то знает либу для поиска по массиву? К примеру - хочу одним "регекспом" вытянуть название региона https://pastebin.com/n6HCcb2U

Ну всмысле, надо потянуть шорт нейм, где в тайпсах administrative_area_level_1

что-то типо xpath только по массивам

json decode + foreach

Найс либка?

ну такое

уже проще енкодить в xml и юзать xpath

Енкодируй в хтмл

И парси домкравлером

Или нодой например

Тоже вариант

народ как в сниппет modx revo передать параметр ?

[[!course? &price=[[+price]]]] — уже не пашет такой вариант ?

[[!course? &price=[[+price]]]] — уже не пашет такой вариант ?

Это пхп ?

да, немного разобрался в проблеме

Это пхп ?

это синтаксис шаблонизатора у них такой

что то строка неправильная, вардамп выдал на цифры стринг и почему то длина 10

http://shot.hsdn.org/ncWdb8Ad

а мне надо флоат из этого получить чтобы округлять

это синтаксис шаблонизатора у них такой

Выглядит жутковато

Выглядит жутковато

очень удобно кстати делать сайты с такими плюшками

удобно это с twig

удобно это с twig

?

удобно это с twig

?

Здрям ребзи! Кто юзал google api и yandex api для построения дорожных маршрутов?

я Гугл юзал

Google maps api лучше

У Yandex более урезанное

ребята а в php ведь нет пропуска аргументов?

по типу того, как в go

хотели, но чёт не сраслось

печаль а то phpcs ругается на неиспользуемый первый аргумент в коллбеке для exists