The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Недоработка в Python-скрипте могла привести к неверным резул..., opennews (??), 13-Окт-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


280. "Недоработка в Python-скрипте могла привести к неверным резул..."  –1 +/
Сообщение от Аноним (280), 14-Окт-19, 12:20 
Не в современности дело, а в том, что неверно делать ПО для научных расчетов на скриптовом языке к тому же с использованием библиотек, не обладающих свойством кроссплатформенности.
Ответить | Правка | Наверх | Cообщить модератору

281. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (-), 14-Окт-19, 12:24 
Ну так, что бы, в самом деле, не пользоваться Julia? Весь код на ней. Все тесты - на ней же.
Ответить | Правка | Наверх | Cообщить модератору

286. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (280), 14-Окт-19, 12:50 
Думаю, научное ПО нужно делать на C/C++ с использованием кроссплатформенного инструментария, такого как Qt. Ранее мое мнение было иным. Возможно, в будущем мнение также изменится. Но на сегодняшний день оно таково.
Ответить | Правка | Наверх | Cообщить модератору

294. "Недоработка в Python-скрипте могла привести к неверным резул..."  +1 +/
Сообщение от Аноним (-), 14-Окт-19, 14:06 
> Думаю, научное ПО нужно делать на C/C++

Все математические языки программирования имеют нумерацию индексов массивов с 1. И компоновка памяти, чаще, фортрановская с упакованными колонками. И языками этими, банально, удобнее пользоваться для программирования именно математики, чем C++. А вот мешанина научный язык - C++ - лишнее место возникновение проблем.

Ответить | Правка | Наверх | Cообщить модератору

300. "Недоработка в Python-скрипте могла привести к неверным резул..."  –1 +/
Сообщение от Аноним (280), 14-Окт-19, 14:40 
> Все математические языки программирования имеют нумерацию индексов массивов с 1.

В С можно сделать нумерацию с 1. Но не нужно. К тому же некоторые алгоритмы предполагают нумерацию с нуля.

> И компоновка памяти, чаще, фортрановская с упакованными колонками.

Не совсем понятно, что имеется в виду. Если речь о массивах векторов различной длины (а также передачи через формальные параметры части массива размерности более 1), то проблема надежно решается использованием в функциях на С только одномерных массивов. Таким образом в данном случае передается указатель на первый элемент массива, количество векторов и массив длин векторов. Кстати, идея не нова. Она как раз из Фортрана. Эффективно применялась в известной математической и статистической библиотеке SSP.

Ответить | Правка | Наверх | Cообщить модератору

306. "Недоработка в Python-скрипте могла привести к неверным резул..."  +1 +/
Сообщение от Аноним (306), 14-Окт-19, 15:00 
> Не совсем понятно, что имеется в виду. Если речь о массивах векторов различной длины

Речь о том, что скорость прохода по элементам матрицы различна в случае: сначала по строкам, потом по колонкам и наоборот в зависимости от языка программирования. В фортрановской ветки, соответственно матлаб и джулия, именно колонка содержит последовательные элементы. В С-ветви, строка содержит последовательные элементы. Если сделаешь наоборот, то резко снижается производительность алгоритма.

Ответить | Правка | Наверх | Cообщить модератору

356. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Окт-19, 12:17 
> Если сделаешь наоборот, то резко снижается производительность алгоритма.

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

Ответить | Правка | Наверх | Cообщить модератору

303. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (280), 14-Окт-19, 14:46 
> мешанина научный язык - C++

Никакой проблемы. Еще на заре ПК, когда был большой багаж научных программ на Фортране, именно "смешанное" программирование: алгоритмы на Фортране, всё остальное (меню, ввод и вывод) на С - показало свою эффективность. В последующем, если говорить о нас, все фортрановские функции были переписаны на С. И опять же для скорости и удобства была реализована модель: алгоритмы на С, всё остальное на Visual Basic. Впрочем, необходимости в этом сейчас уже нет. Всё реализуется на С++.

Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

307. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (306), 14-Окт-19, 15:06 
Никогда не задумывались, почему за 40 лет так на C и не сделали удобный инструмент для интерактивного программирования математики, а все 40 лет пользовались R? Или почему, несмотря на все изменения C++ и новейшие его стандарты со всякими модными нашлёпками, так никто не пишет в Jupyter Notebook на нём?

Julia - как раз тот язык, которым удобно пользоваться как для небольших расчётов, так и собирать что-то сложное из отдельных модулей. При этом, технология монолитна. Она не требует для компенсации провалов производительности что-то писать на C

Ответить | Правка | Наверх | Cообщить модератору

330. "Недоработка в Python-скрипте могла привести к неверным резул..."  +2 +/
Сообщение от Аноним (330), 14-Окт-19, 20:33 
"about 50% of R is written in C, and just under 30% in Fortran" (c) https://blog.revolutionanalytics.com/2011/08/what-language-i...
Ответить | Правка | Наверх | Cообщить модератору

304. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (280), 14-Окт-19, 14:48 
> Ну так, что бы, в самом деле, не пользоваться Julia

Цитата из Википедии: "Julia написана на Си, C++..."

Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

305. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (306), 14-Окт-19, 14:56 
И что? Как это соотносится с кодом, который пишут на Julia и тем, как он выполняется далее?
Ответить | Правка | Наверх | Cообщить модератору

319. "Недоработка в Python-скрипте могла привести к неверным резул..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Окт-19, 18:49 
>> Ну так, что бы, в самом деле, не пользоваться Julia
> Цитата из Википедии: "Julia написана на Си, C++..."

Я не поклонник Юлий, но вырывать цитаты из контекста … нехорошо
> with C++ for the LLVM dependency.
> he LLVM compiler infrastructure project is used as the back end for generation of 64-bit or 32-bit optimized machine code depending on the platform Julia runs on. With some exceptions (e.g., PCRE), the standard library is implemented in Julia itself.

|

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

331. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (330), 14-Окт-19, 20:37 
> Я не поклонник Юлий, но вырывать цитаты из контекста … нехорошо

Т.е. Вы полагаете, что Julia не написана на C++? Думаю, что фактом написания на C++ стоит гордиться.

Ответить | Правка | Наверх | Cообщить модератору

332. "Недоработка в Python-скрипте могла привести к неверным резул..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Окт-19, 20:59 
>> Я не поклонник Юлий, но вырывать цитаты из контекста … нехорошо
> Т.е. Вы полагаете, что Julia не написана на C++?

Я полагаю ровно то, что написал -- нехорошо вырывать цитаты из контекста.

В остальном, я предпочитаю не полагать и не предполагать -- если можно просто посмотреть:
https://github.com/JuliaLang/julia
>  Julia 68.7%      C 16.3%      C++ 9.9%      Scheme 3.2%      Makefile 0.7%      LLVM 0.4%      Other 0.8%

Ответить | Правка | Наверх | Cообщить модератору

311. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от аноним3 (?), 14-Окт-19, 16:13 
питон создавался изначально как самое кроссплатформенное решение из всех имеющихся. то что он не заточен под сильно нагруженные задачи, то да. так кто с этим спорит. хотя в наш век все кричат , что следить за памятью и ресурсами не нужно. купил планку и дальше гоняй. типа если не смог то ло*х. хотя я категорически против. от этой идеи в итоге страдают все. гляньте на операционки. электроны, js, qml и прочие гадости только отнимают ресурсы, а при этом улучшения в самих операционкак как бы почти и нет.
Ответить | Правка | К родителю #280 | Наверх | Cообщить модератору

329. "Недоработка в Python-скрипте могла привести к неверным резул..."  +/
Сообщение от Аноним (330), 14-Окт-19, 20:29 
Всем спасибо за обсуждение. Надеюсь, пользователи сделают правильный выбор.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру