On 02.10.2016 00:30, M.M. wrote:
> On Saturday, October 1, 2016 at 1:44:43 AM UTC+2, bartekltg wrote:
>> On 01.10.2016 00:49, Borneq wrote:
>>> W dniu 30.09.2016 o 23:56, bartekltg pisze:
>>>> na dane z liczbami. To spory narzut pamięciowy jeśli
>>>> potrzebuję jedynie poczwórnej...szesznastokrotnej precyzji,
>>>> oraz rozwala spójność pamieci przy operacjach macierzowych.
>>>
>>> Poczwórnej - czy to nie to co mi podawałeś gdy pytałem się o 128 bitów?
>>> http://www.boost.org/doc/libs/1_57_0/libs/multipreci
sion/doc/html/boost_multiprecision/tut/floats/float1
28.html
>>
>> To jest wrapper na bibliotekę quadmath, albo intelowy, albo włąśnie
>> double double.
>>
>>
>>> Ale szesnaście razy 32 bity to już narzut na długość i wskaźnik nie jest
>>> tak duży, chyba że rozwala spójność pamięci.
>>
>> GMP ma Wskaźnik i dwa inty na długość:/
>>
>> NArzut czasowy niewielki, ale spojność pamięći jest dla mnie dość
>> istotna.
>
> Jeśli są allokowane dane w takiej kolejności w jakiej będzie
> je przeglądał algorytm, to wbrew pozorom jakaś sensowna spójność
> pamięci będzie zachowana.

A teraz robię na tych macierzach rozkłądy LLT albo LUP jakiś
gotowcem, a on przestawia liczby, moze im robi swap.

> Oczywiście wydajność nie będzie taka
> jak w C++ na wyspecjalizowanym szablonie dla określonej precyzji,
> ale tragedii też nie powinno być.

Czasy obliczeń liczy się w godzinach lub dniach, miłoby było
coś wykroić ;-)

pzdr
bartekltg