igushev

The article is about startups mostly. There’re lots of non-technical founders who think they can outsource everything and build a company and it won’t work. I tried to provide some guidelines in the article.

If someone interested to learn more or collaborate, happy to chat!

https://github.com/igushev/fase_lib — Fase library to develop the server of a Fase Service;

https://github.com/igushev/fase_ios — iOS client for a Fase Service;

https://github.com/igushev/fase_android — Android client for a Fase Service;

Examples of Fase Services:

https://github.com/igushev/notes_fase — Saves and synchronizes notes.

Any feedback is welcomed!

I also found out about tiered vectors only in this thread. At the time of implementation I tried to Google for something like this but didn't find.

I mentioned that extension in the published paper, but complexity of access becomes O(d) where d is number of dimensions.

Yes, the structure is sensitive for that and benefits a lot from using reserve(). I need to add automatic restructuring to maintain perfect k.

It seems I need to add automatic restructuring to the structure, so it would maintain perfect lengths of DEQs

I also need to add automatic restructuring when it expands or shrinks significantly.

Thanks for feedback!

There is a disclaimer about that: https://github.com/igushev/IgushArray#limitations

Interesting that some people found an article about tiered vectors, I didn't find it back then. I implemented this structure many many years ago and also published in Bauman Moscow State Technical University magazine back in 2012: http://engjournal.ru/articles/101/101.pdf (in Russian)

That is true. The complexities in Big O notations, but I put all real-life measurements in README.md, so readers could see. On small item counts the complexity of data structure itself makes it performs worse comparing to std::vectors, only on large item counts it performs betters. Note that access is slower then std::vector due to complexity of data structure but multiplier is always the same.

That's a good point. That would make computation of indexes much more complicated though

That sounds like trees are silver bullets but they're not and that's why we have variety of basic data structures.

Thanks for feedback! Any naming suggestions? :-)

Thanks for feedback! I’ll update the README.md

DEQs also allocate internal arrays with hardcoded size only (8 in std, if I remember correctly)

I need to read the paper, but on high-level looks indeed similar.

Correct. I need to add automatic restructuring. Currently structure sensitive and benefits a lot from using reserve() method

DEQ has floating starting index. When you push or pop, you just changing this index. The implementation in the repository also have custom implementation of DEQs which is even more optimized for this structure.

Insertion and deletion from DEQ indeed is linear, but in all of DEQs in the structure only one (!) needs insertion, the rest are just popping/pushing front/back.

At the time I was making research, I found one or two, don’t recall from top of my head. Majority of travel apps focus on hotels and/or tickets, not points of interest. The one which focus on points of interest, usually tries to give user most interesting, but not entire schedule.

Also part of functionality which I wanted to add, is to for user to check what stage he/she at given moment and app would adjust the schedule, for example, user can’t make it today for museum A therefore it rescheduled for tomorrow and today just go to point of interest B. Schedule is supposed to adapt during trip.

Moreover, app is supposed to learn about you, like speed of walk, duration of lunch, etc.

During real live testing I found that it might be appealing to follow this kind of schedule, since there is no need for decision making. I realized why tour buses and cruise ships are popular.

P.S. If someone wants to build real app, I was looking for someone to collaborate or for co-founders. Although haven’t touch for few years, it’s still interesting idea.

P.S. Business model was quite straightforward: reselling tickets to attractions.

No, it’s too big for an interview exercise :-)

I started the startup during mobile revolution and had the idea of an app which by given dates and parameters would optimize your time and give perfect trip. I spent too much time building and perfecting algorithm and backend and making live tests and space became very crowded and saw few websites and apps doing similar thing, so I decided to move on. It was idle for few years and recently decided to just open source. Maybe someone would like to use or collaborate.

Please reach out to me and see if I can help or even collaborate.