Readings Newsletter
Become a Readings Member to make your shopping experience even easier.
Sign in or sign up for free!
You’re not far away from qualifying for FREE standard shipping within Australia
You’ve qualified for FREE standard shipping within Australia
The cart is loading…
This title is printed to order. This book may have been self-published. If so, we cannot guarantee the quality of the content. In the main most books will have gone through the editing process however some may not. We therefore suggest that you be aware of this before ordering this book. If in doubt check either the author or publisher’s details as we are unable to accept any returns unless they are faulty. Please contact us if you have any questions.
Die Idee zu diesem Text entstammt meinem immer wieder unglaubigen Erstaunen daruber, daB selbst erfahrene Ingenieure, Physiker oder Mathematiker ihre Pro- gramme lieber vollstandig selbst schreiben als Programmpakete zu benutzen. Ja, selbst einige meiner Numerik-Diplomanden erachten es als eine Zumutung, wenn ich verlange, daB gewisse Teile ihrer Programme durch Bibliotheks-Routinen er- setzt werden. Woran liegt das? These 1: Programmpakete sind entweder gut oder leicht bedienbar.
Diese These klingt sehr rigoros, enthiilt aber sicher einen wahren Kern. Da gibt es benutzerfreundliche Dialog-Systeme zur Losung numerischer Probleme auf einem PC, die den Benutzer sanft von den Problemstellungen uber die Verfahrensauswahl bis zur Parameter-Eingabe und Losung geleiten, aber nichts zur Fehleranfiilligkeit der Algorithmen sagen, ungenaue Funktionen verarbeiten oder zweideutige Routi- nen enthalten, Beispiele findet man in [30]. Andererseits gibt es Pakete wie NAG!, die uber Hunderte von Routinen verfugen. Sie sind in vielen Jahren Arbeit mit sorgfaltiger Problemanalyse, Programmierung und Test entstanden und werden durch neue Releases regelmaBig gewartet . Ihr Manual fUllt aber viele dicke Ordner. Das schreckt viele Benutzer abo Dabei wird man doch belohnt mit fehlerfreien Programmen, moglichst exakten Ergebnissen, graphischen Darstellungsmaglichkeiten und genau definierten Programmablaufen. These 2: Jedes Programm mit mehr als 50 Zeilen ist falsch.
Diese These trifft leider ebenso haufig zu, wie sie auf Widerspruch staBt. Durch die VerfUgbarkeit guter Programmpakete ist es immer sinnloser geworden, daB der Mathematiker, der Naturwissenschaftler oder der Ingenieur die Losungsroutinen fUr seine numerischen Standardprobleme selbst programmiert.
$9.00 standard shipping within Australia
FREE standard shipping within Australia for orders over $100.00
Express & International shipping calculated at checkout
This title is printed to order. This book may have been self-published. If so, we cannot guarantee the quality of the content. In the main most books will have gone through the editing process however some may not. We therefore suggest that you be aware of this before ordering this book. If in doubt check either the author or publisher’s details as we are unable to accept any returns unless they are faulty. Please contact us if you have any questions.
Die Idee zu diesem Text entstammt meinem immer wieder unglaubigen Erstaunen daruber, daB selbst erfahrene Ingenieure, Physiker oder Mathematiker ihre Pro- gramme lieber vollstandig selbst schreiben als Programmpakete zu benutzen. Ja, selbst einige meiner Numerik-Diplomanden erachten es als eine Zumutung, wenn ich verlange, daB gewisse Teile ihrer Programme durch Bibliotheks-Routinen er- setzt werden. Woran liegt das? These 1: Programmpakete sind entweder gut oder leicht bedienbar.
Diese These klingt sehr rigoros, enthiilt aber sicher einen wahren Kern. Da gibt es benutzerfreundliche Dialog-Systeme zur Losung numerischer Probleme auf einem PC, die den Benutzer sanft von den Problemstellungen uber die Verfahrensauswahl bis zur Parameter-Eingabe und Losung geleiten, aber nichts zur Fehleranfiilligkeit der Algorithmen sagen, ungenaue Funktionen verarbeiten oder zweideutige Routi- nen enthalten, Beispiele findet man in [30]. Andererseits gibt es Pakete wie NAG!, die uber Hunderte von Routinen verfugen. Sie sind in vielen Jahren Arbeit mit sorgfaltiger Problemanalyse, Programmierung und Test entstanden und werden durch neue Releases regelmaBig gewartet . Ihr Manual fUllt aber viele dicke Ordner. Das schreckt viele Benutzer abo Dabei wird man doch belohnt mit fehlerfreien Programmen, moglichst exakten Ergebnissen, graphischen Darstellungsmaglichkeiten und genau definierten Programmablaufen. These 2: Jedes Programm mit mehr als 50 Zeilen ist falsch.
Diese These trifft leider ebenso haufig zu, wie sie auf Widerspruch staBt. Durch die VerfUgbarkeit guter Programmpakete ist es immer sinnloser geworden, daB der Mathematiker, der Naturwissenschaftler oder der Ingenieur die Losungsroutinen fUr seine numerischen Standardprobleme selbst programmiert.