- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
var fn={
'+':{priority:0,exec:function(a,b){return a+b}}
,'-':{priority:0,exec:function(a,b){return a-b}}
,'*':{priority:1,exec:function(a,b){return a*b}}
,'/':{priority:1,exec:function(a,b){return a/b}}
,'&':{priority:1,exec:function(a,b){return a&b}}
,'|':{priority:1,exec:function(a,b){return a|b}}
,'»':{priority:2,exec:function(a,b){return a>>b}}
,'«':{priority:2,exec:function(a,b){return a<<b}}
}
function exec(str){
var machine=putin();
var out=[];
console.log("Executing: "+str);
(str.trim()+" END").split(/\s+/).forEach(parser(function (e){
if (!e) throw "empty:"+e;
out.push(e);
machine.send(e);
}));
console.log(out.slice())
return machine.top();
}
function putin(){
// раз "единственно полезная структура данных"
var stack = [];
return {
send:function(e){
if (fn[e]){
b = stack.pop();
a = stack.pop();
r=fn[e].exec(a, b);
}else{
r=+e;
}
console.log(e,r);
stack.push(r);
},top:function(){return stack[0];}
}
}
function parser(output){
// джва "единственно полезная структура данных"
var ops=[];
var op2;
return function(e){
if (/[0-9]+/.test(e)) {
output(e);
}else if (null!=fn[e]){
op2=ops.slice(-1)[0];
while (fn[op2] && (fn[e].priority <= fn[op2].priority) ){
output(op2);
ops.pop();
op2 = ops.slice(-1)[0];
}
ops.push(e);
}else if (e == "(") {
ops.push(e);
}else if (e == ")") {
while (ops.slice(-1)[0] != "("){
output(ops.pop())
}
ops.pop();
}else if ("END" == e){
var x;
while (x=ops.pop(),x) {
output(x);
}
}else{
throw 'invalid pituh:'+e;
}
}
}
[
[-1187,"1 + 22 - 13 * ( 44 + 51 ) + 150 / 3 « 1"]
,[13,"1 + 3 * 4"]
,[16,"( 1 + 3 ) * 4"]
,[17," 1 + 2 * 3 - 4 * 5 + 10 * ( 12 - 9 )"]
]
.forEach(function (a){
if (a[0]!=exec(a[1])) throw ("Shit:"+ a[0]+" != "+ a[1])
});
После того как я заявил что массив — "единственно полезная структура данных", и можно парсить выражения без деревьев.
Гумно начало брать на «слабо».
Поточный парсер выражений, который принимает пайпом поток токенов и «на лету» пайпает свой выхлоп в интерпретатор.
Таким образом по мере прохождения потока он потихоньку исполняется и упрощается.
3.14159265 19.06.2016 19:48 # 0
http://www.govnokod.ru/20220#comment335515
Sfabrikan 19.06.2016 20:08 # 0
прибежит любой луашник и скажет да.
bormand 19.06.2016 20:09 # +2
3.14159265 19.06.2016 20:14 # +1
inkanus-gray 19.06.2016 20:21 # +6
3.14159265 19.06.2016 20:30 # +3
https://jsfiddle.net/f47afqct/4/
inkanus-gray 19.06.2016 20:43 # +5
1. RPN. Один стек для чисел. Исполнение операторов мгновенное. Есть клавиша для подъёма стека. Обычно четыре регистра (Χ, Υ, Ζ, Τ), причём Χ намертво припаян к экрану. Иногда бывает регистр Χ1 для временного хранения значения X, которое было перед последней операцией.
Пример: 2 ↑ 2 ↑ 2 + *
Ответ: 8
Пример: 2 ↑ 2 ↑ 2 * +
Ответ: 6
Все калькуляторы с RPN программируемые, ибо обычному пользователю они напитон не нужны.
2. Бухгалтерские. Также один стек, но всего на две ячейки, ибо для двухместной операции хватит. Операции исполняются мгновенно.
Пример: 2 + 2 * 2 =
Ответ: 8
3. Инженерные. Есть клавиши скобок и приоритет операций. От размера стека зависит поддерживаемая глубина вложения скобок.
Пример: 2 + 2 * 2 =
Ответ: 6
Судя по всему, у инженерных калькуляторов есть второй стек под операторы, ибо сложение откладывается на потом, если внезапно встретилось умножение.
4. Калькуляторы с AER — algebraic expressions representation. У них красивый редактор вводимого выражения, синус записывается как префикс и со скобками (как в математических формулах), а не как постфикс (как в инженерных калькуляторах). Есть подозрение, что они вообще строят дерево при разборе формулы.
3_14dar 19.06.2016 20:57 # −10
3_14dar 19.06.2016 22:40 # −6
3_14dar 21.06.2016 22:16 # −3
3.14159265 19.06.2016 22:46 # +3
А я говорю: можно не только мат. формулы в калькуляторах, но и программу парсить, компилировать и интерпретировать в один проход!
Допустим парсер получает на вход по одному символу. Он тут же разбирает их, и передаёт на вход интерпретатору запуская программу (тесты)
.
Таким образом еще мы не вычитали и половины программы, а уже исполняем её.
И допустим интепретатор наткунлся на команду goto napython;
Он ожидает пока парсер не дойдёт до места napython: после чего идёт напитон.
Или допустим есть
У интерпретатора уже есть ссылка на Assert, поскольку он только что выполнил предыдущий тест.
Интерпретатор фолдит константу 2+2 в 4.
И говорит: не знаю что такое Pituh и даёт хинт компилятору, тот ищет файл Pituh и кормит его парсеру.
Выходит что тесты можно начать запускать прямо при компиляции, имея частично собранную программу.
LispGovno 19.06.2016 23:07 # 0
И тут посреди исполнения программы ошибка компиляции: метка напитон не найден
3.14159265 19.06.2016 23:28 # +1
Надо ждать пока или "найден" или поток символов не кончится.
Может я неточно выразился.
Но вот же инканус всё очень хорошо расписал.
http://govnokod.ru/20230#comment335561
LispGovno 19.06.2016 23:39 # +3
3.14159265 19.06.2016 23:47 # 0
Ты можешь починить нужную строку и если она еще не прошла интерпретацию — продолжить выполнение с того места где остановился. Бейсик так умел.
>и только потом вдруг обнаружил, что она не корректно.
Тогда и многопоточные компиляторы нинужны. Другие потоки что-то лишнее выполнили, а один отвалился.
Всё — насмарку. Жизнь — тлен.
LispGovno 19.06.2016 23:55 # 0
3.14159265 20.06.2016 00:07 # 0
По сути сейчас так всё и работает сконпелировал — записал ast в память, и выполнил.
LispGovno 20.06.2016 00:14 # 0
а так то твой метод синтаксического стека не слишком годный для интерпретаторов, но годный для трансляторов, имхо.
3.14159265 20.06.2016 01:24 # +1
http://govnokod.ru/17323
см.
Я всё голову ломал, как бы в той хуёвине на свойствах и естественно без скобок сделать читабельный язык.
Нет, конечно можно было сделать постфикс, но там голову сломаешь пока напишешь/прочтёшь.
wvxvw 20.06.2016 11:52 # 0
3.14159265 20.06.2016 13:07 # 0
А. Точно
Но в баше эта фича как-то криво сделана и часто раздражает.
Написал чего-то сверху текущей команды и всё пошло вкривь, поскольку позиция в файле теперь указывает на средину команды.
dxd 20.06.2016 13:17 # 0
inkanus-gray 19.06.2016 23:20 # +1
Если у нас метка napython встретилась до goto (прыжок назад), то мы запоминаем её адрес в табличке меток и к моменту, когда встретится goto, у нас будет уже готовый адрес перехода.
Если goto встретился до метки napython (прыжок вперёд), то мы никуда не прыгаем, а в молчаливом режиме (ничего не выполняем, просто считаем длины команд) разбираем дальнейший код до того момента, пока не встретится метка. Как встретилась метка, выходим из виртуального режима и продолжаем выполнение. В случае же компилятора (а не интерпретатора) придётся латать адрес перехода в goto, но можно и не возвращаться назад, если у goto косвенная адресация: кладём адрес метки napython в таблицу, как и в первом случае, но только тут на запись таблицы уже указывает реальный goto.
meinf 19.06.2016 23:31 # +1
LispGovno 19.06.2016 23:11 # 0
LispGovno 19.06.2016 23:14 # 0
inkanus-gray 19.06.2016 23:37 # +2
У этой машины был забавный баг: при вычислении синуса стиралось содержимое второго стекового регистра. Т. е. синус 30° плюс 5 я мог посчитать, а 5 плюс синус 30° посчитать не мог, ибо пятёрка стиралась во время вычисления синуса. У других микрокалькуляторов той же эпохи (Б3-36, например) такого бага не было и оба варианта выражения считались без ошибок.
Получается, что у МК-18М микропрограмма вычисления синуса использовала не внутренние (скрытые) регистры, а пользовательский стек.
3_14dar 19.06.2016 20:57 # −6
3_14dar 21.06.2016 22:16 # −2
3_dar 19.06.2016 23:00 # 0
сразу подумал про 3.14159265358979323846264338327950288419 7169399375105820974944592307816406286208 9986280348253421170679
LispGovno 19.06.2016 23:37 # +5
Пролистывай по несколько страниц и смотри как топикстартер вореционировал:
Под конец вообще вореции вореции. Короче не шутите с ними и с программированием в частности. Оно не прощает.
http://www.gamedev.ru/flame/forum/?id=133421
inkanus-gray 19.06.2016 23:43 # 0
LispGovno 19.06.2016 23:44 # +1
inkanus-gray 19.06.2016 23:47 # +4
3.14159265 19.06.2016 23:53 # +3
И понеслась! здравствуйте, я Кирилл, я сделаю игру суть токова:
Действия, происходят в городе, есть университетская зона, и поездки на природу или в парк не исключаются. У нас будут более сложные взаимоотношения про любовь и дружбу, чем в Sims 3. Лучше все-таки делать от первого лица, мне “Morrowind” и “Мор Утопия” больше симпатичны. Можно общаться по интернету с ботами, т.е. компьютеры как в “Vampire: The Masquerade – Bloodlines” но более функциональные. Время действия ближайшее наше будущее.
Мне и исходники сильно не нужны, найти бы программистов. Основной вид на них, т.к. интересна большее концепция, реализации этого чем графика. По графике людей мы найдем, потом, когда будет куда ее вставлять.
Да, мне, не надо, скорее роман. Название, да, что-то вроде, 'как Ева, не смогла приказать'.
Но вообще и, Акиана, есть, две книжки. Елена невидимая, в порядке. Она мне по возрасту, подходит.
Спасибо, я очень поольщен. Я, не отказываюсь, От хорошей, сказки. Рэйна - таких, не бывает, Бог...
LispGovno 20.06.2016 00:12 # +1
3.14159265 20.06.2016 00:22 # 0
(осторожно интересуется)
А ты Хаскель уже забросил учить?
LispGovno 20.06.2016 01:27 # +4
CHayT 21.06.2016 22:58 # +6
во-первых, поскольку объём памяти ограничен, N тоже ограничено сверху, следовательно O(log(N))≡O(1); это только питухретики кукарекают про машины анала тьюринга с бесконечными лентами
во-вторых, физически память представляет собой не анскильный сишный массив, а царское дерево фиксированной высоты: каждая ячейка адресуется иерархически: по номеру банка, затем страницы, ну и потом уж строки и столбца
а уж дерево-то ложится на хаскель превосходно!
в общем, адресация за O(1) -- это миф для высокоуровневых адептов сишки, ничего не понимающих в настоящих оптимизациях на низком уровне
итог: хаскель -- царский язык, пацаны всегда будут унижать адептов сишки
bormand 21.06.2016 23:15 # 0
Ну это как посмотреть... Там же размеры банков/страниц/строк не плавают - а значит это просто четырёхмерный царский массив, а не питушиное дерево.
CHayT 21.06.2016 23:33 # 0
только анскильная лалка думает, что контроллер памяти прыгает сразу в произвольный байт
если посмотреть на спецификацию любого DDR SDRAM протокола, видно, что на самом деле он итерирует по этим индексам, сначала подготавливая строку для чтения
так же типичная хаскель-программа рекуррентно поднимается по дереву
отсюда же видно, что последовательный доступ к памяти быстрее, чем рандомный: а именно так работают зипперы в haskell
следовательно зиппер - царская структура, а массив -- нет
bormand 21.06.2016 23:45 # 0
Факт. Но вот деревья на это совсем уж плохо ложатся.
> прыгает сразу в произвольный байт
Ну где я об этом пишу?
bormand 21.06.2016 23:49 # 0
З.Ы. Я про тот sdram, с которым довелось работать. На ddr не так?
CHayT 22.06.2016 00:12 # 0
т.е. нужен мультиплексор, сама схема которого неслабо напоминает дерево
во-вторых, если для обращения к элементу нам в принципе нужно как-то итерировать, мы уже явно работаем не с массивом (в нём достаточно арифметики и _одной_ операции с абстрактной памятью, чтобы прочитать любой элемент, а в случае с реальной памятью таких операций получается как минимум две -- если смотреть снаружи)
wvxvw 22.06.2016 01:16 # 0
Но если мы будем рассматривать другие модели компьютеров, например, что-нибудь базирующееся на лямбда исчислении, то само по себе предположение о том, что может быть доступ к произвольной ячейке в памяти за константое время будет сильно сомнительным.
Надо понимать что RAM была задумана для описания компьютеров прошлого века, когда многопоточность и распределенные системы были исключением из правила, а возможность обработать несколько битов информации практически одновременно (в железе) делала эту модель очень правдоподобной (т.е. вычислить индексы разных ячеек памяти в диапазоне который можно описать несколькими битами).
Но ведь по-сути, индекс ячейки в памяти - это путь в бинарном дереве, он кодирует сколько-то решений, которые нужно принять для доступа к этой ячейке.
3_14dar 22.06.2016 01:52 # 0
wvxvw 22.06.2016 08:09 # 0
3_14dar 22.06.2016 08:16 # 0
wvxvw 22.06.2016 09:26 # 0
Возможно, после этого ты поймеш, что то, что ты сказал про ТМ - в принципе правильно, но не противоречит тому что я сказал раньше (что вызывает подозрения: а понял ли ты сам, что сказал).
3_14dar 22.06.2016 09:40 # 0
inkanus-gray 23.06.2016 01:28 # 0
Away imitationlay ofway Uringtay achinesmay isway atthay eythay
oday otnay odelmay ethay engthsstray ofway away articularpay
arrangementway ellway. Orfay instanceway, odernmay oredstay-
ogrampray omputerscay areway actuallyway instancesway ofway away
oremay ecificspay ormfay ofway abstractway achinemay ownknay
asway ethay andomray accessway oredstay ogrampray achinemay
orway ASPRAY achinemay odelmay. Ikelay ethay Universalway
Uringtay achinemay ethay ASPRAY oresstay itsway "ogrampray"
inway "emorymay" externalway otay itsway initefay-atestay
achine'smay "instructionsway". Unlikeway ethay universalway
Uringtay achinemay, ethay ASPRAY ashay anway infiniteway
umbernay ofway istinguishableday, umberednay utbay unboundedway
"egistersray"—emorymay "ellscay" atthay ancay ontaincay anyway
integerway (cfay. Elgotway andway Obinsonray (1964), Artmanishay
(1971), andway inway articularpay Ookcay-Echowray (1973);
eferencesray atway andomray accessway achinemay). Ethay ASP'sray
initefay-atestay achinemay isway equippedway ithway ethay
apabilitycay orfay indirectway addressingway (eway.gay. ethay
ontentscay ofway oneway egisterray ancay ebay usedway asway
anway addressway otay ecifyspay anotherway egisterray); usthay
ethay ASP'sray "ogrampray" ancay addressway anyway egisterray
inway ethay egisterray-equencesay.
inkanus-gray 23.06.2016 01:28 # 0
Ethay upshotway ofway isthay
istinctionday isway atthay erethay areway omputationalcay
optimizationsway atthay ancay ebay erformedpay asedbay onway
ethay emorymay indicesway, ichwhay areway otnay ossiblepay inway
away eneralgay Uringtay achinemay; usthay enwhay Uringtay
achinesmay areway usedway asway ethay asisbay orfay oundingbay
unningray imestay, away 'alsefay owerlay ound'bay ancay ebay
ovenpray onway ertaincay algorithms'WAY unningray imestay (ueday
otay ethay alsefay implifyingsay assumptionway ofway away
Uringtay achinemay). Anway exampleway ofway isthay isway
inarybay earchsay, anway algorithmway atthay ancay ebay ownshay
otay erformpay oremay icklyquay enwhay usingway ethay ASPRAY
odelmay ofway omputationcay atherray anthay ethay Uringtay
achinemay odelmay.
guest6 Позавчера # 0
guest6 Позавчера # 0
guest6 Позавчера # 0
guest6 Позавчера # 0
bormand 21.06.2016 23:21 # 0
Где здесь деревья, CHayT?
CHayT 23.06.2016 22:38 # +1
guest8 05.02.2020 04:47 # −999
bormand 05.02.2020 08:08 # 0
Данные сразу сохраняются т.к. сенс-ампы ещё подключены к строке.
Но после отключения сенс-ампов от строки их надо перезарядить до среднего значения (precharge). Только тогда можно будет открыть следующую.
bormand 21.06.2016 22:17 # +3
Борисов?
bot 20.06.2016 22:08 # 0
(просто, полагаю, что нужно быть настолько же чертовски талантливым, чтобы упорно находить такое подобное)
Desktop 05.02.2020 01:22 # +1
guestinho 21.06.2016 21:39 # +1