infobase: EDV - Sprachen

Mathematische Funktionen

Abgeleitete mathematische Funktionen:

Einige Programmiersprachen enthalten je nach Version nur eine eingeschränkte Anzahl mathematischer Funktionen.

Die folgende Liste zeigt mathematische Funktionen, die von evtl. vorhandenen mathematischen Funktionen abgeleitet werden können (zugrundegelegt wurde hier der Funktionsumfang einer alten Basic-Version aus dem letzten Jahrtausend; modernere Sprachen beherrschen evtl. mehr Funktionen, die dann auch nicht nachgebildet werden müssen):

Funktion                       Access Basic-Äquivalent

Sekans                         Sec(X) = 1 / Cos(X)
Kosekans                       Cosec(X) = 1 / Sin(X)
Kotangens                      Cotan(X) = 1 / Tan(X)
Arkussinus                     Arcsin(X) = ArcTan(X / Sqr(-X * X + 1))
Arkuskosinus                   Arccos(X) = ArcTan(-X / Sqr(-X * X + 1)) + 1,5708
Arkussekans                    Arcsec(X) = ArcTan(X / Sqr(X * X - 1)) + Sgn(Sgn(X) -1) * 1,5708
Arkuskosekans                  Arccosec(X) = ArcTan(X / Sqr(X * X - 1)) + (Sgn(X) - 1) * 1,5708
Arkuskotangens                 Arccotan(X) = ArcTan(X) + 1,5708
Hyperbolischer Sinus           HSin(X) = (Exp(X) - Exp(-X)) / 2
Hyperbolischer Kosinus         HCos(X) = (Exp(X) + Exp(-X)) / 2
Hyperbolischer Tangens         HTan(X) = (Exp(X) - Exp(-X)) / (Exp(X) + Exp(-X))
Hyperbolischer Sekans          HSec(X) = 2 / (Exp(X) + Exp(-X))
Hyperbolischer Kosekans        HCosec(X) = 2 / (Exp(X) - Exp(-X))
Hyperbolischer Kotangens       HCotan(X) = (Exp(X) + Exp(-X)) / (Exp(X) - Exp(-X))
Hyperbolischer Arkussinus      HArcsin(X) = Log(X + Sqr(X * X + 1))
Hyperbolischer Arkuskosinus    HArccos(X) = Log(X + Sqr(X * X - 1))
Hyperbolischer Arkustangens    HArctan(X) = Log((1 + X) / (1 - X)) / 2
Hyperbolischer Arkussekans     HArcsec(X) = Log((Sqr(-X * X + 1) + 1) / X)
Hyperbolischer Arkuskosekans   HArccosec(X) = Log((Sgn(X) * Sqr(X * X + 1) +1) / X)
Hyperbolischer Arkuskotangens  HArccotan(X) = Log((X + 1) / (X - 1)) / 2
Logarithmus                    LogN(X) = Log(X) / Log(N)

* * * *

Beim Programmieren ertappe ich mich seit meiner Schulzeit (Abi 1983 am Ellental-Gymnasium in Bietigheim-Bissingen) immer wieder dabei, mich bei Umgang mit Prozentberechnungen schwer zu tun. Peinlich, peinlich, aber nichts, was sich im Jahre 2006 nicht online erledigen lassen könnte, und zur Strafe schreib' ich's auch noch auf:

Vorausgesetzt wird: G = Grundwert, P = Prozentwert und p = Prozentsatz.

Es gilt: P = G * p / 100

Beispiel: 5% von 400 sind 400 * 5 / 100 = 20.

Umstellungen lauten:

p = 100 * P / G
G = 100 * P / p

PHP

Ausführen von Skripten verschiedener php-Versionen

Wenn auf einem Webserver Skripte in verschiedenen Versionen ausgeführt werden sollen, müssen dafür spezielle Vorkehrungen getroffen werden.

Dies geschieht auf Seite der Serveradministration und der "gemeine Kunde" muß mit dem zurecht kommen, was er dort vorfindet.

Das folgende Beispiel beschreibt ein Szenario mit php-Skripten auf einem 1und1-Webserver.

1und1 hatte sich als Provider entschieden, Dateinamen mit der Endung ".php" an den php4-Interpreter weiterzuleiten. Das mag im Jahre 2011 anachronistisch erscheinen, aber es gibt nun mal eben eine Unmenge php-Skripte, die in älteren Versionen geschrieben wurden.

Unterscheidung durch die Dateiendung (Dateisuffix)

Ein einfaches Verfahren, php-Skripte durch verschiedene php-Interpreter verarbeiten zu lassen, besteht darin, diese Skripte durch unterschiedliche Dateisuffixe zu kennzeichnen.

Z.B. bei 1und1 sieht eine Zuweisung von Dateiendungen im Jahre 2011 so aus:

• Php 3 Interpreter: .php3
• Php 4 Interpreter: .php
• Php 5 Interpreter: .php5

Individuelle Zuweisung durch die .htaccess-Anweisung AddType

Wer aber auf so einem Server, bei dem .php fest an einen Php 5 Interpreter gebunden ist, z.B. eine neue Version einer php-Software betreiben möchte (z.B. phpMyAdmin), sieht sich dem Problem gegenüber, daß evtl. Tausende von Dateien umbenannt werden müssten. Und dann würde es immer noch nicht funktionieren, da ja auch die Aufrufe innerhalb der Skripte angepasst werden müssten.

Das geht gar nicht.

Auf Webservern, auf denen die Serversoftware Apache läuft, kann mit sog. .htaccess-Dateien gearbeitet werden.

Die schiere Fülle der Möglichkeiten bietet auch eine Lösung für das genannte Problem.

Über die .htaccess-Anweisung AddType kann z.B. für alle .php-Dateien (in diesem und den darunterliegenden Verzeichnissen) vereinbart werden, dass sie durch den Php 5 Interpreter verarbeitet werden.

Das sieht dann so aus:


# php-Skripte im php5-Interpreter ausfuehren
AddType x-mapp-php5 .php AddHandler x-mapp-php5 .php


Das hat bei mir auf Anhieb funktioniert und damit konnte ich mit verschiedenen Versionen von phpMyAdmin, die wiederum in verschiedenen php-Versionen geschrieben wurden, verschiedene Versionen diverser MySql-Datenbanken administrieren.

Visual Basic

In Visual-Basic-Umgebungen wie in den Microsoft-Office-Anwendungen oder VB selbst können Anwendungen mit erweiterten Angaben (sog. Kommandozeilen-Parameter) gestartet werden.

Innerhalb der Anwendung müssen diese Angaben dann ausgewertet und entsprechend verarbeitet werden.

Leider verfügt Visual Basic (zumindest bis VB6) über nur unzureichende Möglichkeiten, um solche Parameter-Informationen auszuwerten.

Mit neidvollem Blick schaue ich im Vergleich dazu auf Sprachen wie z.B. php.
Dort werden Parameter sowohl in einer http-Umgebung als Bestandteil einer URL (z.B. 'http://www.domain.de/index.php?name=abc&alter=18'), wie auch auf der Kommandoprompt-Ebene (z.B. 'php.exe index.php name=abc alter=18') entgegengenommen.
Innerhalb des aufgerufenen php-Skriptes stehen dann all diese Parameter-Angaben in der Form $_REQUEST['name'] usw. als Variablen mitsamt ihren Werten zur Verfügung.

In Visual-Basic muß ich mich aber mit dem zufrieden geben, was mir die Funktion command$() bietet: nämlich einen String, der alle Parameter-Angaben enthält.

Eine Anwendung, die durch Parameter gesteuert werden kann, wartet aber auf ganz bestimmte Parameter und muß prüfen, ob diese überhaupt alle übergeben wurden, ob Werte fehlen dürfen und durch Default-Werte ersetzt werden müssen und ob angegebene Werte in zulässigen Grenzen liegen.

Dafür muß der Inhalt von command$() entsprechend ausgewertet werden.

Ein aus der Visual-Basic6-Dokumentation übernommenes Beispiel, das die command$()-Zeichenkette zerlegt und der Inhalte in ein Array ablegt, habe ich verworfen. Die Implementierung und der Umgang mit Arrays in Visual Basic ist aus meiner Sicht unwürdig und demütigend. Auch die Einführung des dictionary-Objektes in VB6 hat mich nicht in Ehrfurcht erstarren lassen; daß man Array-Inhalte nicht nur über Index-Nummern, sondern auch über aussagekräftige Namen ansprechen kann, sollte längst zum guten Ton gehören. Wenn mein Access 2.0 Baujahr 1994 sowas noch nicht kann, dann muß man halt Umwege gehen (obwohl dort die Impementierung mancher Anweisungen wie $RecordSet("feldname") oder $RecordSet.AddNew moderne Strukturen besitzen und sogar einen Hauch von Objekt-orientiertem Programmieren [OOP] vorwegnehmen). In einer vernünftigen Sprache wie z.B. php nennt man so was ein "assoziatives Array" und wer nicht in den 70er Jahren bei Lochkarten-Speichersystemen stehen geblieben ist, hat auch keine Angst, daß der Prozessor ein Schieberegister mehr oder weniger bemühen muß, um ein solches assoziatives Array zu verarbeiten.

An dieser Stelle nun eine Beschreibung meiner Implementierung einer Anwendungs-Parameter-Steuerung:

Die Anwendung verarbeitet 2 Parameter keys und timeout.

Dafür werden globale Konstanten und Variablen für die Namen und ihre Werte sowie ihren "Verarbeitungs-Datentyp" hinterlegt:

' allgemeine Konstanten
Public Const VALUE_MUST_BE_GIVEN = 0
Public Const VALUE_MUST_BE_BYTE = 1

' Konstanten für die Namen erlaubter Parameter
Public Const PARAMETER_KEYS = "keys"
Public Const PARAMETER_TIMEOUT = "timeout"

' öffentliche Variablen für die Werte übergebener Parameter
Public PARAMETER_KEYS_VALUE As String
Public PARAMETER_TIMEOUT_VALUE As Byte

Beim Start der Anwendung wird die Prozedur CheckArguments aufgerufen.
Bei nicht übergebenen Parametern kann eine Prozedur ShowHelp Auskunft über die vorgesehene Ansteuerung der Anwendung geben, ansonsten werden die erwarteten Parameter-Werte durch die Funktion GetArgumentValue ermittelt:

Sub CheckArguments()

  On Error GoTo err_CheckArguments

  If Command$ = "" Then
     ShowHelp
     End
  End If

  PARAMETER_KEYS_VALUE = GetArgumentValue(PARAMETER_KEYS, VALUE_MUST_BE_GIVEN)
  PARAMETER_TIMEOUT_VALUE = GetArgumentValue(PARAMETER_TIMEOUT, VALUE_MUST_BE_BYTE)

  Exit Sub


err_CheckArguments:

  Fehler "CheckArguments"
  Exit Sub

End Sub

Und hier die Funktion GetArgumentValue(), die einen Parameter sowie dessen zugehörigen Wert unabhängig von der Position innerhalb von command$() ermittelt und einen dazugehörenden "Verarbeitungs-Datentyp" auswertet.

Private Function GetArgumentValue(sParameterName As String, Optional sType As String) As Variant

  On Error GoTo err_GetArgumentValue

  Dim iStart As Integer, iEnde As Integer, vReturn As Variant

  iStart = InStr(Command$, sParameterName)

  If iStart > 0 Then
     iStart = iStart + Len(sParameterName) + 1
     ' stand-alone or one or last of several parameters ?
     If InStr(Command$, " ") = 0 Then
        iEnde = Len(Command$)
     Else
        iEnde = InStr(iStart, Command$, " ")
        If iEnde = 0 Then
           iEnde = Len(Command$)
        End If
     End If
     vReturn = Mid$(Command$, iStart, iEnde - iStart + 1)
  Else
     vReturn = ""    ' not given
  End If

  If Not IsMissing(sType) Then
     Select Case sType
        Case VALUE_MUST_BE_GIVEN:
              If vReturn = "" Then
                 BadParameter sParameterName, "must be given"
              End If
        Case VALUE_MUST_BE_BYTE:
              If IsNumeric(vReturn) = True Then
                 vReturn = CByte(vReturn)
                 If vReturn < 0 Or vReturn > 255 Then
                    BadParameter sParameterName, "between 0 and 255"
                 End If
              ElseIf vReturn = "" Then
                 vReturn = 0
              Else
                 BadParameter sParameterName, "between 0 and 255"
              End If
     End Select
  End If

  GetArgumentValue = vReturn

  Exit Function


err_GetArgumentValue:

  Fehler "GetArgumentValue"
  Exit Function

End Function

Klar, daß diese Implementierung sich auch auf die Routine Fehler() stützt.

Wird der aktuelle Code innerhalb der Visual-Basic-Umgebung im Interpreter oder aber in einer ausführbaren Exe-Datei ausgeführt ?

Das unterscheiden zu können, kann manchmal sehr hilfreich sein, wenn z.B.
- die Code-Abarbeitung in der Umgebung nicht identisch mit der in der Exe-Datei ist und man deswegen ein Workaround schreiben muß
- oder eine kleine Prüfsoftware, die zur Exe-Laufzeit nichts meldenswertes findet, schlicht und ergreifend den Rand halten soll, während hingegen innerhalb der Visual-Basic-Entwicklungsumgebung wenigstens eine Meldung a'la "nichts zu tun" erscheinen soll.

Gerade letzteres kann einen ziemlich verunsichern, wenn ein kleines Progrämmchen nach dem Starten per einfach nur nichts tut und man zuerst gar nicht weiß, wo man anfangen soll zu suchen, um dann nach zu langer Zeit entnervt feststellen zu müssen, daß das Programm gar keinen Fehler hat, sondern einfach nur nichts zu melden hatte.

In der VisualBasic6-Dokumentation wird vollmundig versprochen, mittels der ExeName-Eigenschaft des App-Objektes eine solche Unterschiedung vornehmen zu können.

Zitat: "Gibt den Stammnamen der ausführbaren Datei (ohne Dateinamenerweiterung), die gerade ausgeführt wird, zurück. Erfolgt die Ausführung in der Entwicklungsumgebung, wird der Name des Projekts zurückgegeben."

Klasse, da konnte ich Testen bis zum Umfallen, ich habe NIEMALS irgendetwas unterschiedliches geliefert bekommen.

Irgendwann mal habe ich für diesen Dreck eine Lösung gefunden (entweder per Hinweis aus einer vergessenen Quelle oder mittels Eingebung einer höheren Macht).

Das Ganze geht wieder über eine API-Funktion (würg!): GetModuleHandle().

Die Doku beschreibt Sinn und Zweck dieser Funktion wie folgt:

"The GetModuleHandle function returns a module handle for the specified module if the file has been mapped into the address space of the calling process."

Naja, wie dem auch sei, wenn ich an diese API-Funktion den App.ExeNamen sowie die Exe-Erweiterung ".exe" übergebe und den Return-Wert gegen 0 vergleiche, kann ich zuverlässig sagen, ob der Code in einer Exe-Datei oder innerhalb der VB6-Umgebung ausgeführt wird. Klar, daß das in direktem Widerspruch zur API-Dokumentation steht, die da meint, daß im Erfolgsfalle ein Handle zum angegebenen Modul oder ansonsten NULL zurückgegeben wird - von arabisch 0 war nicht die Rede. Egal, gegen 0 verglichen tut die Scheiße ... und hier der Code:

Private Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As Long

Function IsVbRunning() As Boolean

  On Error Resume Next

  If GetModuleHandle(App.EXEName & ".exe") = 0 Then
    IsVbRunning = True
  End If

End Function

Im entsprechenden Code-Abschnitt läßt sich dann ganz wunderbar mit If IsVbRunning() = True then arbeiten.