Matrisberäkningar med för STM32?

[Gimbal]

Alltså var det språket som var "felet" på. GNU Octave kunde hantera "skitdata", vilket inte C++ eller C kunde.

Är det ena skitresultatet bättre än det andra, och i så fall vet du vilket skitresultat som är den bra skiten?

[Al_Bundy]

Det var Armadillo som kom fram till detta att >> DERAS SVD << gjorde samma resultat som mitt C bibliotek och GNU Octave visade något annat. Nej, det är ingen idé att du försöker slå dem på fingrarna. Dessa erhåller PhD inom beräkningsteknik.

[Al_Bundy]

Alltså var det språket som var "felet" på. GNU Octave kunde hantera "skitdata", vilket inte C++ eller C kunde.

Är det ena skitresultatet bättre än det andra, och i så fall vet du vilket skitresultat som är den bra skiten?

Dom två första värderna är jag endast intresserad utav. Men nu vet jag att min QR-algoritm är inte fel på iallafall.

[Al_Bundy]

Jag har hittat ett C-bibliotek för matrisberäkningar. Biblioteket heter CLAPACK och den är rent C som har konverterats från Fortran 77. Biblioteket är optimerat och välbeprövat.

Nu tänkte jag fråga er hur man går till väga för att installera detta bibliotek. Det finns en manual på deras hemsida som beskriver hur man kompilerar biblioteket.
https://www.netlib.org/clapack/

Jag är på steg 1. Har laddat ned clapack.tgz

Men på steg 2 kör jag fast.

dell@dell-Precision-M6400:~/Hämtningar/CLAPACK-3.2.1$ make f2clib
Makefile:7: make.inc: Filen eller katalogen finns inte
make: *** Ingen regel för att skapa målet ”make.inc”. Stannar.
dell@dell-Precision-M6400:~/Hämtningar/CLAPACK-3.2.1$

Jag lägger mitt C-bibliotek på is ett långt tag. Nu har man fått lite erfarenhet när det kommer till C. Detta ser jag som viktigaste för mig. Dags att använda riktiga verktyg.

[Shimonu]

Har du packat upp filen som de beskriver? Fanns det någon make.inc?

[Al_Bundy]

Ja.

[Shimonu]

Du måste ju anpassa make.inc.example efter dina behov som de har beskrivit och döpa om den till make.inc


.

[Al_Bundy]

Det är frågan vad jag vill ha. Jag kör GCC och jag vill kunna kompilera för ARM.
Jag testa kör denna fil som make.inc. OK. Det fungerade.


Jag måste dock ändra om alla double till float i Lapack först!

# -*- Makefile -*-
####################################################################
# LAPACK make include file. #
# LAPACK, Version 3.2.1 #
# June 2009 #
####################################################################
#
# See the INSTALL/ directory for more examples.
#
SHELL = /bin/sh
#
# The machine (platform) identifier to append to the library names
#
PLAT = _LINUX
#
# Modify the FORTRAN and OPTS definitions to refer to the
# compiler and desired compiler options for your machine. NOOPT
# refers to the compiler options desired when NO OPTIMIZATION is
# selected. Define LOADER and LOADOPTS to refer to the loader
# and desired load options for your machine.
#
#######################################################
# This is used to compile C libary
CC = gcc
# if no wrapping of the blas library is needed, uncomment next line
#CC = gcc -DNO_BLAS_WRAP
CFLAGS = -O3 -I$(TOPDIR)/INCLUDE
LOADER = gcc
LOADOPTS =
NOOPT = -O0 -I$(TOPDIR)/INCLUDE
DRVCFLAGS = $(CFLAGS)
F2CCFLAGS = $(CFLAGS)
#######################################################################

#
# Timer for the SECOND and DSECND routines
#
# Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME
# TIMER = EXT_ETIME
# For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME_
# TIMER = EXT_ETIME_
# For gfortran compiler: SECOND and DSECND will use a call to the INTERNAL FUNCTION ETIME
# TIMER = INT_ETIME
# If your Fortran compiler does not provide etime (like Nag Fortran Compiler, etc...)
# SECOND and DSECND will use a call to the Fortran standard INTERNAL FUNCTION CPU_TIME
TIMER = INT_CPU_TIME
# If neither of this works...you can use the NONE value... In that case, SECOND and DSECND will always return 0
# TIMER = NONE
#
# The archiver and the flag(s) to use when building archive (library)
# If you system has no ranlib, set RANLIB = echo.
#
ARCH = ar
ARCHFLAGS= cr
RANLIB = ranlib
#
# The location of BLAS library for linking the testing programs.
# The target's machine-specific, optimized BLAS library should be
# used whenever possible.
#
BLASLIB = ../../blas$(PLAT).a
#
# Location of the extended-precision BLAS (XBLAS) Fortran library
# used for building and testing extended-precision routines. The
# relevant routines will be compiled and XBLAS will be linked only if
# USEXBLAS is defined.
#
# USEXBLAS = Yes
XBLASLIB =
# XBLASLIB = -lxblas
#
# Names of generated libraries.
#
LAPACKLIB = lapack$(PLAT).a
F2CLIB = ../../F2CLIBS/libf2c.a
TMGLIB = tmglib$(PLAT).a
EIGSRCLIB = eigsrc$(PLAT).a
LINSRCLIB = linsrc$(PLAT).a
F2CLIB = ../../F2CLIBS/libf2c.a

[Icecap]

"Typ 15-20 stycken tror jag."

OK - men det besvarar inte frågan.
Min fråga var: Hur många behöver du? Och med ordet 'behöver' menar jag 'måste'.

Att du har 15-20 st är OK - men är det antal verkligt nödvändigt?
Eller är en del av dom mellanresultat?

[Al_Bundy]

Jag har inget svar på exakt hur många matriser jag kommer att använda. Tyvärr. Just nu tänkte jag testa CLapack om det fungerar för STM32. Jag redan en fundering om STM32 kan hantera datatypen double om det är en single precision CPU? Jag vet om att svaret är NEJ, men vad skulle hända? Systemfel, eller skulle double betraktas som en float?

http://www.netlib.org/lapack/lapacke.ht ... ungqr_code

Om Clapack INTE går att använda för STM32 så går jag då tillbaka till mitt C-bibliotek.

[Icecap]

Faktisk beror det på kompilern. Enl. standarden kan double == float i vissa fall.
Det går ganska säker att tvinga in en double men då blir alla uträkningar gjort i mjukvaran vilket lär ta tid.

[Al_Bundy]

> Det går ganska säker att tvinga in en double men då blir alla uträkningar gjort i mjukvaran vilket lär ta tid.

Så det är bättre att ha mjukvara för float, än att "räkna" en float från en double? Det är så du menar?

[hawkan]

Det går ju alltid att räkna med float och double, det är inbyggda datatyper i C.
Sedan vad som praktiskt händer kan man fundera på.
Finns hårdvara så får man hoppas att kompilatorn gör kod så den utnyttjas. Finns det inte så lägger den ut kod som inte är lika effektiv. Svaret ska dock bli exakt samma vad det gäller siffror och decimaler.
Det är klart man vill använda hårdvara för flyttalsberäkningar. Men för linjär algebra skulle jag alltid välja double för att få så bra precision som möjligt.
Du får väl avväga vad som är viktigt, precision eller beräkningstid eller båda.

[Al_Bundy]

För mig spelar det ingen roll. Jag måste ha ett alternativ som fungerar.

Frågan är om CLapack fungerar för inbyggda system så det inte är massa calloc, malloc överallt i vissa funktioner? Inte helt omöjligt.

[AndLi]

Konceptet rtfm är inget för dig va?

memory management is handled by the functions LAPACKE_malloc and LAPACKE_free. This allows users to easily use their own memory manager instead of the default by modifying their definitions in lapacke.h.

This interface should be thread-safe to the extent that these memory management routines and the underlying LAPACK routines are thread-safe.

Så gör en egen uc vänlig malloc och du är hemma.