Да, конечно, FindSequenceFunction не найдет всего, хотя спектр того, что найдет очень широк. Поэтому про OEIS и написал, потрясающий сайт.
Что касается FindFormula — ее главная задача, как я считаю, дать толчок для поисков или решить задачи не очень сложные, относительно, в полностью автоматическом режиме.
FindFit уже требует явного указания на то, в каком виде искать.
Вообще, эта тема очень интересная — оптимизация — если читателю интересно — то подробнее об этом можно почитать в разделе Optimization.
Вообще примерно можно указать круг функций, относящихся к оптимизации (их больше — еще спец. функции машинного обучения, всевозможные оптимизации выражений и т. п.)
Вы говорите о преимуществах точной зависимости — они, конечно, бесспорны. Особенно если зависимость проста.
Когда я занимался математической физикой — там часто появлялись аналитические зависимости, которые для численного счета можно было выкинуть в топку — ряды от несобственных интегралов, скажем, которые аналитически берутся в свою очередь в ряды…
Конечно для решения того, о чем вы пишите аналитическая зависимость прекрасна, я по-моему с этим и не спорю, а подтверждаю.
Другое дело, что она откровенно не всегда нужна и я бы не советовал всегда все сводить к поиску аналитической зависимости. Как только отойдешь от чистой математики в сторону обработки реальных данных, выяснится, что аналитически там ни одну зависимость не продлить и нужны уже совсем другие методы.
Да, хочу заметить, что встроенная функция LinearRecurrence отлично справляется с рекуррентными последовательностями.
Последовательность Фибоначчи в ней будет задаваться как:
LinearRecurrence[{1, 1}, {1, 1}, n]
Эта конструкция еще примерно в 2 раза быстрее чем та, что основана на мемоизации. Особенно, если использовать приближенные начальные значения и потом их перевести в целые:
Да, это круто!
Просто это такая, назовем её, "научная оптимизация".
Это безусловно круто, если так получается, но очевидно это требует много таланта.
Статья же посвящена больше приемам оптимизации, которые будут работать независимо от того, насколько круто программист умеет что-то упрощать с точки зрения теории и науки.
В целом я описал свой взгляд уже выше)
И да и нет. Смотрите: когда я руководил на протяжении почти 3 лет разработкой очень большого продукта образовательного (издательство Баласс) регулярно приходилось искать компромисс между качеством и скоростью: часто разработчики хотят сделать круто, и это очень ценно. Но часто решение нужно уже сегодня, как говорится. Поэтому приходится часто откидывать «оптимизацию» и её продумывание до рефакторинга, потому что тратить время и деньги сейчас нецелесообразно.
Проблема в том, что оптимизация может съесть больше времени, чем будет от нее выхлоп. Если речь идет о решении, использующемся здесь и сейчас — то нет смысла особенно морочиться и оптимизировать его. Напротив — если решение используется постоянно и, тем более, очень многими людьми — то чем больше в начале продумаешь и оптимизируешь, тем лучше.
2) способность WL решать рекуррентные уравнения вообще говоря не очевидна — я сам о ней узнал чисто случайно, и примеры с рекурсивным вычислением факториала этому никак не способствуют.
Да, как и многие вещи, поэтому нужно больше листать справку)))
По-моему, это очевидный недостаток языка или его реализации конкретной версии — учитывая, что сам Леонид Шифрин постоянно твердит «используйте встроенные функции, если они есть, и не изобретайте велосипеды».....
Да, все так, но как говорится — у каждого правила есть исключение.
Вам когда нибудь нужно было хотя бы 100 чисел Фибоначчи? Мне пока нет.
Так что для 99,(сколько-то девяток)% пользователей встроенной функции хватит, как и производительности). А тем, кому нужен триллион этих чисел — можно использовать другой алгоритм или поморочиться и получить формулу)
По-моему, тут не хватает самой главной рекомендации — не используйте списки и рекурсию там, где они не нужны явным образом. Использовать списки для рекурсивного нахождения чисел Фибоначчи — это треш, за это нужно бить палкой по голове. Вы можете не знать, что в WL есть встроенная функция для чисел Фибоначчи, но вы обязаны знать, что в WL есть решатель рекуррентных уравнений!
Думаю вы это не мне писали, а сообществу. В противном случае это просто смешно, так как эти функции я давно популяризирую.
То о чем вы написали — это уже не оптимизация кода. Если удается найти аналитическую зависимость, то ок, счет пойдет мгновенно, это очевидно. Но в большинстве случаев это нереально.
Рад, что в комментариях это отмечено. На канале у меня скоро выйдут ролики про FindSequenceFunction и RSolve, хотя там много функций, для поиска всяких зависимостей в последовательностях. А решение рекуррентных уравнений — это то, на чем все это базируется.
Если вам действительно нужен список из чисел Фибоначчи — не используйте примеры из статьи. Используйте
Table[Fibonacci[n], {n, 10}]
А вот тут вы жесткоко ошибаетесь. Встроенная функция медленная, весьма. Она может помимо чисел генерировать полиномы Фибоначчи, тут она может помочь. А так представленный способ быстр, причем чем больше нужно чисел, тем в большее число раз.
Я бы даже сказал, что WL — самый недооценённый язык на текущий момент, причём за пропаганду Mathematica мне никто ничего не платит))
Целиком согласен. Регулярно говорю об этом и требуется подчас потратить немало сил, чтобы убедить заказчика его использовать. Но потом ситуация меняется, когда распробуют)
Продвигать Mathematica нужно (как мне кажется) не для уже сформировавшихся разработчиков, а для школьников и студентов, у которых всё ещё впереди
Да, это разумно, безусловно. Как и то, что вы написали на тему Matlab, Maple, к которым я добавил бы еще Maple, скажем, и вещи, типа SymPy.
Кирилл, спасибо за отличный комментарий! Вы отлично уточнили эти пункты.
Безусловно все в одну статью невозможно запихнуть, а если углубляться в дебри, то можно написать хороший томик)
Перед собой я ставил главную цель: продемонстрировать на простых примерах главные краеугольные камни ускорения кода в Wolfram Language. Ведь, как я в статье постарался сфокусировать внимание читателя на том, что медленность Wolfram Language это миф. К сожалению, у нас пока что мало знают об этом языке.
Уточните, пожалуйста, что именно имеете ввиду? Если вам нужна интерактивная среда разработки — можете использовать:
Wolfram|One, Wolfram Cloud, Mathematica…
Когда мы с ребятами делали систему для одного очень крупного издательства — вы знаете, какой там был от сервера главного пароль и логин?
admin
admin1
Что касается FindFormula — ее главная задача, как я считаю, дать толчок для поисков или решить задачи не очень сложные, относительно, в полностью автоматическом режиме.
FindFit уже требует явного указания на то, в каком виде искать.
Вообще, эта тема очень интересная — оптимизация — если читателю интересно — то подробнее об этом можно почитать в разделе Optimization.
Вообще примерно можно указать круг функций, относящихся к оптимизации (их больше — еще спец. функции машинного обучения, всевозможные оптимизации выражений и т. п.)
Optimization (10)
ConicOptimization, LinearFractionalOptimization, LinearOptimization, QuadraticOptimization, SecondOrderConeOptimization, SemidefiniteOptimization, VectorGreater, VectorGreaterEqual, VectorLess, VectorLessEqual
Fitting (20)
FindFit, ConfidenceLevel, CovarianceEstimatorFunction, DesignMatrix, DispersionEstimatorFunction, ExponentialFamily, FindFormula, FitRegularization, FittedModel, GeneralizedLinearModelFit, IncludeConstantBasis, LeastSquares, LinearModelFit, LinearOffsetFunction, LinkFunction, LogitModelFit, NominalVariables, NonlinearModelFit, ProbitModelFit, VarianceEstimatorFunction, Weights
Min Max (22)
ArgMax, ArgMin, FindArgMax, FindArgMin, FindCurvePath, FindMaximum, FindMaxValue, FindMinimum, FindMinValue, FindShortestTour, KnapsackSolve, LinearProgramming, Maximize, MaxValue, Minimize, MinValue, NArgMax, NArgMin, NMaximize, NMaxValue, NMinimize, NMinValue
Net (90)
AggregationLayer, AppendLayer, AttentionLayer, BasicRecurrentLayer, BatchNormalizationLayer, BatchSize, CatenateLayer, ConstantArrayLayer, ConstantPlusLayer, ConstantTimesLayer, ContrastiveLossLayer, ConvolutionLayer, CrossEntropyLossLayer, CTCLossLayer, DeconvolutionLayer, DotLayer, DropoutLayer, ElementwiseLayer, EmbeddingLayer, ExtractLayer, FlattenLayer, GatedRecurrentLayer, LearningRate, LearningRateMultipliers, LinearLayer, LocalResponseNormalizationLayer, LongShortTermMemoryLayer, LossFunction, MaxTrainingRounds, MeanAbsoluteLossLayer, MeanSquaredLossLayer, NetAppend, NetBidirectionalOperator, NetChain, NetDecoder, NetDelete, NetDrop, NetEncoder, NetEvaluationMode, NetExtract, NetFlatten, NetFoldOperator, NetGraph, NetInformation, NetInitialize, NetInsert, NetInsertSharedArrays, NetJoin, NetMapOperator, NetMapThreadOperator, NetMeasurements, NetModel, NetNestOperator, NetPairEmbeddingOperator, NetPort, NetPortGradient, NetPrepend, NetRename, NetReplace, NetReplacePart, NetSharedArray, NetStateObject, NetTake, NetTrain, NetTrainResultsObject, NormalizationLayer, OrderingLayer, PaddingLayer, PartLayer, PoolingLayer, PrependLayer, ReplicateLayer, ReshapeLayer, ResizeLayer, SequenceLastLayer, SequenceMostLayer, SequenceRestLayer, SequenceReverseLayer, SoftmaxLayer, SpatialTransformationLayer, SummationLayer, ThreadingLayer, TotalLayer, TrainingProgressCheckpointing, TrainingProgressFunction, TrainingProgressMeasurements, TrainingProgressReporting, TrainingStoppingCriterion, TransposeLayer, UnitVectorLayer
Когда я занимался математической физикой — там часто появлялись аналитические зависимости, которые для численного счета можно было выкинуть в топку — ряды от несобственных интегралов, скажем, которые аналитически берутся в свою очередь в ряды…
Конечно для решения того, о чем вы пишите аналитическая зависимость прекрасна, я по-моему с этим и не спорю, а подтверждаю.
Другое дело, что она откровенно не всегда нужна и я бы не советовал всегда все сводить к поиску аналитической зависимости. Как только отойдешь от чистой математики в сторону обработки реальных данных, выяснится, что аналитически там ни одну зависимость не продлить и нужны уже совсем другие методы.
Последовательность Фибоначчи в ней будет задаваться как:
Эта конструкция еще примерно в 2 раза быстрее чем та, что основана на мемоизации. Особенно, если использовать приближенные начальные значения и потом их перевести в целые:
Просто это такая, назовем её, "научная оптимизация".
Это безусловно круто, если так получается, но очевидно это требует много таланта.
Статья же посвящена больше приемам оптимизации, которые будут работать независимо от того, насколько круто программист умеет что-то упрощать с точки зрения теории и науки.
В целом я описал свой взгляд уже выше)
И да и нет. Смотрите: когда я руководил на протяжении почти 3 лет разработкой очень большого продукта образовательного (издательство Баласс) регулярно приходилось искать компромисс между качеством и скоростью: часто разработчики хотят сделать круто, и это очень ценно. Но часто решение нужно уже сегодня, как говорится. Поэтому приходится часто откидывать «оптимизацию» и её продумывание до рефакторинга, потому что тратить время и деньги сейчас нецелесообразно.
Проблема в том, что оптимизация может съесть больше времени, чем будет от нее выхлоп. Если речь идет о решении, использующемся здесь и сейчас — то нет смысла особенно морочиться и оптимизировать его. Напротив — если решение используется постоянно и, тем более, очень многими людьми — то чем больше в начале продумаешь и оптимизируешь, тем лучше.
Да, как и многие вещи, поэтому нужно больше листать справку)))
Да, все так, но как говорится — у каждого правила есть исключение.
Вам когда нибудь нужно было хотя бы 100 чисел Фибоначчи? Мне пока нет.
Так что для 99,(сколько-то девяток)% пользователей встроенной функции хватит, как и производительности). А тем, кому нужен триллион этих чисел — можно использовать другой алгоритм или поморочиться и получить формулу)
Думаю вы это не мне писали, а сообществу. В противном случае это просто смешно, так как эти функции я давно популяризирую.
То о чем вы написали — это уже не оптимизация кода. Если удается найти аналитическую зависимость, то ок, счет пойдет мгновенно, это очевидно. Но в большинстве случаев это нереально.
Рад, что в комментариях это отмечено. На канале у меня скоро выйдут ролики про FindSequenceFunction и RSolve, хотя там много функций, для поиска всяких зависимостей в последовательностях. А решение рекуррентных уравнений — это то, на чем все это базируется.
А вот тут вы жесткоко ошибаетесь. Встроенная функция медленная, весьма. Она может помимо чисел генерировать полиномы Фибоначчи, тут она может помочь. А так представленный способ быстр, причем чем больше нужно чисел, тем в большее число раз.
Целиком согласен. Регулярно говорю об этом и требуется подчас потратить немало сил, чтобы убедить заказчика его использовать. Но потом ситуация меняется, когда распробуют)
Да, это разумно, безусловно. Как и то, что вы написали на тему Matlab, Maple, к которым я добавил бы еще Maple, скажем, и вещи, типа SymPy.
Безусловно все в одну статью невозможно запихнуть, а если углубляться в дебри, то можно написать хороший томик)
Перед собой я ставил главную цель: продемонстрировать на простых примерах главные краеугольные камни ускорения кода в Wolfram Language. Ведь, как я в статье постарался сфокусировать внимание читателя на том, что медленность Wolfram Language это миф. К сожалению, у нас пока что мало знают об этом языке.
Отрадно, что вы, очевидно, глубоко в теме)!
Еще каждую неделю делается разбор новых функций репозитория.
Wolfram|One, Wolfram Cloud, Mathematica…
Лично я применял в своей работе Wolfram со следующими заказчиками (Яндекс, Баласс, ВалентаФарм и др.).
Это можно делать через Wolfram Cloud выгружая через Cloud CDF, см. скажем Web Operations. Сами интерактивы делаются на основе Manipulate, DynamicModule.