Тука чета нещо много веселко: http://apenwarr.ca/log/?...

Има 3 статийки на тая страница, и 3те са свързани тематично и са много забавни ... реших че все ще се харесат на някой :)

А гоненето си е буквално. Нямам идея кой и кога ще е свободен.

Септември ще има защити.

Първият, който донесе гъба за триене на бяла дъска ще бъде изпитан приоритетно. Но няма да повлияе на оценката.

(r'^public/+(?P<path>.*)', 'django.views.static.serve', {'document_root': 'public'}),

Така каквото и да слагаш в /public/ ще бъде видимо.

Както Митко написа - графика е примерен.

@Никола:

Ако искаш може да се разменим.

Имаше някакви приказки в съседната :) тема, че който е на работа, може да мине в след работно време. Аз не работя, пък и нямам никакви претенции кога ще мина, та ако някой му се е паднало да е следобед, а е на работа, може да пише да се разменим.

ПП: Не виждам развитие по тоя въпрос с работещите (някакви списъци кой кога може/не може) та затва спамя. Ако съм изпуснал нещо, тъп съм, сори :)

То и доста болезнена греда е че във ФМИ има изпити и утре и на 13-ти, така че защитите трябва да са все след 15:00...

Това с неработенето няма да е само за css ами и за всички други файлове които линкваш към хтмл-а.

и после в дадена страница съм include-нал head.html Но при <style type="text/css">
много текст.... </style> в head.html работи.

Т.е търсенето, примерно, да се реализира горе-долу така:

>>> search('Label1', 'Label2', ..., type='Note', text='Part of the text in the note')

Като разбира се съответната фунцкионалност е подкрепена от лесно достъпен и достатъчно описателен HELP

По този начин избягваме директното четене от клавиатурата и главоболията свързани с визуализирането на цялата работа.

:?

@Никола:
Пробвай scipy
Това също може да ти свърши работа: random.lognormvariate / wiki

За хората, които са на работа - можете да дойдете извън работно време. Защитата ще продължи поне до 8-9 вечерта.

В много екстремни случаи ще можете да защитите на 13ти. Но това - само в случай, че имате уважителна причина. Освен това трябва да ни съобщтите предварително, за да се разберем за някакъв час.

Търся си вероятностно разпределение, което да отговаря на следните условия:

1. да взима за параметри математическото си очакване и стандартното си отклонение
2. да е в интервала [0, inf) или [параметър, inf)
3. вероятностната (не кумулативната :) ) му функция да не е строго намаляваща, ами да прилича малко на Chi-square - да расте и после да намалява безкрайно

Написах си един Chi-square, ама не ми върши - трябва ми и контрол върху стандартното отклонение

Идеи ?

Ще пуснем някакъв примерен график, за да не висите ей така. Има вероятност да почнем преди 3, навън пред ФМИ, защото наистина времето е малко. Ако разполагате с лаптоп най-добре си го донесете.

Честно казано, далеч съм от мисълта, че обявяването на дата за защита 2 дена по-рано е коректно.

ПП: благодаря

"комерсиално" май е неточна дума. Идеята е следната: Написали сте нещо на питон. Искате познати / приятели / клиенти да могат да го ползват. Но те нямат питон на компютрите си, а и са разглезени и искат .exe :):):)

Как се нарича това? И къде мога да почета как да го направя ?

Граничен случай, hence Disclaimer 1 ("еволюционно неоптимална стратегия" покрива както личните, така и общите(социалните) импликации при нарушаването на Нашовото равновесие)

Ако сега подадеш молба за общежитие и вътре излъжеш, че изпита си го взел с 6-ца (примерно), никой няма да провери на момента. Тая проверка се прави най-рано октомври месец, когато си изваждаш удостоверение за успех от ФМИ и го носиш в студентски. Ерго имаш 2 опита (сега и септемврийска сесия) да добуташ оценката, която си декларирал. Освен това никога (по някакво тяхно си правило) не правят проблем, ако си декларирал по-НИСКА оценка, отколкото пише на удостоверението. С други думи, ако излъжеш, че изпита си го взел с 4-ка, а ти го вземеш с 5 или 6 примерно, светът е цветя и рози

Disclaimer:

1. в повечето случаи лъжата е еволюционно неоптимална стратегия. Не се препоръчва при наличие на алтернатива (не е ли забавно как можеш да сведеш етика и морал до математика ? :):):))
2. животът в софийския лас вегас също е еволюционно неоптимална стратегия (а.к.а. превръща те в алкохолизиран идиот). Препоръчва се още по-малко :)

Понякога е трудно днес да кажеш, че утре или дригиден ще отсъстваш от работа и да те пуснат...

'да е възможно да се добавят лесно други формати за вход въпросите (да се четат от база от данни, JSON или YAML например)'

Тия неща аз ли трябва да реализирам, или просто трябва да спазвам някакви дизайнерски принципи и добавянето на нова функционалност да е лесно? """

*bump

Т.е търсенето, примерно, да се реализира горе-долу така:

>>> search('Label1', 'Label2', ..., type='Note', text='Part of the text in the note')

Като разбира се съответната фунцкионалност е подкрепена от лесно достъпен и достатъчно описателен HELP

По този начин избягваме директното четене от клавиатурата и главоболията свързани с визуализирането на цялата работа.

Освен това статистиката показва, че шанса да имате 30 от 30 на теста е много по-голям ако се казвате Николай. Да знаете за догодина.

Сега бачка бързо и компресира повече, само че е за сметка на RAM-а.

for i in range(len(buffer))
    buffer[b:b+1]

Постигна ли заветните 29.999999%? :-|

...
buffer = f.read(1024*1024)
for i in buffer:
    b = int_to_byte[i]
    ...

По този начин можеш да се обходи много бързо файла, но за съжаление i` е от тип `int. Затова предварително създадох речник от 256 елемента, който ми map-ва на всяко число съответстащия байт. И сега работата с байтове е доста по-лека от това да се правят разни списъци и прочие.

file.read() и file.write() заемат основната част от времето. Каквото и кеширане да измислям не става много по-бързо. Дефакто скоростта е 3 S/MB, което значи, че 700MB ще е ~35min. Това при условие, че се ползва едното ядро на 4200+. Доста зле ми изглежда.

Компресията е от рода на 35%. Ползвам 64K речник и записвам цели двубайтови кодове. Поне е лесно, ако не друго.

Просто вече се чудя какво да измислям, но пък поне още мога да мисля. :-D

import struct
...
for i in f.read():
    b = struct.pack('B', i)
    ...
    l = len(b)
    ...
    outfile.write(b)
...

го направете така:

import struct
...
pack = struct.pack
ln = len
write = output.write
for i in f.read():
    b = pack('B', i)
    ...
    l = ln(b)
    ...
    write(b)
...

По-късно може да постна и други дребни хитринки за ускоряване.

За колко време приблизително комресирате 50 мб файл?

b = bytes([1, 2, 3])
b += f.readbyte(1) # или ползваш някакъв array

Проблемът с бързодействието при мен се оказа, че е най-вече заради четене и записване на по 1 байт, а също така и евентулно chr() и len(). Лесно се вижда, ползвай cProfile. Пример:

import cProfile

def compress(file_in, file_out):
    ....

cProfile.run("compress('myfile', 'myfile.lzw')")

1. Preprocessing на XML файлове с цел съкращаване на имена не бива да се прави. Нали същото се опитва да направи и LZ? Кодът ще стане боза.

2. Размерът на файла се определя от крайните байтове, които записваш и в този смисъл Bit Reduction ще е полезен. Без работа с битове няма да се мине, казвам ти. То дефакто това реално е половината от идеята.

Huffman може доста да намали нещата в някои случаи. Примерно при Deflate имаме две huffman дървета, където distance offset-а е 0-32k. Тия числа можеш да ги заместиш с по-кратки кодове.

Проблемът с Huffman е, че трябва да работиш с битове, което не е съвсем удобно. Аз не виждам никакъв друг начин да слезем до 30%, освен с Dictionary + Bit Reduction и най-простия начин за реализация ми се струва LZW+Huffman.

От друга страна с LZW с variable-width codes стана 29.7% :-D Това поне прави unix-кия compress и се замислям доста по въпроса...