http://www.softtime.ru/info/task.php?id_article=102
И ещё:
если на 10.10 в десятиричной у меня вывело 1010.00011001100110011001100110011 в двоичной,
а на 1010.00011001100110011001100110011 в двоичной вывело 10.09999999986 в десятиричной,
то это защитывается? Или ошибка?

Спасибо.

Из бинарного представления дробного числа должно получить тоже самое дробное число.

PS Тонкости лучше не раскрывать раньше срока.

>Из бинарного представления дробного числа должно получить
>тоже самое дробное число.

То есть, у меня была ошибка? А если там период?

>PS Тонкости лучше не раскрывать раньше срока.
Прошу прощение.
**************************************************************************
А можно использовать строковые функции?
Такие, как strlen, strpos, substr, chr, ord?

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

Функциями нельзя пользоваться никакими. Только базовыми средствами языка. Если лень писать собственную функцию strlen() - то в принципе можно воспользоваться библиотечной.

а как тогда заменить chr и ord?
Вы не говорите "если лень писать", что бы не было недоразумений.
"Можно" или "нельзя".
Я уже свои написал, кроме chr и ord.

chr() и ord() для решения задачи не требуются - длину поступившей строки узнать нужно будет - отсюда поблажка в сторону strlen(), но вообще можно и без неё длину строки узнать.

Да я узнал и без неё длину строки.
Я же не могу придумать авторское решение.
Поэтому мне и нужны функции chr и ord.
И для проверки корректности входных данных, тоже...

Условия есть условия, никаких функций - если вам удалось найти решение без strlen(), тогда вообще всё просто - никаких функций кроме своих. Ведь все функции написаны на базовом языке, конечно не на PHP, а на С, но тут это не имеет значение. Вся соль задачи - вернуться к истокам - как люди без всяких библиотек создавали библиотечные функции?

Просто мне нужно использовать строки для ввода больших чисел
и для проверки корректности входных данных.
Без chr и ord не обойдусь.
Ой, а тогда isset и empty тоже нельзя?

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

К символу строки можно обратиться трояким образом.
Через substr, запрещенный условиями.
Через [ ], deprecated действующим (php5) мануалом.
Через { }, deprecated текущими (php6) рекомендациями разработчиков php.
:))

Указатели тоже относятся к разраду не рекомендованных, однако на них построено всё. Разумеется гпупо в промышленном коде, на который ориентируются разработчики PHP запрещать использование функции, но в задаче по другому нельзя, иначе она будет решаться при помощи одной единственной функции decbin(). Вся соль в том, что задача позволяет оценить функцию decbin() и множество других функций, созданных на чистой алгоритмистике.

1) Isset мне нужен был, потому что я передаю данные из формы самому себе.

2) А строки я использовал для того, что бы если пользователь введёт "не цифры",
то что б выдавало сообщение... Или, если ввели 123 в двоичной системе...

3) Скажите, корректность входных данных гарантируется? Что б мне не использовать пункт 2)

Нет корректность входных данных не гарантируется.

Тоже нельзя,
isset() и empty(), кстати говоря, языковые конструкции.

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

А можно без фильтров значений форм? Я вообще предложил бы убрать форму и кнопку, но думаю администрации удобней просматривать результаты.

А в бинарной системе разве можно представлять десятичные числа? Даже стандартные функции php не умеют этого делать :) Просто интересно было посмотреть как такое число может выглядеть :)

1. Можно всё :))) просто результат будет рассматриваться как правильный и как неправильный :)))
2. Все числа в компьютере, все операторы, команды храняться в бинарной форме, ни для кого нет исключений ни для отрицательных чисел, ни для дробных. С отрицательными и дробными числами помимо PHP не работает так же и windows-калькулятор, но это не значит что дробных и отрицательных чисел нет :)))

После нажатия кнопки отправить у меня произошел переход на эту страницу. Нормально ли это?

http://www.softtime.ru/info/task.php

Это про ответ на задачу или сообщение в форуме? Если ответ, то всё нормально, вижу вас в ответах... если захотите ещё поместить решение - можете добавлять ещё (но опубликовано будет только последнее решение).

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

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

Согласен, не дело, поправим в ближайшее время.

.

у меня перевод из двоичной в десятиричную начинает глючить после 1111111111(2), что равно 1023(10). это норм?

Система счисления десятичная.
1 111 111 111 (2) действительно равно 1 023(10) .
Глюк-то в чем заключается?

после этого числа (больше 1023 в десятичной) скрипт перевода чисел из двоичной в десятичную перестает работать правильно, 10000000000(2) - уже не работает

Вы наверное 1000000000 как число храните, а не как строку.
Числа больше 10 цифр в формат int просто напросто не помещаются. Если цифры десятичные. :))

Нет, 11 бит маловато, в идеале нужна поддержка 80 бит.

80? Странный выбор размера мантиссы. Она даже у long double (который занимает 10 байт)лишь 64 бита. Остальные 16 бит отданы на хранение знака и характеристики.

long double имею ввиду (в Linux он вообще 12 байт занимает, вместо 10 в Windows).

long double в Linux занимает 12 байт. Согласен.
Но Вы уверены, что под мантиссу в нем отводится больше 64 бит?

В long double в 32-битной архитектуре под число отводится 80 бит, двумя лишними байтами в Linux выравнивают число. В Windows скорее всего тоже так, но реализации доступных мне компиляторов возвращают фактическое число 80 бит. 64 бита отводится обычно просто под double.

Вот именно. и из этих 80 бит под мантиссу отводится 64 . В long double
(Соответственно в double из 64 бит под мантиссу отводится 53)

Напомню, откуда спор возник. P@Sol заметил, что с числами, мантисса которых вылезает за пределы 11 бит, творится что-то неладное. Вы посоветовали ему реализовать 80 бит. А я лишь заметил, что с такой точностю, плавучку никто не реализует.
Есть, конечно где-то в IEEE четырехкратная точность в 128 бит, из которых 112 отданы под мантиссу, но физически я её ни разу не видел. А чтоб 80 кто-то под мантиссу отдал, не видел и на бумаге.

Согласен.