Здравствуйте, samius, Вы писали:

S>Уверен что и не это (I>10?I)
А зря. Такая конструкция ложится на КУДУ идеально...

E>>Ну и что в этом интересного? Я так понял, что тебе трудно думать абстрактно о синтаксисе. Ну считай, что мы хотим разработать язык для компа будущего, у которого будет возможность выполнять миллиарды похожих вычислений параллельно...
S>Причем тут синтаксис (дубль 2)? Решения есть, думать о них не интересно. Если интересен сам синтаксис, то тут есть спецы по синтаксису.
Синтаксис тут не при чём. А ХОРОШИХ решений для "компьютеров будущего" пока что нет, как раз.
Дело в том, что уже придуманными решениями всегда можно воспользоваться. Только они не решения, к сожалению.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, samius, Вы писали:

S>>Уверен что и не это (I>10?I)
E>А зря. Такая конструкция ложится на КУДУ идеально...
И в чем заключается сложность с LC по сравнению с этой конструкцией?

E>>>Ну и что в этом интересного? Я так понял, что тебе трудно думать абстрактно о синтаксисе. Ну считай, что мы хотим разработать язык для компа будущего, у которого будет возможность выполнять миллиарды похожих вычислений параллельно...
S>>Причем тут синтаксис (дубль 2)? Решения есть, думать о них не интересно. Если интересен сам синтаксис, то тут есть спецы по синтаксису.
E>Синтаксис тут не при чём. А ХОРОШИХ решений для "компьютеров будущего" пока что нет, как раз.
E>Дело в том, что уже придуманными решениями всегда можно воспользоваться. Только они не решения, к сожалению.
Мне не кажется что тут случайно найдется решение для компьютеров будущего при единственной цели — ультракомпактности.

S>Мне не кажется что тут случайно найдется решение для компьютеров будущего при единственной цели — ультракомпактности.

В смысле, ты сомневаешся что языки будуйщего будут ультракомпактны ?

Тут уже говорили, что самый просто и ультракомпатный язык:

"Напиши мне шахматы"

16 байт. Все что менее понятно или длинее этого не от хорошей жизни

Вот РС какбы уже оторвался от того драйверного говнеца которое плотненько сидит на архитектуре корча ( вызовы функций, передача параметров, жесткие типы данных, адресная арифметика ) и идет по-тихоньку вот к тем 16 байтам.
Конечно он туда не дойдет, но пускай это будет эдакий идеал и путеводная, хоть и недостижимая звезда

Здравствуйте, ambel-vlad, Вы писали:

AV>Ээээээ, этот код несколько другой, нежели был ранее.
AV>Там было что-то типа
AV>!х=1..10
AV>x.I = 5

AV>Потому что
AV>х=1..10
AV>x.I = 5
AV>разворачивается в следующую последовательность
AV>1. Сначала создаем массив
AV>2. заполняем его значениями от 1 до 10
AV>3. Потом проходимся по массиву и каждому элементу присваиваем 5.
AV>Спрашивается, нафига козе баян. Тьфу, то есть на кой черт пункт 2?

Ну, не знаю, нафига. Так написали.
А зачем массив пятёрок вообще нужен?
Пример какой-то дурацкий.
Тем не менее, смотри:
E !Y = 1..10
Имеем переборщик от 1 до 10.
E !Z = (Y>0?5)
Имеем переборщик из 10 пятёрок
E X = Z
дампим переборщик в массив.
Кстати, это наводит нас на мысли, что Y>0 -- это тоже переборщик из 10 true
Так что можно вообще подумать на тему о том что ? имеет такие синтаксис и семантику:
<какой-то переборщик>?какое-то выражение, возможно зависящее от параметра переборщика слева
А всё вместе обозначает профильтрованный и отображённый переборщик.

Тогда для записи последовательности из 10-ти пятёрок можно было бы написать как-то так:
E X = 1..10?5

Кстати, наверное термин "последовательность" тоже хороший. Понятный.

Здравствуйте, Mamut, Вы писали:

Эх, не удержусь...
M>это не относится к синтаксису, а к архитектуре и дизайну языка
Ну называет он второе первым. Ну не пофигу ли тебе?

Здравствуйте, PC_2, Вы писали:

S>>Мне не кажется что тут случайно найдется решение для компьютеров будущего при единственной цели — ультракомпактности.

PC_>В смысле, ты сомневаешся что языки будуйщего будут ультракомпактны ?
Даже не сомневаюсь что они НЕ будут ультракомпактны. Открой пару библиотек и посмотри, сколько там функций для решенных задач. Этим функциям нужны внятные имена. В стремлении к ультракомпактности ты быстро выкушаешь все ASCII символы и возьмешься за иероглифы, отрезав путь к использованию твоего языка значительной части населения планеты.

PC_>Тут уже говорили, что самый просто и ультракомпатный язык:

PC_>"Напиши мне шахматы"

PC_>16 байт. Все что менее понятно или длинее этого не от хорошей жизни

PC_>Вот РС какбы уже оторвался от того драйверного говнеца которое плотненько сидит на архитектуре корча ( вызовы функций, передача параметров, жесткие типы данных, адресная арифметика ) и идет по-тихоньку вот к тем 16 байтам.
И что представляет из себя твой оператор ,= как не вызов встроенной функции с передачей аргументов?

PC_>Конечно он туда не дойдет, но пускай это будет эдакий идеал и путеводная, хоть и недостижимая звезда
Сомнительный идеал ты себе выбрал.

Здравствуйте, Erop, Вы писали:

E>Тем не менее, смотри:
E>E !Y = 1..10
E>Имеем переборщик от 1 до 10.
E>E !Z = (Y>0?5)
E>Имеем переборщик из 10 пятёрок
E>E X = Z
E>дампим переборщик в массив.
E>Кстати, это наводит нас на мысли, что Y>0 -- это тоже переборщик из 10 true
E>Так что можно вообще подумать на тему о том что ? имеет такие синтаксис и семантику:
E><какой-то переборщик>?какое-то выражение, возможно зависящее от параметра переборщика слева
E>А всё вместе обозначает профильтрованный и отображённый переборщик.
Тебе нравится заниматься велосипедированием list comprehension? Если да, то я отстану.

E>Кстати, наверное термин "последовательность" тоже хороший. Понятный.
как и list

Здравствуйте, Erop, Вы писали:

AV>>Ээээээ, этот код несколько другой, нежели был ранее.
AV>>Там было что-то типа
AV>>!х=1..10
AV>>x.I = 5

AV>>Потому что
AV>>х=1..10
AV>>x.I = 5
AV>>разворачивается в следующую последовательность
AV>>1. Сначала создаем массив
AV>>2. заполняем его значениями от 1 до 10
AV>>3. Потом проходимся по массиву и каждому элементу присваиваем 5.
AV>>Спрашивается, нафига козе баян. Тьфу, то есть на кой черт пункт 2?

E>Ну, не знаю, нафига. Так написали.



E>А зачем массив пятёрок вообще нужен?
E>Пример какой-то дурацкий.
E>Тем не менее, смотри:
E>E !Y = 1..10
E>Имеем переборщик от 1 до 10.
E>E !Z = (Y>0?5)
E>Имеем переборщик из 10 пятёрок
E>E X = Z
E>дампим переборщик в массив.

Вот только первоначально был несколько другой код, у которого очень интересно поведение. В двух соседних строках одна и та же переменная является разными сущностям. И ладно бы сначала была массивом, а потом на его базе (не)явно строилась последовательность. Но в примерах последовательность ни с того ни с сего превращается в массив.

E>Тогда для записи последовательности из 10-ти пятёрок можно было бы написать как-то так:
E>E X = 1..10?5

Нет, нельзя. Потому что 1..10 — это массив. И последовательностью это становится только когда присваивается мифическому !Х.

Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Здравствуйте, PC_2, Вы писали:
KV>>Ок, больше вопросов не имею.
PC_>>>Тоесть банально этот код не решает поставленную задачу. Точка.
KV>>Предлагаю со столь смелым заявлением отправляться сразу сюда: http://rsdn.ru/forum/decl/, а я пока за попкорном сбегаю. Троеточие...

LP>А парень-то прав. quicksort он

in-place

. В противном случае это и не quicksort вовсе. По крайней мере не в его традиционном понимании.

Although quicksort is usually not implemented as an in-place sort, it is possible to create such an implementation.

PC_>>В смысле, ты сомневаешся что языки будуйщего будут ультракомпактны ?
S>Даже не сомневаюсь что они НЕ будут ультракомпактны. Открой пару библиотек и посмотри, сколько там функций для решенных задач. Этим функциям нужны внятные имена.

Зачем им внятные имена.
Для тебя жизненно необходимо нагромождение быдло интерфейсов с мильярдом функций вроде GetPtrIntToStr в жаваподобном шпагетти ?

Существующее программирование скатилось в пропасть. Количество кода "интерфейсов", "обработки ошибок" и склейки зачастую приближается к количеству полезного кода. Который собственно что-то делает ...

То что в программирование это нормально, "подумай сколько тебе нужно времени и умножь это на три" это вообще нонсенс.
Не нормально и то что вычищение багов больше занимает чем сама разработка. Такого нет не в одной отрасли. Это кстате говорит о том что
инструменты не совершенны ...

PC_>>Тут уже говорили, что самый просто и ультракомпатный язык:
PC_>>"Напиши мне шахматы"
PC_>>16 байт. Все что менее понятно или длинее этого не от хорошей жизни
PC_>>Вот РС какбы уже оторвался от того драйверного говнеца которое плотненько сидит на архитектуре корча ( вызовы функций, передача параметров, жесткие типы данных, адресная арифметика ) и идет по-тихоньку вот к тем 16 байтам.

Не путай цель и средства. Цель всегда простая и формулируется просто заказчиком.
Только вот даже невинная переделка и спека в пару строк может вчистую разрушить структуру над которой гадало не одно поколение программистов.

PC_>>Конечно он туда не дойдет, но пускай это будет эдакий идеал и путеводная, хоть и недостижимая звезда

Зато кодить не много

AV>Вот только первоначально был несколько другой код, у которого очень интересно поведение. В двух соседних строках одна и та же переменная является разными сущностям. И ладно бы сначала была массивом, а потом на его базе (не)явно строилась последовательность. Но в примерах последовательность ни с того ни с сего превращается в массив.

о_О

KV>

KV>Although quicksort is usually not implemented as an in-place sort, it is possible to create such an implementation.

Это они про Немерле

S>Тебе нравится заниматься велосипедированием list comprehension? Если да, то я отстану.

Переборщики значит велосипед,
А list comprehension которым может похвастаться с десяток языков, значит не велосипед ?

Здравствуйте, PC_2, Вы писали:

S>>Тебе нравится заниматься велосипедированием list comprehension? Если да, то я отстану.

PC_>Переборщики значит велосипед,
PC_>А list comprehension которым может похвастаться с десяток языков, значит не велосипед ?

И вообще, практика критерий истины.
Есть задача (с генерацией того же пароля), вперед к реализации. Там и поглядим ху из ху

Здравствуйте, samius, Вы писали:

S>И в чем заключается сложность с LC по сравнению с этой конструкцией?
Возможно, я чего-тоне понимаю, то вроде бы в LC мы задаём какую-то последовательность, примерно как в цикле.
А в (?) мы задаём правила как заменить одну последовательность другой. Возможно профильтрованной. Этакое исчисление последовательностей получается.
Второе намного ближе к КУДЕ.
Но я предлагаю не фиксироваться на КУДЕ и вообще на практическом смысле. Практический смысл потом найдётся или нет. А пока интересно с таким представлением переборов побаловаться. Это де прикольно и относительно ново. Или кто-то может дать ссылочки на аналогичные статьи?

E>>Синтаксис тут не при чём. А ХОРОШИХ решений для "компьютеров будущего" пока что нет, как раз.
E>>Дело в том, что уже придуманными решениями всегда можно воспользоваться. Только они не решения, к сожалению.
S>Мне не кажется что тут случайно найдется решение для компьютеров будущего при единственной цели — ультракомпактности.
Ну так идея же не только в ультракомпактности. Есть ещё желание отдать транслятору особенности реализации перебора/цикла.
Вот в SQL есть планировщик запроса, а в RS может быть переборщик перебора, который разложит по головам кластера и испольнительным устройствам супервектора цикл оптимальным или субоптимальным способом...

Но это опять фиксация на профите, а пока и без профита интересно, на самом деле...

Здравствуйте, ambel-vlad, Вы писали:


AV>Нет, нельзя. Потому что 1..10 — это массив. И последовательностью это становится только когда присваивается мифическому !Х.

А зачем это массив, а не переборщик?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, samius, Вы писали:

S>>И в чем заключается сложность с LC по сравнению с этой конструкцией?
E>Возможно, я чего-тоне понимаю, то вроде бы в LC мы задаём какую-то последовательность, примерно как в цикле.
E>А в (?) мы задаём правила как заменить одну последовательность другой. Возможно профильтрованной. Этакое исчисление последовательностей получается.
E>Второе намного ближе к КУДЕ.
Чем оно ближе, если нужна та же инкрементация что бы размазать по железу?
E>Но я предлагаю не фиксироваться на КУДЕ и вообще на практическом смысле. Практический смысл потом найдётся или нет. А пока интересно с таким представлением переборов побаловаться. Это де прикольно и относительно ново. Или кто-то может дать ссылочки на аналогичные статьи?
Гугли по итераторам, лист компрехеншнам.
Я не знаю как объяснить что переборщик — это частный случай генератора.

E>Ну так идея же не только в ультракомпактности. Есть ещё желание отдать транслятору особенности реализации перебора/цикла.
E>Вот в SQL есть планировщик запроса, а в RS может быть переборщик перебора, который разложит по головам кластера и испольнительным устройствам супервектора цикл оптимальным или субоптимальным способом...
Оптимальным способом можно задать цикл явно. Это будет куда оптимальнее, чем подбирать генератор по виду условия, не говоря о том что эта задача вообще не решается в общем виде.

E>Но это опять фиксация на профите, а пока и без профита интересно, на самом деле...

Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, PC_2, Вы писали:

S>>>Тебе нравится заниматься велосипедированием list comprehension? Если да, то я отстану.

PC_>>Переборщики значит велосипед,
PC_>>А list comprehension которым может похвастаться с десяток языков, значит не велосипед ?
понимаешь, когда ты говоришь что у меня здесь используются генераторы — это не велосипед. Когда ты говоришь что изобрел переборщики — то это велосипед, причем без сидения.

PC_>И вообще, практика критерий истины.
PC_>Есть задача (с генерацией того же пароля), вперед к реализации. Там и поглядим ху из ху
не собираюсь с тобой мериться байтами. Мне это чести не добавит, а доказывать что-то тебе мне надоело.

Здравствуйте, samius, Вы писали:

S>Чем оно ближе, если нужна та же инкрементация что бы размазать по железу?
Инкрементация чего нужна? Ты КУДУ видел? Это я не в смысле наезда, а чтобы понять понимаем ли мы друг друга.
На всяк случай напомню, что в КУДЕ ты задаёшь код некой простой функции, которая одновременно исполняется на куче вычислителей. При этом изнутри этого кода доступен некий индекс вычислителя, но он очень сложный. И от конкретной платы зависит, кстати. А весь код исполняется на вычичлителях независимо.
При этом код на некоторых вычислителях можно остановить. Типа не считать какое-то время. Пропустить часть алгоритма.

По идее, это всё очень прямо на (?) ложится. А что у нас в LC выходит?

S>Гугли по итераторам, лист компрехеншнам.
S>Я не знаю как объяснить что переборщик — это частный случай генератора.
Да. Мало того, можно и наоборот на это взглянуть. И что? Какие есть формализмы для исчисления генераторов? Да ещё и читабельные при этом?

S>Оптимальным способом можно задать цикл явно. Это будет куда оптимальнее, чем подбирать генератор по виду условия, не говоря о том что эта задача вообще не решается в общем виде.
Нет, так как на разных прогонах программы оптимальный план может быть разным...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, samius, Вы писали:

S>>Чем оно ближе, если нужна та же инкрементация что бы размазать по железу?
E>Инкрементация чего нужна? Ты КУДУ видел? Это я не в смысле наезда, а чтобы понять понимаем ли мы друг друга.
КУДУ не видел, но с HLSL работал.
E>На всяк случай напомню, что в КУДЕ ты задаёшь код некой простой функции, которая одновременно исполняется на куче вычислителей. При этом изнутри этого кода доступен некий индекс вычислителя, но он очень сложный. И от конкретной платы зависит, кстати. А весь код исполняется на вычичлителях независимо.
E>При этом код на некоторых вычислителях можно остановить. Типа не считать какое-то время. Пропустить часть алгоритма.
Вот как ляжет (I>10?I)? Сам I придется получать из некого индекса вычислителя, так?
E>По идее, это всё очень прямо на (?) ложится. А что у нас в LC выходит?
Результат генератора так же можно получить из индекса вычислителя ничуть не хуже чем I, только число итераций будет известно заранее. Смотрим на Range генератора и знаем сколько раз надо зарядить вычислители.

S>>Гугли по итераторам, лист компрехеншнам.
S>>Я не знаю как объяснить что переборщик — это частный случай генератора.
E>Да. Мало того, можно и наоборот на это взглянуть. И что? Какие есть формализмы для исчисления генераторов? Да ещё и читабельные при этом?
В формализмах не силен

S>>Оптимальным способом можно задать цикл явно. Это будет куда оптимальнее, чем подбирать генератор по виду условия, не говоря о том что эта задача вообще не решается в общем виде.
E>Нет, так как на разных прогонах программы оптимальный план может быть разным...
Я так и не понял как ты собрался решать задачу эффективного перебора по I с условием.
(I%10000+42==0?)
Погонишь по всему диапазону?