Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем. И кто тут сетовал, что личные предпочтения выдаются за руководство к действию? mOleg писал(а): Но я не предлагал вообще убрать BASE, я лишь говорил, что без нее можно прекрасно обходиться.
"Лишь сказать" в разделе "стандарт" представляется как очень толстый намек. Я уже предлагал помечать такие предложения как наблюдения, эксперименты, пробы. Но не как "а вот в этой теме (новый стандарт) я вскользь упоминаю, что X - устарело и глючит (у меня), а значит, без него надо обойтись".
[quote="mOleg"]к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем. [/quote] И кто тут сетовал, что личные предпочтения выдаются за руководство к действию? [quote="mOleg"]Но я не предлагал вообще убрать BASE, я лишь говорил, что без нее можно прекрасно обходиться.[/quote]
"Лишь сказать" в разделе "стандарт" представляется как очень толстый намек. Я уже предлагал помечать такие предложения как наблюдения, эксперименты, пробы. Но не как "а вот в этой теме (новый стандарт) я вскользь упоминаю, что X - устарело и глючит (у меня), а значит, без него надо обойтись".
|
|
|
|
Добавлено: Чт мар 11, 2010 17:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): mOleg писал(а): Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда". "Мне не нужна глобальная BASE, значит глобальная BASE ерунда"?
к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем.
Но я не предлагал вообще убрать BASE, я лишь говорил, что без нее можно прекрасно обходиться.
[quote="Хищник"]mOleg писал(а): Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда". "Мне не нужна глобальная BASE, значит глобальная BASE ерунда"?[/quote]
к сожалению, это не ерунда, а очень узкое место из-за которого лично я имел немало проблем.
Но я не предлагал вообще убрать BASE, я лишь говорил, что без нее можно прекрасно обходиться.
|
|
|
|
Добавлено: Чт мар 11, 2010 17:19 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Надо! Очень уж интересно на этого зверя посмотреть...
кстати, обсуждение уже поднималось http://fforum.winglion.ru/viewtopic.php ... 6368570190
[quote="Хищник"]Надо! Очень уж интересно на этого зверя посмотреть...[/quote]
кстати, обсуждение уже поднималось http://fforum.winglion.ru/viewtopic.php?t=2313&sid=e81aaf7f147fc8d3cc56576368570190
|
|
|
|
Добавлено: Ср мар 10, 2010 20:58 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а : (.) ( n --> asc # ) ... ;
Почему "даже"? Опять же, я не должен думать, как оно устроено внутри, и проходит ли строковое представление через буфер. Печатать - надо. Достигать при этом заданных побочных эффектов - не обязательно. Да и asc # - с какой стати? А если asciiz или иной формат представления строк?
[quote="mOleg"]то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а : (.) ( n --> asc # ) ... ;[/quote]
Почему "даже"? Опять же, я не должен думать, как оно устроено внутри, и проходит ли строковое представление через буфер. Печатать - надо. Достигать при этом заданных побочных эффектов - не обязательно. Да и asc # - с какой стати? А если asciiz или иной формат представления строк?
|
|
|
|
Добавлено: Ср мар 10, 2010 20:22 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором?
интересная идея.
то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а
: (.) ( n --> asc # ) ... ;
[quote="Хищник"]Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором?[/quote]
интересная идея.
то есть можно забыть и о PAD и о <# # #> , а оставить даже не '.' ,а
: (.) ( n --> asc # ) ... ;
|
|
|
|
Добавлено: Ср мар 10, 2010 19:42 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): короче, это и есть тот вопрос, который меня интересует, ведь, к примеру слова: <# # #S HOLD SIGN #> отвязаны от разрядности чисел, что есть замечательно! Только вот в начале всеравно приходится ставить S>D , а ведь можно придумать, как это обойти, сделать так, что код не будет менять ни при работе с числами двойной длины, ни тройной, ни одинарной. Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором? Вот печатают регулярно, странно было бы, если бы программист не хотел печатать числа. А уж как устроена печать, интересует авторов трансляторов. mOleg писал(а): Хищник писал(а): Тема-то не моя.
я думал, что тему поднимает тот, кому она больше интересна Ну уж явно не мне. У меня она проходит по разряду "не обосновано". mOleg писал(а): посмотреть можно и в СПФе, если не ошибаюсь ns.f или ее часть, и в форке (штатно имеется) если уж очень интересно. Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).
Кода на свете очень много. Но перед тем, как его писать, необходимо сформулировать, что именно делается, как оно делается, и что необходимо искать в результатах в качестве признака успешной реализации. А иначе получится постоянное убегание от проблем - вот приносят конкретную задачу, ан нет! "Погодите, я тут обдумываю древовидную оптимизацию многопоточного хэширования виртуального входного потока, это тааааак круто!.... будет... когда допишу, а то вдруг ваши данные будут грузиться целых 0,06 секунд, а это непорядок, надо 0,05".
[quote="mOleg"]короче, это и есть тот вопрос, который меня интересует, ведь, к примеру слова: <# # #S HOLD SIGN #> отвязаны от разрядности чисел, что есть замечательно! Только вот в начале всеравно приходится ставить S>D , а ведь можно придумать, как это обойти, сделать так, что код не будет менять ни при работе с числами двойной длины, ни тройной, ни одинарной. [/quote] Можно. Ограничив спецификацию на систему словом . , и не задумываясь, что у него внутри. Разве большинство прикладных программистов пользуется всем указанным набором? Вот печатают регулярно, странно было бы, если бы программист не хотел печатать числа. А уж как устроена печать, интересует авторов трансляторов. [quote="mOleg"]Хищник писал(а): Тема-то не моя.
я думал, что тему поднимает тот, кому она больше интересна [/quote] Ну уж явно не мне. У меня она проходит по разряду "не обосновано". [quote="mOleg"]посмотреть можно и в СПФе, если не ошибаюсь ns.f или ее часть, и в форке (штатно имеется) если уж очень интересно. Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).[/quote]
Кода на свете очень много. Но перед тем, как его писать, необходимо сформулировать, что именно делается, как оно делается, и что необходимо искать в результатах в качестве признака успешной реализации. А иначе получится постоянное убегание от проблем - вот приносят конкретную задачу, ан нет! "Погодите, я тут обдумываю древовидную оптимизацию многопоточного хэширования виртуального входного потока, это тааааак круто!.... будет... когда допишу, а то вдруг ваши данные будут грузиться целых 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 или ее часть, и в форке (штатно имеется) если уж очень интересно.
Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).
[quote="Хищник"]Разве слово . зависит от разрядности?[/quote] слово не зависит, но уже набор слов к ней оказывается привязан. Тут стоит взять предлагаемый мною вариант 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 , а ведь можно придумать, как это обойти, сделать так, что код не будет менять ни при работе с числами двойной длины, ни тройной, ни одинарной.
[quote="Хищник"]Речь шла об "особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет". Как реализовать на таком процессоре преобразование чисел, пускай думает разработчик.[/quote] еще раз, стандарт в первую очередь нужен разработчику, и именно ему он должен упрощать жизнь. Пользователь туда заглядывать не обязан, а возможно даже не должен. При этом стандарт еще и не должен сильно ограничивать разработчика (то есть, код в стандарте все же лишний), и это уже особенность Форта. Кроме того, стандарт должен подходить к максимально широкому набору вычислительных систем, иначе от него опять же будет мало толка.
[quote="Хищник"]Тема-то не моя.[/quote] я думал, что тему поднимает тот, кому она больше интересна ;)
[quote="Хищник"]Надо! Очень уж интересно на этого зверя посмотреть.[/quote]
посмотреть можно и в СПФе, если не ошибаюсь ns.f или ее часть, и в форке (штатно имеется) если уж очень интересно.
Вариантов решения проблемы несколько, оптимально простой и эффективный я пока не нашел (для общего случая).
|
|
|
|
Добавлено: Вт мар 09, 2010 22:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей. Разве слово . зависит от разрядности? mOleg писал(а): имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе! Речь шла об "особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет". Как реализовать на таком процессоре преобразование чисел, пускай думает разработчик. Учитывая при этом, что другие языки на этом процессоре с числами как-то работают, а значит, и в Форт можно вставить такой же код в виде примитивов. Пользователю же надо вводить числа и печатать их. mOleg писал(а): Хищник писал(а): mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!
Надо! Очень уж интересно на этого зверя посмотреть...
создавай!
Тема-то не моя.
[quote="mOleg"]Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей. [/quote] Разве слово . зависит от разрядности? [quote="mOleg"]имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе! [/quote] Речь шла об "особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет". Как реализовать на таком процессоре преобразование чисел, пускай думает разработчик. Учитывая при этом, что другие языки на этом процессоре с числами как-то работают, а значит, и в Форт можно вставить такой же код в виде примитивов. Пользователю же надо вводить числа и печатать их. [quote="mOleg"]Хищник писал(а): mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!
Надо! Очень уж интересно на этого зверя посмотреть...
создавай![/quote]
Тема-то не моя.
|
|
|
|
Добавлено: Вт мар 09, 2010 21:59 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): В процессе работы с числами мы неминуемо обращаемся к "внешним" характеристикам транслятора. Преобразование между внутренним представлением системы и текстовым форматом затрагивает процесс эксплуатации, а значит, требования приходят из области применения продукта. Скажут тройную разрядность - значит надо тройную. абсолютно согласен! Более того, исхожу из тех же предпосылок. Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей. Хищник писал(а): Это интересно как раз разработчику транслятора, а никак не пользователю. имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе! Хищник писал(а): mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!
Надо! Очень уж интересно на этого зверя посмотреть...
создавай!
[quote="Хищник"]В процессе работы с числами мы неминуемо обращаемся к "внешним" характеристикам транслятора. Преобразование между внутренним представлением системы и текстовым форматом затрагивает процесс эксплуатации, а значит, требования приходят из области применения продукта. Скажут тройную разрядность - значит надо тройную.[/quote] абсолютно согласен! Более того, исхожу из тех же предпосылок. Поэтому и поднят вопрос о том, как лучше спроектировать интерфейс для работы с числами, чтобы он как можно меньше зависел от разрядностей.
[quote="Хищник"]Это интересно как раз разработчику транслятора, а никак не пользователю.[/quote] имхо, стандарт интересен в первую очередь разработчику, а не пользователю. Пользователю подавай документацию к конкретной форт-системе! :D
[quote="Хищник"]mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!
Надо! Очень уж интересно на этого зверя посмотреть...[/quote]
создавай!
|
|
|
|
Добавлено: Вт мар 09, 2010 20:54 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): ну, к чему приведет, это как раз вопрос обсуждения. просто двойная арифметика не всегда нужна (это и код лишний, а значит и объем), более того, ведь форт-система вообще может не заниматься трансляцией чисел, а получать их уже в бинарном виде (если текст предварительно обработан - можно вспомнить colorforth) в старых стандартах проработки этого момента вообще нет. кстати, я не требую, чтобы мое мнение было принято к исполнению, я просто считаю, что рассмотреть этот (эти) вопрос необходимо. В процессе работы с числами мы неминуемо обращаемся к "внешним" характеристикам транслятора. Преобразование между внутренним представлением системы и текстовым форматом затрагивает процесс эксплуатации, а значит, требования приходят из области применения продукта. Скажут тройную разрядность - значит надо тройную. mOleg писал(а): _Harry писал(а): Пока что видно усложнение работы пользователю форт-системы
с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений. Это интересно как раз разработчику транслятора, а никак не пользователю. Пользователь хочет вводить числа и печатать их. Целочисленное деление везде делается последовательным приближением (даже в x86), так что это не та проблема, о которой нужно беспокоиться. mOleg писал(а): А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение!
Надо! Очень уж интересно на этого зверя посмотреть...
[quote="mOleg"]ну, к чему приведет, это как раз вопрос обсуждения. просто двойная арифметика не всегда нужна (это и код лишний, а значит и объем), более того, ведь форт-система вообще может не заниматься трансляцией чисел, а получать их уже в бинарном виде (если текст предварительно обработан - можно вспомнить colorforth) в старых стандартах проработки этого момента вообще нет. кстати, я не требую, чтобы мое мнение было принято к исполнению, я просто считаю, что рассмотреть этот (эти) вопрос необходимо. [/quote] В процессе работы с числами мы неминуемо обращаемся к "внешним" характеристикам транслятора. Преобразование между внутренним представлением системы и текстовым форматом затрагивает процесс эксплуатации, а значит, требования приходят из области применения продукта. Скажут тройную разрядность - значит надо тройную.
[quote="mOleg"]_Harry писал(а): Пока что видно усложнение работы пользователю форт-системы
с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений. [/quote] Это интересно как раз разработчику транслятора, а никак не пользователю. Пользователь хочет вводить числа и печатать их. Целочисленное деление везде делается последовательным приближением (даже в x86), так что это не та проблема, о которой нужно беспокоиться. [quote="mOleg"]А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение! [/quote]
Надо! :) Очень уж интересно на этого зверя посмотреть...
|
|
|
|
Добавлено: Вт мар 09, 2010 20:41 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
_Harry писал(а): И хотелось бы знать к чему хорошему это приведет? ну, к чему приведет, это как раз вопрос обсуждения. просто двойная арифметика не всегда нужна (это и код лишний, а значит и объем), более того, ведь форт-система вообще может не заниматься трансляцией чисел, а получать их уже в бинарном виде (если текст предварительно обработан - можно вспомнить colorforth) в старых стандартах проработки этого момента вообще нет. кстати, я не требую, чтобы мое мнение было принято к исполнению, я просто считаю, что рассмотреть этот (эти) вопрос необходимо. _Harry писал(а): Пока что видно усложнение работы пользователю форт-системы с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений. _Harry писал(а): И возможно (хотя не уверен) упрощение для разработчика ядра? ну, можешь сам попробовать написать вариант для одиночной арифметики (я сейчас просто выложить результат не могу, т.к. в процессе) _Harry писал(а): Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "
и тоже большой вопрос.
сказать, что многопоточность для Форта не нужна я все же не рискну, однако видов многопоточности несколько.
И решений, соответственно может быть несколько.
А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение! Тут эта тема таки оффтопик...
[quote="_Harry"]И хотелось бы знать к чему хорошему это приведет?[/quote] ну, к чему приведет, это как раз вопрос обсуждения. просто двойная арифметика не всегда нужна (это и код лишний, а значит и объем), более того, ведь форт-система вообще может не заниматься трансляцией чисел, а получать их уже в бинарном виде (если текст предварительно обработан - можно вспомнить colorforth) в старых стандартах проработки этого момента вообще нет. кстати, я не требую, чтобы мое мнение было принято к исполнению, я просто считаю, что рассмотреть этот (эти) вопрос необходимо.
[quote="_Harry"]Пока что видно усложнение работы пользователю форт-системы[/quote] с чего? как раз наоборот, особенно на "убогих процах" а так же форт-процах, где доступ позволен только к двум-трем верхним ячейкам стека данных и операции деления в явном виде нет. То есть потеря не только в размере кода, но и во времени вычислений.
[quote="_Harry"]И возможно (хотя не уверен) упрощение для разработчика ядра?[/quote] ну, можешь сам попробовать написать вариант для одиночной арифметики (я сейчас просто выложить результат не могу, т.к. в процессе)
[quote="_Harry"]Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "[/quote]
и тоже большой вопрос.
сказать, что многопоточность для Форта не нужна я все же не рискну, однако видов многопоточности несколько.
И решений, соответственно может быть несколько.
А вообще, если хочется про многопоточную компиляцию, то надо создавать отдельное обсуждение! Тут эта тема таки оффтопик...
|
|
|
|
Добавлено: Вт мар 09, 2010 20:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).
И хотелось бы знать к чему хорошему это приведет?
Пока что видно усложнение работы пользователю форт-системы. И возможно (хотя не уверен) упрощение для разработчика ядра?
Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "
Это ж просто страшно подумать, что получится если разные потоки асинхронно начнут в один кодофайл писать.
А главное не понятно кому это нужно. На практие я думаю никому
[quote="mOleg"]А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).[/quote]
И хотелось бы знать к чему хорошему это приведет?
Пока что видно усложнение работы пользователю форт-системы. И возможно (хотя не уверен) упрощение для разработчика ядра?
Кстати насчет многопоточной компиляции мое мнение " ... В печку ее в печку!!!! "
Это ж просто страшно подумать, :shock: что получится если разные потоки асинхронно начнут в один кодофайл писать.
А главное не понятно кому это нужно. На практие я думаю никому :roll:
|
|
|
|
Добавлено: Вт мар 09, 2010 17:25 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Alexander писал(а): Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23. В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут
А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).
[quote="Alexander"]Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23. В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут[/quote]
А тут скорее вопрос, как можно "изолировать" разрядность чисел (и можно ли это сделать красиво).
|
|
|
|
Добавлено: Сб мар 06, 2010 19:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Что сказать, ну что сказать?! - устроены так люди...
Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23.
В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут
Что сказать, ну что сказать?! - устроены так люди...
Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23.
В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут
|
|
|
|
Добавлено: Сб мар 06, 2010 19:03 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
[img]http://i.smiles2k.net/sport_smiles/sport_boxing.gif[/img] [img]http://i.smiles2k.net/sport_smiles/sport_boxing.gif[/img] [img]http://i.smiles2k.net/sport_smiles/box.gif[/img]
надо бы :idea: :writer; :idea:
|
|
|
|
Добавлено: Сб мар 06, 2010 11:55 |
|
|
|
|