лучше запрашивать готовые чарты, очень много мелочей нужно учитывать, например, бар может открыться с опозданием на несколько минут, или на несколько минут раньше закрыться, или вообще может быть пропуск бара. более правильный подход - запросить снапшот баров, подписаться на асинхронные обновления и дополнять снапшот, тогда у вас будет всегда актуальный набор данных
# if current candlestick closed
if datetime.now().minute % 5 == 0:
# get latest price for the symbol
latest_price = client.futures_symbol_ticker(symbol=symbol)['price']
latest_price = float(latest_price)
prices.append(latest_price)
Вот это условие будет в течение 60 секунд добавлять цены в массив и запрашивать клиентский API, и еще, нужно проверять не текущее время суток, а время изменения цены, иначе, предположим, если рынок "замрет" на час, массив будет наполнен протухшими ценами
Конкретно вот схема, линии адреса A18 и A19 в XT использовались для выбора между кристаллами RAM, ROM и всем остальным, что есть в адресном пространстве за С0000, более того, опционально, через набор джемперов, могли быть задействованы еще A16 и A17, это объясняет почему "с завода" больше 256к не ставили.
Следовательно, в том и была задумка, чтоб железо за C0000 унести, а почему так? да потому, что 640к хватит на все...
Не нет, а да :) Ничего не имею против непрерывного адресного пространства которое мог адресовать процессор. Но в это пространство вероломно врывалась всякая ерунда, кроме CGA можно было установить другие видео адаптеры, с другими адресами, соответственно, диапазоны адресов резервировались, так как и другие адаптеры тоже вероломно врывались в непрерывное адресное пространство, а линии адреса A19 и A18 (C0000 - и выше) использовались для своих какихто нужд. Вот и получалось что из 1м простым пользователям доставалось только половина (правда, большая, но все равно половина). И, кстати, те устройства расширения требовали цыганских трюков на ассемблере, либо специальных драйверов, из-за чего они были полезны только для специфичных задач.
Простите, а какие IBM PC были до эпохи IBM PC/XT? IBM PC/XT выпускались с 128кб и возможностью расширения до 512кб, ограничение связано с тем, что процессор имел 20 битную шину адреса, 1 пин которой использовался для выбора внешнего устройства. Позже у процессоров была 24-х разрядная шина адреса с возможностью адресовать 16Мб памяти. И, таки, да- фраза про 640кб относилась к процессорам с 20 разрядной шиной адреса, а не к конкретной архитектуре или модели IBM. Эх молодежь...
Вот как в OpenJDK 10 (и мне кажется, что в последующих версиях ничего менялось) реализовано и описано, ничего про Mutable или Immutable, просто fixed-size. Пусть не смущает ArrayList — это вложенный класс, реализующий простую обертку над массивом. Суть этого метода — предоставить доступ к элементам массива через интерфейс List, что и сказано в документации «This method acts as bridge between array-based and collection-based APIs».
/**
* Returns a fixed-size list backed by the specified array. (Changes to
* the returned list "write through" to the array.) This method acts
* as bridge between array-based and collection-based APIs, in
* combination with {@link Collection#toArray}. The returned list is
* serializable and implements {@link RandomAccess}.
*
* <p>This method also provides a convenient way to create a fixed-size
* list initialized to contain several elements:
* <pre>
* List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");
* </pre>
*
* @param <T> the class of the objects in the array
* @param a the array by which the list will be backed
* @return a list view of the specified array
*/
@SafeVarargs
@SuppressWarnings("varargs")
public static <T> List<T> asList(T... a) {
return new ArrayList<>(a);
}
Следовательно, меняя элементы в полученном списке они будут заменены и в исходном массиве:
А вот что касается принципов SOLID, и буквы «L», и что имплементации интерфейсов должны быть заменяемыми без нарушения корректности программы, тут хотелось бы обратить внимание, что бросаемые исключения не являются нарушением корректности программы, просто, надо делать как надо, а как не надо делать не надо)
В PHP если на каждой из них нет большой нагрузки все ограничено дисковыми пространством
Это Вы про тот случай, когда основными источниками трафика на сайте являются фрилансеры и их заказчики? Так для таких целей PHP хорош как он есть, и без всяких улучшений!
Границ у этих, так сказать, целей нет. В этом весь фокус. Достигнув простой цели, планка требований поднимется выше, потом ещё выше, и ещё… а потом бах и OutOfMemoryException, например.
Так или иначе язык ограничен (любой язык), а задачи — нет. Так может разработчикам PHP пора начать делать что-то более серьезное чем добавление сахара из других языков? Начать с таймера и многопоточности, вот тогда язык станет языком вне конкуренции, а не темой для холиваров.
Скоро линии развития PHP и Java сойдутся в одной точке пространства-времени. Но покуда жизненный цикл PHP скрипта будет 'выполнил задачу или запрос и сдох' по-насоящему лучше он не станет.
лучше запрашивать готовые чарты, очень много мелочей нужно учитывать, например, бар может открыться с опозданием на несколько минут, или на несколько минут раньше закрыться, или вообще может быть пропуск бара.
более правильный подход - запросить снапшот баров, подписаться на асинхронные обновления и дополнять снапшот, тогда у вас будет всегда актуальный набор данных
Вот это условие будет в течение 60 секунд добавлять цены в массив и запрашивать клиентский API, и еще, нужно проверять не текущее время суток, а время изменения цены, иначе, предположим, если рынок "замрет" на час, массив будет наполнен протухшими ценами
Конкретно вот схема, линии адреса A18 и A19 в XT использовались для выбора между кристаллами RAM, ROM и всем остальным, что есть в адресном пространстве за С0000, более того, опционально, через набор джемперов, могли быть задействованы еще A16 и A17, это объясняет почему "с завода" больше 256к не ставили.
Следовательно, в том и была задумка, чтоб железо за C0000 унести, а почему так? да потому, что 640к хватит на все...
Не нет, а да :) Ничего не имею против непрерывного адресного пространства которое мог адресовать процессор. Но в это пространство вероломно врывалась всякая ерунда, кроме CGA можно было установить другие видео адаптеры, с другими адресами, соответственно, диапазоны адресов резервировались, так как и другие адаптеры тоже вероломно врывались в непрерывное адресное пространство, а линии адреса A19 и A18 (C0000 - и выше) использовались для своих какихто нужд. Вот и получалось что из 1м простым пользователям доставалось только половина (правда, большая, но все равно половина).
И, кстати, те устройства расширения требовали цыганских трюков на ассемблере, либо специальных драйверов, из-за чего они были полезны только для специфичных задач.
Простите, а какие IBM PC были до эпохи IBM PC/XT? IBM PC/XT выпускались с 128кб и возможностью расширения до 512кб, ограничение связано с тем, что процессор имел 20 битную шину адреса, 1 пин которой использовался для выбора внешнего устройства. Позже у процессоров была 24-х разрядная шина адреса с возможностью адресовать 16Мб памяти.
И, таки, да- фраза про 640кб относилась к процессорам с 20 разрядной шиной адреса, а не к конкретной архитектуре или модели IBM. Эх молодежь...
Следовательно, меняя элементы в полученном списке они будут заменены и в исходном массиве:
А вот что касается принципов SOLID, и буквы «L», и что имплементации интерфейсов должны быть заменяемыми без нарушения корректности программы, тут хотелось бы обратить внимание, что бросаемые исключения не являются нарушением корректности программы, просто, надо делать как надо, а как не надо делать не надо)
Если выполниться одно из условий, то оператор break someLabel выведет выполнение из блока
Границ у этих, так сказать, целей нет. В этом весь фокус. Достигнув простой цели, планка требований поднимется выше, потом ещё выше, и ещё… а потом бах и OutOfMemoryException, например.
Так или иначе язык ограничен (любой язык), а задачи — нет. Так может разработчикам PHP пора начать делать что-то более серьезное чем добавление сахара из других языков? Начать с таймера и многопоточности, вот тогда язык станет языком вне конкуренции, а не темой для холиваров.
Скоро линии развития PHP и Java сойдутся в одной точке пространства-времени. Но покуда жизненный цикл PHP скрипта будет 'выполнил задачу или запрос и сдох' по-насоящему лучше он не станет.