Несмотря на переход Nokia на Windows Phone, развитие Qt и MeeGo продолжится

>>> недоучками-физиками

и ничего про онкологию не говорю.

Не следим за тем, что говорим? Может вы даже ведаете о финансировании лечения больных? Или откуда берутся деньги на это оборудование? И вообще о состоящии медицинской службы в целом? Если не компетентны, лучше и не начинать. Да и этот вопрос никакого отношения в линуксу/виндовсу никакого отношения не имеют, не находите?

> На ASM в любом случае этого не видно, но инструкции прописаны...

Речь шла вообще-то о том, как именно OC может влиять на результаты работы стороннего приложения. Один из вариантов такого влияния - кривая/неточная реализация математических функций. Не подумав о том, что кто-то может не знать про FSIN и причины по которым его не используют для вычислений синуса почти везде, а используют написанную руками функцию, я ляпнул про «синусы-косинусы». Отсюда и произошёл весь этот пустой флейм.

>>> недоучками-физиками >>>и ничего про онкологию не говорю.

Не следим за тем, что говорим?

Нет, просто кто-то не следит кого читает.

Я ничего про «недоучек-физиков» не говорил.

Верно. Прошу прощения. Сказывается время суток.

FPU с начала 486х уже все нормально обрабатывала. В архитектуре, считается 16 знаков после запятой, или 65536 байт в такте. Адресация ограничена также.Но математические функции все реализованы.Не вижу разницы в количестве мат. функций x64 архитектуры.

>Я конечно слышал, что у Нокии дела плохи, но не думал что настолько. Это уже агония.

Скорее микрософт им дал _ооооочень_ много денег. То есть за пользование WP7 заплатили не микросойту - а наоборот микрософт отдал свою венду и еще доплатил за пользование.

>>обработка FPU Exception и всякая эмуляция сопроцессора, если FPU нету

- прям в ядре и находятся.

в каком ядре? в ядре Виндовс? или в ядре МС-ДОС тоже была эмуляция

сопроцессора на случай его отсутствия для процессоров 8086-80386?

Ну да, в ядре виндовса. Откуда сопроцессор, например, в каком-нибудь древнем iPAQ?

>получается что Qt на хрен ни кому не было нужно и не будет нужно (окромя кучки фанатов)

гомофилы такие гомофилы...

Может и так) Сделали ставку на именитую торговую марку? )

>Может и так) Сделали ставку на именитую торговую марку? )

Точнее нашли того кто смотрит на них не с таким отвращением как все остальные:)

Реквестирую финский грибной справочник и технологию хранения.

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

И что мы видим?

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?

gcc вовсю использует инструкции сопроцессора, что можно узнать, например, в пункте 3.17.15 Intel 386 and AMD x86-64 Options документации GCC.

Так круто сливать это надо уметь.

В винде используют FSIN. В GCC используют FSIN. в glibc используют FSIN. Может быть вам стоит остановиться и перестать врать?

Возможно баян, НО: Кроме того, Элоп опроверг информацию о том, что штаб-квартира Nokia может переместиться в Силиконовую долину: «Это финская компания и она всегда ею будет». Глава Nokia также дал дополнительную информацию по устройству на базе MeeGo. Он говорил уклончиво. Судя по всему, первый MeeGo-смартфон станет пробным продуктом, устройством для энтузиастов, как в свое время Nokia N900. Отношение Nokia к этой платформе прояснится со временем. http://www.cnews.ru/news/line/index.shtml?2011/02/11/427114

Насколько я помню была такая история:
сначала выпустили 387.
потом через достаточно продолжительное время оказалось, что он неправильно (с недостаточной точностью) считает синус и косинус при определённых диапазонах аргумента.
т.к. сопроцессоров уже было выпущено дофига, и софт подстроили под этот глюк, то в следующих сопроцессорах fsin и fcos решили оставить как есть, с ошибкой. Ещё были всякие флеймы по поводу того, что AMD то-ли тоже повторила этот глюк, то-ли наоборот не повторила и софт стал неправильно считать, не помню уже.
Продолжает ли тянуться этот глюк во всяких CoreDuo и прочем - я не знаю, но судя по интелевской привычке обеспечивать обратную совместимость любой ценой и тащить до сих пор 16-разрядный режим, глюк должны были оставить.

> gcc вовсю использует инструкции сопроцессора, что можно узнать,

например, в пункте 3.17.15 Intel 386 and AMD x86-64 Options

документации GCC.

С чего бы это _компилятору_ не давать возможность использовать любые инструкции сопроцессора, если этого хочет пользовательн?

насколько помните или насколько нашли в гугле мало что понимая о предмете? пункт 4.2 правил форума не для вас писали?

Вроде пофиксили на атлонах и пентиумах. Иначе мы живем в математичеки неправильном мире. :)))

действительно с чего бы не использовать FSIN? я тоже удивляюсь. Ещё я удивляюсь на вас, уважаемый, ваша светлая персона за пару часов несколько раз уже изволила кардинально поменять своё мнение, сообщив массу недостоврной информации.

> В винде используют FSIN.

Не в курсе. Если используют - то идиоты.

В GCC используют FSIN.

GCC - это компилятор, а не ОС. Если я хочу по каким-то причинам использовать именно fsin - то компилятор обязан предоставить мне эту возможность.

в glibc используют FSIN.

Где? Я что-то не нашёл.
Даже в uClibc - и то fsin будет только если _специально_ __FAST_MATH__ включить.

подведём итоги.
вы наврали:
1) в процессорах интела нет синусов (но они там есть)
2) синусы есть, но их никто не использует (но используют и по умолчанию)
3) в glibc нет синусов интела (но они там есть)
3) в синусах есть ошибка ещё до пентиума, которую все повторяли (но ошибка была в делении у пентиума и никто её не повторял)

я за бан по 4.2

1) в процессорах интела нет синусов (но они там есть)

То, что там есть - не синус, а глюк.

2) синусы есть, но их никто не использует (но используют и по умолчанию)

Я нашёл только в uClibc если принудительно включить __FAST_MATH__

3) в glibc нет синусов интела (но они там есть)

Не нашёл. Где? файл:строчку кода на бочку.

3) в синусах есть ошибка ещё до пентиума, которую все повторяли (но ошибка была в делении у пентиума и никто её не повторял)

Не могу уловить смысл написанного.

кушай, тролль! желаю тебе приятного бана по 4.2

bubuntu@bubuntu-desktop:~$ cat test.c 
#include <math.h>
int main(int argc, char** argv)
{
	return (int)sin(argc);
}

bubuntu@bubuntu-desktop:~$ gcc -lm test.c

bubuntu@bubuntu-desktop:~$ gdb a.out 
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/bubuntu/a.out...(no debugging symbols found)...done.

(gdb) break sin
Breakpoint 1 at 0x804836c

(gdb) run
Starting program: /home/bubuntu/a.out 

Breakpoint 1, 0x00137200 in sin () from /lib/tls/i686/cmov/libm.so.6

(gdb) disassemble
Dump of assembler code for function sin:
=> 0x00137200 <+0>:	fldl   0x4(%esp)
   0x00137204 <+4>:	fxam   
   0x00137206 <+6>:	fstsw  %ax
   0x00137209 <+9>:	mov    $0x45,%dh
   0x0013720b <+11>:	and    %ah,%dh
   0x0013720d <+13>:	cmp    $0x5,%dh
   0x00137210 <+16>:	je     0x137236 <sin+54>
   0x00137212 <+18>:	fsin   
   0x00137214 <+20>:	fnstsw %ax
   0x00137216 <+22>:	test   $0x400,%eax
   0x0013721b <+27>:	jne    0x137220 <sin+32>
   0x0013721d <+29>:	ret    
   0x0013721e <+30>:	xchg   %ax,%ax
   0x00137220 <+32>:	fldpi  
   0x00137222 <+34>:	fadd   %st(0),%st
   0x00137224 <+36>:	fxch   %st(1)
   0x00137226 <+38>:	fprem1 
   0x00137228 <+40>:	fnstsw %ax
   0x0013722a <+42>:	test   $0x400,%eax
   0x0013722f <+47>:	jne    0x137226 <sin+38>
   0x00137231 <+49>:	fstp   %st(1)
   0x00137233 <+51>:	fsin   
   0x00137235 <+53>:	ret    
   0x00137236 <+54>:	push   %ebx
   0x00137237 <+55>:	call   0x131517
   0x0013723c <+60>:	add    $0x1bdb8,%ebx
   0x00137242 <+66>:	call   0x1313a8 <__errno_location@plt>
   0x00137247 <+71>:	movl   $0x21,(%eax)
   0x0013724d <+77>:	pop    %ebx
   0x0013724e <+78>:	jmp    0x137212 <sin+18>
End of assembler dump.
(gdb) 

И ещё для неугомонных ононимов:

test.c: -------------------

#include <math.h>
#include <stdio.h>

double fsin( double x )
{
register double res;
asm( «fsin» : «=t» (res) : «0» (x) );
return res;
}

int
main(int argc, char** argv)
{
printf(«sin(43998769152.000000) is %.16le\n», sin(43998769152.000000));
printf(«fsin(43998769152.000000) is %.16le\n», fsin(43998769152.000000));
}
------------------------

$ gcc -lm -o test test.c
$ ./test
sin(43998769152.000000) is -4.0252920638371055e-09
fsin(43998769152.000000) is -4.0819367251002277e-09

Офигенно fsin синусы считает.

Если чо -
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Mobile Intel(R) Celeron(R) CPU 2.40GHz
stepping : 9
cpu MHz : 2400.304
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4801.15
clflush size : 64

Это чо за ужос?

Где обещанный точный и замечательный FSIN имени Интеля?

Не можем никак успокоиться после всей лжи? пример показывает, что
1) fsin есть у интела
2) fsin используется в линуксах
3) fsin используется в GCC
4) fsin используеться в glibc
5) fsin используется по умолчанию без явного указания пользователем

За 4.2 надо банить анонимусов, причём превентивно.

Вот ещё, тот же код выдаёт:

$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16

Этот FSIN не может даже sin(около pi) посчитать правильно.

Не можем никак успокоиться после всей лжи? пример показывает, что
1) fsin есть у интела
2) fsin используется в линуксах
3) fsin используется в GCC
4) fsin используеться в glibc
5) fsin используется по умолчанию без явного указания пользователем

Бла-бла-бла.

--------------- test.c -------------------------------
#include <math.h>
#include <stdio.h>

double fsin( double x )
{
register double res;
asm( «fsin» : «=t» (res) : «0» (x) );
return res;
}

int
main(int argc, char** argv)
{
printf(«sin(%.16le) is %.16le\n», M_PI, sin(M_PI));
printf(«fsin(%.16le) is %.16le\n», M_PI, fsin(M_PI));
}

-----------------------------------------

$ gcc -lm -o test test.c
$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16


Этот пример показывает, что для вычисления sin() не используется fsin имени интеля а используется куча кода, которая может быть разная в разных ОС, что может служить источником ошибок.

гыгыгы. ты хоть на калькуляторе проверял вывод своей программы? sin(43998769152.000000) = 0.951056516

откуда там fsin взялся то? у Вас же его не было в принципе и в линуксах он не использовался, только в винде. Таки откуда он объявился?

> гыгыгы. ты хоть на калькуляторе проверял вывод своей программы?

sin(43998769152.000000) = 0.951056516

Радианы включи, чудо... На твоём калькуляторе есть радианы?

что ты так облажался? твой же текст

Не знаю как у вас, а у меня синус из интелевского FPU сидит в fsin() и никогда не используется, а что?

Ну нету double sin(double) в x86 FPU. Оно везде ручками написано. Ну хоть в сырцы libc гляньте для приличия.

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?

GCC тогда почему использует, лгунишка?

> откуда там fsin взялся то? у Вас же его не было в принципе и в

линуксах он не использовался, только в винде. Таки откуда он

объявился?

Где это я такое говорил?

Я утверждал, что :

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899619

А чем FPU на Linux так кардинально отличается от FPU на Windows?

Если FPU есть - то оно не на линуксе и не на винде, а в процессоре.

Отличаются математические библиотеки, ибо в x86 в FPU всяких синусов

и косинусов нету.

Ибо fsin от интеля за синус считать никак нельзя. Даже выдернутый из убунты код libm для вычисления синуса почему-то содержит кучу всякой всячины, а не единственный fsin, который якобы синус сам по себе.
В винде, скорее всего, код sin будет другой.

Linux, вперде!

Облажался не я, а кто-то другой.

Если sin === FSIN, то как тогда получается это:

$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16

Любому идиоту понятно из этого примера, что для вычисления правильного sin() используется не команда сопроцессора FSIN, а какой-то код.

Убунта по умолчанию использует fsin интела. А ты что понаписал вранья кучу?

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899619
в x86 в FPU всяких синусов и косинусов нету.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899653
Минуточку. в винде double sin(double) это FSIN?
Ахренеть.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899662
Не знаю как у вас, а у меня синус из интелевского FPU сидит в fsin() и никогда не используется, а что?

Ну нету double sin(double) в x86 FPU. Оно везде ручками написано. Ну хоть в сырцы libc гляньте для приличия.

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?


http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899695
Ну не пришло мне в голову, что кто-то знаменитый своим вечным багом FSIN/FCOS x87 может всерьёз воспринимать.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899715
Не подумав о том, что кто-то может не знать про FSIN и причины по которым его не используют для вычислений синуса почти везде, а используют написанную руками функцию


http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899734
С чего бы это _компилятору_ не давать возможность использовать любые инструкции сопроцессора, если этого хочет пользовательн?



http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899743

В винде используют FSIN.

Не в курсе. Если используют - то идиоты.

в glibc используют FSIN.

Где? Я что-то не нашёл.

Это всё вообще к чему?
Ну посмотрели на бубунтов sin. Функция не состоит из единственного fsin, а состоит из кучи кода, как и утверждалось.
В винде используется такой же код?
В винде линуксе и пр. - может использоваться разный код?
Очевидно может. И если где-то он кривой - то это приведёт к ошибкам при вычислениях. Что не так?

Не нравится sin(), потому что как бы есть fsin?
Ну давайте поговорим об arcsin()
Надеюсь утверждение, что arcsin реализован программно в математической библиотеке не вызовет аналогичного баттхерта?
Если не вызовет - то можно перейти к сути.
Итак, дадите гарантию, что в винде и линуксе и где-то там ещё код arcsin() одинаков и что этот код не может служить источником ошибок?

> Я уже писал выше что _уже_ юзаю порт Qt на Android для своих программ и внедряю на работе... http://code.google.com/p/android-lighthouse/ В настоящий момент готовится документация и размещаются Qt либы на Android Market. Но пользоваться можно уже сейчас.

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

Eсли бы Nokia занялась этим, то это стало бы очередной очень вкусной фичей Qt, а так это 3rd-party-workaround, настоящее и будущее которого весьма туманно.

И потом, через пару лет Qt со всеми этими lighthouse устареют, через 4 года еще больше, баги будут копиться и висеть... зачем Нокии их чинить?

Ты утверждал, что fsin вообще нет. Потом что fsin есть, но не используется. Потом утверждал что использующие её люди являются идиотами. Потом что её нет в glibc.

Таким образом ты энергично сливал, пользовался гуглом. потом опять сливал и так много раз.

> Таким образом ты энергично сливал, пользовался гуглом. потом опять

сливал и так много раз.

Слил тут кто-то другой. Тот, кто пытается рассказать, что fsin в интеле - это синус, вместо того, чтобы понять, что речь шла вовсе не об этом.

Я, кстати, опечален тем, что в убунте кривой sin().
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
Правда, всех послали в glibc жаловаться на регрессию.
У меня вот sin() нормальный и fsin не использует, как оказалось.

Не нравится, когда оказывается, что интель выпускает не такие уж замечательные железки? Ну извиняйте, это не ко мне.

Синус который fsin - использует для уменьшения аргумента число пи с мантиссой 66 бит. В glibc видно (код я приводил), что там для уменьшения аргумента используется отдельная команда почему-то, которая загружает в FPU число пи, которое округляется по документации до 64 знаков. Уменьшение аргумента происходит с этим более грубым пи.

Поэтому есть основания доверять больше чистому fsin, а не реализации glibc, которая ещё от себя код добавляет.

какой из них нормальный? какими средствами, независимыми от линукса, виндовс, интела и амд проверялись? Откуда уверенность, что верно первое, а не второе?

sin(43998769152.000000) is -4.0252920638371055e-09
fsin(43998769152.000000) is -4.0819367251002277e-09

>У меня вот sin() нормальный

как это было доказано? какую использоали библиотеку, независимую от 80-битных чисел с плавающей точкой и процессоров интела и амд? Где взять точное значение вашего синуса хотя бы 20 значащих цифр, чтобы убедиться, что ваш синус правильный, а не чистый синус fsin?

Но мой-то sin() который без fsin даёт правильный результат, а чистый fsin даёт неправильный.

Если glibc где-то использует fsin - то это и есть доказательство того, что от системы зависит наличие ошибок в софтине. Софтина-то может и правильно считает, а вот синус ей даден неправильный. О чём с самого начала и шла речь.

Уверены, что результат правильный? Уверены, что у вас sin без fsin? на 32 разрядах по умолчанию FPU используется.

MathLab говорит первое правильно.
Винда, кстати, в калькуляторе так же считает.
http://web2.0calc.com/ тоже.

Да, уверен.
Если бы sin был с fsin - то результаты совпадали бы, разве не так?

>Windows Phone будет основной платформой для смартфонов Nokia (подробнее);

А-я-я-й. Нокла RIP.

развитие Qt продолжится;

В рамках KDE...

Не так. Ассемблерный код приведите вашего sin. В случае использования константы sin вообще не вызывается - компилятор туда константу забивает вычисленную заранее. Если константу умножить на argc (т.е. 1), то происходит вызов sin (там внутри fsin) и результат становится другой.

Уверен.
Вот результат с D-Link DIR-320 - он вообще MIPS и без всякого сопроцессора:
---------------- sin_test.c ------------------------
#include <math.h>
#include <stdio.h>

int
main(int argc, char** argv)
{
double d = 43998769152.000000;
printf(«sin(%.16le) is %.16le\n», d, sin(d));
}
------------------------------------------------------

# /tmp/sin_test
sin(4.3998769151999998e+10) is -4.0252920638371056e-09
# cat /proc/cpuinfo
system type : Broadcom BCM5354 chip rev 3
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available