Kazan (Volga region) Federal University, KFU
KAZAN
FEDERAL UNIVERSITY
Ziyatdinov Mansur Tagirovich
Ziyatdinov Mansur Tagirovich
Date of birth 
15.03.1989
Positions 
Files 
Research work 
Performance 
Performance 
2019
2018
2017
2016
2014
2013
Events 
2019
2018
2017
2015
2014
2010

Just the place for a Snark!

Темы курсовых/дипломных работ

LARS and Complex Event Processing

Сложность: высокая. Язык: Haskell. Выбрано: нет.

LARS - A Logic-based Framework for Analytic Reasoning over Streams

See Luigi Bellomarini, Georg Gottlob, Andreas Pieris, and Emanuel Sallinger. Swift Logic for Big Data and Knowledge Graphs - Overview of Requirements, Language, and System // SOFSEM 2018 Proceedings (можно получить доступ у меня по запросу)

Задача обработки сложных запросов над потоками стала актуальной с появлением большого количества данных, например, от IoT и в будущем будет лишь становиться актуальнее с развитием информатизации общества.

В работе необходимо будет реализовать на Haskell (прототип) системы - языка программирования для рассуждений о потоках - представленной на SOFSEM 2018, и добавить в неё возможность обработки сложных запросов.

Cascase Heap Implementation in Haskell

Сложность: высокая. Язык: Haskell. Выбрано: нет.

Cascade Heap реализует структуру кучи с обычными для куч параметрами временной сложности и одним дополнительным: время получения $k$ минимальных элементов из кучи из $n$ элементов равно $O(k)$.

В работе необходимо будет реализовать на Haskell структуру Cascade Heap, провести необходимые benchmarks и сравнить имеющиеся реализации с Cascade Heap.


QISKit for ejudge and olympiads

Сложность: средняя. Язык: не слишком важен. Выбрано: нет.

Написать наиболее простое корректно работающее и поддерживаемое решение для возможности реализации олимпиад по квантовой информатике на базе QISKit от IBM и, вероятно, ejudge.

Propp

Сложность: выше средней. Язык: Haskell (?). Выбрано: нет.

Аналогично статье Miroslava Hrešková and Kristína Machová. Models used in Automated Haiku Poetry Generation // SOFSEM 2018 Proceedings (можно получить доступ у меня по запросу), детали будут добавлены позже.

Pirozhki generation

Сложность: выше средней. Язык: Haskell (?). Выбрано: нет.

Аналогично статье Miroslava Hrešková and Kristína Machová. Models used in Automated Haiku Poetry Generation // SOFSEM 2018 Proceedings (можно получить доступ у меня по запросу), рассмотреть модели и написать ПО генерации стишков-пирожков

Science of Science: case study of Russia

Сложность: выше средней. Язык: Python, R, Haskell (?). Выбрано: нет.

Аналогично статье Antonia Gogoglou, Theodora Tsikrika, Yannis Manolopoulos. Network Analysis of the Science of Science: A Case Study in SOFSEM Conference // SOFSEM 2018 Proceedings (можно получить доступ у меня по запросу) изучить статьи, опубликованные в КФУ, в России и т.д., кластеризовать их по влиянию аффилиации, страны, положения в сети соавторства и прочих признаков на "импакт" - влияние статьи, количество её цитирований и т.п. Выделить возможные кластеры по временному распределению цитирований.

Science of Science: case study of pseudoscience

Сложность: выше средней. Язык: Python, R, Haskell (?). Выбрано: нет.

Аналогично статье Antonia Gogoglou, Theodora Tsikrika, Yannis Manolopoulos. Network Analysis of the Science of Science: A Case Study in SOFSEM Conference // SOFSEM 2018 Proceedings (можно получить доступ у меня по запросу) изучить "статьи", публикуемые в области каких-либо псевдо- или лженаук, кластеризовать их по влиянию аффилиации, страны, положения в сети соавторства, временному распределению цитирований и прочих признаков. Сравнить с имеющимися данными по научным статьям.

Property Testing with Context

Сложность: выше средней. Язык: Haskell. Выбрано: нет.

From: Ben Franksen
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] property testing with context
Date: Fri, 19 Oct 2018 09:19:35 +0200 (9 hours, 29 minutes, 29 seconds ago)

Hi everyone

it seems to be the season for new variations on the "property testing"
theme, so I would like to chime in... not to announce a new library,
sadly, but with a rough idea how the existing ones could perhaps be
improved, based on practical experience in Darcs.

The problem I have is that there is a tension between

(a) stating a property in a clear and simple way, so its code doubles as
a formal specification

and

(b) writing the property in such a way that when it fails, the reported
value(s) give enough information about the context to be useful for
finding the cause of the problem.

Let me give an example to demonstrate what I mean.

There is a simple law that says if a sequential pair of patches A;B
commutes to B';A' then B';A' commutes back to A;B. In code this looks
(more or less) like this:

prop_recommute :: Commute p => (p :> p) wA wB -> Bool
prop_recommute (x:>y)
  | Just (y':>x') <- commute (x:>y) =
      case commute (y':>x')of
        Just (x'':>y'') -> x==x'' && y==y''
        Nothing -> False
  | otherwise = True

This is a bit more verbose than the informal spec but still quite readable.

Now suppose this property fails. So quickcheck reports the counter
example pair (X:>Y) for some X and Y. But that isn't too useful in
itself. We'd like to know a bit more:

 * did the second commute fail?
 * or did it succeed but x/=x'' or y/=y''?
 * and in the latter case, which of the two?

So in practice our property code looks more like this:

prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool
prop_recommute (x :> y)
  | Just (y' :> x') <- commute (x :> y) =
      case commute (y' :> x') of
        Nothing ->
          failed (redText "failed, where x" $$ displayPatch x $$
                  redText ":> y" $$ displayPatch y $$
                  redText "y'" $$ displayPatch y' $$
                  redText ":> x'" $$ displayPatch x')
        Just (x'' :> y'') ->
          if y'' /= y
            then
              failed (redText "y'' =/\\= y failed, where x" $$
                      displayPatch x $$
                      redText ":> y" $$ displayPatch y $$
                      redText "y'" $$ displayPatch y' $$
                      redText ":> x'" $$ displayPatch x' $$
                      redText "x''" $$ displayPatch x'' $$
                      redText ":> y''" $$ displayPatch y'')
            else
              if x'' /= x
                then
                  failed (redText "x'' /= x, where x" $$
                          displayPatch x $$
                          redText ":> y" $$ displayPatch y $$
                          redText "y'" $$ displayPatch y' $$
                          redText ":> x'" $$ displayPatch x' $$
                          redText "x''" $$ displayPatch x'' $$
                          redText ":> y''" $$ displayPatch y'')
                else True
  | otherwise = True

Now this code tells us exactly what went wrong when the property fails
but it is ugly and repetitive and the additional code obscures the
simple logical content. So this is no longer quite as suitable for a
(human readable) formal spec.

I wonder if displaying

(1) all relevant contextual variables and
(2) "where in the code it fails"

could be automated away, somehow. I guess this is not trivial and may
require syntactic analysis, so perhaps expecting a /library/ to solve
the problem is unrealistic, except perhaps by using Template Haskell.
I'd also go with a separate tool that extracts properties from a module
and enriches them with code that displays the additional information.

 

Ещё: GSoc Haskell 2018

 

 

Дистанционное образование

Прекратить думать, что "интернет-уроки" это то же самое, что и в классе, только через интернет. Нет — это другое. Например, вполне можно отказаться от "он-лайн лекции", когда учитель в интернете рассказывает что-то точно так же, как и в классе. Эту методику вполне заменяет одна ссылка на видеозапись.

И да — текущий кризис покажет, что дистанционное обучение вполне возможно, и что оно будет ничуть не хуже, чем "классическое". И да — пора пересматривать вообще все образовательные процессы и подходы. А когда еще-то? Именно в такие кризисы и проявляется никчемность огромных инертных систем, оставшихся неизменными с XIX века.

@ZaTelecom, https://t.me/zatelecom/14198

 

Ссылки для присоединения к курсам по предметам:

2019/20, весна

2020/21, осень

Taught disciplines 
Discipline Curriculum Authors File
Функциональное программирование  230700.62 Applied computer scince , Bachelor's Degree (Nonapplicable) 2012 y. Зиятдинов М.Т.
Функциональное программирование  230700.62 Applied computer scince , Bachelor's Degree (Nonapplicable) 2011 y. Зиятдинов М.Т.
Функциональное программирование  230700.62 Applied computer scince , Bachelor's Degree (Nonapplicable) 2013 y. Зиятдинов М.Т.
Функциональное программирование  09.03.03 Applied Computer Sciences, Bachelor's Degree (не предусмотрено) 2014 y. Зиятдинов М.Т.
Функциональное программирование  09.03.03 Applied Computer Sciences, Bachelor's Degree 2012 y. Зиятдинов М.Т.
Функциональное программирование  09.03.04 Software Engineering, Bachelor's Degree (Industrial software development) 2017 y. Голицына И.Н.
Зиятдинов М.Т.
Функциональное программирование  09.03.04 Software Engineering, Bachelor's Degree (Industrial software development) 2020 y. Зиятдинов М.Т.
Функциональное программирование  09.03.03 Applied Computer Sciences, Bachelor's Degree (Прикладная информатика в экономике) 2013 y. Зиятдинов М.Т.
Функциональное программирование  09.03.03 Applied Computer Sciences, Bachelor's Degree (не предусмотрено) 2015 y. Зиятдинов М.Т.
Функциональное программирование  09.03.04 Software Engineering, Bachelor's Degree (Industrial software development) 2019 y. Голицына И.Н.
Зиятдинов М.Т.
Функциональное программирование  09.03.04 Software Engineering, Bachelor's Degree (Industrial software development) 2016 y. Голицына И.Н.
Зиятдинов М.Т.
Функциональное программирование  09.03.04 Software Engineering, Bachelor's Degree (Industrial software development) 2018 y. Голицына И.Н.
Зиятдинов М.Т.
Функциональное программирование  09.03.03 Applied Computer Sciences, Bachelor's Degree (не предусмотрено) 2013 y. Зиятдинов М.Т.
Experience:
 5 г 11 м 13 д   from 02.09.2013
Scientific and pedagogical experience:
 8 г 1 м 17 д   from 16.08.2010
General experience:
 11 г 5 м 27 д   from 02.07.2007
Experience in KFU:
 4 г 5 м 3 д   from 01.10.2016