Куда помещать табличные данные для програмки

а можно по русски?

У меня в голове крутиться такой вариант марка двигателя, скорость вращения, ном ток, ном момент, и т.д. …

всё это я записываю в лист [code] (set! mark1 (list n I M …)) (set! mark2 (list n I M …)) ….. [/code] и всё это будет грузиться с программкой, а хотелось бы чтобы это было отдельно и програмка бы туда обращалась за данными, а как так сделать не знаю.

Храни данные в XML, а программа пусть его при старте парсит. Выхлоп будет в виде записей.

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

за тебя уже все придумали. Самый топовый сейчас вариант json. Если много данных можно взять хотя бы sqlite

Если он пишет на каком-нибудь MIT Scheme, то из коробки парсера не будет.

В отдельный файл

Именно так, пиши в файл

#марка   скорость  ток  момент 
тошиба   100500    1.5  3.2
якудза   500100    2.5  2.2
омаива   880055    3.5  1.2

Затем читай строку из фала. Не знаю как в scheme но в си теперь можно передать строку в sscanf() и получить значение

struct data_t
{
   char   name[512];
   int    speed;
   float  A;
   float  moment;
}data;

sscanf(string,"%s %i %f %f",&data.name,&data.speed,&data.A,&data.moment);

if(strcmp(data.name,"тошиба")==0)
{
   printf("Есть параметры тошибы, заводи машину!\n");
}

Далее из файла читаешь следующую строку и всё. У тебя же данные одни и теже понимаю. Вот тебе надо тоже самое только для scheme.

lovesan помоги падавану.

В чем проблема хранить в схемовских структурах данных в отдельном файле и нативно загружать? Советы по хранению в xml позабавили :)

Со структурами данных в схеме я наверное еще не знаком.

Падаван

Это кто!

У тебя из вариантов только записи (там, где они реализованы, а сделано это может быть по-разному) и хэш-таблицы, ну. При этом, если ты хочешь записать много двигателей, то первый вариант [для хранения в списках, разумеется] становится предпочтительней, а если очень много, то есть смысл хранить вообще не в нативном для языка формате, а внешнем, из которых для большинства реализаций готовый для разбора прямо в поставке есть только один – XML.

У тебя какая реализация Scheme? MIT? Guile? Gambit? Chicken? Chez?

Racket.

Отлично! А таких записей, ну, там где торговая марка двигателя, скорость вращение и прочее, много, или одна? Если много, то сколько примерно?

Листа четыре, офсетной печати.

Со структурами данных в схеме я наверное еще не знаком.

А они там что, какие-то особенные? Хеш-таблицы, списки, массивы, структуры, просто строки. Смотришь, что лучше подходит для твоих данных и берешь. Все нормальные фреймворки хранят данные в структурах языка, а не каких-то уе$%щных xml / ini.

А тебе нужно в программе нужно просто пройтись по ним, или обращаться к каждому напрямую?

Если у тебя какая-то специфическая прям структура данных (очень редко так бывает) - берешь и пишешь свою, с вероятностью 98,2% тебе это не нужно.

Надо выбрать двиг по току, моменту и вытащить момент инерции.

Да какая там специфичная.

name[512];

Сишники ужасны.

Ну хорошо, расскажи тогда, чем тебе для «табличных данных» не подходит двумерный массив?

Мне надо еще понять что такое двумерный массив и как его реализовать в ракете. Сбрось пару строк для наглядности.

Cмотри. Если ты хочешь просто вбить эти данные себе и забыть про них, то можно действительно их подгружать как отдельный модуль, описав их в типах данных языка. Это будет быстрее и проще, да и если ты единственный, кто имеет с этими данными дело, то, наверное, и самый правильный вариант. Но если их в будущем потребуется часто менять, и менять, возможно, кому-то другому – лучше заранее продумать, как их хранить в каком-нибудь другом представлении. Просто подумай об этом.

Наиболее простым (но наименее производительным, имей в виду!) вариантом будет хранить данные в виде списка из ассоциативных списков:

(list '( ;; здесь описываем какой-нибудь двигатель:
	'('model . "Модель такая-то")
	'('spinning-speed . 100) ;; или какая там у тебя скорость
	'(...) ;; и так далее
	...)
      '( ;; и вот ещё один:
	'('model . "...")
	'('spinning-speed . 200)
	'(...)
	)
      ...)

Ассоциативный список – это такой список, в котором находятся пары из ключа и значения (именно в этом порядке), и он выступает таким словариком. Значения вытаскиваются так:

(assq v lst) → (or/c pair? #f)

Например, вот такое выражение:

(assq 'c (list (list 'a 'b) (list 'c 'd) (list 'e 'f)))

Вернёт вот это:

'(c d)

То есть, нужную пару из ключа и значения. Искать двигатель по току, моменту и прочему можно с помощью filter:

(filter pred lst) → list?

Например, вот так можно отфильтровать положительные числа:

(filter positive? '(1 -2 3 4 -5))

Но вообще, советую использовать хэш-таблицы. Они гораздо быстрее работают, и вообще это больше по уму.

Мне надо еще понять что такое двумерный массив

У тебя какой опыт в программировании и на каких языках?

и как его реализовать в ракете. Сбрось пару строк для наглядности.

https://docs.racket-lang.org/math/array_quick.html

Ух ты, здорово, если завтра будет время попробую.

Вместо ассоциативных списков можешь использовать записи – они гораздо лучше подходят для этой задачи, а ещё работают побыстрее. Но для этого тебе надо будет подгрузить модуль с их реализацией. Скорее всего, этот. К сожалению, к нему доступна только спецификация, но для другого диалекта Scheme, Guile, есть более простое описание того, как с ними работать.

Опыт, ты смеяться будешь, одна программа на elisp исследования четырех звенного механизма аж 900 строк кода с использованием widget и малюсенькая программка перевода градусов минут секунд в радианы с окошечком на ракете. И когда то давно маленькая часть курсовика на AutoCAD cl. That’s all of my experience in programming.

Спасибо.

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

Ты, ученик. Который ещё не познал силу. Познавший силу является джедаем.

В редис пихай. :)

и всё это будет грузиться с программкой, а хотелось бы чтобы это было отдельно и програмка бы туда обращалась за данными

Ну прямо в листах и опиши. Но грузи схемошным ридером. Там просто порт открываешь файловый и из него read делаешь. Если не попутал функцию чтения. И всё в структуре будет и отдельно.

Обычно достаточно csv, но если данных много, то sqlite чтоб запросы делать

Ничего себе, какой лишп читаемый нынче стал :)

Обычно достаточно csv, но если данных много

c ~10 млн. строк норм работает, правда на java.

Ухты, весьма специфический опыт. Ну, я тогда бы советовал вообще просто что-то по программированию почитать, есть хорошие книги как раз на лиспе (схеме) и питоне. А на какой специальности учишься, что у вас совсем нет никакого программирования и тем более всяких там pascal, java, c++?

На учебе я программировал микропроцессор кр 560 если не ошибаюсь, на ассемблере. А с лиспом столкнулся когда решил диплом другой специальности получить, да плюнул, неинтересно. Книжки я читал, задачи перед собой не было, так знания почерпнутые из книжек понемножку забываясь еще находятся в голове А с студентами программистами одно разочарование, как то написал парсер на awk для html, показал им, они ахнули но он работал только на одной странице, на другой что попало городил, попросил его подпилить, был момент Зена, они растерялись, просто потому что не знали как это делается, вот так.

Racket

Кури мануалы же https://docs.racket-lang.org/csv-reading/index.html

Так ты препод или что, я так и не понял? :) Лисп хорошая штука, есть clojure, racket, cl - каждого свои преимущества и недостатки. На счет табличных данных - либо родные структуры данных, либо csv, как здесь сказали. Никаких там xml и прочей хероты.

Да не я не препод, я просто когда в отпуске развлекаю себя как могу, чтобы не спиться не в значай.

Спасибо, за наколку.

Ели программа грамотно написана, то достаточно просто сохранить в файл и все. Не важно как оно в файле будет выглядеть, если table.SaveToFile() есть значит и table.LoadFromFile() из этого файла пройдет успешно. Что касается логической организации, формы там и т.д то это не вопрос хранения и программирования вообще, это вопрос проектирования схемы данных. Если же надо максимально просто хранить table-like данные в text-формате, то text/csv - like вполне подойдет.

Хорошая корректировка, вопрос проектирования схемы данных.