вторая формула для квадратного уравнения
А вы знаете про альтернативную формулу решений квадратного уравнения?Вместо "минус бэ плюс-минус корень... поделить на два а", в ней "2це поделить на минус бэ минус-плюс корень...".Ну, разобраться в том, что она дает ровно те же два решения, не очень тяжело. Почему там "минус-плюс" в знаменателе, тоже не бином Ньютона: суть в том, что один и тот же корень получается, если в первоначальной формуле взять плюс, а в этой минус. И наоборот, если в обеих взять плюс, то выйдут два разных корня, в общем случае.Но вот зачем это все надо? Те, кто знают, уже усмехаются и кивают, а я расскажу. Это нужно, если обычная формула заставляет сделать "катастрофическое сокращение". Что такое катастрофическое сокращение, спросите вы? Это когда мы делаем вычитание двух чисел, очень близких друг к другу. Из-за того, как вещественные числа записываются в памяти компьютера (вспоминайте эти странные слова: мантисса... экспонента...), происходит потеря точности.Например, если b очень большое в сравнении с a,c, то получится, что дискриминант sqrt(b^2-4ac) очень близок по значению к b. Тогда операция -b+sqrt(D) потеряет почти все значащие биты в представлениях b и sqrt(D). Мы получим какое-то решение, но оно легко может на 10-20% отличаться от истинного. А второе решение, где берется минус, будет в порядке. Тут-то и пригождается альтернативная формула: где в обычной минус, в ней плюс и наоборот. Тот же корень она позволит вычислить с гораздо большей точностью. Все старое опять становится новым. Когда-то в 70-х и 80-х годах прошлого века, такие трюки были обыденным делом для программистов. Потом мы все привыкли к 64-битным вещественным типам и обленились, хотя конечно эксперты в определенных областях знали и это и гораздо более продвинутые техники численного анализа. А сейчас в нейронных сетях один из главных трендов - снижение точности до 32- и 16-битных представлений, чтобы выиграть скорость и память на миллионах и миллиардах параллельных операций внутри GPU. Не то чтобы с 64-битными числами не надо никогда следить за точностью, но в 32- и 16-битных эта проблема опять выходит на передний план.
А вы знаете про альтернативную формулу решений квадратного уравнения?
Вместо "минус бэ плюс-минус корень... поделить на два а", в ней "2це поделить на минус бэ минус-плюс корень...".
Ну, разобраться в том, что она дает ровно те же два решения, не очень тяжело.
Почему там "минус-плюс" в знаменателе, тоже не бином Ньютона: суть в том, что один и тот же корень получается, если в первоначальной формуле взять плюс, а в этой минус. И наоборот, если в обеих взять плюс, то выйдут два разных корня, в общем случае.
Но вот зачем это все надо? Те, кто знают, уже усмехаются и кивают, а я расскажу.
Это нужно, если обычная формула заставляет сделать "катастрофическое сокращение". Что такое катастрофическое сокращение, спросите вы? Это когда мы делаем вычитание двух чисел, очень близких друг к другу. Из-за того, как вещественные числа записываются в памяти компьютера (вспоминайте эти странные слова: мантисса... экспонента...),
происходит потеря точности.
Например, если b очень большое в сравнении с a,c, то получится, что дискриминант sqrt(b^2-4ac) очень близок по значению к b. Тогда операция -b+sqrt(D) потеряет почти все значащие биты в представлениях b и sqrt(D). Мы получим какое-то решение, но оно легко может на 10-20% отличаться от истинного. А второе решение, где берется минус, будет в порядке.
Тут-то и пригождается альтернативная формула: где в обычной минус, в ней плюс и наоборот. Тот же корень она позволит вычислить с гораздо большей точностью.
Все старое опять становится новым. Когда-то в 70-х и 80-х годах прошлого века, такие трюки были обыденным делом для программистов. Потом мы все привыкли к 64-битным вещественным типам и обленились, хотя конечно эксперты в определенных областях знали и это и гораздо более продвинутые техники численного анализа. А сейчас в нейронных сетях один из главных трендов - снижение точности до 32- и 16-битных представлений, чтобы выиграть скорость и память на миллионах и миллиардах параллельных операций внутри GPU. Не то чтобы с 64-битными числами не надо никогда следить за точностью, но в 32- и 16-битных эта проблема опять выходит на передний план.
