Численная проверка abc-гипотезы (да, той самой)

Привет habr.

На geektimes habr было уже несколько статей про abc-гипотезу (например в 2013 и в 2018 годах). Сама история про теорему, которую сначала много лет не могут доказать, а потом столько же лет не могут проверить, безусловно заслуживает как минимум, художественного фильма. Но в тени этой чудесной истории, сама теорема рассматривается черезчур поверхностно, хотя она не менее интересна. Уже хотя бы тем, что abc-гипотеза — одна из немногих нерешенных проблем современной науки, постановку задачи которой сможет понять даже пятиклассник. Если же эта гипотеза действительно верна, то из нее легко следует доказательство других важных теорем, например доказательство теоремы Ферма.

Не претендуя на лавры Мотидзуки, я тоже решил попробовать решил проверить с помощью компьютера, насколько выполняются обещанные в гипотезе равенства. Собственно, почему бы нет — современные процессоры ведь не только для того чтобы в игры играть — почему бы не использовать компьютер по своему основному (compute — вычислять) предназначению…

Кому интересно что получилось, прошу под кат.

Постановка задачи

Начнем с начала. О чем собственно, теорема? Как гласит Википедия (формулировка в английской версии немного более понятна), для взаимно-простых (не имеющих общих делителей) чисел a, b и с, таких что a+b=c, для любого ε>0 существует ограниченное число троек a+b=c, таких что:

Функция rad называется радикалом, и обозначает произведение простых множителей числа. Например, rad(16) = rad(2*2*2*2) = 2, rad(17) = 17 (17 простое число), rad(18) = rad(2*3*3) = 2*3 = 6, rad(1000000) = rad(2^6 ⋅ 5^6) = 2*5 = 10.

Собственно, суть теоремы в том, что количество таких троек довольно мало. Например, если взять наугад ε=0.2 и равенство 100+27=127: rad(100) = rad(2*2*5*5) = 10, rad(27)=rad(3*3*3)=3, rad(127) = 127, rad(a*b*c) = rad(a)*rad(b)*rad© = 3810, 3810^1.2 явно больше 127, равенство не выполняется. Но бывают и исключения, например для равенства 49 + 576 = 625 условие теоремы выполняется (желающие могут проверить самостоятельно).

Следующий ключевой для нас момент — этих равенств, согласно теореме, ограниченное число. Т.е. это значит, что их все можно просто попытаться перебрать на компьютере. В итоге, это дает нам Нобелевскую премию вполне интересную задачу по программированию.

Итак, приступим.

Исходный код

Первая версия была написана на Python, и хотя этот язык слишком медленный для подобных расчетов, писать код на нем легко и просто, что удобно для прототипирования.

Получение радикала: раскладываем число на простые множители, затем убираем повторы, преобразуя массив в множество. Затем просто получаем произведение всех элементов.

def prime_factors(n):     factors = []     # Print the number of two's that divide n     while n % 2 == 0:         factors.append(int(2))         n = n / 2      # n must be odd at this point so a skip of 2 ( i = i + 2) can be used     for i in range(3, int(math.sqrt(n)) + 1, 2):         # while i divides n , print i ad divide n         while n % i == 0:             factors.append(int(i))             n = n / i      # Condition if n is a prime number greater than 2     if n > 2:         factors.append(int(n))     return set(factors)  def rad(n):     result = 1     for num in prime_factors(n):          result *= num     return result 

Взаимно-простые числа: раскладываем числа на множители, и просто проверяем пересечение множеств.

def not_mutual_primes(a,b,c):     fa, fb, fc = prime_factors(a), prime_factors(b), prime_factors(c)     return len(fa.intersection(fb)) == 0 and len(fa.intersection(fc)) == 0 and len(fb.intersection(fc)) == 0 

Проверка: используем уже созданные функции, тут все просто.

def check(a,b,c):     S = 1.2  # Eps=0.2     if c > (rad(a)*rad(b)*rad(c))**S and not_mutual_primes(a, b, c):         print("{} + {} = {} - PASSED".format(a, b, c))     else:         print("{} + {} = {} - FAILED".format(a, b, c))  check(10, 17, 27) check(49, 576, 625) 

Желающие могут поэкспериментировать самостоятельно, скопировав вышеприведенный код в любой онлайн-редактор языка Python. Разумеется, код работает ожидаемо медленно, и перебор всех троек хотя бы до миллиона был бы слишком долгим. Ниже под спойлером есть оптимизированная версия, рекомендуется использовать ее.

Окончательная версия была переписана на С++ с использованием многопоточности и некоторой оптимизации (работать на Си с пересечением множеств было бы слишком хардкорно, хотя вероятно и быстрее). Исходный код под спойлером, его можно скомпилировать в бесплатном компиляторе g++, код работает под Windows, OSX и даже на Raspberry Pi.

Код на С++
// To compile: g++ abc.cpp -O3 -fopenmp -oabc  #include <string.h> #include <math.h> #include <stdbool.h> #include <stdint.h> #include <stdio.h> #include <vector> #include <set> #include <map> #include <algorithm> #include <time.h>  typedef unsigned long int valType; typedef std::vector<valType> valList; typedef std::set<valType> valSet; typedef valList::iterator valListIterator;  std::vector<valList> valFactors; std::vector<double> valRads;  valList factors(valType n) {   valList results;   valType z = 2;   while (z * z <= n) {     if (n % z == 0) {       results.push_back(z);       n /= z;     } else {       z++;     }   }   if (n > 1) {     results.push_back(n);   }   return results; }  valList unique_factors(valType n) {   valList results = factors(n);   valSet vs(results.begin(), results.end());   valList unique(vs.begin(), vs.end());   std::sort(unique.begin(), unique.end());   return unique; }  double rad(valType n) {   valList f = valFactors[n];   double result = 1;   for (valListIterator it=f.begin(); it<f.end(); it++) {       result *= *it;   }   return result; }  bool not_mutual_primes(valType a, valType b, valType c) {   valList res1 = valFactors[a], res2 = valFactors[b], res3; // = valFactors[c];   valList c12, c13, c23;   set_intersection(res1.begin(),res1.end(), res2.begin(),res2.end(), back_inserter(c12));   if (c12.size() != 0) return false;   res3 = valFactors[c];   set_intersection(res1.begin(),res1.end(), res3.begin(),res3.end(), back_inserter(c13));   if (c13.size() != 0) return false;   set_intersection(res2.begin(),res2.end(), res3.begin(),res3.end(), back_inserter(c23));   return c23.size() == 0; }  int main() {   time_t start_t, end_t;   time(&start_t);      int cnt=0;   double S = 1.2;   valType N_MAX = 10000000;      printf("Getting prime factors...\n");      valFactors.resize(2*N_MAX+2);   valRads.resize(2*N_MAX+2);   for(valType val=1; val<=2*N_MAX+1; val++) {       valFactors[val] = unique_factors(val);       valRads[val] = rad(val);   }      time(&end_t);   printf("Done, T = %.2fs\n", difftime(end_t, start_t));      printf("Calculating...\n");   #pragma omp parallel for reduction(+:cnt)   for(int a=1; a<=N_MAX; a++) {     for(int b=a; b<=N_MAX; b++) {       int c = a+b;       if (c > pow(valRads[a]*valRads[b]*valRads[c], S) && not_mutual_primes(a,b,c)) {         printf("%d + %d = %d\n", a,b,c);         cnt += 1;       }     }   }   printf("Done, cnt=%d\n", cnt);      time(&end_t);   float diff_t = difftime(end_t, start_t);   printf("N=%lld, T = %.2fs\n", N_MAX, diff_t); } 

Для тех кому лень устанавливать компилятор С++, приведена слегка оптимизированная Python-версия, запустить которую можно в любом онлайн редакторе (я использовал https://repl.it/languages/python).

Python-версия

from __future__ import print_function import math import time import multiprocessing  prime_factors_list = [] rad_list = []  def prime_factors(n):     factors = []     # Print the number of two's that divide n     while n % 2 == 0:         factors.append(int(2))         n = n / 2      # n must be odd at this point so a skip of 2 ( i = i + 2) can be used     for i in range(3, int(math.sqrt(n)) + 1, 2):         # while i divides n , print i ad divide n         while n % i == 0:             factors.append(int(i))             n = n / i      # Condition if n is a prime number greater than 2     if n > 2:         factors.append(int(n))     return factors  def rad(n):     result = 1     for num in prime_factors_list[n]:          result *= num     return result  def not_mutual_primes(a,b,c):     fa, fb, fc = prime_factors_list[a], prime_factors_list[b], prime_factors_list[c]     return len(fa.intersection(fb)) == 0 and len(fa.intersection(fc)) == 0 and len(fb.intersection(fc)) == 0  def calculate(N):     S = 1.2     cnt = 0     for a in range(1, N):         for b in range(a, N):             c = a+b             if c > (rad_list[a]*rad_list[b]*rad_list[c])**S and not_mutual_primes(a, b, c):                 print("{} + {} = {}".format(a, b, c))                 cnt += 1      print("N: {}, CNT: {}".format(N, cnt))     return cnt  if __name__ == '__main__':      t1 = time.time()      NMAX = 100000     prime_factors_list = [0]*(2*NMAX+2)     rad_list = [0]*(2*NMAX+2)     for p in range(1, 2*NMAX+2):         prime_factors_list[p] = set(prime_factors(p))         rad_list[p] = rad(p)          calculate(NMAX)      print("Done", time.time() - t1) 

Результаты

Троек a,b,c действительно очень мало.

Некоторые результаты приведены ниже:
N=10: 1 «тройка», время выполнения <0.001c
1 + 8 = 9

N=100: 2 «тройки», время выполнения <0.001c
1 + 8 = 9
1 + 80 = 81

N=1000: 8 «троек», время выполнения <0.01c
1 + 8 = 9
1 + 80 = 81
1 + 242 = 243
1 + 288 = 289
1 + 512 = 513
3 + 125 = 128
13 + 243 = 256
49 + 576 = 625

N=10000: 23 «тройки», время выполнения 2с

Тройки A,B,C до 10000

1 + 8 = 9
1 + 80 = 81
1 + 242 = 243
1 + 288 = 289
1 + 512 = 513
1 + 2400 = 2401
1 + 4374 = 4375
1 + 5831 = 5832
1 + 6560 = 6561
1 + 6655 = 6656
1 + 6859 = 6860
3 + 125 = 128
5 + 1024 = 1029
10 + 2187 = 2197
11 + 3125 = 3136
13 + 243 = 256
49 + 576 = 625
1331 + 9604 = 10935
81 + 1250 = 1331
125 + 2187 = 2312
243 + 1805 = 2048
289 + 6272 = 6561
625 + 2048 = 2673

N=100000: 53 «тройки», время выполнения 50c

Тройки A,B,C до 100000

1 + 8 = 9
1 + 80 = 81
1 + 242 = 243
1 + 288 = 289
1 + 512 = 513
1 + 2400 = 2401
1 + 4374 = 4375
1 + 5831 = 5832
1 + 6560 = 6561
1 + 6655 = 6656
1 + 6859 = 6860
1 + 12167 = 12168
1 + 14336 = 14337
1 + 57121 = 57122
1 + 59048 = 59049
1 + 71874 = 71875
3 + 125 = 128
3 + 65533 = 65536
5 + 1024 = 1029
7 + 32761 = 32768
9 + 15616 = 15625
9 + 64000 = 64009
10 + 2187 = 2197
11 + 3125 = 3136
13 + 243 = 256
28 + 50625 = 50653
31 + 19652 = 19683
37 + 32768 = 32805
49 + 576 = 625
49 + 16335 = 16384
73 + 15552 = 15625
81 + 1250 = 1331
121 + 12167 = 12288
125 + 2187 = 2312
125 + 50176 = 50301
128 + 59049 = 59177
169 + 58880 = 59049
243 + 1805 = 2048
243 + 21632 = 21875
289 + 6272 = 6561
343 + 59049 = 59392
423 + 16384 = 16807
507 + 32768 = 33275
625 + 2048 = 2673
1331 + 9604 = 10935
1625 + 16807 = 18432
28561 + 89088 = 117649
28561 + 98415 = 126976
3584 + 14641 = 18225
6561 + 22000 = 28561
7168 + 78125 = 85293
8192 + 75843 = 84035
36864 + 41261 = 78125

При N=1000000 имеем всего лишь 102 «тройки», полный список приведен под спойлером.

Тройки A,B,C до 1000000

1 + 8 = 9
1 + 80 = 81
1 + 242 = 243
1 + 288 = 289
1 + 512 = 513
1 + 2400 = 2401
1 + 4374 = 4375
1 + 5831 = 5832
1 + 6560 = 6561
1 + 6655 = 6656
1 + 6859 = 6860
1 + 12167 = 12168
1 + 14336 = 14337
1 + 57121 = 57122
1 + 59048 = 59049
1 + 71874 = 71875
1 + 137780 = 137781
1 + 156249 = 156250
1 + 229375 = 229376
1 + 263168 = 263169
1 + 499999 = 500000
1 + 512000 = 512001
1 + 688127 = 688128
3 + 125 = 128
3 + 65533 = 65536
5 + 1024 = 1029
5 + 177147 = 177152
7 + 32761 = 32768
9 + 15616 = 15625
9 + 64000 = 64009
10 + 2187 = 2197
11 + 3125 = 3136
13 + 243 = 256
13 + 421875 = 421888
17 + 140608 = 140625
25 + 294912 = 294937
28 + 50625 = 50653
31 + 19652 = 19683
37 + 32768 = 32805
43 + 492032 = 492075
47 + 250000 = 250047
49 + 576 = 625
49 + 16335 = 16384
49 + 531392 = 531441
64 + 190269 = 190333
73 + 15552 = 15625
81 + 1250 = 1331
81 + 123823 = 123904
81 + 134375 = 134456
95 + 279841 = 279936
121 + 12167 = 12288
121 + 255879 = 256000
125 + 2187 = 2312
125 + 50176 = 50301
128 + 59049 = 59177
128 + 109375 = 109503
128 + 483025 = 483153
169 + 58880 = 59049
243 + 1805 = 2048
243 + 21632 = 21875
289 + 6272 = 6561
338 + 390625 = 390963
343 + 59049 = 59392
423 + 16384 = 16807
507 + 32768 = 33275
625 + 2048 = 2673
864 + 923521 = 924385
1025 + 262144 = 263169
1331 + 9604 = 10935
1375 + 279841 = 281216
1625 + 16807 = 18432
2197 + 583443 = 585640
2197 + 700928 = 703125
3481 + 262144 = 265625
3584 + 14641 = 18225
5103 + 130321 = 135424
6125 + 334611 = 340736
6561 + 22000 = 28561
7153 + 524288 = 531441
7168 + 78125 = 85293
8192 + 75843 = 84035
8192 + 634933 = 643125
9583 + 524288 = 533871
10816 + 520625 = 531441
12005 + 161051 = 173056
12672 + 117649 = 130321
15625 + 701784 = 717409
18225 + 112847 = 131072
19683 + 228125 = 247808
24389 + 393216 = 417605
28561 + 89088 = 117649
28561 + 98415 = 126976
28561 + 702464 = 731025
32768 + 859375 = 892143
296875 + 371293 = 668168
36864 + 41261 = 78125
38307 + 371293 = 409600
303264 + 390625 = 693889
62192 + 823543 = 885735
71875 + 190269 = 262144
131072 + 221875 = 352947
132651 + 588245 = 720896

Увы, программа работает все равно медленно, результатов для N=10000000 я так и не дождался, время вычисления составляет больше часа (возможно я где-то ошибся с оптимизацией алгоритма, и можно сделать лучше).

Еще интереснее посмотреть результаты графически:

В принципе, вполне очевидно, что зависимость количества возможных троек от N растет заметно медленнее самого N, и вполне вероятно, что результат будет сходиться к какому-то конкретному числу для каждого ε (рискну высказать гипотезу что в данном случае оно не превысит 256:). Кстати, при увеличении ε число «троек» заметно сокращается, например при ε=0.4 имеем всего 2 равенства при N<100000 (1 + 4374 = 4375 и 343 + 59049 = 59392). Так что в целом, похоже что теорема действительно выполняется (ну и наверное ее уже проверяли на компьютерах помощнее, и возможно, все это уже давно посчитано).

Желающие могут поэкспериментировать самостоятельно, если у кого будут результаты для чисел 10000000 и выше, я с удовольствием добавлю их к статье.


ссылка на оригинал статьи https://habr.com/post/427091/

«Мы команда инженеров Android P. Спроси нас!»

Chet Haase. @chethaase And here we are, busily answer AMA questions. Or checking email. Hard to tell the difference.

19 июля 2018 на Reddit прошел раунд вопросов от сообщества разработчиков под Android и ответов от команды инженеров Android, посвященный последним нововведениям фреймворка (но не ограниченный этим списком):

  • Android Jetpack
  • Kotlin
  • Notifications
  • Power — app standby, app restrictions
  • Display cutout
  • Actions and Slices
  • Compatibility and non-SDK interface restrictions
  • Android P Beta devices, Project Treble

Среди участников Android команды, всего свыше 30 человек, в т.ч. засветились: Dianne Hackborn, Ian Lake, Jake Wharton, Romain Guy, Brian Carlstrom и другие.

Чувствуете уровень?

На заглавном фото — команда Android потеет над вопросами, источник.

Здесь перевод некоторых интересных вещей с переднего края разработки.

Navigation framework

Q. С новым Navigation framework, продвигающим идею single activity (или нескольких действий), каков план для Android планшетов? Я уверен, что внутри вас все хотят, чтобы планшеты ушли, но клиенты продолжают просить об этом, а разработка для планшетов стала серьезным препятствием. Есть ли планы сделать это проще? master/detail кажется простой, но когда приложение не является простым GitHubRepo (гм …), все выходит из-под контроля и быстро становится сложным. Отсутствие хорошего оборудования не помогает. По правде говоря, большинство приложений, которые я видел, имеют < 2% пользователей планшетов, это очень грустно.

A. Ian Lake, Software Engineer, Jetpack (Fragments, Navigation, Work Manager):

Навигация и планшеты на самом деле — это то, о чем я уже много говорил с группами Material и Chrome OS. Одним из факторов, который значительно повлиял на пространство дизайна для больших экранных устройств, стало введение многооконных режимов, в частности free-form windows, которые полностью изменяются по размеру, как вы можете найти на устройствах Chrome OS.

Это значительно повышает акцент на каждом экране вашего приложения, который реагирует, а не меняет структуру навигации на основе размера экрана (который может быть чрезвычайно дезориентирующим при изменении размера вашего приложения). Тактика, которую я рассмотрел в 2015 году, так же актуальна сегодня, когда речь идет о адаптации каждого экрана к большему (или меньшему) пространству.

Одна вещь, которую я, вероятно, добавлю сейчас, это то, что вы можете и должны подумать над тем, чтобы сделать navigation chrome вашего приложения (bottom nav, navigation drawer, etc) адаптированным к размеру экрана — если вы загрузите код Navigation codelab, вы обратите внимание, что приложение переходит из navigation drawer, в multi-window режиме на телефонах (где пространство дорого) к bottom navigation bar на телефонах и всегда отображается видимая side nav на планшетах.

При этом мы хорошо знаем, что еще многое предстоит сделать.

Soft Keyboard

Q. Есть ли хоть какие-то планы по его переработке? Почему мы заботимся об IMM, почему мы заботимся о «фокусе», почему нам даже нужен контекст, чтобы делать что-либо ?

Я уверен, что большинство пользователей хотят просто: Я открываю Activity / Fragment / X, и есть три edit texts, я хочу, чтобы клавиатура вела себя так, как должна. Не появляться в середине моего transition, что приводит к пропуску кадров или запутыванию transition framework, потому что зафиксированные значения начала / конца изменились (потому что, например, у меня есть настройка adjustResize в моем манифесте, или, может быть, у меня есть настройка adjustPan, чтобы обойти это, но теперь у меня есть другие проблемы … это просто выглядит действительно уродливо, когда клавиатура появляется, когда вы не хотите, чтобы она появлялась. Я понимаю последствия для безопасности и «third-party kbd support», но я думаю, что большинство разработчиков Android офигеет, если вы анонсируете API, который выглядел бы так:
Keyboard.isVisible(); Keyboard.isHardware(); Keyboard.show (focusThisView, callbackWhenKBVisible); Keyboard.hide(callbackWhenKBGone);

A. Adam Powell. TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

Да, мы это знаем. Это боль. Мы не построили конструкторы более высокого уровня, которые эффективно справляются с клавиатурой, и, как вы уже упоминали, она глубоко увязывается с режимом view focus, где, к сожалению, в приложениях много ожиданий, на которые они полагаются, для обеспечения совместимости.

Мы всегда были немного щепетильны в том, чтобы раскрыть запросы типа Keyboard.isVisible, поскольку большинство допущений, сделанных на их основе, ошибочны по крайней мере в одном реальном сценарии — «У меня меньше вертикального пространства, если возвращается true», «пользователь активно редактирует текст, если возвращается true, «у какого-то представления есть valid фокус», «пользователю не нужно видеть дополнительный интерфейс редактирования текста, когда возвращается false» и т. д.

Тем не менее, window insets не так хорошо работают, и мы знаем, что нам нужно предложить некоторые (многие) лучшие решения там. Есть также ряд других действий, которые люди пытаются эмулировать: «Скажите, отображается ли клавиатура, чтобы я мог накладывать ее на custom sticker/photo picker, который не передает UI» является одним из примеров использования который мы должны поддерживать лучше.

Reply из зала. Я просто не понимаю, как инженеры Google не видят этой проблемы с клавиатурой. Вот что они сказали вам: «В настоящее время у нас нет каких-либо значительных планов, хотя нам бы хотелось услышать об определенных проблемах / багах, которые разработчики приложений видят, чтобы мы могли их решать». Люди жаловались и хакали IMM API уже почти 10 лет … Да, вы владеете платформой. Хотите поддержать все IMM дерьмо? Идем дальше, но затем предоставляем API SOFT KEYBOARD для 98% разработчиков, которым просто нужно ПОКАЗАТЬ / СКРЫТЬ КЛАВИАТУРУ, и, может быть, только, возможно, надежно, под контролем, с точными обратными вызовами. Это не сложно, Android. iOS сделала это. И вы сможете.

RecyclerView

Q. Какие-либо планы по оказанию официальной поддержки headers и collapsing groups? Каждая неофициальная попытка в какой-то момент терпит неудачу, и стыдно, насколько легко она работает на iOS с 2008 года.

A. Adam Powell: TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

Голосуй, если хочешь этого. В основном это вопрос приоритетов, и, поскольку есть библиотеки от сообщества, мы не считаем это срочным.

Reply из зала. Пожалуйста, где я могу проголосовать! Я еще не нашел приложение, которым не нужен список вещей. Это было верно 10 лет назад. Теперь парадигма такова: мне еще предстоит найти список, который не нуждается в какой-то grouping/header/stickyness/material animation.

Themes

Q. В словах Баллмера вместо «developers developers…» подумайте о: Themes themes themes themes… Каковы планы для Themes/Styles/Attrs? Поскольку вопросы существуют, исследование того, как тема реализует, например, menu item color, представляет собой подвиг силы, проклятие и движуха на StackOverflow, что приводит к неправильным идеям повсюду. Планируете ли вы прикоснуться к этому, чтобы сделать … проще?

A. В ближайшей перспективе мы фокусируемся на обучаемости — возможность указать что-то на экране и понять, как было разрешено конкретное свойство без необходимости вручную выкапывать исходный код платформы, имея возможность настроить свойство view on-device, возможность экспериментировать, изменяя значение в теме или стиле и быстро видя, как это влияет на другие атрибуты. Сейчас это слишком black-box, и мы надеемся сначала разобраться в этом.

Fragments

Q. Почему бы не выставить API анимации напрямую, что позволило бы сделать animate(View previousView, View newView, ViewGroup container, int direction, AnimationCallback callback)? У Conductor есть это, и это самая простая вещь, которую можно придумать. Это же гораздо легче, чем setExitTransition или setCustomAnimations, особенно в отношении Z-order.

Почему вы, ребята, не дали Fragment’у метод onRetainNonConfigurationInstance? Вы можете retain сам фрагмент (что делает его non-backstack-friendly и не рекомендуется использовать, если он имеет view), но дать ему onRetainNonConfigurationInstance было бы намного проще, и тогда даже AAC ViewModel не понадобится ( хотя обратный вызов onCleared() хорош). Его можно сохранить вместе с состоянием FragmentManager как non-config! Почему нет?

Почему только операция REPLACE инициирует shared element transition, но не SHOW / HIDE, DETACH / ATTACH или ADD / REMOVE?

Почему views в child fragment уничтожаются до того, как они будут анимированы при использовании DETACH или REMOVE или REPLACE (вместо HIDE)?

A. Ian Lake:

Animation API — это то, о чем мы много думали, особенно учитывая такие вещи, как MotionLayout. FragmentManager определенно должен выполнять гораздо более сложные вещи, которые вам нужно будет сделать, только потому, что он пытается охватить все возможные сценарии.

ViewModels — рекомендуемый шаблон для сохранения данных через все configuration changes в фрагментах. Как вы указали, обратный вызов onCleared() является важной частью этого (вам абсолютно не нужна ваша собственная логика, чтобы определить, когда делать окончательную очистку), но разделение ownership и создания сравнения объекта, который вы предоставляете действительно важно для testability perspective.

В Fragments, как правило, слишком много возможных операций, которые делают разные вещи и обрабатываются по-разному. Мы смотрим более целостно на это, но, пожалуйста, сделайте file a bug, если найдете что-то особенное, что, по вашему мнению, должно работать, но этого не происходит.

Android Architecture Components

Q. Каков рекомендуемый способ обмена данными между несколькими фрагментами, но не делая его app-global через ActivityModel Activity?

Если я использую ViewModel Activity, как мне узнать, с помощью Navigation AAC, когда очистить этот кеш (соответствующие фрагменты, которые будут использовать эти данные, больше не будут существовать и могут быть удалены)?

A. Ian Lake:

Да, то, что вы действительно хотите, это некоторая область связанное между single destination/Fragment и всей областью активити. Одна естественная область видимости, которая существует в навигации, находится вокруг графа навигации (поскольку вы можете вкладывать навигационные графы для инкапсуляции login flow или checkout flow). Я создал feature request для этого — пожалуйста, поучаствуйте, если это та концепция, которую вы хотели бы нам представить более полно.

Direct Share APIs

Q. Почему share sheet UI настолько медленный? Обычно share sheet загружается в два этапа: во-первых, загружается основная нижняя часть, а затем вторая, опции «direct share» будут загружаться над всеми.

Часто доля «direct share» в этом пользовательском интерфейсе занимает очень много времени, даже на моем Pixel XL. Кроме того, пока пользователь ожидает, чтобы панель «direct share» загрузилась, нижний share sheet (который уже загружен!) не принимает сенсорные нажатия. Это слишком раздражает пользователя, потому что заставляет пользователя думать, что с телефоном что-то не так, когда на самом деле панель просто не принимает никакого сенсорного ввода. Кроме того, иногда панель «direct share» приводит к тому, что нижний share sheet перемещается, и поэтому пользователь случайно нажимает что-то непреднамеренное.

Вот статья, где освещены и другие проблемы Rita El Khoury had a wonderful article at Android Police.

(Прим. мое. Эта штука действительно бесит).

A. Adam Powell, TLM on UI toolkit/framework; views, lifecycle, fragments, support libs:

Потому что ваши приложения медленны! 🙂

(Прим. мое. Типа «сам дурак»).

Это моя ошибка, поскольку я добавил исходные Direct Share APIs. Он привязывается к сервисам из приложений с прямым доступом, поддерживающих Direct Share, и запрашивает у них своих лучших кандидатов на участие в рейтинге (ChooserTargetService).

Если приложение запускается медленно и медленно возвращает результаты, оно получает штраф в рейтинге. Это оказалось намного менее масштабируемым, чем указано в первоначальном тестировании, но Adam Cohen был достаточно вежлив, чтобы не говорить мне «Я же говорил» слишком часто.

Теперь мы получили сочетание отзывов пользователей перед выпуском и несколько ошибок. Людям не нравились direct share targets в несколько этапов, так как приложения каждый возвращали свои результаты, так как это приводило к неустойчивости пользовательского интерфейса, поэтому теперь он ждет самого медленного приложения, прежде чем показывать любые Direct Share targets. Люди беспокоились о том, чтобы не ошибиться, если пользовательский интерфейс изменился, пока они собирались нажать на свою цель, поэтому ничего не запускается, если вы нажмете во время анимации. Если вы подловите момент, прежде чем начнется анимация, то нажатие будет работать, но обычно ваш палец проигрывает эту гонку.

У нас были некоторые идеи для улучшения API в течение последних двух выпусков, которые не вписались в расписание. Эти идеи включали в себя изменение API, чтобы быть более похожими на launcher shortcuts, когда приложения пушат targets заранее, поэтому нам не нужно их запрашивать, изменяя верхнюю часть UI, чтобы присутствие или отсутствие поздних прибытий не было так разрушительно, и ряд других. Мы увидим, как далеко мы доберемся в будущих релизах, и сколько из них мы сможем включить в Jetpack API.

Material Components

Q. Короткий вопрос: Material Components для Android (на GitHub) — это постоянный беспорядок. Я всегда слышу, что все будет лучше, но все остается по прежнему. Что вы делаете для улучшения ситуации?

Подробности:

  • Десятки неотвеченных проблем
  • Отсутствие связи
  • Закрытая разработка
  • Большинство Pull Requests полностью игнорируются — некоторым из них много лет
  • Документы также устарели и / или функций там нет. Также гиперссылки на material components docs на dev.android.com в основном не работают.

По сравнению с iOS Material Components:

  • Действительно открытая разработка (2250 Pull Requests)
  • общение с разрабами в Discord
  • открыто для contributions
  • разрабы отвечают на issues, ставят tag, помогают как могут.

A. Dave Carlsson:

Прежде всего, спасибо за ваш вопрос. Он привлекает нас к ответственности и облегчает нам понимание того, что мы можем сделать, чтобы лучше поддерживать наше сообщество с открытым исходным кодом. Мы очень много работаем над Material Components для Android и ценим терпение сообщества open source, в то время как мы продолжаем создавать нашу команду и лучше взаимодействовать с нашими пользователями.

Этот вопрос освещает основные исторические различия между тем, как наши Material engineers разрабатывают библиотеки для iOS и Android. Material Components для Android были впервые разработаны и выпущены как Design Lib в библиотеке поддержки. Это означало, что нашим внешним пользователям Material приходилось жить с более медленным циклом выпуска в составе библиотеки поддержки Android. Мы продолжаем тесно сотрудничать с Android Support Library, даже когда мы переходим к использованию Jetpack в рамках нашего release cycle. В этом релизе мы создаем артефакты для Maven, которые легко используются разработчиками с помощью Android Studio для создания красивых Material apps. Получение наилучшего кода в инструменты, используемые разработчиками Android, наш первый приоритет.

Предоставление свежей копии нашей библиотеки Android на GitHub становится все более важным, поскольку мы разрабатываем обновления для Material. Эти обновления означают, что мы быстрее тестируем и делаем больше изменений вMaterial. В течение года между открытием кода нашей библиотеки на Google I/O в 2017 году и анонсом Material Theming in 2018, наша команда плотно работает с нашей основной библиотекой. Мы также потратили этот год на развитие команды и научились масштабировать все большее число внутренних и внешних клиентов. Нам предстоит долгий путь и в настоящее время уделяем особое внимание стабильности, улучшениям в нашей существующей библиотеке и лучшему реагированию на потребности наших пользователей Google и open source пользователей.

Мы будем сообщать больше о Material в Google Design newsletter. Недавно мы создали public tracker для технических вопросов, специфичных для Material Component library for Android. Мы используем этот трекер вместо GitHub issues для лучшего согласования с нашими внутренними требованиями к проекту, чтобы мы могли быть более отзывчивыми и эффективными. Мы также делаем все возможное, чтобы поделиться нашей roadmap с сообществом, чтобы у наших пользователей было лучшее представление о том, над чем мы сейчас работаем, и что мы будем делать дальше.

Я знаю, что много написал, так что я собираюсь закончить. Я также не буду обещать волшебное превращение за одну ночь, потому что если делать все правильно, то это занимает много времени. Мы продолжим писать наш код внутри Google’s codebase, как и для многих наших продуктов. Я чрезвычайно горжусь тем огромным усилием, которое наша небольшая команда по Material Android заложила в прошлом году, и я тоже рад видеть, как команда растет. Мы работаем над более быстрыми версиями при поддержке команды Android, и я думаю, что мы уже улучшаем то, как мы планируем наши вехи и обновляем код на GitHub. Даже эта AMA — еще один шаг в правильном направлении, и я благодарен за то, что у меня есть шанс участвовать в этом.

ART

Q. Здравствуйте, я хотел бы получить дополнительную информацию об изменениях, внесенных в ART на android P, каковы эти изменения, как эти изменения повлияют на использование ram / storage и время выполнения? Я заметил, что размер приложений растет все больше и больше, и это будет продолжаться в будущем?

A. Brian Carlstrom. Director of Software Engineering, covering App Compatibility, ART, NDK, Auth, Autofill, “adb shell”, etc:

Мы работаем в Android N, O и P, чтобы продолжать уменьшать использование памяти и памяти при одновременном повышении производительности.
Например, в Android N мы отошли от компиляции с full ahead-of-time (AOT), чтобы использовать JIT + profile guided AOT для уменьшения объема storage и memory.

В Android O мы начали делать device layout из dex code, чтобы уменьшить использование памяти и увеличить (прим. наверное имелось в виду “уменьшить”) время запуска.

Мы также добавили непрерывную сборку мусора для приложений на переднем плане.

Мы также уменьшили накладные расходы для внутренних структур данных кэша, используемых для классов и полей в 8.0, и для методов в 8.1, делая их LRU вместо пропорционального размера файлам приложений dex.

Для Android P мы продолжили фокусироваться на сокращении использования storage и памяти с внедрением CompactDex, о котором мы немного поговорим в наших I/O talk.

В целом я считаю, что приоритетами команды ART являются:

  1. корректность
  2. память
  3. производительность,

поэтому определенно у нас память в качестве приоритета в будущем.

Treble

Q. О телефонах Treble и Non-treble: смогут ли телефоны с нестандартными формами получать официальное или неофициальное обновление (Lineage и другие)?

(Прим. мое. Project Treble — это хитрый план Google, который поможет производителям упростить процесс обновления, чтобы сделать обновления более своевременными).

A. Brian Carlstrom:

Что касается телефонов Treble vs non-Treble, или можно обновить новые Android O до Android P, или для телефонов, которые имеют Google Play, нужно внедрить архитектуру Treble для начала. Поддержка custom ROMs, таких как Lineage OS, а также общий хакинг Android и эксперименты, теперь стали намного проще.

Generic System Image который построен из источников AOSP, является требованием совместимости. Это означает, что Treble-enabled devices будут работать с GSI по определению. Эта базовая гарантия позволяет создавать custom ROMs на основе GSI, используя эту стабильность.

Мы уже много знаем об этом с помощью различных сообщений на форумах XDA и связанных с ними сайтах, где люди могут более легко поддерживать Custom ROMs on Treble-enabled devices. В ближайшие месяцы мы опубликуем подробные инструкции по созданию Generic System Images, чтобы этот процесс стал еще проще.

Kotlin, JavaScript

Q. Что вы думаете о Kotlin Native, и видите ли вы какое-либо будущее в кросс-платформенной разработке с использованием Kotlin Native?

A. James Lau:

Да, мы считаем, что Kotlin Native очень интересен. Мы получаем много вопросов об этом от разработчиков, которые считают это очень перспективным направлением. В частности, одна из главных вещей, которую мы слышим от разработчиков, — это то, что обмен кодами для логики бизнес-процессов очень ценен. И что Kotlin Native был бы потрясающим решением по сравнению с этим на C ++ или JavaScript (как это делают большинство наших разработчиков сегодня). Мы тесно сотрудничаем с JetBrains, чтобы узнать, каким может быть его будущее в отношении разработки Android, включая встречу с разработчиками, которые пытаются это сделать, чтобы получить обратную связь и повторить попытку. KotlinNative все еще находится на ранней стадии, даже не Beta, но мы считаем, что перспектива довольно классная.

Q. Просто любопытно, как вы используете JavaScript на Android? В веб-приложении, прикрепленном к окну или какой-то безголовой JS-среде выполнения?

A. Jake Wharton:

V8, javascriptcore или duktape — это некоторые варианты движков, которые вы можете использовать для работы на Android.

Power management

Q. В поисках оптимизации батареи многие OEM-производители Android часто переусердствуют и в конечном итоге убивают приложения, даже если у них есть notifications переднего плана. Каждый OEM имеет свое собственное конкретное место, где пользователи могут отключить эти «оптимизации», и это становится кошмаром для управления всем этим. Существуют ли какие-либо планы по унификации battery optimizations, чтобы приложения на переднем плане были в безопасности ?

A. В P мы внедрили Background Restriction в качестве шага в этом направлении, и мы предоставляем руководство, направленное на обеспечение согласованности между OEM-производителями.

Разное

Q. Каковы некоторые из неочевидных вещей, которые вы хотите, чтобы сторонние разработчики перестали делать?

A. Не отправляйте ошибки платформы или библиотек для устройств, на которых запущены темы Xposed или RRO. Если вы ковыряетесь в кишках framework вне сферы действия CTS, вы сами по себе.

Q. Почему Android не поддерживает SVG напрямую? Насколько я понимаю, Vector Drawables реализует только часть функций SVG, и это ломает совместимость с остальным миром.

A. Chet Haase, Lead/Manager of the UI Toolkit team (views & widgets, text rendering, HWUI, support libraries):

Мы приняли сознательное решение поддержать подмножество функциональных возможностей, которые бы хорошо работали. SVG (в его многочисленных вариантах) поддерживает огромное количество функциональных возможностей, не все из которых необходимы всем, и мы хотели предоставить что-то, что будет охватывать наиболее важные функции для векторного рисования, не вызывая непредсказуемых проблем с производительностью, если какой-то asset используется что было труднее ускорить.

Q. Почему компас настолько ненадежен? Это дико неточно даже на Pixel-телефонах.

A. Это в основном аппаратное ограничение. Производители должны балансировать различные аспекты, такие как цена, размер, требования по энергопитанию, внутренняя интерференция, скорость, точность и т. д.

Чтобы найти баланс для того, чего хотят большинство людей и которые готовы за это заплатить.

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

Это обсуждение устарело, но затрагивает различные вопросы, о которых я говорил выше.


ссылка на оригинал статьи https://habr.com/post/427089/

Уязвимость в плагине jQuery активно эксплуатируется злоумышленниками

image
 
Уязвимость в популярном плагине jQuery File Upload активно эксплуатируется злоумышленниками для внедрения вредоносных файлов и перехвата контроля над серверами. Плагин и более 7800 форков, используются в огромном количестве проектов, CRM-системах, WordPress плагинах, дополнениях Drupal, компонентах Joomla и многих других приложениях.

Уязвимость обнаружил специалист компании Akamai Ларри Кэшдоллар (Larry Cashdollar). Уязвимость, которой присвоен CVE-2018-9206 существует во всех версиях jQuery File Upload до 9.22.1. Ларри опубликовал инструмент для поиска уязвимого кода.

image

Разработчик jQuery File Upload провел собственный анализ, по итогам которого выяснилось, что в действительности уязвимость связана не с исходным кодом приложения, а с изменением, внесенным командой проекта Apache Web Server в 2010 году, косвенным образом повлиявшим на поведение плагина на серверах Apache. Речь идет о выпущенной в ноябре 2010 года версии Apache HTTP Server 2.3.9, в которой появилась возможность игнорировать пользовательские настройки в отдельных папках, выставленных через файлы .htaccess. Данная опция включена по умолчанию в версии Apache HTTP Server 2.3.9 и последующих релизах.

В свою очередь, jQuery File Upload был создан таким образом, чтобы полагаться в работе именно на кастомный файл .htaccess, содержащий ограничения безопасности для директории загрузки. Тогда разработчик попросту не знал о том, что несколько дней назад создатели Apache HTTPD внесли в свой продукт изменение, вредящее корректной работе его плагина.

Судя по всему, злоумышленники обнаружили эту уязвимость еще несколько лет назад:

Рекомендуется обновить jQuery File Upload до версии 9.22.1, в которой данная проблема устранена.


ссылка на оригинал статьи https://habr.com/post/427085/

Критерии разума человека, с точки зрения одного программиста

Сознание. Множество копий сломано на эту тему. Мы воодушевленные рывком цифровой техники и ростом вычислительной мощности с опаской ожидаем появления первого искусственного интеллекта. Как это будет? Возможно, в каком-то гараже, чей то компьютер выведет на экран вопрос: «Кто я?». Или мега корпорация добра/зла в своих кулуарах поставит большую черную коробку, которая со временен негласно станет принимать все решения в данной корпорации… У меня не очень богатая фантазия, а посему оставлю придумывание вариантов создания ИИ на футурологов, сценаристов и писателей. Хотя я думаю, что каждый, кто хоть немного связан с программированием или микроэлектроникой, однажды задумывался, а как он, этот самый ИИ, должен работать. И тут начинаются споры и домыслы… ИИ – это особый софт, или особая архитектура устройства…

Равно как и все, я порой в пути на работу/с работы, проваливаюсь в чертоги своего сознания и размышляю на вечные вопросы, терзающие лучшие умы человечества. Данная статья не является статьей в самом широком её смысле, а просто моя попытка зафиксировать печатным словом и несколько структурировать рой мыслей в голове. Как говорится: «Хочешь что-то понять — расскажи это другому». Данный текст я изначально писал для себя, поэтому местами мысли могут быть рваными, скомканными и возможно даже без логики. Если не испугал, прошу под кат.

Итак. «Я мыслю – значит существую». Насколько это верно? Улитка существует, но она не мыслит. Точнее мыслит, но не так как человек. Ну всё сложно. У улитки вообще нет мозга. Есть набор нервов (ганглиев). Что-то порядка 20к нейронов.

1

Собственно мыслить она не может по определению. Но, тем не менее, она существует. Её существование примитивное, подчиненное даже не инстинктам, а чему-то более глубокому. Суть её существования думаю даже не надо пояснять. Она не намного продвинулась, от одноклеточных. И тем не менее, продвинулась. Она может управлять своим телом, получать информацию о внешнем мире, спариваться, отличать съедобное от несъедобного. Чисто теоретически, если мы создадим нейронную сеть на 20к нейронов, в точности копирующую нервную систему улитки, оно решит что ему надо поесть и спариться? Я думаю нет. Без какого-то начального импульса и алгоритма это так и останется грудой металла. Но тут резонно заметить, что тяга к питанию и размножению есть и у одноклеточных и даже растений. Хотя это и происходит потому что «так исторически сложилось». Потому что так в процессе эволюцию скомпоновались гены, которые в изначальном хаосе складывались в безумные комбинации, порождая биологические машины Голдберга. Оставались только лучшие, а именно живучие. Но речь не об этом. Мы имеем факт. Живых существ с разной степенью интеллекта и сознания. Все они подчинены изначальным инстинктам, а именно дать выжить своему геному. Но разумным человек считает именно себя. Каковы критерии разума? Хоть это ближе к философии и эпистемологии, и, тем не менее, я для себя попробую выделить ключевые понятия и определиться с тем, какие из этих критериев важнее.

2

Ну, во-первых, самосознание, т.е. умение выделять себя среди прочего мира. Понимание своего места в мире и обществе. Наверно это надо было сказать. Однако это глупость. Самосознание – красивое слово, придуманное дабы потешить свое человеческое эго. Данный термин настолько же бессмысленен насколько пафосен. Посмотрите собаке в глаза и скажите, что она не осознает свое место в мире. Или место в стае. Но разумна ли она? Однозначно нет. В принципе, я тут немного слукавил, и кто хоть немного интересовался теорией разумности поняли, что данный пункт скорее троллинг, потому как ни одно серьезное исследование по теории разума, не использует такое понятие как «самопознание» как критерий разумности. Но слишком многие мои оппоненты по данному вопросу использовали это понятие. Слишком многие… Но не будем о грустном. Летс го лэтер.

Вторым пунктом (а по сути первым) у нас идет абстрактное мышление. Вот тут очень сложно спорить. Абстрактное мышление, по сути есть некий столп разума. Хочу обратить внимание: АБСТРАКТНОЕ. Потому как далее в термине идет слово мышление. Что само по себе дает нам почву для софистики и сделать вывод, что не только человек способен мыслить. Я пожалуй воздержусь от дачи определения абстрактного мышления. Я думаю, каждый понимает его. И даже если есть расхождения в определениях – в этом тоже зерно абстрактного мышления. Ну если нет понимания – то без паники, я к нему вернусь дальше.

Третьим пунктом идет умение контролировать себя, и подавлять свое «животное» эго.
На дальнейших пунктах даже не буду останавливаться, ибо там уже идут посылы от первых трёх (двух) такие как: Объективность восприятия окружающего мира, творческая мысль, Степень подавления инстинктов, Рациональность мышления, Контроль разума над эмоциями, умение логично мыслить и бла, бла, бла. Прошу прощения, разных критериев понадуманно великое множество, почти все высосанные из пальца и в лучшем случае не опирающиеся на «духовность». А эмоции я контролирую слабо … Судя по всему не разумен…

Подводя резюме к тому, что уже сказанному, я хочу остановить внимание именно на абстрактном мышлении и подавлению «животного я». (Собственно, всё прочее я проигнорировал).

3

В самом широком понимании абстрактное мышление – это способность воспринимать мир без самого мира. То есть через неких его посредников. Я никогда в жизни не видел вживую КВМ, но я знаю что это. Так же я не видел слона. Но думаю, когда увижу, то пойму что это он, а не кенгуру, которого я так же не видел (имеется ввиду вживую). То есть, я имею представление о некоей сущности через абстрактные понятия: я видел картинки, слышал звуки, читал книги. Более того, я могу видеть в одних сущностях другие, проводя параллели. Например, решить, что облако похоже на крокодила. Именно умение абстрактно мыслить позволяет отличать фотографию собаки от фотографии кошки. Но это всё субъекты материального мира. Их можно увидеть, сравнить, выделить общие черты. Умение отличать кошку от собаки, уже давно не ноу-хау в мире ИИ. Я предполагаю, что живая собака тоже вполне себе способна отличать нарисованную кошку от нарисованной собаки. Зависит от терпеливости и грамотности её дрессировщика. Значит абстракция нечто большое, чем сопоставление различных объектов реальности. Тут опять начинается игра с понятиями и терминами. Я чуть ранее в примерах приводил материальные примеры. Облако – крокодил, фотография – собака/кошка. Равно мы можем манипулировать данными других наших чувств: кошка – говорит мяу, собачка – гав-гав, голубь – курлы-курлы. И прочее. Туда же до кучи запахи, осязание. Это всё объекты материального мира. Это всё в некоторой степени можно измерить, «пощупать» и каталогизировать. Это всё доступно так же и другим высшим представителям животной фауны.

Абстракция дарует нам несколько больше. Благодаря ей, мы можем оперировать такими понятиями как справедливость, итог, канцелярия, начальник, жизнь/смерть и т.п. То есть некие определения, которые мы сами для себя придумали. Хотя если мы начнем копать, и разбираться то, чтобы дать определение, мы воспользуемся другими определениями. Например: Экзистенциали́зм — особое направление в философии… Направление – линия движения.

Движение — перемещение с места на место. Тут уже мы скатились в материальный мир. Думаю логика понятна. Любое абстрактное определение можно выразить через серию других определений, и на определенном уровне абстракции мы рано или поздно выпадем в определения материального мира. По сути, способность оперировать обобщенными понятиями нам дает способность обобщать знания. Тавтология для усиления слова обобщать. По сути, все наши знания можно выразить через другие знания. И что самое главное, мы можем эти знания передать другому. Высшие представители животного мира также учат друг друга. Самки учат потомство, как добывать еду, как охотиться, как драться. Но эти знания на уровне того как младенец учится сжимать ладошку в кулачок. Кстати. Владение своим телом – тоже знание. Которому надо учиться и можно научить. Но это к слову. Весь процесс накопления знаний человечества строится именно таким образом. Мы обобщаем уже имеющиеся знания, создавая новые. На базе созданных путем перебора или сочетаний имеющихся, создаем новые. И так в бесконечность и далее… Вся наука на этом стоит. Не так давно статья об этом была. (На момент написания этих строк, а не публикации). Одни люди делают гипотезы, на основании других гипотез. А третьи на основании гипотез вторых делают свои. И не важно: ошибочные или нет. Они создают новое знание. И тут мы подошли к ещё важному пункту. Создание нового. Оно же творчество. Я не стал выделять это в отдельный пункт, хотя очень часто именно способность «творить» определяют разум. Тут я любил играть словами, выстраивая тупиковую логическую ветвь. Создавать вещи могут многие представители животного мира. Птицы строят гнезда, муравьи муравейники. Животные роют норы. Так чем термитник принципиально отличается от многоэтажки? Хорошо. Можно сказать, что человек способен создавать новое. Художник рисует картины, которые ранее не были нарисованы. Писатель пишет книги. Программисты пишут программы. Они творцы. А если кто-то не рисует, не пишет ни книги, ни музыку. Если возьмем среднестатистического менеджера в вакууме, который работа-пятница-диван-работа? Что этот человек создает нового? Но считаем ли мы его разумным? Однозначно да. Почему? Рассмотрю дальше, если не забуду. Вернемся к созиданию. Ласточка строит гнездо. Вряд ли найдутся те, кто скажет, что это простая архитектурная конструкция. Человек строит небоскреб. В чем принципиальная разница между этим? Ну в первую очередь, для того чтобы ласточки научилась строить гнездо, потребовались миллионы лет. А человек научился за десятилетия и продолжает улучшать свой навык строительства. За счет чего? Разума? Нет. За счет того, что он создает новое знание и вполне успешно оперирует имеющимся.

Вернемся к нашему «диванному офис-менеджеру», не создавшему за свою жизнь ничего принципиально нового. Он однозначно разумен. Что нам для этого послужит критерием? Он способен осмысленно отвечать на вопросы. Критерий? Ну почему бы и нет. Не буду останавливаться на том, что Алиса, Сири или ещё что, способны создавать иллюзию осмысленного ответа. Это будет именно иллюзия, и мы её чувствуем. Как мы понимаем «осмысленность» ответа? Очень просто – ключевая идея ответа, совпадает с ключевой мыслью вопроса (данный принцип не работает, на многих политиках, из чего можно поставить вопрос о сознании и разумности оных). Подчеркиваю, совпадают ключевые мысли вопроса и ответа. Не ключевые слова и словосочетания. А именно мысли. Некая абстрактная суть сказанного, которая выделяется нашим умением абстрактного мышления. В некотором роде работает принцип «преобладания содержания над формой». Мы способны понять, что нам говорят вне зависимости от того, что и как нам говорят. Например. Юзверь говорит: «Я включила программу, а она мне показала табличку, что программа не работает». И мудрый получатель данного тикета, без применения телепатических способностей, понимает, что пользователь запустил 1Ску, которая у него выдала ошибку. Хотя, может пример и притянут за уши, но, тем не менее, надеюсь, дает понять, что есть огромная разница между тем, что мы говорим, что мы хотим сказать и как нас понимают. Чем лучше нас понимают, тем выше разумность нашего собеседника. Я не включил столь важный критерий разумности в свои критерии, по той простой причине, что это следствие из нашего умения абстрактно мыслить.

В принципе, умение говорить уже само по себе очень большой критерий разумности. Мы же думаем на своем языке. Наши внутренние диалоги проходят на нашем языке. Может именно умение говорить делает нас разумными? Я какое-то время всерьез обдумывал эту мысль.

4

И в ней есть здравый смысл. Если бы не глухонемые. Задумывались о том на каком языке думают люди, от рождения не способные слышать и говорить? (Если не ошибаюсь, на эту тему даже есть книга). То, что они думают это факт. То, что они разумны – так же неоспоримый факт. Эти люди способны читать и общаться. Логичное следствие, что наш язык помогает нам формулировать наши мысли, из этой помойки, что у нас в голове. Структурировать и выдавать в некое оконченное знание. И общение это не обмен словами, а обмен знанием. Пусть даже мелким и нелепым. Когда мы говорим с кем-то, мы либо передаем ему информацию, либо передаем запрос на получение информации. Ни больше, ни меньше. Без альтернатив. Даже пустой треп, несет в себе информацию. Так как вся моя писанина- это набор моих личных домыслов и рассуждений, не подкрепленных четкими математическими расчетами, а базирующихся лишь на словесных логических выводах, поэтому к каждому моему выводу можно найти несколько контраргументов и развести дискуссию. Но то, что все наше общение – это не более чем передача/запрос информации, мало чем отличающийся от GET/POST, я предлагаю принять как факт.

Каждый из нас заинтересован в своем благополучии. Наше благополучие напрямую зависит от того чем мы обладаем. Наши знания – это так же наше имущество, дающее нам благополучие. Зачем тогда нам делиться им? Логично ведь, что как только мы кому-то передали часть наших знаний, мы помогли человеку преумножить его благополучие. Естественно, разные знания обладают разной ценностью. Знание о том, что сегодня хорошая погода, не равноценно со знанием, о чем-то, что повлияет на биржевую стоимость каких либо акций. И мы им можем поделиться. Зачем? Ну, например тем самым мы принуждаем человека к диалогу, результатом, которого станет для нас его ответ, и как следствие – новое знание. А может дело в какой-то другой мотивации. В любом случае, когда мы открываем рот, чтобы издать какой-то звук, который донесет информацию до чужих ушей, мы делаем это не просто так. Каждый раз мы имеем какую-то определенную цель. Даже если не осознаем её. Иначе мы ничего не делали бы, потому что чтобы что-то сделать, надо приложить какое-то усилие. А мы так устроены, что когда есть выбор приложить усилие или нет, то мы его не приложим. То есть, в нас есть какая-то движущая сила, которая заставляет нас в течении жизни что-то делать. Внутри каждого из нас есть мотивация. Про эту самую мотивацию. Здесь очень к месту вспомнить Абрахама Маслоу с его широкоизвестной пирамидой. Пожалуй, я даже остановлюсь на ней. Как известно данная теория имеет большее отношение к экономической теории, нежели к психологии. И именно в ключе маркетинга и попытках влиять на потребительский спрос, она получила такое широкое распространение. И, тем не менее, современная психология была бы не та, не внеси в неё г-н Маслоу свой труд. И я позволю себе рассматривать пирамиду, как наглядное представление нашей мотивации.

5

В основе пирамиды лежат примитивные позывы – физиологические потребности. Кушать, спать, размножаться. Чуть выше потребность в безопасности. Я думаю, что данная мотивация свойственна не только человеку. Более того, я буду утверждать, что это мотивация всего, «что состоит из генов». Начиная от амеб и растений, и заканчивая человеком. Это основа всего живого. А вот элементы вершины пирамиды: эстетические потребности и самореализация, свойственны уже человеку. Сложно себе представить собаку/кошку/хомячка/etc, которые придумывают стихи, делают перестановку в своем жилище, рисуют картины… И тем не менее, несмотря на всю тонкость последующих умозаключений, я наберусь смелость утверждать, что эти высшие мотивации есть следствие нашего животного Я.

Уверен, что у части тех немногих, кто дочитал до этого места, могут возникнуть сомнения в моей адекватности. Тем более, что оказывается на Хабре присутствуют люди, кто на полном серьезе говорит о полевой структуре. Но смею заверить, я полностью разумен и, надеюсь, сохраняю ясность мышления. Давайте потихоньку разбираться на конкретных примерах. Как пример эстетической потребности давайте возьмем моду (желание красиво одеваться) и ремонт в квартире. Откуда родилась мода? Хотя не так. Ви нид го дипэ. Если человек одет модно это красиво? Тут зависит от вкуса. Кому-то да, кому-то нет. Есть устоявшиеся каноны в одежде, которые общепризнано являются красивыми. К примеру, мужчина, одетый в подогнанный и хорошо сидящий классический английский костюм, будет выглядеть красиво. Здесь очень важным является понятие хорошо подогнанный и хорошо сидящий. Есть ли какой-то критерий этого? Конечно есть. Но эти критерии сложились исторически. Как и само понятие костюма. Я думаю вид человека в классическом костюме 21 века, лет так 300 назад вызвал бы в лучшем случае смех. То есть понятие моды и красоты одежды у нас не врожденное. Мода и красота у нас выученные знания. Нам их надиктовало наше ближайшее окружение и общество. Изменения в одежде проходят не сразу. Есть некий предпосыл прежде чем появится тренд. Кто-то изменил одну деталь. Другому это понравилось. Третий это растиражировал, массово начали появляться такие детали и всё. Получаем новый виток моды. Галстук то, например, не сразу стал таковым. Ему предшествовал долгий путь от шейного платка. Люди хотят отличаться от общей массы, сохраняя при этом свое положение в разряде нормы. То есть мы хотим быть принятым в обществе, но при этом выделяться. Поэтому незначительно меняем элементы одежды, так чтобы это было как у всех, но с какой-то изюминкой. Тоже самое касается и интерьеров. Мы хотим большой дом, дорогую машину. Чтобы это было «красивым» по меркам принятым в обществе. Чтобы общество нас принимало, но и мы были лучше, чем остальные. Чем больше людей «хуже» нас (хуже одеты, хуже имущество etc), тем лучше нам. Это нас заставляет расти, что-то делать и к чему-то стремиться. Не буду далеко ходить. Я это повожу к той мысли, что всё наше эстетическое восприятие, не намного ушло от павлиньих перьев. Многократно усложненное, но суть осталась прежняя, показать свой статус, чтобы возвыситься над другими и получить большие блага в виде лучших партеров.

Да, у нас есть искусства. Живопись, музыка… Но все они развились из чего-то более приземленного, и умение понимать музыку и живопись оно не дано нам с рождения. Это приобретенный навык. Искусство растет и усложняется год от года. Но это мы сами усложняем его, благодаря нашему абстрактному мышлению. Искусство это искусственная форма деятельности. Она выдумана человеком.

6

Это глубокий уровень абстракции. И тем не менее, оно начиналось так же как и всё. С простейших форм, имеющих глубоко практическую цель. И постепенно стало тем, чем является. Но ещё раз подчеркну, что понимание эстетики и искусства – это следствие нашего абстрактного мышления. Поэтому высшие потребности человека, не более чем усложнившиеся и мутировавшие, базовые потребности всего живого.

Не могу не остановиться на вере. Понятие души/духовности разумного существа веками вбиваемые в наши головы, слишком глубоко в нас сидит. Даже самые ярые атеисты, могут носить крестики, и потихоньку креститься. Так. На всякий случай. Нужно понимать, что религия всегда существовала в том или ином виде на протяжении всей истории человека. И многие её постулаты стали для нас базовыми жизненными пресуппозициями. Я не хочу останавливаться на духовных сущностях человека. Хотя бы потому, что я не могу опровергнуть существование души. Сколько бы аргументов я не привел против, всегда найдется куча аргументов за. Но я выступаю за то, что если и есть у человека душа, то она есть у всего живого. А так не всё живое обладает разумом, то не она делает нас разумными, и её наличие я просто проигнорирую.

7

Касаясь веры, я хочу затронуть не религию, а именно веру. Ведь вера это когда мы воспринимаем, что-то чего не существует, как словно оно есть. Вера живет в наших головах. Вера это тот мирок который заполняет пробелы в нашей голове, когда нам не хватает информации. Пожалуй, я даже не преуменьшу, когда скажу, что именно вера определяет нас как разумных существ. Но ещё раз заострю внимание, когда я говорю вера, я не имею в виду религию. Вера это то, как мы заполняем пробелы в нашей информации. Если я удалю строку в БД, и вдруг решу воспользоваться ссылкой на эту строку, то получу null. А если я воспользуюсь ссылкой в своем разуме на нечто несуществующее, я получу веру в то, что там что-то находится. (Немного натянуто, но тем не менее. Чуть дальше я коснусь темы того, как мы получаем что-то из закромов нашей памяти. И это аналогия ссылками вообще умрет). Вера это то как мы используем наши знания, или точнее их отсутствие. Когда Резерфорд после серии экспериментов выдвинул свою теорию строения атома, он не был в ней верен. Он верил в это. У него не было знания по данному вопросу, или же они были умозрительными, он сделал ряд экспериментов. Обобщил, что знает, и создал новое знание. Но это знание существует только на абстрактном уровне, гипотез, предположений, умозаключений. По сути своей гипотезой он закрыл пробел в своем знании, ровно то, что делает вера. Это я сейчас немного поиграл словами, дабы несколько раскрыть понятие веры. Вера – заполняет нашу картину миру делая её целостной. Она опирается на некие представления о том, что мы знаем и на базе этого создает новые сущности в нашем разуме. Причем эти сущности могут даже противоречить тому, что мы знаем 100%. Я могу искренне верить, что если я отложу работу на завтра, то завтра её сделать будет проще. Я могу искренне верить, что легко брошу курить в любой момент, хотя за плечами уже с десяток неудачных попыток. Я могу верить, что если в машине слышался жуткий лязг, а потом пропал, то машина сама починилась. Я могу верить во, что угодно. Вера обобщает имеющиеся знания и создает новое, не существующее знание. Но оно так же является знанием, ибо используя веру во что-то мы можем её присовокупить к имеющимся знаниям и получить новое. Но и научная гипотеза работает по этому же принципу. Мы берем имеющиеся знания, и на их базе создаем новое, выдвигая гипотезу или предположение. Другие люди берут гипотезы, созданные в разное время, разными людьми и рождают новые гипотезы. И тем самым продвигают науку. Более того, знание вообще мало отлично от веры в принципе. Я никогда не видел землю из космоса. Но я являюсь «шаровером». А то что наша планета круглая, это знание. Это ого-го какое знание. И, тем не менее, мы можем наблюдать людей, для которых земля плоская. Мы обладаем очень большими знаниями, в которых не можем лично удостовериться. Но тем не менее. Это именно знания. Но мы них «верим». Общее в этих механизмах то, что каждое отдельное знание, состоит из набора других знаний. Каждое знание можно выделить через набор других знаний. Если знаний не хватает, то создается новое знание. А создается ли оно?

Давайте разбираться с тем, что мы знаем. Вы знаете какого цвета ваша зубная щетка? Вы знаете, как она выглядит? Вы знаете, как выглядит ваша ручка, которой вы пишите? Вот прям уверены? Не глядя на сии девайсы, представьте их у себя в голове.

8

Это точная копия? Скорее всего да. Но с некоторыми деталями. Когда вы пытаетесь представить какой-то предмет, вы не достаете его из памяти как фотографию. Ваш мозг получает из своих темных глубин то, что связано с этим предметом, что лежит на поверхности, и уже из этого компонует картинку. Чем дольше мы сосредотачиваемся на картинке, тем больше и глубже наш мозг достает всякой всячины и тем большими подробностями обрастает картинка. И так длится пока нашему мозгу одна из ссылок, по которой он достает всякий хлам, не покажется важнее и он начинает, собирать хлам уже для той ссылки, что показалась важнее. В самом широком смысле я хочу сказать, что мы ничего не помним. Все наши воспоминания это совокупность каких-то знаний. Каждое наше знание состоит из других знаний. А абстрактное знание, знание, которое состоит из других знаний.

Сложность понимания этого заключается в том, что до сих пор не существует единицы измерения знания. Как можно измерить знание «холода», «яркого света», «шума». Каждое по отдельности мы вполне способны оценить измерить, дать определение и даже оцифровать это знание. Но в нашем мозгу не происходят замеры, у нас есть состояние яркого света, шума, ощущения. Все наши ощущения поступают в мозг, вызывают там ассоциации, воспоминания, примешиваются в текущие мысли и образы. И это все одно. Но если чисто гипотетически допустить что есть такая единица измерения. Пусть она так и будет ЗНАНИЕ. Всё, что мы можем выделить в отдельную сущность, будет ЗНАНИЕ. Как сжать кулак – ЗНАНИЕ. Тепло солнца на коже – ЗНАНИЕ. Ощущение высоты- ЗНАНИЕ. 2+2=4 – ЗНАНИЕ. Что 2 это цифра – ЗНАНИЕ. Что цифры бывают арабские и римские – ЗНАНИЕ. Что 2 это символ — ЗНАНИЕ. Что 2 это тоже что и два – ЗНАНИЕ. И так далее.

Что из этого можно предположить. Все ЗНАНИЯ связаны. ЗНАНИЕ само в себе невозможно. Нельзя дать определение чему то используя одно слово. А даже если и можно то тут потребуется посредник, такое понятие как определение. То есть для того чтобы ЗНАНИЕ существовало, должны существовать как минимум два других ЗНАНИЯ, через которое можно было бы определить первое. Сложно? Давайте представим себе базу данных, которая состоит из двух таблиц: ЗНАНИЯ и ПАМЯТЬ. В первой таблице у нас одна колонка, она же ПК, с типом ЗНАНИЕ. Вторая состоит из трех колонок: ЗНАНИЕ (ПК), СВОЙСТВО, ЗНАЧЕНИЕ. У каждой тип ЗНАНИЕ. Каждый элемент в строке второй ссылается на строку в первой. Для тех, кто пишет (писал/знаком) с 1С, это конструкция хорошо знакома на примере регистров сведений типа КатегорииОбъектов, ЗначенияСвойствОбъектов. Только в нашей второй таблице нет ограничений по дублям записей, нет понятий измерений и ресурсов, и во всех трех колонках используется один и тот же тип. В принципе данная конструкция всем знакома, когда надо динамически определить набор свойств объекта, а мы не знаем ни количество этих свойств, ни их сути. И у разных объектов могут быть свои свойства. А теперь прикинем, сколько всего мы знаем. Прикинем связи того что мы знаем. И ужаснемся от размера этой потенциальной таблицы. Но даже если её создать каков будет запрос к ней? Как понять какое свойство приоритетнее? Банально. Давайте закинем в эту таблицу все, что мы знаем о зубных щетках. Всё что мы знаем о свойствах зубных щеток, а теперь закинем все, что мы знаем о свойствах свойств зубных щеток. И попробуем к этому сделать запрос и из полученного собрать образ зубной щетки. Я думаю, что это, мягко говоря, проблемно. Не придумали ещё такого квантового алгоритма. Но, тем не менее, это происходит. И есть ещё гвоздь в крышку данной теории. Наша память не ПЗУ. Даже долговременная. Она скорее ОЗУ. Есть интересная статья на эту тему. Не вижу проблем в ней сомневаться. Вопросы организации хранения знаний у нас в мозгу, я освещу позже и более детально. Пока остановимся на том, что мы как-то обладаем знаниями.

Пожалуй для меня из всего того, что было сказано выше, это и есть главный критерий разумности. Мы способны осознавать свои знания и управлять ими.

Пожалуй, здесь я всё-таки оборву свой полет мысли, ибо текста получилось много. В рамках вводно-философской части в последующих публикациях я глубже коснусь вопросов мотивации нашего поведения и организации хранения информации в мозгу. А после перейду к описанию своих попыток эмуляции мышления. Хотя, если честно признаться, я сам пока не знаю, что я напишу дальше. To be continued…


ссылка на оригинал статьи https://habr.com/post/427081/

Вольтметр для батареек: карманный гаджет для смартфона с «крокодильчиками»

Компания FTlab во многом известна как производитель мобильных полупроводниковых датчиков с разъемом Jack, каждый из которых определяет либо уровень ультрафиолета, либо температуру и влажность, либо электромагнитное излучение и даже уровень радиации.

Устройства имеют довольно ограниченную применимость из-за характеристик, и скорее являются чем-то вроде игрушки для гика, но тем не менее они вполне себе работают в рамках заявленных особенностей.



При всех своих ограниченных возможностях миниатюрные датчики «расползлись» по разным площадкам от Amazon’а до Aliexpress’а, не минуя и отечественные интернет-магазины. При этом удивляет и цена — 30-40-50 USD за единицу.

Вольтметр

Вольтметр — лишь один из датчиков. Он предназначен для проверки постоянного тока, однако девайс загнан в узкие рамки: 0 ~ 10 В. Это делает его практически «игрушечным», или, как вынесено в заголовок — гаджетом для проверки батареек.

Делает это, правда, достаточно точно в сравнении с более «квалифицированными» приборами:

Правда, погрешность в рамках заявленных цифр (± 0.05V) наблюдается.

Как работает

Для работы с устройством потребуется приложение: под каждый датчик можно скачать свое, но есть и такое, которое бы позволяло работать сразу со всеми устройствами (Android | IOS).

Далее рекомендуется выкрутить громкость на полную и исключить лишние помехи путем перевода смартфона в режим полета. Подключается датчик через Jack (и сейчас владельцы седьмых Айфонов, конечно, сильно жалеют).

После этого концы-крокодилы необходимо приложить к измеряемому объекту и нажать на кнопку «Старт» на дисплее.

Плюсом такого девайса является и то, что никакой встроенной батареи тут нет: питание он получает от смартфона. Не разрядится, не подведет. От свои собратьев по категории, других «смарт-чекеров«, он отличается лишь формой:

Большинство из них — это просто небольшие «штырьки», тут же у нас еще от датчика отходит два провода с крокодильчиками на конце. Это делает его чуть менее удобным + более ненадежным (провод можно зацепить, порвать).

Впрочем, сказать, что тут все кое-как да на соплях — тоже нельзя: спаяно вполне прилично, да и носить его можно в коробочке, в которой он продается.

Из очевидных минусов:

  • Маленький диапазон, ограниченная применимость
  • Подключение через Jack

Несмотря на то, что разъем для наушников будет еще какое-то время актуален для смартфонов, все вероятно в будущем. Компания уже сейчас дублирует некоторые свои устройства с беспроводным соединением (например), но на отечественном рынке их пока не было замечено.

Из плюсов:

  • Компактный размер
  • Быстрые результаты (в пределах 5 секунд)
  • Работа без батареек

Как и любой портативный девайс, эта штука дает некоторые допвозможности своему владельцу, но при этом накладывает ряд ограничений. В целом — справедливый расклад. Стоит же такая «игрушка» полторы тысячи рублей.


ссылка на оригинал статьи https://habr.com/company/medgadgets/blog/427039/