hudrogen

Стартонуть 100 потоков - не лучшая идея. Если у вас конечно не 100 ядерный сервер или кластер.

Создатт ExecutorPool на количество с n + 1 потоков. И запихните туда свой Callable. А потом ждите результата на get()

Вот тут официальный оракловский туториал, как это сделать. Я уверен он поможет разобраться.

https://blogs.oracle.com/CoreJavaTechTips/entry/ge...

Используйте коллекции, как уже советовали выше, например очереди или Map'ы. Лучше использовать из пакета java.util.concurrent
Еще можно заюзать новый интерфейс Callable -

docs.oracle.com/javase/7/docs/api/java/util/concur...

Который как раз может возвращать значение, в отличии от Runnable.

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

Можно использовать Future. Ну или синхронизацию.
Кстати, для многопоточности надо использовать контейнеры, которые специально заточе.... А судя по приведённому коду, тебе нужно почитать литературу по многопоточности в java, а не спрашивать тут такие вещи. Тогда и таких вопросов не будет возникать.

Так ведь же написано: Интерфейс программирования осуществляется через OpenCL

Всяк кулик свой буллшит хвалит. Но в реальности пользоваться можно чем угодно, любой средой разработки. Разумеется, у каждого свои недостатки (ограничения) и достоинства перед первичной основной средой разработки, выбранной авторами платформы. Нужно просто знать эти недостатки\достоинства. Рано или поздно Вы упретесь в ограничения ненативной среды разработки.
Я использую не Java для Android, и на 95% мне хватает возможностей, но ... для профессиональной работы в крупных\серьезных организациях Вам, конечно, придется использовать только нативный, общепринятый инструмент - всегда максимально эффективный и сложный в освоении (в сравнении с прочими). Но часто полностью бесплатный.

Единственное что имеет смысл использовать вместо java это kotlin, но только если вы хипстер и готовы идти на риски вроде "все перестало работать" на пустом месте. А так, пока не советую.

Basic4Android, Kivy и иже с ними - мусор и не заслуживают внимания.

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

> если на Basic4Android, Delphi XE разработка гораздо легче как выражаются создатели Basic4Android, Delphi XE ?

а ты ожидал, что производитель какой-то неведомой херни под названием "Basic4Android" скажет "никогда не пробуйте, это намного сложнее, чем на Java!!1"

Каждый кулик будет нахваливать своё болото. Ты еще дельфи для пыха вспомни.
По моему субъективному мнению, это всё ересь.
Изучи подход, предлагаемый автором системы, а все погремушки - потом.

На Basic4Android, Delphi XE, разработка, извините, через задницу.
1. Java вариант поддерживается производителем (Google)
2. Комьюнити гораздо, гораздо больше
Этих двух пунктов должно быть достаточно. Тут может быть их гораздо больше, но я с Basic4Android иDelphi XE не работал и не знаю всех косяков, которые из-за них вылезают )

Можно и гвозди глазом забивать…

1. берите QT
2. берите wxWidgets

пишите один раз и под все платформы, ну или конкретно для одной

1. С++ кроссплатформенный язык, поэтому под разными платформами будут разные api для GUI, которые принадлежат платформе, а не С++.
2. Чтобы работать с устройствами средствами Windows, которая предлагает свой UAC и другие средства/аттрибуты, присущие windows системе.
3. Нет, но штатные методы подразумевают прямой доступ к устройству, а winapi - через драйвера windows.

Попала в руки олдскульная книжка"Microsoft Windows 2000 API" листая которую возникли вопросы.

Не читайте Windows-литературы перед едой!

1. Применительно к Win и С++ native, есть старая библиотека MFC. Есть C++.net, а там и WPF и формы. А вообще есть Qt, он работает поверх Win Api
2. Что бы писать приложения оптимизированные под работу с осью. Было сильно актуально, когда не хватало вычислительных мощностей.
3. Думаю что там своя кросс-платформенная реализация. К тому же, Win API - это не С++, а "С"

1) нет
2) 3) Да, стандартные методы C++ - обертки над API различных ОС. Зачем - каждый пишет о том, о чём хочет.

В C++ нет штатных средств создания GUI. Это универсальный язык.
"Штатные средства" - обертки над системными вызовами, описание интерфейсов ОС может быть нужно для написания таких новых оберток.

первое что приходит в голову консольное приложение на python которому delphi скармлевает массивы и получает результат, но овчинка не стоит выделки, проще написать все что нужно на delphi

Для таких вещей очень удобен python со своими математическими библиотеками numpy и scipy.

Вот код, который решает Вашу задачу поиска неизвестных коэффициентов:

import numpy as np
from scipy.optimize import curve_fit

test_a = 1.7
test_b = -5.689
test_c = 1.2456


def test_sin(x, a, b, c):
    return a + b * np.sin(x + c)

if __name__ == '__main__':
    x = np.array(range(10))   
    y = test_sin(x, test_a, test_b, test_c)

    params, cov = curve_fit(test_sin, x, y)
    print(params)

Ссылка на описание функции curve_fit.

lab.polygonal.de/?p=205
оно?