похоже на происки конкурентов ) почитав блог я выяснил, что с ниссан лиф такого никогда не может случится )
судя из разъяснений оказывается: батареи теслы саморазряжаются (как и все другие батареи в мире) и через несколько месяцев сработает система защиты и машина превратится в кирпич. Надо будет ее буксировать до ближайшей розетки, чтобы зарядить батареи и перезагрузить систему управления батареей.
но полного разряда лучше не допускать никогда, вредно для банок.
ИМХО специальная док станция это ничто иное как обычный USB hub.
Of course, your phone needs the docking capability and hardware support for HDMI and USB. But that’s standard for high-end models in the current generation of devices in development.
монитор втыкаем в hdmi, а док станция должна давать питание на телефон и обеспечить пару разъемов USB, чтобы воткнуть клаву и мышку.
даешь фотошоп и Unity 3d и Corona SDK — только изза этого пересел с нее на OsX
Убунта и так уже в массах. Много народу пользуется, знаю даже несколько офисов с манагерами, которые успешно сидят на убунте )
Если закрыть глаза на редкие несовместимости OpenOffice и MS Office — убунту отличный вариант для неиграющих людей )
ну эйр тоньше уже особо не сделаешь, в новый эйр разве что экран новый воткнут и чуть причешут…
а вот из прошки обещают выкинуть двд, поставить ссд, новые процы и экран тоже получше (будет почти эйр, но с портами и посолидней)
сделав профайлинг PGO должен был увидеть, что вы запоняете массив одними и теми же числалами и сразу выдавать правильный результат сортировки )
а по делу:
графики не очень информативны, особенно тот где надо смотреть на занимаемую цветом площадь, хорошо бы 1 картинку из которой сразу все тренды
почему вы собираете проект без -O3 хорошо бы сравнить, только оптимизации по-умолчанию (-O0), -O3( возможно еще и 1-2), PGO и PGO+-O3, тогда можно сказать: «Вот добавили PGO и это нам дало дополнительные Х процентов к уже оптимизированному коду -O3»
Зачем изобретать велосипед? есть же библиотеки для этого…
вот это место непойдет: while (l!=r){
c = (l+r) >> 1;
if (wheel[c]<index){
l=c;
}else{
r=c;
}
}
задача бинарным поиском найти максимальный индекс элемента в массиве wheel, значение которого меньше переменной index
а вы находите непонятно что, вы смотрите только элементы в середине отрезков, и если значение элемента в середине предыдущего отрезка меньше, а в середине следующего отрезка больше index, вы считаете, что середина предыдущего отрезка это наш искомый элемент и берете его индекс… но это неправильно, это не рулетка.
а еще эта штука иногда зацикливается, например если:
wheel = [1; 1000];
r = 1; l =0; index = 900; c =0;
то из вашего while мы никогда не выйдем
судя из разъяснений оказывается: батареи теслы саморазряжаются (как и все другие батареи в мире) и через несколько месяцев сработает система защиты и машина превратится в кирпич. Надо будет ее буксировать до ближайшей розетки, чтобы зарядить батареи и перезагрузить систему управления батареей.
но полного разряда лучше не допускать никогда, вредно для банок.
монитор втыкаем в hdmi, а док станция должна давать питание на телефон и обеспечить пару разъемов USB, чтобы воткнуть клаву и мышку.
Убунта и так уже в массах. Много народу пользуется, знаю даже несколько офисов с манагерами, которые успешно сидят на убунте )
Если закрыть глаза на редкие несовместимости OpenOffice и MS Office — убунту отличный вариант для неиграющих людей )
без андройда не обойтись
вот это очень хорошо, особенно если они в МакОсХ будут всегда работать )
а вот из прошки обещают выкинуть двд, поставить ссд, новые процы и экран тоже получше (будет почти эйр, но с портами и посолидней)
а по делу:
графики не очень информативны, особенно тот где надо смотреть на занимаемую цветом площадь, хорошо бы 1 картинку из которой сразу все тренды
почему вы собираете проект без -O3 хорошо бы сравнить, только оптимизации по-умолчанию (-O0), -O3( возможно еще и 1-2), PGO и PGO+-O3, тогда можно сказать: «Вот добавили PGO и это нам дало дополнительные Х процентов к уже оптимизированному коду -O3»
вот это место непойдет:
while (l!=r){
c = (l+r) >> 1;
if (wheel[c]<index){
l=c;
}else{
r=c;
}
}
задача бинарным поиском найти максимальный индекс элемента в массиве wheel, значение которого меньше переменной index
а вы находите непонятно что, вы смотрите только элементы в середине отрезков, и если значение элемента в середине предыдущего отрезка меньше, а в середине следующего отрезка больше index, вы считаете, что середина предыдущего отрезка это наш искомый элемент и берете его индекс… но это неправильно, это не рулетка.
а еще эта штука иногда зацикливается, например если:
wheel = [1; 1000];
r = 1; l =0; index = 900; c =0;
то из вашего while мы никогда не выйдем