Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 11:59

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - числа формат, преобразование, представление
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем.

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

"Лишь сказать" в разделе "стандарт" представляется как очень толстый намек. Я уже предлагал помечать такие предложения как наблюдения, эксперименты, пробы. Но не как "а вот в этой теме (новый стандарт) я вскользь упоминаю, что X - устарело и глючит (у меня), а значит, без него надо обойтись".
Сообщение Добавлено: Чт мар 11, 2010 17:49
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
mOleg писал(а): Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда".
"Мне не нужна глобальная BASE, значит глобальная BASE ерунда"?

к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем.
Но я не предлагал вообще убрать BASE, я лишь говорил, что без нее можно прекрасно обходиться.
Сообщение Добавлено: Чт мар 11, 2010 17:19
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Надо! Очень уж интересно на этого зверя посмотреть...

кстати, обсуждение уже поднималось http://fforum.winglion.ru/viewtopic.php ... 6368570190
Сообщение Добавлено: Ср мар 10, 2010 20:58
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а
: (.) ( n --> asc # ) ... ;

Почему "даже"? Опять же, я не должен думать, как оно устроено внутри, и проходит ли строковое представление через буфер. Печатать - надо. Достигать при этом заданных побочных эффектов - не обязательно. Да и asc # - с какой стати? А если asciiz или иной формат представления строк?
Сообщение Добавлено: Ср мар 10, 2010 20:22
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором?

интересная идея.
то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а
: (.) ( n --> asc # ) ... ;
Сообщение Добавлено: Ср мар 10, 2010 19:42
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
короче, это и есть тот вопрос, который меня интересует, ведь, к примеру слова: <# # #S HOLD SIGN #> отвязаны от разрядности чисел, что есть замечательно! Только вот в начале всеравно приходится ставить S>D , а ведь можно придумать, как это обойти, сделать так, что код не будет менять ни при работе с числами двойной длины, ни тройной, ни одинарной.

Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором? Вот печатают регулярно, странно было бы, если бы программист не хотел печатать числа. А уж как устроена печать, интересует авторов трансляторов.
mOleg писал(а):
Хищник писал(а):
Тема-то не моя.

я думал, что тему поднимает тот, кому она больше интересна

Ну уж явно не мне. У меня она проходит по разряду "не обосновано".
mOleg писал(а):
посмотреть можно и в СПФе, если не ошибаюсь ns.f или ее часть, и в форке (штатно имеется) если уж очень интересно.
Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).

Кода на свете очень много. Но перед тем, как его писать, необходимо сформулировать, что именно делается, как оно делается, и что необходимо искать в результатах в качестве признака успешной реализации. А иначе получится постоянное убегание от проблем - вот приносят конкретную задачу, ан нет! "Погодите, я тут обдумываю древовидную оптимизацию многопоточного хэширования виртуального входного потока, это тааааак круто!.... будет... когда допишу, а то вдруг ваши данные будут грузиться целых 0,06 секунд, а это непорядок, надо 0,05".
Сообщение Добавлено: Ср мар 10, 2010 14:12
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Разве слово . зависит от разрядности?

слово не зависит, но уже набор слов к ней оказывается привязан.
Тут стоит взять предлагаемый мною вариант INTERPRET
<pre>
: INTERPRET ( --> )
BEGIN NextToken DUP WHILE
EvalToken ?STACK
REPEAT DROP DROP ;
</pre>
все замечательно в том плане, что количество параметров(выходящих) у NextToken уравновешивается количеством входящих у EvalToken .
код по сути практически не зависит от того, как представлены токены и какое количество информации передается между ними (и это замечательно), однако, как ни странно все портит убирание параметров в конце: DROP DROP - которое сразу говорит о том, что параметров передается два и оба на стеке данных. И получается, что лучше написать так:
<pre>
: INTERPRET ( --> )
BEGIN NextToken DUP WHILE
EvalToken ?STACK
REPEAT DropToken ;
</pre>
то есть ввести вроде бы лишнюю сущность, которая сбалансирует количество параметров.
короче, это и есть тот вопрос, который меня интересует, ведь, к примеру слова: <# # #S HOLD SIGN #> отвязаны от разрядности чисел, что есть замечательно! Только вот в начале всеравно приходится ставить S>D , а ведь можно придумать, как это обойти, сделать так, что код не будет менять ни при работе с числами двойной длины, ни тройной, ни одинарной.

Хищник писал(а):
Речь шла об "особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет". Как реализовать на таком процессоре преобразование чисел, пускай думает разработчик.

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

Хищник писал(а):
Тема-то не моя.

я думал, что тему поднимает тот, кому она больше интересна ;)

Хищник писал(а):
Надо! Очень уж интересно на этого зверя посмотреть.

посмотреть можно и в СПФе, если не ошибаюсь ns.f или ее часть, и в форке (штатно имеется) если уж очень интересно.
Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).
Сообщение Добавлено: Вт мар 09, 2010 22:49
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей.

Разве слово . зависит от разрядности?
mOleg писал(а):
имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе!

Речь шла об "особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет". Как реализовать на таком процессоре преобразование чисел, пускай думает разработчик. Учитывая при этом, что другие языки на этом процессоре с числами как-то работают, а значит, и в Форт можно вставить такой же код в виде примитивов. Пользователю же надо вводить числа и печатать их.
mOleg писал(а):
Хищник писал(а):
mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!

Надо! Очень уж интересно на этого зверя посмотреть...

создавай!

Тема-то не моя.
Сообщение Добавлено: Вт мар 09, 2010 21:59
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
В процессе работы с числами мы неминуемо обращаемся к "внешним" характеристикам транслятора. Преобразование между внутренним представлением системы и текстовым форматом затрагивает процесс эксплуатации, а значит, требования приходят из области применения продукта. Скажут тройную разрядность - значит надо тройную.

абсолютно согласен! Более того, исхожу из тех же предпосылок.
Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей.

Хищник писал(а):
Это интересно как раз разработчику транслятора, а никак не пользователю.

имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе! :D

Хищник писал(а):
mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!

Надо! Очень уж интересно на этого зверя посмотреть...

создавай!
Сообщение Добавлено: Вт мар 09, 2010 20:54
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
ну, к чему приведет, это как раз вопрос обсуждения.
просто двойная арифметика не всегда нужна (это и код лишний, а значит и объем), более того, ведь форт-система вообще может не заниматься трансляцией чисел, а получать их уже в бинарном виде (если текст предварительно обработан - можно вспомнить colorforth)
в старых стандартах проработки этого момента вообще нет.
кстати, я не требую, чтобы мое мнение было принято к исполнению, я просто считаю, что рассмотреть этот (эти) вопрос необходимо.

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

mOleg писал(а):
_Harry писал(а):
Пока что видно усложнение работы пользователю форт-системы

с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений.

Это интересно как раз разработчику транслятора, а никак не пользователю. Пользователь хочет вводить числа и печатать их. Целочисленное деление везде делается последовательным приближением (даже в x86), так что это не та проблема, о которой нужно беспокоиться.
mOleg писал(а):
А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!

Надо! :) Очень уж интересно на этого зверя посмотреть...
Сообщение Добавлено: Вт мар 09, 2010 20:41
  Заголовок сообщения:   Ответить с цитатой
_Harry писал(а):
И хотелось бы знать к чему хорошему это приведет?

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

_Harry писал(а):
Пока что видно усложнение работы пользователю форт-системы

с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений.

_Harry писал(а):
И возможно (хотя не уверен) упрощение для разработчика ядра?

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

_Harry писал(а):
Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "

и тоже большой вопрос.
сказать, что многопоточность для Форта не нужна я все же не рискну, однако видов многопоточности несколько.
И решений, соответственно может быть несколько.
А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение! Тут эта тема таки оффтопик...
Сообщение Добавлено: Вт мар 09, 2010 20:09
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).

И хотелось бы знать к чему хорошему это приведет?
Пока что видно усложнение работы пользователю форт-системы. И возможно (хотя не уверен) упрощение для разработчика ядра?

Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "
Это ж просто страшно подумать, :shock: что получится если разные потоки асинхронно начнут в один кодофайл писать.
А главное не понятно кому это нужно. На практие я думаю никому :roll:
Сообщение Добавлено: Вт мар 09, 2010 17:25
  Заголовок сообщения:   Ответить с цитатой
Alexander писал(а):
Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23.
В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут

А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).
Сообщение Добавлено: Сб мар 06, 2010 19:43
  Заголовок сообщения:   Ответить с цитатой
Что сказать, ну что сказать?! - устроены так люди...
Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23.
В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут
Сообщение Добавлено: Сб мар 06, 2010 19:03
  Заголовок сообщения:   Ответить с цитатой
Изображение Изображение Изображение

надо бы :idea: :writer; :idea:
Сообщение Добавлено: Сб мар 06, 2010 11:55

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB