Хм, Яндекс.Карты тогда были другими, так себе :) Да и в офлайн поиск POI не работал. А в командировке иногда так надо найти подходящий трамвай/автобус или продуктовый магазин. Еще все-таки Яндекс на постсоветское пространство специализирован.
OsmAnd использует OpenStreetMap со всех возможных сторон. Баги, рендеринг, редактирование OSM, создание различных индексов, различные тайловые рендеринги.
Приведите примеры ) Я достаточно долго изучал, наделся, что AndNav2 стартанет или Navit поменяет стратегию. А остальные вообще ориентировались на растр.
Согласен, но Куба, маленькая страна. В OsmAnd векторные данные Кубы занимают 2Мб, что означает, что отрисовываться будет относительно быстро. Поиск же будет работать и в офлайн на векторных данных.
Суть в другом, что если взять такие страны, как Германия, Испания, векторные данные будут превышать 100Мб, а то и больше, соотвественно и работа по обработке файлов тяжело сказывается на мобильном устройстве.
ИМХО, использовать лучше сочетание этих 2 видов карт )
RMaps — растровые карты, что заметно (!) больше занимает места на карточке. Да и с растровыми картами, такие функции как поиск POI, поиск по адресу недоступны.
Хотя в андроиде действительно есть аналоги MapDroyd, Osmand, Skobbler(?).
RMaps по-моему не совсем то приложение, что имеется в виду, потому что карты там растровые, что заметно (!) больше занимает места на карточке. Да и с растровыми картами, такие функции как поиск POI, адреса недоступны.
Хотя в андроиде действительно есть аналоги MapDroyd, Osmand, Skobbler(?).
Само понятие «математическое ожидание» это всего лишь абстракция, которая формализует понятие «среднего выигрыша».
Если бы вам сказали, что вероятность выигрыша 99.9999, вы бы рискнули? ;)
Возможно и даже не спросили мат. ожидание. Хотя максимальный выигрыш 1000, а проигрыш 2^1000
Да, опять руки подвели, неправильно посчитал вероятность события, что выигрыш больше 0. Вероятность для 2 ну явно больше 0.
Не вручную считаю, а программу написал, могу для проверки показать.
Но если на все это посмотреть с другой стороны, математика она же инструмент, то математическое ожидание не так уж и важно )
Рассмотрим вероятность того, что после игры в N ходов ты остаешься в выигрыше.
N=2 Вероятность 0
N=3 Вероятность 0.25
N=4 Вероятность 0.375
N=5 Вероятность 0.438
N=6 Вероятность 0.5
N=7 Вероятность 0.562
N=8 Вероятность 0.617
N=9 Вероятность 0.66
N=10 Вероятность 0.691
N=11 Вероятность 0.714
N=12 Вероятность 0.731
N=13 Вероятность 0.747
N=14 Вероятность 0.763
N=15 Вероятность 0.779
N=16 Вероятность 0.796
N=17 Вероятность 0.811
N=18 Вероятность 0.825
Как видим вероятность растет и приближается к 1 )))
Ошибка была в расчетах, для 3 тоже 0. В общем написал программу, посчитал до 25 везде ожидание 0, но доказывать лень) Можно принять что ожидание 0.
Суть стратегии состоит как раз не в том, чтобы заранее знать когда закончить, а чтобы акцентировать усилия на минимальных возможностях проиграть.
Так выигрыши малы, но их очень много (!), а проигрыши маловероятны, но зато до 100 хода проигрыш может составлять 2^100, но и вероятность этого сами представляете какая)
Чего же не посчитать, посчитаем ) Даже интересно.
1. Возьмем, что человек будет играть до 3-х попыток.
000 — -7, 001 — +1, 010 — 0, 011 — +1, 100 — -2, 101 — +2, 110 — +1, 111 — +3.
Матетическое ожидание = -1/8
2. Возьмем, что человек будет играть до 2-х попыток.
00 — -3, 01 — +1, 10 — 0, 11 — +2.
Матетическое ожидание = 0.
Да и казино же не выигрывает за счет матвероятности, оно точно так же играет в 0. За исключением сектора «зеро», на котором оно как раз и зарабатывает.
Странные какие то люди пошли. Все магистры, а объяснить толком не могут.
Да скорее всего нет такой теоремы, что нельзя выиграть при бросании монетки. Так еще определить, что это за игра с монеткой достаточно сложно (их же много :) ), а в математике с теорией игр все достаточно сложно.
Я не совсем понял почему с арифмитической прогрессией выигрышная стратегия и поигрывавшись с кодом могу сказать, что математическое ожидание скорее всего 0 или я не правильно что-то понял. private static void arithStrategy() {
Random rnd = new Random();
int exp = 100;
int sumValue = 0;
for (int i = 0; i < exp; i++) {
int value = 0;
int bid = 1;
int astep = 3;
int steps = 10000;
while (steps-- > 0) {
boolean res = rnd.nextBoolean();
if (res) {
value += bid;
bid += astep;
} else {
value -= bid;
bid = 1;
}
}
sumValue += value;
}
System.out.println(sumValue/exp);
}
Зато знаю другой вариант выигрышной стратегии. Это если выигрываешь ставишь 1 в следующий раз, если проигрываешь в 2 раза больше. Предполагаю (!), что эта стратегия дает математическое ожидание половину от числа розыгрышей. Код на Java попробуйте сами :) private static void winStrategy() {
Random rnd = new Random();
int exp = 1000;
int sumValue = 0;
for (int i = 0; i < exp; i++) {
int value = 0;
int bid = 1;
int steps = 10000;
while (steps-- > 0) {
boolean res = rnd.nextBoolean();
if (res) {
value += bid;
bid = 1;
Идея действительно потрясающая )
Скажите, а почему грузится vmlinux.bin, root.bin, linuxstart.bin? Может же грузится только жесткий диск (hardware.img) и загрузка начинаться именно с жесткого диска?
Если бы это был только один файл системы, то возможно было бы немного модифицировать клиентский JS код, чтобы загружать с какого-то своего жесткого диска, с ftp, к примеру.
А еще лучше, можно было делать hibernate и обмениваться (сохранять, загружать) жесткие диски.
Насчет помочь конечно можно :) Только думаю не с роутингом и так уже достаточно людей занимается для начальной стадии функционала. Зато с рендерингом может понадобится помощь. Дело в том, что большая часть векторного рендеринга взята из Mapnik, что соответственно не есть хорошо к примеру для автомобильной навигации. На неделях будет расшарен xml файл в котором можно менять рендеринг соответственно стоит задача построить ночной рендеринг, для автомобилей, для велосипедов и другие + разные комбинации.
Другое улучшение в том, что существуют страны в которых слишком много данных (Голландия, Германия) естественно, что для автомобильного рендеринга они все не нужны, соответственно можно выделить правила (xml файл) на основании, которых часть данных будет попадать в векторную карту, что позволит уменьшить размер карты и отрисовывать маленькие зумы 6-10 (все объекты невозможно загрузить в память из-за ограничений android)
Роутинг в плохом состоянии (его нету и он только планируется) ) Возможно бинарных индексов версии 0.5 будет достаточно для роутинга. Кэшируются только файлы картинки, по ним вообще ничего не расчитать. Алгоритм поиска простой, но как всегда дьявол в деталях. На мобильном устройстве есть ограничения по памяти и по быстродействию.
К сожалению OsmAnd не умеет прокладывать даже маршрут для автомобиля offline. А прокладка с учетом общественного транспорта, еще более сложная задача, чаще всего для этого лучше учитывать расписание (так на метро можно доехать в 5 раз быстрее, чем на автобусе по одному и тому же маршруту).
В OsmAnd есть полуавтоматический поиск маршрута, в принципе пользуясь простым правилом, все время продвигаться на транспорте ближе к цели — транспорт так и сортируется в OsmAnd :) можно спланировать маршрут отличающийся на 20-30% от оптимального.
Да и вообще думаю кроме как по офлайн картам, сравнивать их достаточно некорректно.
Суть в другом, что если взять такие страны, как Германия, Испания, векторные данные будут превышать 100Мб, а то и больше, соотвественно и работа по обработке файлов тяжело сказывается на мобильном устройстве.
ИМХО, использовать лучше сочетание этих 2 видов карт )
Хотя в андроиде действительно есть аналоги MapDroyd, Osmand, Skobbler(?).
Хотя в андроиде действительно есть аналоги MapDroyd, Osmand, Skobbler(?).
Если бы вам сказали, что вероятность выигрыша 99.9999, вы бы рискнули? ;)
Возможно и даже не спросили мат. ожидание. Хотя максимальный выигрыш 1000, а проигрыш 2^1000
Не вручную считаю, а программу написал, могу для проверки показать.
Приведу тогда статистику для события, что выигрыш >= 0.
N=2 Вероятность 0.75
N=3 Вероятность 0.75
N=4 Вероятность 0.75
N=5 Вероятность 0.781
N=6 Вероятность 0.812
N=7 Вероятность 0.836
N=8 Вероятность 0.852
N=9 Вероятность 0.861
N=10 Вероятность 0.868
N=11 Вероятность 0.875
N=12 Вероятность 0.882
N=13 Вероятность 0.89
N=14 Вероятность 0.898
N=15 Вероятность 0.906
N=16 Вероятность 0.913
N=17 Вероятность 0.919
N=18 Вероятность 0.924
Рассмотрим вероятность того, что после игры в N ходов ты остаешься в выигрыше.
Как видим вероятность растет и приближается к 1 )))
Суть стратегии состоит как раз не в том, чтобы заранее знать когда закончить, а чтобы акцентировать усилия на минимальных возможностях проиграть.
Так выигрыши малы, но их очень много (!), а проигрыши маловероятны, но зато до 100 хода проигрыш может составлять 2^100, но и вероятность этого сами представляете какая)
1. Возьмем, что человек будет играть до 3-х попыток.
000 — -7, 001 — +1, 010 — 0, 011 — +1, 100 — -2, 101 — +2, 110 — +1, 111 — +3.
Матетическое ожидание = -1/8
2. Возьмем, что человек будет играть до 2-х попыток.
00 — -3, 01 — +1, 10 — 0, 11 — +2.
Матетическое ожидание = 0.
Смотрите ниже
Да скорее всего нет такой теоремы, что нельзя выиграть при бросании монетки. Так еще определить, что это за игра с монеткой достаточно сложно (их же много :) ), а в математике с теорией игр все достаточно сложно.
Я не совсем понял почему с арифмитической прогрессией выигрышная стратегия и поигрывавшись с кодом могу сказать, что математическое ожидание скорее всего 0 или я не правильно что-то понял.
private static void arithStrategy() {
Random rnd = new Random();
int exp = 100;
int sumValue = 0;
for (int i = 0; i < exp; i++) {
int value = 0;
int bid = 1;
int astep = 3;
int steps = 10000;
while (steps-- > 0) {
boolean res = rnd.nextBoolean();
if (res) {
value += bid;
bid += astep;
} else {
value -= bid;
bid = 1;
}
}
sumValue += value;
}
System.out.println(sumValue/exp);
}
Зато знаю другой вариант выигрышной стратегии. Это если выигрываешь ставишь 1 в следующий раз, если проигрываешь в 2 раза больше. Предполагаю (!), что эта стратегия дает математическое ожидание половину от числа розыгрышей. Код на Java попробуйте сами :)
private static void winStrategy() {
Random rnd = new Random();
int exp = 1000;
int sumValue = 0;
for (int i = 0; i < exp; i++) {
int value = 0;
int bid = 1;
int steps = 10000;
while (steps-- > 0) {
boolean res = rnd.nextBoolean();
if (res) {
value += bid;
bid = 1;
} else {
value -= bid;
bid = bid * 2;
}
}
sumValue += value;
}
System.out.println(sumValue/exp);
}
Скажите, а почему грузится vmlinux.bin, root.bin, linuxstart.bin? Может же грузится только жесткий диск (hardware.img) и загрузка начинаться именно с жесткого диска?
Если бы это был только один файл системы, то возможно было бы немного модифицировать клиентский JS код, чтобы загружать с какого-то своего жесткого диска, с ftp, к примеру.
А еще лучше, можно было делать hibernate и обмениваться (сохранять, загружать) жесткие диски.
Другое улучшение в том, что существуют страны в которых слишком много данных (Голландия, Германия) естественно, что для автомобильного рендеринга они все не нужны, соответственно можно выделить правила (xml файл) на основании, которых часть данных будет попадать в векторную карту, что позволит уменьшить размер карты и отрисовывать маленькие зумы 6-10 (все объекты невозможно загрузить в память из-за ограничений android)
Смотрите за объявлениями на сайте
В OsmAnd есть полуавтоматический поиск маршрута, в принципе пользуясь простым правилом, все время продвигаться на транспорте ближе к цели — транспорт так и сортируется в OsmAnd :) можно спланировать маршрут отличающийся на 20-30% от оптимального.