Texas rekenmachine misrekent zich
leo Koenen
Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
volgende formule:
4 3
1/4.(-4) + (-4)
Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
Ik heb vervolgens aan het servicekantoor van Texas gevraagd hoe dit
komt en ik kreeg daar een standaardstencil op terug (kennelijk zijn er
meer gebruikers die met dergelijke probleem kampen) waaruit ik de
volgende onbeschoftheden citeer:
citaat 1:
"zeer veel calculators geven niet exact de nul als uitkomst, wat ze in
feite wel zouden moeten zijn. De TI-30X geeft bijvoorbeeld als
-12
uitkomst -5.235987756 . Dit ziet er voor een basisscholier nogal
heftig uit, maar het betekent -zoals u bekend zal zijn- niets anders
dan -0,00000000000532....."
citaat 2:
"wetenschappers -van astronomen tot elementaire-deeltjes-fysici-
hebben met dit soort toleranties geen enkel probleem. Alleen neuswijze
scholieren en soms -erg genoeg- hun leerkrachten (die "kracht" is vaak
niet wat ze ooit was) willen hierover wel eens graag hoog te paard
gaan zitten."
citaat 3:
"een voordeeltje van die onverwachte uitkomsten is wellicht nog het
feit dat de gebruiker even wakker wordt geschud; dat hij leert
beseffen wat wetenschappelijke (ook wel genaamd: drijvende komma-)
notatie eigenlijk precies wil zeggen, en, nog veel belangrijker, dat
hij zich blijft realiseren dat calculators en computers geen orakels
zijn of bronnen van kristallen waarheden maar simpelweg krachtige
stukken gereedschap. Zij moeten -als ieder goed gereedschap- met
beleid worden gebruikt (geen schroeven indraaien met een beitel) en
hun resultaten dienen altijd met scepsis te worden bekeken.
Onverwachte resultaten willen namelijk best wel eens voorkomen, maar
die zijn dan niet te wijten aan onnauwkeurigheden van de machine maar
zijn het resultaat van onze eigen blunders bij het invoeren."
Tot zover de reactie van Texas. Hun fatsoen benadert het nulpunt
dichter dan hun rekenmachines.
Hoog te paard gezeten ben ik toch benieuwd waarom , wanneer ik
blunderend bovenstaande formule invoer en de rekenmachine alleen met
absolute getallen hoeft te werken, geen nul als uitkomst krijg.
Is dat een bekend probleem of een Texas-probleem (oftewel: heb ik een
beitel gekocht)?
Leo
Abigail
On Fri, 04 Apr 1997 23:10:22 GMT, leo Koenen wrote in nl.wetenschap:
++ Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
++ volgende formule:
++ 4 3
++ 1/4.(-4) + (-4)
++
++ Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
++ weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
++
[ Citaten ]
++
++ Tot zover de reactie van Texas. Hun fatsoen benadert het nulpunt
++ dichter dan hun rekenmachines.
++ Hoog te paard gezeten ben ik toch benieuwd waarom , wanneer ik
++ blunderend bovenstaande formule invoer en de rekenmachine alleen met
++ absolute getallen hoeft te werken, geen nul als uitkomst krijg.
++ Is dat een bekend probleem of een Texas-probleem (oftewel: heb ik een
++ beitel gekocht)?
Het is een bekend probleem, en TI heeft volkomen gelijk. Ze zijn
uiterst beleefd, jij zit hoog te paard, en je moet eigenlijk geen
gereedschap gebruiken voor je weet wat de grenzen zijn.
En je moet ook geen proportioneel font gebruiken om dingen
verticaal uit te lijnen. Dat werkt niet.
Abigail
$ bc -l
1/4 * (-4)^4 + (-4)^3
0
$ perl -w
print 1/4 * (-4)**4 + (-4)**3, "\n"
__END__
0
$
D.J. van Damme
Mijn HP-32S(II) geeft netjes 0 als uitkomst. Ik vind het trouwens raar
dat de TI met zulke kleine machten reeds onnauwkeurigheden te zien
geeft.
------------------------------------------------------------------------
David
vand...@xs4all.nl http://www.xs4all.nl/~vandamme/
"What happens to the hole when the cheese is gone?"
one liner by Bertolt Brecht
Frank Bemelman
le...@knoware.nl (leo Koenen) wrote:
>Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>volgende formule:
> 4 3
>1/4.(-4) + (-4)
Een kwart van 256 min 64 is bij mij 0. Ik zou ook niets anders
verwachten. Op een sharp EL-531GH calculator krijg ik ook
netjes een 0.
Dat stencil is echt de limit. Heeft iemand een email-adres van de
consumentenbond, kunnen we dat meteen even forwarden,
en een CC naar Texas Increment.
Hartelijke groeten,
Frank Bemelman.
Rob Janssen
>Tot zover de reactie van Texas. Hun fatsoen benadert het nulpunt
>dichter dan hun rekenmachines.
>Hoog te paard gezeten ben ik toch benieuwd waarom , wanneer ik
>blunderend bovenstaande formule invoer en de rekenmachine alleen met
>absolute getallen hoeft te werken, geen nul als uitkomst krijg.
>Is dat een bekend probleem of een Texas-probleem (oftewel: heb ik een
>beitel gekocht)?
Texas Instruments geeft goed aan wat er aan de hand is: de gebruiker
weet niet wat hij in handen heeft en reageert fel als er niet precies
gebeurt wat hij voorspelt, en dan mogen zij ook best wel eens fel
reageren. Ik neem aan dat ze al heel wat brieven ontvangen hebben
die heel wat feller/negatiever gesteld zijn dan het bovenstaande.
Als je op een rekenmachine x^y uitrekent dan doet hij intern e^(y * ln(x))
of iets vergelijkbaars met een ander grondtal.
Je zult dus begrijpen dat er uit 1/x * e^((y+1) * ln(x)) niet noodzakelijk
precies hetzelfde komt, door allerlei afrondings fouten, en als je dat
dan heel precies gaat bekijken (die 2 van elkaar aftrekken) dan zie je
een "fout".
Maar dat wil niet zeggen dat de rekenmachine het fout doet, je gaat gewoon
over de grenzen heen.
In de tijd dat ik me met rekenmachines bezig hield deed Texas het zelfs
beter dan de gemiddelde concurrent, maar dat is lang geleden en kan best
wel anders zijn tegenwoordig.
Echter als je het bovenstaande op een PC doet dan krijg je ook die fouten
hoor.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
Erik Springelkamp
On Sat, 5 Apr 1997 03:22:35 GMT, abi...@ny.fnx.com (Abigail) wrote:
>On Fri, 04 Apr 1997 23:10:22 GMT, leo Koenen wrote in nl.wetenschap:
>++ Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>++ volgende formule:
>++ 4 3
>++ 1/4.(-4) + (-4)
>++
>++ Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
>++ weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>
>Het is een bekend probleem, en TI heeft volkomen gelijk. Ze zijn
>uiterst beleefd, jij zit hoog te paard, en je moet eigenlijk geen
>gereedschap gebruiken voor je weet wat de grenzen zijn.
>
Toch is het vreemd: een formule als y^x = exp( x.log(y) ) kan hier
niet toegepast zijn vanwege de negatieve y.
Dan zou je een aparte procedure voor gehele x verwachten die geen
preciezie verliest. Ik kan me zo niet voorstellen wat het verlies
veroorzaakt.
Op mijn HP rekenmachine wordt deze formule netjes 0.
leo Koenen
On Sat, 5 Apr 1997 03:22:35 GMT, abi...@ny.fnx.com (Abigail) wrote:
>Het is een bekend probleem, en TI heeft volkomen gelijk.
Vreemd dat andere rekenmachines wel een goede uitkomst geven.
Zeker een bekend probleem bij TI, gezien hun standaardantwoord.
> Ze zijn uiterst beleefd, jij zit hoog te paard,
Over beleefdheid kun je verschillend denken.
Als je beleefd de vraag stelt hoe het kan dat je een onverwachte
onverwachte uitkomst op een som krijgt, dan lijkt me een andere
benadering wat tactvoller. Ook op wat dan kennelijk een domme vraag is
kun je fatsoenlijk antwoorden.
>en je moet eigenlijk geen
>gereedschap gebruiken voor je weet wat de grenzen zijn.
>
>Abigail
Waar ik eigenlijk benieuwd naar ben is hoe dat afwijkende antwoord
ontstaat, oh vriendelijke gemoedelijke Abigail. Een afrondingsprobleem
lijkt me niet voor de hand liggend.
Leo
Paul Bataille
Los van de inderdaad domme reactie van TI (hadden ze er maar een smiley
bijgezet, dan zou ik er misschien om kunnen glimlachen): dat het niet 0
wordt heeft dacht ik te maken met afronding, toch? Maar hoe precies...
Tja..
Groeten
Paul
leo Koenen <le...@knoware.nl> wrote in article
<3345815...@news.knoware.nl>...
> Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
> volgende formule:
> 4 3
> 1/4.(-4) + (-4)
>
> Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
> weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>
> Ik heb vervolgens aan het servicekantoor van Texas gevraagd hoe dit
> komt en ik kreeg daar een standaardstencil op terug (kennelijk zijn er
> meer gebruikers die met dergelijke probleem kampen) waaruit ik de
> volgende onbeschoftheden citeer:
>
etc
> Leo
>
Abigail
On Sat, 05 Apr 1997 13:18:35 GMT, leo Koenen wrote in nl.wetenschap:
++ On Sat, 5 Apr 1997 03:22:35 GMT, abi...@ny.fnx.com (Abigail) wrote:
++
++ >Het is een bekend probleem, en TI heeft volkomen gelijk.
++
++ Vreemd dat andere rekenmachines wel een goede uitkomst geven.
++ Zeker een bekend probleem bij TI, gezien hun standaardantwoord.
Voor iedere maker/gebruiker van digitale rekenapparatuur is dit een
bekend probleem (af beter gezegd, het zou een bekend probleem moeten
zijn). Dat ze een standaard antwoord hebben zegt meer over de klanten
dan over TI. Als jij bij een autofabrikant werkt, en na de 2000ste
klant die klaagt dat zijn auto het niet meer doet omdat ze nooit
getankt hebben moet je een standaard brief opstellen, hoe zou jij het
doen?
++ > Ze zijn uiterst beleefd, jij zit hoog te paard,
++
++ Over beleefdheid kun je verschillend denken.
++ Als je beleefd de vraag stelt hoe het kan dat je een onverwachte
++ onverwachte uitkomst op een som krijgt, dan lijkt me een andere
++ benadering wat tactvoller. Ook op wat dan kennelijk een domme vraag is
++ kun je fatsoenlijk antwoorden.
Ik vond het beleefd genoeg; maar ja, mensen vinden mij helemaal niet
beleefd.
++
++ >en je moet eigenlijk geen
++ >gereedschap gebruiken voor je weet wat de grenzen zijn.
++ >
++ >Abigail
++
++ Waar ik eigenlijk benieuwd naar ben is hoe dat afwijkende antwoord
++ ontstaat, oh vriendelijke gemoedelijke Abigail. Een afrondingsprobleem
++ lijkt me niet voor de hand liggend.
Toch ben ik er bijna 100% zeker van dat het een afrondfout betreft. Er
zijn verschillende manier op machten en delingen te berekenen, en
afrondfouten worden altijd gemaakt, dat is inherent aan het feit dat je
rekenmachine nog draagbaar en betaalbaar moet zijn. Er is ook geen
"beste" manier, de ene manier zal bij expressie x een grotere afrond
fout tonen, en de andere manier bij expressie y.
Dat TI nu net een afrondfout vertoond bij een simpel lijkende
expressie is ongelukkig, en hun standaard antwoord gaat over het
algemene probleem, niet je specifieke instantie van het probleem.
Abigail
Erik Springelkamp
On Sun, 6 Apr 1997 08:59:11 GMT, rob@pe1chl (Rob Janssen) wrote:
> 4 3
> 1/4.(-4) + (-4)
>
>>Toch is het vreemd: een formule als y^x = exp( x.log(y) ) kan hier
>>niet toegepast zijn vanwege de negatieve y.
>
>Pardon?
>En moet ik de rest van je verhaal nu nog geloven?
>
>Rob
??????????
K de Jong
le...@knoware.nl (leo Koenen) wrote:
>Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>volgende formule:
> 4 3
>1/4.(-4) + (-4)
>Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
>weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>uitkomst -5.235987756 . Dit ziet er voor een basisscholier nogal
>heftig uit, maar het betekent -zoals u bekend zal zijn- niets anders
>dan -0,00000000000532....."
Ach, vroeger met de SR-50 of de TI-58 kreeg je bij: 69! - 69*68!
een fout van zo'n beetje 10 tot de macht 80, of zoiets.
Waar maken jullie je nou eigenlijk druk om ??
Rekenmachines blijven gewoon grenzen houden, ze zijn alleen zo slim
dat ze de fouten vaak niet meer laten zien !!
Vroeger werkten dit soort rekenmachines voor bijvoorbeeld sinussen of
machten mbv reeksontwikkeling (volgens Taylor of zo) en dan krijg je
gewoon altijd afrondingsfouten, en dat zal nu nog wel zo zijn.
Met vriendelijk groet,
K de Jong
Frank Bemelman
rob@pe1chl (Rob Janssen) wrote:
[snip]
>Als je op een rekenmachine x^y uitrekent dan doet hij intern e^(y * ln(x))
>of iets vergelijkbaars met een ander grondtal.
>Je zult dus begrijpen dat er uit 1/x * e^((y+1) * ln(x)) niet noodzakelijk
>precies hetzelfde komt, door allerlei afrondings fouten, en als je dat
>dan heel precies gaat bekijken (die 2 van elkaar aftrekken) dan zie je
>een "fout".
>Maar dat wil niet zeggen dat de rekenmachine het fout doet, je gaat gewoon
>over de grenzen heen.
Bij x^y waarbij y een geheel getal is, zie ik liever de exacte
uitkomst.
>In de tijd dat ik me met rekenmachines bezig hield deed Texas het zelfs
>beter dan de gemiddelde concurrent, maar dat is lang geleden en kan best
>wel anders zijn tegenwoordig.
>Echter als je het bovenstaande op een PC doet dan krijg je ook die fouten
>hoor.
Niet op mijn windows95 desktop calculator.
Hartelijke groeten,
Frank Bemelman.
Gerard van Wilgen
le...@knoware.nl (leo Koenen) wrote:
>Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>volgende formule:
> 4 3
>1/4.(-4) + (-4)
>Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
>weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
Ik denk dat de macht 3 hier de boosdoener is omdat het getal 3 nu
eenmaal niet exact in binaire notatie kan worden weergegeven.
Blijkbaar vermenigvuldigt deze machine niet simpelweg -4 driemaal met
zichzelf maar gebruikt een ingewikkelder algoritme (zal wel
efficienter zijn bij hogere machten) waarbij die onnauwkeurigheid een
onnauwkeurige uitkomst veroorzaakt.
Overigens vind ik wel dat je aan het mierenneuken bent. Bij de meeste
van dit soort berekeningen komt er hoe dan ook, bij elke calculator,
geen exacte uitkomst uit. Texas Instruments heeft gelijk met hun
verhaal over het gebruik van het juiste gereedschap; in dit geval is
dat gewoon je eigen brein.
Gerard
--------------------------------------------------------------------------------------
Take a look at my multilingual dictionary programme at:
http://www.travlang.com/Ergane/
-------------------------------------------------------------------------------------
Ekrigardu mian multlingvan vortarprogramon je:
http://www.travlang.com/Ergane/
-------------------------------------------------------------------------------------
Rob Janssen
>On Sat, 5 Apr 1997 03:22:35 GMT, abi...@ny.fnx.com (Abigail) wrote:
>>On Fri, 04 Apr 1997 23:10:22 GMT, leo Koenen wrote in nl.wetenschap:
>>++ Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>>++ volgende formule:
>>++ 4 3
>>++ 1/4.(-4) + (-4)
>>++
>>++ Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
>>++ weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>>
>>Het is een bekend probleem, en TI heeft volkomen gelijk. Ze zijn
>>uiterst beleefd, jij zit hoog te paard, en je moet eigenlijk geen
>>gereedschap gebruiken voor je weet wat de grenzen zijn.
>>
>Toch is het vreemd: een formule als y^x = exp( x.log(y) ) kan hier
>niet toegepast zijn vanwege de negatieve y.
Pardon?
En moet ik de rest van je verhaal nu nog geloven?
Rob
Tarzan
Aan 5-04-97 0:10, in bericht <3345815...@news.knoware.nl>, leo Koenen
<le...@knoware.nl> schreef:
> Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
> volgende formule:
> 4 3
> 1/4.(-4) + (-4)
>
> Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
> weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>
Ach, ik roep het al jaren: gewoon een casio kopen. Die zijn sneller,
gebruiksvriendelijker en ze geven het juiste antwoord.
Computers geven trouwens bij zeer simpele bewerkingen ook snel fouten. Probeer
dit BASIC-programmaatje maar:
do
x = x +.16
print x
loop
Binnen de kortste keren heb je een getal met 6 cijfers achter de komma.
Groetjes,
Bas
--
Bas Vermeulen
E-mail: bjd...@worldaccess.nl
Homepage: http://www.worldaccess.nl/~bjdeuso
Ik heb ontdekt dat ik het vermogen heb om iemands karakter uit een enkel e-mailtje
kan bepalen. Wil jij weten hoe je echt in elkaar zit? Stuur me dan een e-mailtje met
omschrijving van je uiterlijk, geboortedatum, opleiding en evt. beroep. Geef ook aan
welk aspect van je karakter wil leren kenne
n. Je krijgt zo snel mogelijk antwoord.
Frank Bemelman
gvwi...@worldonline.nl (Gerard van Wilgen) wrote:
[snip]
>Ik denk dat de macht 3 hier de boosdoener is omdat het getal 3 nu
>eenmaal niet exact in binaire notatie kan worden weergegeven.
Drie is binair toch gewoon 11 ? Afgezien daarvan begrijp ik je
redenatie ook niet erg.
>Blijkbaar vermenigvuldigt deze machine niet simpelweg -4 driemaal met
>zichzelf maar gebruikt een ingewikkelder algoritme (zal wel
>efficienter zijn bij hogere machten) waarbij die onnauwkeurigheid een
>onnauwkeurige uitkomst veroorzaakt.
Als Cas Spijkers een nieuwe, 4 x zo effieciente methode had
uitgevonden om een ossehaas te bereiden, die dan wel iets minder
lekker smaakt, was ie nu misschien chef bij van der Valk.
>Overigens vind ik wel dat je aan het mierenneuken bent. Bij de meeste
>van dit soort berekeningen komt er hoe dan ook, bij elke calculator,
>geen exacte uitkomst uit. Texas Instruments heeft gelijk met hun
>verhaal over het gebruik van het juiste gereedschap; in dit geval is
>dat gewoon je eigen brein.
Betere calculators komen alleen op de markt als er gemierenneukt
wordt. Als iedereen met alles tevreden was, zaten we nu nog bananen
te pellen en vlooien te knappen. Als ik met mijn calculator 37 keer de
wortel uit 2 trek, en daarna 37 keer kwadrateer, heb ik een
aanzienlijke afwijking die ik wel accepteer, maar dat laat niet
onverlet dat de fabrikanten daar iets aan zouden mogen doen.
>Gerard
Hartelijke groeten,
Frank Bemelman.
Johan Wevers
leo Koenen <le...@knoware.nl> wrote:
>Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>volgende formule:
> 4 3
>1/4.(-4) + (-4)
Dat moet natuurlijk
1/4*(-4)^4 + (-4)^3 zijn (een macht na de komma is syntactisch incorrect).
>Daar hoort dus nul uit te komen.
Dat zou je wel denken ja.
>Zo niet bij de Texas TI-35X. Er kwam
>weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
Hmmm. Slechte afronding zeg. Mijn jaren oude Casio fx98 wetenschappenlijke
rekenmachine op creditcardformaat geeft keurig 0. Maar mijn ervaring met TI
op de middelbare school (op de MAVO waar ik zat was een TI 35 verplicht) is
dat die dit soort dingen wel vaker heeft.
>citaat 1:
>"zeer veel calculators geven niet exact de nul als uitkomst, wat ze in
>feite wel zouden moeten zijn. De TI-30X
Weten ze ook andere dan TI calculators te noemen die dit fout doen?
>uitkomst -5.235987756E-12 . Dit ziet er voor een basisscholier nogal
>heftig uit,
Teken je volgende brief met dr. ir. L, Koenen, dan ben je van dat soort
opmerkingen waarschijnlijk wel af. :-)
>citaat 2:
>"wetenschappers -van astronomen tot elementaire-deeltjes-fysici-
>hebben met dit soort toleranties geen enkel probleem.
Nou, als het gaat om de relatieve fout in een getal ongelijk aan 0, dan is
een afwijking van 5E-12 op 1 wel acceptabel ja. Maar in dit geval eigenlijk
niet - het is vaak van belang of iets bijna 0 is of precies 0. Al volgt dat
dan meestal uit analytische berekeningen en niet uit numerieke simulaties.
>Alleen neuswijze scholieren en soms -erg genoeg- hun leerkrachten (die
>"kracht" is vaak niet wat ze ooit was) willen hierover wel eens graag hoog
>te paard gaan zitten."
Tsssk. Wat een arrogantie. Al weet ik nog dat de wiskunde docent op het VWO
(da's dus al weer bijna 10 jaar geleden voor mij) ons eens een calculator
zien die op 5^4 geen 625 maar 624.999999 gaf. En hij zei er nog bij dat
zoiets bij oude calculators wel eens voorkwam... lijkt me wel iets te
zeggen over de stand der techniek bij TI.
>citaat 3:
>"een voordeeltje van die onverwachte uitkomsten is wellicht nog het
>feit dat de gebruiker even wakker wordt geschud;
Vast en zeker, hopenlijk wordt men bij TI ook eens wakker geschud als zo'n
opstelling ze klanten kost.
>blunderend bovenstaande formule invoer en de rekenmachine alleen met
>absolute getallen hoeft te werken, geen nul als uitkomst krijg.
De calculator rekent intern blijkbaar in floating point als het niet nodig
is en gebruikt intern te weinig cijfers (de interne precisie van
calculators is meestal groter dan het aantal cijfers dat op het display
aangegeven wordt).
--
ir. J.C.A. Wevers <*> For Physics and science fiction information:
joh...@vulcan.xs4all.nl <*> http://www.xs4all.nl/~johanw/index.html
Finger joh...@xs4all.nl for my PGP public key. PGP-KeyID: 0xD42F80B1
Johan Wevers
Rob Janssen <pe1...@amsat.org> wrote:
>>Toch is het vreemd: een formule als y^x = exp( x.log(y) ) kan hier
>>niet toegepast zijn vanwege de negatieve y.
>Pardon?
>En moet ik de rest van je verhaal nu nog geloven?
Dacht je soms dat ze in rekenmachines gammafuncties (of ingewikkelder
reeksen) gebruikten om de log van negatieve getallen uit te rekenen?
Ze zijn nu al traag genoeg (de standaardtest is nog altijd de tijd die
de calculator voor 69! nodig heeft).
Johan Wevers
Tarzan <bjd...@worldaccess.nl> wrote:
>Computers geven trouwens bij zeer simpele bewerkingen ook snel fouten. Probeer
>dit BASIC-programmaatje maar:
>
>do
>x = x +.16
>print x
>loop
>
>Binnen de kortste keren heb je een getal met 6 cijfers achter de komma.
Dat zegt meer over de BASIC variant die jij gebruikt dan over moderne PC's
denk ik. In C of Pascal heb je in elk geval nog invloed over de grootte van
de interne representatie (en het emplementeren van een willekeurig precieze
interne notatie is een standaardopgave in veel C boeken als men
pointerstructuren behandeld). Kan zelfs vrij eenvoudig (maar niet zo
efficient) zonder pointers.
Kees J Bot
In article <5i8cfg$lui$2...@neptune.worldonline.nl>,
Frank Bemelman <fbe...@worldonline.nl> wrote:
>rob@pe1chl (Rob Janssen) wrote:
>
>[snip]
>>Als je op een rekenmachine x^y uitrekent dan doet hij intern e^(y * ln(x))
>>of iets vergelijkbaars met een ander grondtal.
>
>>Je zult dus begrijpen dat er uit 1/x * e^((y+1) * ln(x)) niet noodzakelijk
>>precies hetzelfde komt, door allerlei afrondings fouten, en als je dat
>>dan heel precies gaat bekijken (die 2 van elkaar aftrekken) dan zie je
>>een "fout".
>
>>Maar dat wil niet zeggen dat de rekenmachine het fout doet, je gaat gewoon
>>over de grenzen heen.
>
>Bij x^y waarbij y een geheel getal is, zie ik liever de exacte
>uitkomst.
Niet als dat betekent dat de algemene x^y functie daarmee discontinu
wordt, dwz als bijvoorbeeld x^4.999999, x^5, en x^5.000001 niet keurig
opeenvolgende waarden opleveren.
Het is veel belangrijker dat de machine implementatie van een
mathematische functie keurig continu is dan dat ie preciese antwoorden
geeft voor "nette getallen". Misschien dat TI wel een x^y functie
heeft die een kleine fout heeft bij de nette machten, maar voor de hele
reeks waarden van x en y een gemiddeld betere benadering is dan andere
mogelijke x^y functies. Als dat zo is dan heeft TI de juiste keuze
gemaakt.
--
Kees J. Bot, Systeemprogrammeur, Vrije Universiteit Amsterdam
Luc Peersman
Er was nogal wat te doen om de Pentium die niet kon rekenen. Zoals uit
deze draad al blijkt, zijn er echter altijd beperkingen en daar moet
je mee leren leven.
Probeer maar eens
=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
in Excel of zo. Hij zegt dat het ONWAAR is.
Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
Pentium! :-)
Bram Heerink
Bram Heerink
>>In de tijd dat ik me met rekenmachines bezig hield deed Texas het zelfs
>>beter dan de gemiddelde concurrent, maar dat is lang geleden en kan best
>>wel anders zijn tegenwoordig.
>>Echter als je het bovenstaande op een PC doet dan krijg je ook die fouten
>>hoor.
>
> Niet op mijn windows95 desktop calculator.
>
>
De fout wordt zeker `gecorigeerd' door de Pentium bug ;)
Abigail
On Mon, 07 Apr 1997 16:29:36 +0200, Jan Gerritsjans wrote in nl.wetenschap:
++ Johan Wevers wrote:
++
++ > Dacht je soms dat ze in rekenmachines gammafuncties (of ingewikkelder
++ > reeksen) gebruikten om de log van negatieve getallen uit te rekenen?
++ > Ze zijn nu al traag genoeg (de standaardtest is nog altijd de tijd die
++ > de calculator voor 69! nodig heeft).
++ >
++ Moet je een scientific Philipsding kopen: die van mij heeft 10!, 20!,
++ 30!, 40!, 50! en 60! in z'n geheugen zitten, zodat 65! sneller
++ uitgerekend wordt dan 59!, om maar een voorbeeld te noemen.
++
++ Btw, op hoeveel nullen eindigt 52!?
oo
sum int (52/5^i) == 12.
i=1
++ Deze vraag stelde ik onlangs in het pleeboek van mijn studentenhuis. De
++ PABO'ers, TIO'er en HTS'er kwamen er niet uit. Ze namen overigens ook
++ niet de moeite om het uit te rekenen, terwijl er toch papier genoeg
++ was...
't Is gewoon hoofdrekenen (50/5 + 50/25, dat moet toch iedereen
kunnen zonder papier?).
Op hoeveel nullen eindigt 1000! in het 36-tallig stelsel?
Abigail
perl -we '$,="*";$\="\n";print(1..52);'|bc
80658175170943878571660636856403766975289505440883277824000000000000
Tarzan
Aan 6-04-97 22:00, in bericht <5i8uio$8g4$2...@neptune.worldonline.nl>, Gerard van
Wilgen <gvwi...@worldonline.nl> schreef:
> le...@knoware.nl (leo Koenen) wrote:
>
> Ik denk dat de macht 3 hier de boosdoener is omdat het getal 3 nu
> eenmaal niet exact in binaire notatie kan worden weergegeven.
Wat dacht je van: 11 ?
> Overigens vind ik wel dat je aan het mierenneuken bent. Bij de meeste
> van dit soort berekeningen komt er hoe dan ook, bij elke calculator,
> geen exacte uitkomst uit.
Onzin! Bij onvervalste Casio zakbakken niet!
Tarzan
Aan 7-04-97 18:37, Tarzan <bjd...@worldaccess.nl> schreef:
> Aan 7-04-97 1:06, in bericht <33482c67.5...@vulcan.xs4all.nl>, Johan
> Wevers <joh...@vulcan.xs4all.nl> schreef:
>
> > Tarzan <bjd...@worldaccess.nl> wrote:
> >
> > >Computers geven trouwens bij zeer simpele bewerkingen ook snel fouten.
> > Probeer
> > >dit BASIC-programmaatje maar:
> > >
> > >do
> > >x = x +.16
> > >print x
> > >loop
> > >
> > >Binnen de kortste keren heb je een getal met 6 cijfers achter de komma.
> >
> > Dat zegt meer over de BASIC variant die jij gebruikt dan over moderne PC's
> > denk ik. In C of Pascal heb je in elk geval nog invloed over de grootte van
> > de interne representatie (en het emplementeren van een willekeurig precieze
> > interne notatie is een standaardopgave in veel C boeken als men
> > pointerstructuren behandeld). Kan zelfs vrij eenvoudig (maar niet zo
> > efficient) zonder pointers.
>
> Maakt niet uit welke BASIC versie je gebruikt. Ik denk zelfs dat C het ook doet. In
> BASIC gebruikt dit programmaatje gewoon een 'SINGLE'-formaat ofwel: gewoon
> een
> zooitje cijfers achter de komma. Onnodige nullen worden niet afgedrukt. De
> uitkomst
> zou dus nooit meer dat 2 decimalen moeten bevatten. Toch krijg je 6 decimalen.
Ik heb het geprobeert in C:
#include <math.h>
#include <stdio.h>
void main(void)
{
float x;
do
{
x = x +.16;
printf ("x= %f\n", x);
} while (x <= 8);
}
Mijn C is niet zo goed (misschien voor de kenner te merken) maar dit programmaatje
werkt (bij mij). Toegeven....hij doet het een stuk beter dan Basic maar hij gaat de
fout in.
leo Koenen
>Overigens vind ik wel dat je aan het mierenneuken bent. Bij de meeste
>van dit soort berekeningen komt er hoe dan ook, bij elke calculator,
>geen exacte uitkomst uit. Texas Instruments heeft gelijk met hun
>verhaal over het gebruik van het juiste gereedschap; in dit geval is
>dat gewoon je eigen brein.
>
>Gerard
>
Sinds wanneer is vragen hoe iets komt mierenneuken?
Mag je je gereedschap niet leren kennen? Bij die bovenstaande formule
verwachtte ik geen afrondingen en was dus verwonderd dat er geen nul
uit kwam. Stom, natuurlijk, maar je probeert je gebrekkige kennis wat
op te vijzelen door te vragen. Ook stom, natuurlijk.
Een fatsoenlijk antwoord met een uitleg lijkt mij passender dan een
beledigend stencil terugsturen in de trant van 'hoe durf je dat te
vragen, wij vatten dat op als grove kritiek op ons product, etc.'
Ik hoop dat jij geen leraar bent (de leerkrachten zijn toch al niet zo
denderend als je TI moet geloven).
Leo
Rob Janssen
>Btw, op hoeveel nullen eindigt 52!?
Eens even kijken...
$ bc
define f(x) {
if (x == 1) return (1) else return (x * f(x-1))
}
f(52)
80658175170943878571660636856403766975289505440883277824000000000000
$
12 nullen dus.
maar deze manier bedoelde je niet zeker...
(wiens rekenmachine rekent dat ook zo gemakkelijk even uit?)
Frank Bemelman
kjb=730...@cs.vu.nl (Kees J Bot) wrote:
[snip]
>>Frank Bemelman <fbe...@worldonline.nl> wrote:
>>Bij x^y waarbij y een geheel getal is, zie ik liever de exacte
>>uitkomst.
>Niet als dat betekent dat de algemene x^y functie daarmee discontinu
>wordt, dwz als bijvoorbeeld x^4.999999, x^5, en x^5.000001 niet keurig
>opeenvolgende waarden opleveren.
>Het is veel belangrijker dat de machine implementatie van een
>mathematische functie keurig continu is dan dat ie preciese antwoorden
>geeft voor "nette getallen". Misschien dat TI wel een x^y functie
>heeft die een kleine fout heeft bij de nette machten, maar voor de hele
>reeks waarden van x en y een gemiddeld betere benadering is dan andere
>mogelijke x^y functies. Als dat zo is dan heeft TI de juiste keuze
>gemaakt.
>--
>Kees J. Bot, Systeemprogrammeur, Vrije Universiteit Amsterdam
Ja, daar heb je wel een heel goed argument in handen. Bij een off-line
handcalculator zie ik niet direct het gevaar, maar bij een coprocessor
of math-library is dat wel zo prettig.
Hartelijke groeten,
Frank Bemelman.
Jan Gerritsjans
Johan Wevers wrote:
> Dacht je soms dat ze in rekenmachines gammafuncties (of ingewikkelder
> reeksen) gebruikten om de log van negatieve getallen uit te rekenen?
> Ze zijn nu al traag genoeg (de standaardtest is nog altijd de tijd die
> de calculator voor 69! nodig heeft).
>
Moet je een scientific Philipsding kopen: die van mij heeft 10!, 20!,
30!, 40!, 50! en 60! in z'n geheugen zitten, zodat 65! sneller
uitgerekend wordt dan 59!, om maar een voorbeeld te noemen.
Btw, op hoeveel nullen eindigt 52!?
Deze vraag stelde ik onlangs in het pleeboek van mijn studentenhuis. De
PABO'ers, TIO'er en HTS'er kwamen er niet uit. Ze namen overigens ook
niet de moeite om het uit te rekenen, terwijl er toch papier genoeg
was...
> ir. J.C.A. Wevers <*> For Physics and science fiction
Jan
Tarzan
Aan 7-04-97 1:06, in bericht <33482c67.5...@vulcan.xs4all.nl>, Johan
Wevers <joh...@vulcan.xs4all.nl> schreef:
> Tarzan <bjd...@worldaccess.nl> wrote:
>
> >Computers geven trouwens bij zeer simpele bewerkingen ook snel fouten.
> Probeer
> >dit BASIC-programmaatje maar:
> >
> >do
> >x = x +.16
> >print x
> >loop
> >
> >Binnen de kortste keren heb je een getal met 6 cijfers achter de komma.
>
> Dat zegt meer over de BASIC variant die jij gebruikt dan over moderne PC's
> denk ik. In C of Pascal heb je in elk geval nog invloed over de grootte van
> de interne representatie (en het emplementeren van een willekeurig precieze
> interne notatie is een standaardopgave in veel C boeken als men
> pointerstructuren behandeld). Kan zelfs vrij eenvoudig (maar niet zo
> efficient) zonder pointers.
Maakt niet uit welke BASIC versie je gebruikt. Ik denk zelfs dat C het ook doet. In
BASIC gebruikt dit programmaatje gewoon een 'SINGLE'-formaat ofwel: gewoon een
zooitje cijfers achter de komma. Onnodige nullen worden niet afgedrukt. De uitkomst
zou dus nooit meer dat 2 decimalen moeten bevatten. Toch krijg je 6 decimalen.
Groetjes,
Johan Wevers
Luc Peersman <Luc.Pe...@net.HCC.nl> wrote:
>Er was nogal wat te doen om de Pentium die niet kon rekenen.
[...]
>Probeer maar eens
>
>=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
>in Excel of zo. Hij zegt dat het ONWAAR is.
Zegt denk ik meer over excel dan over die pentium. Probeer dat maar eens in
een ftsoenlijk methematisch pakket als Maple, die verrekend zich echt niet
met zoiets.
Gerard van Wilgen
fbe...@worldonline.nl (Frank Bemelman) wrote:
>gvwi...@worldonline.nl (Gerard van Wilgen) wrote:
>[snip]
>>Ik denk dat de macht 3 hier de boosdoener is omdat het getal 3 nu
>>eenmaal niet exact in binaire notatie kan worden weergegeven.
>Drie is binair toch gewoon 11 ? Afgezien daarvan begrijp ik je
>redenatie ook niet erg.
Het schaamrood stijg mij naar de kaken. Je hebt helemaal gelijk. Ik
bedoelde natuurlijk dat het geen macht van 2 is en dat zoiets in een
binair rekenende machine op de een of andere manier (vraag me niet
hoe) een verschil zou kunnen maken. Een uiterst zwakke redenering
realiseer ik me nu.
<KNIP>
>Betere calculators komen alleen op de markt als er gemierenneukt
>wordt. Als iedereen met alles tevreden was, zaten we nu nog bananen
>te pellen en vlooien te knappen. Als ik met mijn calculator 37 keer de
>wortel uit 2 trek, en daarna 37 keer kwadrateer, heb ik een
>aanzienlijke afwijking die ik wel accepteer, maar dat laat niet
>onverlet dat de fabrikanten daar iets aan zouden mogen doen.
Waarvoor heb je zo'n nauwkeurigheid dan nodig? Het lijkt mij net
zoiets als vragen om een personenweegschaal die het gewicht tot op een
picogram nauwkeurig kan meten.
>Hartelijke groeten,
>Frank Bemelman.
-------------------------------------------------------
Take a look at my multilingual dictionary programme at:
http://www.travlang.com/Ergane/
-------------------------------------------------------
Izak van Langevelde
> On Fri, 04 Apr 1997 23:10:22 GMT, leo Koenen wrote in nl.wetenschap:
> ++ Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
> ++ volgende formule:
> ++ 4 3
> ++ 1/4.(-4) + (-4)
> ++
> ++ Daar hoort dus nul uit te komen. Zo niet bij de Texas TI-35X. Er kwam
> ++ weliswaar een getal uit dat dicht bij nul lag, maar geen nul.
>
> [ Citaten ]
>
> Het is een bekend probleem, en TI heeft volkomen gelijk.
Niet helemaal: een formulering als 'neuswijze scholieren' is niet bepaald
tactvol. Daarbij kan ik me levendig voorstellen dat iemand vindt dat een
telraampje zo'n nare formule eerst maar even moet omschrijven voordattie
met vieze decimalen gaat rekenen. Zoals ieder weldenkend dat zou doen...
--
Grinnikend door het leven...
Frank Bemelman
Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
>Er was nogal wat te doen om de Pentium die niet kon rekenen. Zoals uit
>deze draad al blijkt, zijn er echter altijd beperkingen en daar moet
>je mee leren leven.
Wat is dat toch voor een zacht-gekookte-eieren-mentaliteit om te
stellen 'daar moet je mee leren leven'. Dit zijn toch behoorlijk
grote ergernissen.
>Probeer maar eens
>=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
>in Excel of zo. Hij zegt dat het ONWAAR is.
>Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
>Pentium! :-)
Ja, en dat is een schande. Wordt het niet eens tijd dat coprocessors
en dergelijke een bit toevoegen aan een getal wat aangeeft dat er
decimalen verloren zijn gegaan, ofwel dat het aantal decimalen tekort
schiet om het getal exact weer te geven ?
Ontwerpers die produkten maken die door de massa gebruikt worden,
hebben de morele verplichting om iets fatsoenlijks neer te zetten.
Deksels die niet van potjes willen, waterpomptangen die te ver
dichtklappen en je vingers kneuzen als je van een werkstuk afschiet,
schakelaars die blijven hangen, houdbaarheidsdatums die onleesbaar
zijn, of voor tweeerlei uitleg vatbaar, alarmklokken zonder
backupbatterij, plakband wat verloopt en niet meer plakken wil,
lucifers die afbreken, boutjes met amerikaanse schroefdraad, veters
die zich in een dubbele knoop vasttrekken bij het losmaken (!) knopen
die van overhemden afvallen (in een tijdperk waarin met g.v.d.
raketten naar de maan schiet) het laatste nietje in een niettang wat
zich onwrikbaar in het mechaniek vastzet, 6 verschillende pluggen bij
batterijadapters behalve de goeie, busjes gas die niet op je aansteker
passen, PC's die er 3 minuten over doen om op te booten terwijl er
maar maximaal 32 MB ram te vullen valt waardoor het in 20 seconden
moet kunnen, telefoonsnoeren die in de krul raken, warmwaterkranen met
water >80C waar je je handen onder verbrandt,
kneiteharde roomboter uit de koelkast, wijnkurken die er maar half
uitkomen, postzegels die loslaten, spaarakties die aflopen voor je
kaart vol is, GSM-telefoons die niet te verstaan zijn, witte
behuizingen die in 6 maanden vergelen, en zo kan ik nog wel even
doorgaan. En daar moeten we dan maar mee leren leven ?
Hartelijke groeten,
Frank Bemelman.
Johan Wevers
Tarzan <bjd...@worldaccess.nl> wrote:
>> >do
>> >x = x +.16
>> >print x
>> >loop
>Maakt niet uit welke BASIC versie je gebruikt. Ik denk zelfs dat C het ook
>doet. In
In C en Pascal moet je eerst aangeven welk type "x" is. Dat kan een signed
of unsigned float, real of double zijn, of een eigen structuur die bv. 32
bytes groot is. Als je in C++ werkt kun je daar ook allerlei operatoren op
definieren zodat je eigen types net zo gebruikt kunnen worden als de
standaard types.
>BASIC gebruikt dit programmaatje gewoon een 'SINGLE'-formaat ofwel: gewoon een
>zooitje cijfers achter de komma.
Hoeveel precies? Als je numeriek werk gaat doen is het wel handig dat te
weten (maar ja, wie gaat er nu serieus rekenwerk in BASIC doen?).
>Onnodige nullen worden niet afgedrukt.
Da's irrelevant voor de rekenprecisie. Dat kun je in C en Pascal trouwens
in je afdrukroutines aangeven.
>De uitkomst zou dus nooit meer dat 2 decimalen moeten bevatten. Toch krijg
>je 6 decimalen.
Tja, moet je ook maar een serieuzer programmeertaal gebruiken.
Abigail
On Mon, 07 Apr 1997 19:37:21 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:<33495b01.5...@vulcan.xs4all.nl>>:
++ Jan Gerritsjans <j.m.j.m.g...@math.utwente.nl> wrote:
++
++ >Moet je een scientific Philipsding kopen: die van mij heeft 10!, 20!,
++ >30!, 40!, 50! en 60! in z'n geheugen zitten, zodat 65! sneller
++ >uitgerekend wordt dan 59!, om maar een voorbeeld te noemen.
++
++ Slim.
Nee, niet slim, maar een marketing truc. Als ie slim was, dan deed ie
59! wel sneller dan 65!. (59! = 60! / 60).
++ >Btw, op hoeveel nullen eindigt 52!?
++
++ Op 12 nullen volgens Maple.
Bleh, kun je het echt niet uit je hoofd?
Abigail
Jeroen Rutten
Rob Janssen (rob@pe1chl) wrote:
: In <334904...@math.utwente.nl> Jan Gerritsjans <j.m.j.m.g...@math.utwente.nl> writes:
: >Btw, op hoeveel nullen eindigt 52!?
: Eens even kijken...
: $ bc
: define f(x) {
: if (x == 1) return (1) else return (x * f(x-1))
: }
: f(52)
: 80658175170943878571660636856403766975289505440883277824000000000000
: $
: 12 nullen dus.
: maar deze manier bedoelde je niet zeker...
Aantal nullen van n! = (n div 5) + (n div 5^2) + (n div 5^3) + ...
Voor n=52 geeft dit dus 10 + 2 + 0 + 0 + ... = 12.
Groeten,
--
Jeroen Rutten | ....
Maastricht University, Department of Mathematics | ' __
P.O. Box 616 | /_/ /
6200 MD Maastricht, The Netherlands | _/ /
e-mail: jer...@orthos.math.unimaas.nl | =__ (
URL: http://www.cs.unimaas.nl/~math/jeroenr/jeroenr.htm | ~ ||
Freek Kamst
Wat dacht je van Windows 95? Het ultieme wanprodukt, door grote haast zo
snel in elkaar gezet dat er belangrijke fouten er niet uitgehaald zijn.
Bovendien is het zo dichtgetimmerd dat als er echt iets aan de hand is
alleen een deskundige het probleem op kan lossen. De ontwikkelingen in
de maatschappij gaan zo snel, dat er geen tijd is om rustig over een
produkt na te denken.
Freek Kamst
Henk Schets
In article <5ib0ha$jld$3...@elektron.et.tudelft.nl>,
br...@dutein61.et.tudelft.nl says...
>
>De HP48S(X) Revision E geeft gewoon 0.
>
>
Henkie
Jan Gerritsjans
Abigail wrote:
>
>
> 't Is gewoon hoofdrekenen (50/5 + 50/25, dat moet toch iedereen
> kunnen zonder papier?).
Vind ik ook, maar ja.
>
> Op hoeveel nullen eindigt 1000! in het 36-tallig stelsel?
>
248?
Of heb je 1000 ook 36-tallig weergegeven? Dan pas ik met m'n blote
hoofd.
> Abigail
> perl -we '$,="*";$\="\n";print(1..52);'|bc
> 80658175170943878571660636856403766975289505440883277824000000000000
Jan
K de Jong
Freek Kamst <G.F....@wbmt.tudelft.nl> wrote:
>Wat dacht je van Windows 95? Het ultieme wanprodukt, door grote haast zo
>snel in elkaar gezet dat er belangrijke fouten er niet uitgehaald zijn.
Die fouten zitten er vaak al vanaf DOS 1.0 in !!
>Bovendien is het zo dichtgetimmerd dat als er echt iets aan de hand is
>alleen een deskundige het probleem op kan lossen. De ontwikkelingen in
>de maatschappij gaan zo snel, dat er geen tijd is om rustig over een
>produkt na te denken.
Heb je wel eens gewerkt met software die gewoon doet wat ervan
verwacht wordt ?? Dat is helemaal niet leuk, is mijn ervaring.
Software moet gewoon een beetje 'krom' zijn anders gaat de
aantrekkingskracht verloren. Maar zo erg als WIN95 hoeft natuurlijk
niet !!
Voordeel voor Microsoft: de roep om updates wordt sterker.
K de Jong
Luc Peersman
>Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
>
>>Er was nogal wat te doen om de Pentium die niet kon rekenen. Zoals uit
>>deze draad al blijkt, zijn er echter altijd beperkingen en daar moet
>>je mee leren leven.
>
>Wat is dat toch voor een zacht-gekookte-eieren-mentaliteit om te
>stellen 'daar moet je mee leren leven'. Dit zijn toch behoorlijk
>grote ergernissen.
>
>>Probeer maar eens
>
>>=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
>
>>in Excel of zo. Hij zegt dat het ONWAAR is.
>>Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
>>Pentium! :-)
>
>Ja, en dat is een schande. Wordt het niet eens tijd dat coprocessors
>en dergelijke een bit toevoegen aan een getal wat aangeeft dat er
>decimalen verloren zijn gegaan, ofwel dat het aantal decimalen tekort
>schiet om het getal exact weer te geven ?
>
etc etc. Ik heb smakelijk moeten lachen om je Youp van 't Hek achtige
tirade tegen de ergernissen die de Modern Times met zich meebrengen !
Maar die zacht-gekookte eieren spuug ik weer ff uit. Punt is dat je
moet leren omgaan met apparatuur en beperkingen. Mijn moeder is altijd
verontwaardigd als ze een videoband in het apparaat doet en het ding
niet laat zien wat ze wilt. Dat het de juiste band moet zijn en dat
ding ook nog tot de juiste plaats gespoelt moet worden valt buiten
haar beleving. Rekenmachines maken fouten, dat is inherent aan die
dingen! Als je weet waar die fouten vandaan komen, is de ergernis maar
half zo groot.
CD's blijken altijd net een minuut te lang te duren als je ze opneemt,
batterijen van rekenmachines raken alleen maar op tijdens een
belangrijk tentamen, treinen vertrekken altijd te laat, behalve als
jij te laat bent, veters trek je kapot en vergeet het maar om de vlam
van de CV-ketel weer aan te krijgen.
En ja, daar moeten we allemaal mee leren leven!
Kees J Bot
In article <5ibilc$4o1$2...@neptune.worldonline.nl>,
Ik heb nog even rondgekeken in de math library van een O.S. waar ik mijn
vrije tijd aan verspil: http://Minix-vmd.cs.vu.nl/current/src/lib/libm/
In de file e_pow.c kwam ik dit tegen:
* Accuracy:
* pow(x,y) returns x**y nearly rounded. In particular
* pow(integer,integer)
* always returns the correct integer provided it is
* representable.
Als ik dit goed lees dan geeft de pow(x,y) functie het best mogelijke
resultaat van de mathematische x^y binnen de nauwkeurigheid van een
double precision floating point getal. Beter kan het dus niet, alleen
mogelijk sneller. Ook staat er dat voor gehele getallen als input ook
zo mogelijk een geheel getal uitkomt.
Er zijn nu verschillende mogelijkheden:
- Een rekenmachine is te beperkt om een goede x^y te bevatten, en de
best mogelijke implementatie is niet exact voor gehele getallen (TI).
- Een rekenmachine is te beperkt om een goede x^y te bevatten, maar om
de gebruiker geen neerbuigende brieven te hoeven sturen herkennen we
gehele getallen en geven een exact resultaat. Dit maakt x^y dis-
continu, maar dat merkt toch niemand (TI's concurrenten).
- Een rekenmachine kan wel een goede x^y bevatten (TI's concurrenten).
- Anders?
Zolang ze er bij een rekenmachine niet goed bijvertellen wat de
precisie van het apparaat en de geimplementeerde functies is zullen we
helaas niet kunnen zeggen of een TI slechter, beter of eerlijker is.
Rob Janssen
>Op hoeveel nullen eindigt 1000! in het 36-tallig stelsel?
249
Rob Janssen
>Het schaamrood stijg mij naar de kaken. Je hebt helemaal gelijk. Ik
>bedoelde natuurlijk dat het geen macht van 2 is en dat zoiets in een
>binair rekenende machine op de een of andere manier (vraag me niet
>hoe) een verschil zou kunnen maken. Een uiterst zwakke redenering
>realiseer ik me nu.
Je hebt de klok horen luiden maar weet niet waar de klepel hangt...
Wat er aan de hand is, is dat een gebroken getal wat decimaal met een
begrensd aantal cijfers is voor te stellen, in een binaire floating-point
representatie een repeterende breuk kan zijn. Gevolg is dat simpele
bewerkingen zoals herhaald optellen vreemde resultaten geven. Het herhaald
optellen van 0.16 is daarvan een voorbeeld.
Vergelijk het representeren van 1/3 in het decimale stelsel. Je kunt dit
niet exact weergeven, je moet afronden. Als je dergelijke afgeronde waarden
herhaald gaat optellen dan kom je niet op het verwachte resultaat.
Bijvoorbeeld: 1/3 is ongeveer 0.333
0.333 + 0.333 + 0.333 is 0.999 terwijl 1/3 + 1/3 + 1/3 = 1.
aqu...@dds.nl
Henk Schets wrote:
en mijn casio fx82 ook nog!
(waar over gaat het nu eigenlijk)
JAC
Erik Springelkamp
|>=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
|
|>in Excel of zo. Hij zegt dat het ONWAAR is.
|>Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
|>Pentium! :-)
|
|Ja, en dat is een schande. Wordt het niet eens tijd dat coprocessors
|en dergelijke een bit toevoegen aan een getal wat aangeeft dat er
|decimalen verloren zijn gegaan, ofwel dat het aantal decimalen tekort
|schiet om het getal exact weer te geven ?
In principe moet je er van uitgaan dat een real/float nooit precies
is. Een test als IF(A=B) met A en B real zou eigenlijk verboden moeten
worden.
Voor zover ik me herinner geeft Excel ook wel waarscuwingen tegen het
testen op gelijkheid.
--
Erik Springelkamp
spri...@noord.bart.nl
http://www.noord.bart.nl/~springel/
Luc Peersman
On Fri, 04 Apr 1997 23:10:22 GMT, le...@knoware.nl (leo Koenen) wrote:
>Na aankoop van een texas rekenmachine (type TI-35X) probeerde ik de
>volgende formule:
> 4 3
>1/4.(-4) + (-4)
>
etc.
vreemd verloop van deze draad, de reactie van Texas was beneden alle
peil. Ook al is de fout van de machine te verklaren en is het
interessant om er over na te denken hoe rekenmachines hun kunsten
vertonen, het geeft geen pas om zo'n toon tegen een klant aan te
slaan.
Groet,
Luc.
Luc Peersman
On Mon, 07 Apr 1997 16:54:12 -0100, joh...@vulcan.xs4all.nl (Johan
Wevers) wrote:
>Luc Peersman <Luc.Pe...@net.HCC.nl> wrote:
>
>>Er was nogal wat te doen om de Pentium die niet kon rekenen.
>[...]
>>Probeer maar eens
>>
>>=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
>>in Excel of zo. Hij zegt dat het ONWAAR is.
>
>Zegt denk ik meer over excel dan over die pentium. Probeer dat maar eens in
>een ftsoenlijk methematisch pakket als Maple, die verrekend zich echt niet
>met zoiets.
Ik heb het ondertussen geprobeerd met Excel, Mathematica, Qbasic en
Matlab en die gaan allemaal nat. (Qbasic is nauwelijks serieus te
nemen, zoiets zei jij elders ook al, daar gaat echt alles fout)
Maple heb ik niet, ik heb het geprobeerd bij een vriend op een 486,
daar ging het goed! Kun jij het ff op je Pentium doen? (bvd!) En als
het goed gaat, hoe kan dan dat dat programma de machine-fout omzeilt
en bv Matlab niet?
Overigens val ik er niet zo over dat het mis gaat, het verbaast me
alleen dat het bij zo'n simpel sommetje al aan het licht komt.
Met groet,
Luc
Johan Wevers
Abigail <abi...@ny.fnx.com> wrote:
>>Op 12 nullen volgens Maple.
>Bleh, kun je het echt niet uit je hoofd?
Net zo goed als jij het zonder Perl kunt.
Frank Bemelman
Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
[snip]
>Maar die zacht-gekookte eieren spuug ik weer ff uit. Punt is dat je
>moet leren omgaan met apparatuur en beperkingen. Mijn moeder is altijd
>verontwaardigd als ze een videoband in het apparaat doet en het ding
>niet laat zien wat ze wilt. Dat het de juiste band moet zijn en dat
>ding ook nog tot de juiste plaats gespoelt moet worden valt buiten
>haar beleving. Rekenmachines maken fouten, dat is inherent aan die
>dingen! Als je weet waar die fouten vandaan komen, is de ergernis maar
>half zo groot.
>CD's blijken altijd net een minuut te lang te duren als je ze opneemt,
>batterijen van rekenmachines raken alleen maar op tijdens een
>belangrijk tentamen, treinen vertrekken altijd te laat, behalve als
>jij te laat bent, veters trek je kapot en vergeet het maar om de vlam
>van de CV-ketel weer aan te krijgen.
>En ja, daar moeten we allemaal mee leren leven!
En die laatste zin zit me dus niet lekker. Misschien ken je die
sleufjes wel, waar je een pasje doorheen moet halen om een deur te
openen. Geheid dat je je pasje er verkeerd doorheen haalt, dus nog een
linksom, rechtsom, ondersteboven, achterstevoren. Had men zich de
moeite getroost 2 magneetkoppen te monteren en de processor zo in te
richten dat die de bitstream zowel voorwaarts als achterwaarts juist
weet te interpreteren.
Misschien komen er nog weleens videobanden met een kleine LCD erop
geplakt, die bij opname uit de teletekstsignalen de programma-naam
haalt, en in het display zet en laat staan. Kun je een band pakken, en
je ziet meteen wat erop staat. Het kan nog wel goedkoper, een
i2c-eeprom op de casette, die na inwerpen van de band een menu op de
buis zet met een overzicht van de aanwezige opnames. Je moeder heeft
gewoon gelijk. De techniek is er om ons te dienen, en niet andersom.
Laatst trek ik een kaartje uit een parkeermeter. Staat een tekst op
geprint 'ongeldig', plus de toegestane parkeertijd. Wie het niet
gelooft wil ik wel een pcx-file van dat kaartje sturen (heb 'm
bewaard). Er zal op het moment wel iets mis geweest zijn, maar welke
verziekte geest richt de software zo in dat er ook nog een kaartje
geprint wordt ?
Ik heb hier een rekenmachientje met 'dual power'. Geeft een prima
aflezing op de batterij, en als die leeg is wat minder. Moet ik een
beetje draaien/richten naar het licht. Dat is al een stuk beter dan
dat ding van jou, die tijdens een tentamen de geest geeft.
Het is zo makkelijk om te zeggen 'daar moet je maar mee leven'. De
arabieren hebben een spreuk 'Alleen het werk van Allah is perfect'. In
een handgeknoopt kleed vind je daarom altijd 1 knoop die verkeerd zit.
Daar heb ik niks op tegen, want verder is er dan ook niets op zo'n
kleed aan te merken. In een andere situatie wilde ik een gaatje boren,
door de slaapkamervloer (voor een antennekabeltje). Ik dacht wel door
het tapijt heen te kunnen boren. Een druk op de knop, en er zat meteen
een hele kluit synthetische wol rond mijn boor plus een lange kale
streep in het tapijt, over de hele lengte van de slaapkamer. Van mij
mogen de tapijtfabrikanten wel een andere machine bedenken die anders
weeft en knoopt om dit soort ongein te voorkomen.
Hartelijke groeten,
Frank Bemelman.
Abigail
On Tue, 08 Apr 1997 22:19:35 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:334ad287.5...@vulcan.xs4all.nl>:
++ Abigail <abi...@ny.fnx.com> wrote:
++
++ >>Op 12 nullen volgens Maple.
++ >Bleh, kun je het echt niet uit je hoofd?
++
++ Net zo goed als jij het zonder Perl kunt.
Ik deed het zonder perl. (10 + 2 dat kan ik echt wel op mijn vingers).
Abigail (of dacht je echt dat ik 52! uitrekende en nullen ging tellen?)
Antoon Pardon
: >Probeer maar eens
: >=ALS(5,7-3*1,9=0;WAAR;ONWAAR)
: >in Excel of zo. Hij zegt dat het ONWAAR is.
: >Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
: >Pentium! :-)
: Ja, en dat is een schande. Wordt het niet eens tijd dat coprocessors
: en dergelijke een bit toevoegen aan een getal wat aangeeft dat er
: decimalen verloren zijn gegaan, ofwel dat het aantal decimalen tekort
: schiet om het getal exact weer te geven ?
Waarom. De normale verwachtingen zijn dat er decimalen verloren
zijn gegaan of dat het aantal tekort schoot. Wat die persoon aan
dat rekenmasjientje vroeg kwam er op neer dat je aan een persoon
vroeg om 3 * 0.3333 uit te rekenen en dan verbaast bent dat hij
niet 1 uitkwam.
: Ontwerpers die produkten maken die door de massa gebruikt worden,
: hebben de morele verplichting om iets fatsoenlijks neer te zetten.
Ja maar wat jij wil lijkt meer op het vragen naar een mes waarmee
je je niet in de vingers kan snijden.
--
All opinions expressed herein are currently under revision
==========================================================
Antoon Pardon Brussels Free University Computing Centre
==========================================================
Antoon Pardon
: [snip]
: >Maar die zacht-gekookte eieren spuug ik weer ff uit. Punt is dat je
: >moet leren omgaan met apparatuur en beperkingen. Mijn moeder is altijd
: >verontwaardigd als ze een videoband in het apparaat doet en het ding
: >niet laat zien wat ze wilt. Dat het de juiste band moet zijn en dat
: >ding ook nog tot de juiste plaats gespoelt moet worden valt buiten
: >haar beleving. Rekenmachines maken fouten, dat is inherent aan die
: >dingen! Als je weet waar die fouten vandaan komen, is de ergernis maar
: >half zo groot.
: >CD's blijken altijd net een minuut te lang te duren als je ze opneemt,
: >batterijen van rekenmachines raken alleen maar op tijdens een
: >belangrijk tentamen, treinen vertrekken altijd te laat, behalve als
: >jij te laat bent, veters trek je kapot en vergeet het maar om de vlam
: >van de CV-ketel weer aan te krijgen.
: >En ja, daar moeten we allemaal mee leren leven!
: En die laatste zin zit me dus niet lekker.
Doe er dan zelf iets aan. Als het voor jouw een groot genoeg
probleem is neem dan het inisiatief om zelf voor een oplossing te
zorgen. Maar als dat niet kan en er zijn geen andere mensen die
het doen moet je niet zeuren als andere mensen jouw probleem niet
belangrijk genoeg vinden om hun tijd in te steken en zal je daar
inderdaad mee moeten leren leven.
Jan Gerritsjans
Abigail wrote:
>
> On Tue, 08 Apr 1997 13:05:56 +0200, Jan Gerritsjans wrote in
> nl.wetenschap <URL: news:334A26...@math.utwente.nl>:
> ++ Abigail wrote:
> ++ >
> ++ >
> ++ > 't Is gewoon hoofdrekenen (50/5 + 50/25, dat moet toch iedereen
> ++ > kunnen zonder papier?).
> ++
> ++ Vind ik ook, maar ja.
> ++ >
> ++ > Op hoeveel nullen eindigt 1000! in het 36-tallig stelsel?
> ++ >
> ++ 248?
>
> Mijn hoofdrekenen kwam op 249.
>
[lang getal en veel nullen geknipt]
> 249 nullen....
>
Het is fout gegaan vanaf het moment dat ik 498 factoren drie had
gevonden...
> Abigail
Jan
Abigail
On Mon, 07 Apr 1997 23:42:29 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:33499475.5...@vulcan.xs4all.nl>:
++ Tarzan <bjd...@worldaccess.nl> wrote:
++
++ >> >do
++ >> >x = x +.16
++ >> >print x
++ >> >loop
++
++ >Maakt niet uit welke BASIC versie je gebruikt. Ik denk zelfs dat C het ook
++ >doet. In
++
++ In C en Pascal moet je eerst aangeven welk type "x" is. Dat kan een signed
++ of unsigned float, real of double zijn, of een eigen structuur die bv. 32
++ bytes groot is. Als je in C++ werkt kun je daar ook allerlei operatoren op
++ definieren zodat je eigen types net zo gebruikt kunnen worden als de
++ standaard types.
++
++ >BASIC gebruikt dit programmaatje gewoon een 'SINGLE'-formaat ofwel:
++ >gewoon een
++ >zooitje cijfers achter de komma.
++
++ Hoeveel precies? Als je numeriek werk gaat doen is het wel handig dat te
++ weten (maar ja, wie gaat er nu serieus rekenwerk in BASIC doen?).
++
++ >Onnodige nullen worden niet afgedrukt.
++
++ Da's irrelevant voor de rekenprecisie. Dat kun je in C en Pascal trouwens
++ in je afdrukroutines aangeven.
++
++ >De uitkomst zou dus nooit meer dat 2 decimalen moeten bevatten. Toch krijg
++ >je 6 decimalen.
++
++ Tja, moet je ook maar een serieuzer programmeertaal gebruiken.
Dus je vindt C geen serieuze programmeertaal?
$ cat f.c
# include <stdio.h>
# include <stdlib.h>
main () {
float x;
int i;
x = 0;
for (i = 1000; i --; x += 0.16);
printf ("%f\n", x);
}
$ gcc -o f f.c
$ ./f
160.002136
$
Of Perl?
$ perl -w
my $x = 0;
foreach (1 .. 1000) {$x += 0.16;}
print $x, "\n"
__END__
159.999999999997
$
LPC?
> more g.c
void create () {
float x;
int i;
x = 0.0;
for (i = 1000; i --; x += 0.16);
write (sprintf ("%f\n", x));
}
> load g
160.002136
Ok.
>
Wat is dan wel een serieuze programmeertaal in jouw ogen?
Awk misschien?
$ awk '
BEGIN {x = 0
for (i = 1000; i --; x += 0.16);}
END {printf ("%f\n", x);}
'
^D
160.000000
$
Of SQL?
1> declare @x float
2> declare @i int
3> select @x = 0
4> select @i = 1000
5> while (@i > 0)
6> begin select @x = @x + 0.16
7> select @i = @i - 1
8> end
9> select @x
10> go
--------------------
160.000000
(1 row affected)
1>
bc?
$ bc -l
define f () {
auto x, i
i = 1000
while (i > 0) {
i = i - 1
x = x + 0.16
}
return (x)
}
f ()
160.00
$
Wat, meneer de ir., is nu een serieuze programmeertaal?
Abigail
Frank Bemelman
Paul van Empelen <p...@nospam.xs4all.nl> wrote:
>br...@dutein61.et.tudelft.nl (Bram Heerink) writes:
>> De HP48S(X) Revision E geeft gewoon 0.
>En wat geeft 'ie voor sin (pi)?
>Mijn HP-42s komt op -206e-15.
>Ooit een commodore 64 gehad?
>7^2 = 49.00000000001.
Op mijn Sharp EL-531GH (van de kijkshop)
resp. 0 en 49.
Hartelijke groeten,
Frank Bemelman.
Johan Wevers
Abigail <abi...@ny.fnx.com> wrote:
>>Tja, moet je ook maar een serieuzer programmeertaal gebruiken.
>Dus je vindt C geen serieuze programmeertaal?
Jawel, maar ook in C kun je het fout doen.
>Of Perl?
Perl? Dat is een scripttaal.
>LPC?
Nooit van gehoord.
>Wat is dan wel een serieuze programmeertaal in jouw ogen?
>Awk misschien?
Ook een scripttaal.
>Of SQL?
Niet voor serieus numeriek werk, wel voor grote financiele databases.
>bc?
Ken ik te weinig.
>Wat, meneer de ir., is nu een serieuze programmeertaal?
Ada. :-)
Johan Wevers
Luc Peersman <Luc.Pe...@net.HCC.nl> wrote:
>Maple heb ik niet, ik heb het geprobeerd bij een vriend op een 486,
>daar ging het goed! Kun jij het ff op je Pentium doen? (bvd!)
Als je me een Pentium cadeau doet wel, ik heb nu alleen een 486.
>En als het goed gaat, hoe kan dan dat dat programma de machine-fout
>omzeilt en bv Matlab niet?
Volgens mij is dat zeker geen machine fout. Trouwens, elke moderne pentium
is al lang verlost van die fdiv bug, die zat alleen in de oudste 60 en 66
MHz versies.
Johan Wevers
Tarzan <bjd...@worldaccess.nl> wrote:
>Gelukkig lukt het in C ook niet :-)
Jawel, alleen is hier gedeminstreerd dat het in C ook fout kan gaan. En
dat heb ik ook nooit ontkent. Je moet die grotere structuren wel zelf
definieren of uit een library halen.
>Je hoeft BASIC trouwens niet zo af te zeiken: voor beginners is het een
>zeer goede taal.
Ach... een van de grootste nadelen van alle BASIC dialecten is wel dat ze
totaal niet portable zijn. C heeft dat veel meer, een puur rekenprogramma
in C kun je zonder aanpassingen meestal op zowel een zware Cray als op een
PC onder DOS compileren.
>Ik heb ontdekt dat ik het vermogen heb om iemands karakter uit een enkel
>e-mailtje kan bepalen.
Als je er een stuurt kun je daar zeker uit afleiden dat die persoon een
bijgelovige sukkel is.
Frank Bemelman
Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
>On Tue, 08 Apr 1997 13:41:48 GMT, fbe...@worldonline.nl (Frank
>Bemelman) wrote:
>>En die laatste zin zit me dus niet lekker. Misschien ken je die
>>sleufjes wel, waar je een pasje doorheen moet halen om een deur te
>>openen. Geheid dat je je pasje er verkeerd doorheen haalt, dus nog een
>>linksom, rechtsom, ondersteboven, achterstevoren. Had men zich de
>>moeite getroost 2 magneetkoppen te monteren en de processor zo in te
>>richten dat die de bitstream zowel voorwaarts als achterwaarts juist
>>weet te interpreteren.
>>
>Dus er moet een extra kop bij omdat jij te beroerd bent om het een
>paar keer te proberen? Als jij een sjekkie rolt, lukt er zeker maar
>één op de vier. Vloeitjes moeten 4 plakranden hebben?
Ja, er moet een kop bij. Op de totale kosten van een dergelijk
apparaatje maakt een extra kop niet veel uit. De software zo inrichten
dat de bitstream zowel vooruit als achteruit juist wordt
geinterpreteerd is een kwestie van iets listiger software, wat extra
inspanning van de programmeur. Met name dat laatste heeft nauwelijks
invloed op het kostenplaatje. Gezien de problemen met het draaien van
sjekkies rook ik alleen sigaretten.
>>Misschien komen er nog weleens videobanden met een kleine LCD erop
>>geplakt, die bij opname uit de teletekstsignalen de programma-naam
>>haalt, en in het display zet en laat staan. Kun je een band pakken, en
>>je ziet meteen wat erop staat. Het kan nog wel goedkoper, een
>>i2c-eeprom op de casette, die na inwerpen van de band een menu op de
>>buis zet met een overzicht van de aanwezige opnames. Je moeder heeft
>>gewoon gelijk. De techniek is er om ons te dienen, en niet andersom.
>Dat laatste is zeker waar, maar de door jou voorgestelde videobanden
>bieden geen oplossing. Het zal altijd mogelijk blijven de dingen op
>een stupide manier te gebruiken. Als voetbal bv. en dan klagen dat ze
>zo slecht stuiteren.
Point taken, ik chargeer de boel ook een beetje, maar het lijkt er af
en toe weleens op dat het begrip 'intuitief' langzamerhand uit onze
woordenschat dreigt te verdwijnen. Kijk eens naar je numerieke pad
op je keyboard, en vergelijk het met dat van je telefoon. Valt je niks
op ? De PTT was overigens wel consequent bij het ontwerpen van
de bekende 'numculator', zelfde indeling als op de telefoons.
Flappentappers hebben ook de telefoon-indeling, evenals de meeste
(maar niet alle!) pinautomaten , terwijl je zou verwachten dat men
hier de numerieke variant zou gebruiken.. Je kunt het gezeur noemen,
maar weleens gedacht aan mensen die blind/slechtziend zijn ?
>>Laatst trek ik een kaartje uit een parkeermeter. Staat een tekst op
>>geprint 'ongeldig', plus de toegestane parkeertijd. Wie het niet
>>gelooft wil ik wel een pcx-file van dat kaartje sturen (heb 'm
>>bewaard). Er zal op het moment wel iets mis geweest zijn, maar welke
>>verziekte geest richt de software zo in dat er ook nog een kaartje
>>geprint wordt ?
>Dat is inderdaad ten hemel schreiend. Ik ben het met je eens dat een
>slimmihgheidje vaak veel ergernis kan voorkomen. Toch verwacht ik ook
>een bepaalde attitude van de gebruiker naar de machine.
Een beetje gezond verstand kan geen kwaad.
(...)
>>In een andere situatie wilde ik een gaatje boren, door de slaapkamervloer
>>(voor een antennekabeltje). Ik dacht wel doorhet tapijt heen te kunnen boren. Een druk op de knop, en er zat meteen
>>een hele kluit synthetische wol rond mijn boor plus een lange kale
>>streep in het tapijt, over de hele lengte van de slaapkamer. Van mij
>>mogen de tapijtfabrikanten wel een andere machine bedenken die anders
>>weeft en knoopt om dit soort ongein te voorkomen.
>Eigen schuld, dikke bult. Dat ding is om op te lopen, niet om er gaten
>in te boren.
Ja, dat is ook wel zo. Er mag ook wel wat fout gaan, heb ik ook nog
eens een leuke aneckdote.
>Ik sta er elke strenge vorst weer van te kijken dat mensen het
>presteren om met hun tong(!) aan een brug vast te vriezen. Ligt dat
>aan de brug?
Dat ligt aan de schoolmeesters, die waarschuwen de kinderen dat ze dat
niet moeten doen. Ik garandeer je, wanneer ze hun waffel hielden, er
heel wat minder tongen aan bruggen zouden vastvriezen.
Hartelijke groeten,
Frank Bemelman.
Tarzan
Aan 8-04-97 2:42, in bericht <33499475.5...@vulcan.xs4all.nl>, Johan
Wevers <joh...@vulcan.xs4all.nl> schreef:
> Tarzan <bjd...@worldaccess.nl> wrote:
>
> >> >do
> >> >x = x +.16
> >> >print x
> >> >loop
>
> >Maakt niet uit welke BASIC versie je gebruikt. Ik denk zelfs dat C het ook
> >doet. In
>
> In C en Pascal moet je eerst aangeven welk type "x" is. Dat kan een signed
> of unsigned float, real of double zijn, of een eigen structuur die bv. 32
> bytes groot is. Als je in C++ werkt kun je daar ook allerlei operatoren op
> definieren zodat je eigen types net zo gebruikt kunnen worden als de
> standaard types.
>
> >BASIC gebruikt dit programmaatje gewoon een 'SINGLE'-formaat ofwel: gewoon
> een
> >zooitje cijfers achter de komma.
>
> Hoeveel precies? Als je numeriek werk gaat doen is het wel handig dat te
> weten (maar ja, wie gaat er nu serieus rekenwerk in BASIC doen?).
Gelukkig lukt het in C ook niet :-)
>
> >Onnodige nullen worden niet afgedrukt.
>
> Da's irrelevant voor de rekenprecisie. Dat kun je in C en Pascal trouwens
> in je afdrukroutines aangeven.
Poeh Poeh! Da's knap: ik schrijf de afrondroutine zelf! Da's pas irrelevant voor de
discussie!
>
> >De uitkomst zou dus nooit meer dat 2 decimalen moeten bevatten. Toch krijg
> >je 6 decimalen.
>
> Tja, moet je ook maar een serieuzer programmeertaal gebruiken.
Hallo Johan? Zie mijn andere mailtje: een programmaatje in C dat de fout ook maakt!
Zie ook het mailtje van Abigail.
Je hoeft BASIC trouwens niet zo af te zeiken: voor beginners is het een zeer goede
taal. Ik begrijp ook wel dat het niet geschikt is voor zware berekeningen, maar
aangezien het hier geen zware berekeningen betreft en mijn BASIC aanzienlijk beter
is dan mijn C heb ik het voorbeeldprogramma in BASIC geschreven. (Dat is trouwens
ook makkelijker te begrijpen voor de lezers die helemaal niet programmeren)
Groetjes,
Bas
--
Bas Vermeulen
E-mail: bjd...@worldaccess.nl
Homepage: http://www.worldaccess.nl/~bjdeuso
Ik heb ontdekt dat ik het vermogen heb om iemands karakter uit een enkel e-mailtje
kan bepalen. Wil jij weten hoe je echt in elkaar zit? Stuur me dan een e-mailtje met
omschrijving van je uiterlijk, geboortedatum, opleiding en evt. beroep. Geef ook aan
welk aspect van je karakter wil leren kenne
n. Je krijgt zo snel mogelijk antwoord.
Frank Bemelman
abi...@ny.fnx.com (Abigail) wrote:
[snip][snip][snip][snip]
>Dus je vindt C geen serieuze programmeertaal?
>Of Perl?
>LPC?
>Awk misschien?
>Of SQL?
>bc?
>Abigail
Tiny basic vond ik wel serieus. Had je geen gelazer met
floating point.
Hartelijke groeten,
Frank Bemelman.
Luc Peersman
>Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
>
>[snip]
>>En ja, daar moeten we allemaal mee leren leven!
>
>En die laatste zin zit me dus niet lekker. Misschien ken je die
>sleufjes wel, waar je een pasje doorheen moet halen om een deur te
>openen. Geheid dat je je pasje er verkeerd doorheen haalt, dus nog een
>linksom, rechtsom, ondersteboven, achterstevoren. Had men zich de
>moeite getroost 2 magneetkoppen te monteren en de processor zo in te
>richten dat die de bitstream zowel voorwaarts als achterwaarts juist
>weet te interpreteren.
>
Dus er moet een extra kop bij omdat jij te beroerd bent om het een
paar keer te proberen? Als jij een sjekkie rolt, lukt er zeker maar
één op de vier. Vloeitjes moeten 4 plakranden hebben?
>Misschien komen er nog weleens videobanden met een kleine LCD erop
>geplakt, die bij opname uit de teletekstsignalen de programma-naam
>haalt, en in het display zet en laat staan. Kun je een band pakken, en
>je ziet meteen wat erop staat. Het kan nog wel goedkoper, een
>i2c-eeprom op de casette, die na inwerpen van de band een menu op de
>buis zet met een overzicht van de aanwezige opnames. Je moeder heeft
>gewoon gelijk. De techniek is er om ons te dienen, en niet andersom.
Dat laatste is zeker waar, maar de door jou voorgestelde videobanden
bieden geen oplossing. Het zal altijd mogelijk blijven de dingen op
een stupide manier te gebruiken. Als voetbal bv. en dan klagen dat ze
zo slecht stuiteren.
>Laatst trek ik een kaartje uit een parkeermeter. Staat een tekst op
>geprint 'ongeldig', plus de toegestane parkeertijd. Wie het niet
>gelooft wil ik wel een pcx-file van dat kaartje sturen (heb 'm
>bewaard). Er zal op het moment wel iets mis geweest zijn, maar welke
>verziekte geest richt de software zo in dat er ook nog een kaartje
>geprint wordt ?
Dat is inderdaad ten hemel schreiend. Ik ben het met je eens dat een
slimmihgheidje vaak veel ergernis kan voorkomen. Toch verwacht ik ook
een bepaalde attitude van de gebruiker naar de machine.
(...)
>In een andere situatie wilde ik een gaatje boren, door de slaapkamervloer
>(voor een antennekabeltje). Ik dacht wel doorhet tapijt heen te kunnen boren. Een druk op de knop, en er zat meteen
>een hele kluit synthetische wol rond mijn boor plus een lange kale
>streep in het tapijt, over de hele lengte van de slaapkamer. Van mij
>mogen de tapijtfabrikanten wel een andere machine bedenken die anders
>weeft en knoopt om dit soort ongein te voorkomen.
Eigen schuld, dikke bult. Dat ding is om op te lopen, niet om er gaten
in te boren.
Ik sta er elke strenge vorst weer van te kijken dat mensen het
presteren om met hun tong(!) aan een brug vast te vriezen. Ligt dat
aan de brug?
>Hartelijke groeten,
>Frank Bemelman.
Groeten terug en suc6.
Luc
Robert Bos
[Snip]
>Dus je vindt C geen serieuze programmeertaal?
Ik heb geen idee waar de onenigheid over is, maar ik denk dat ik een
(gedeeltelijke) oplossing voor het C nauwkeurigheids probleem heb:
>$ cat f.c
># include <stdio.h>
># include <stdlib.h>
>
>main () {
> float x;
> int i;
>
> x = 0;
>
> for (i = 1000; i --; x += 0.16);
>
> printf ("%f\n", x);
>}
>$ gcc -o f f.c
>$ ./f
>160.002136
>$
In dit programma kun je vrij eenvoudig de nauwkeurigheid van x opvoeren door
een double voor x te gebruiken in plaats van een float. Dat geeft de volgende
resultaten:
8.Ram Disk:> type doubletest.c
#include <stdio.h>
main () {
double x;
int i;
x = 0;
for (i = 1000; i --; x += 0.16);
printf ("%f\n", x);
}
8.Ram Disk:> gcc -o test doubletest.c
8.Ram Disk:> protect test +e
8.Ram Disk:> test
160.000000
8.Ram Disk:>
Precies 160.00000, is het niet prachtig.... :)
Robert Bos
... When in doubt, use a bigger hammer.
Abigail
On Wed, 09 Apr 1997 19:00:41 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:334bf569.5...@vulcan.xs4all.nl>:++ >>Tja, moet je ook maar een serieuzer programmeertaal gebruiken.
++
++ >Dus je vindt C geen serieuze programmeertaal?
++
++ Jawel, maar ook in C kun je het fout doen.
En was mijn methode dan "fout"? Natuurlijk kun je je eigen floating
point operaties gaan schrijven, maar dat kun je in (vrijwel) iedere
taal, zeker degene die je afdankte als "niet serieus". Wat je dan
doet heeft weinig meer met de taal zelf te maken.
++ >Of Perl?
++
++ Perl? Dat is een scripttaal.
Ja en? Je kunt Perl ook naar C compileren en je kunt C ook
interpreteren (niet dat Perl geinterpreteerd is, Perl wordt
gecompileerd). Wat heeft "scripttaal" te maken te maken met wat er hier
ter discussie staat, afrondings fouten bij floating point operaties??
Of roep je maar wat op indruk te maken?
++ >LPC?
++
++ Nooit van gehoord.
Lars Pensj\"o C. Een object oriented taal die qua controlstructuur
en syntax op C lijkt.
++ >Wat is dan wel een serieuze programmeertaal in jouw ogen?
++ >Awk misschien?
++
++ Ook een scripttaal.
Ja en?
++ >Of SQL?
++
++ Niet voor serieus numeriek werk, wel voor grote financiele databases.
Hmmm, toch maakte SQL geen afrondfouten....
++ >bc?
++
++ Ken ik te weinig.
++
++ >Wat, meneer de ir., is nu een serieuze programmeertaal?
++
++ Ada. :-)
En waarom dan wel?
Abigail
Abigail
On Wed, 09 Apr 1997 23:55:59 +0200, Peter Elderson wrote in nl.wetenschap
<URL: news:334C10...@xs4all.nl>:
++ Abigail wrote:
++ > Wat, meneer de ir., is nu een serieuze programmeertaal?
++
PL1 heb ik nooit wat mee gedaan. Kheb nauwelijks iets gedaan met Cobol
of Fortran, maar 1000 keer 0.16 bij iets optellen is wel snel uit te
vinden. Kheb hier alleen geen Cobol of Fortran compiler, dus ik had de
resultaten niet kunnen geven toch niet kunnen geven.
Pascal, Modula en Algol had ik ook aan het rijtje kunnen toevoegen,
maar ook daarvoor heb ik hier geen compilers (zijn er ergens gratis
Pascal & Modula compilers (in source vorm?) te krijgen (voor solaris),
dan ben ik zeer geinteresseerd). Ik had geen zin op uit te zoeken hoe
assembler te gebruiken, vandaar dat die ontbreekt. Oh, en de Python
compiler annex interpreter staat nog op CD-Rom, 't Wordt wel eens tijd
op die te installeren.
Hmmm, tcl ligt hier wel ergens, daar moet ik ook maar eens in duiken.
Hier is nog een voorbeeldje in Javascript:
<head>
<title>Nananana</title>
<script>
function doit () {
var x = 0;
var i;
for (i = 1000; i --; x += 0.16);
document.form.special.value = x;
}
</script>
</head>
<body>
<form name = "form">
<input type = button value = "Do It" onclick = "doit()">
<input type = "text" name = "special">
</form>
</body>
En dat geeft:
159.9999999999973
vile macros kunnen helaas niet met floats werken:
13 store-macro
set-variable %x 0
set-variable %i 1000
*LABEL
set-variable %x &add %x 0.16
set-variable %i &sub %i 1
~if ¬ &equ %i 0
~goto LABEL
~endif
write-message &cat "x = " %x
~endm
bind-key execute-macro-13 M-k
M-k
x = 0
Abigail
--
(Als ik het sendmail boek uit heb, zal ik dan wat sendmail macros
posten die 1000 keer 0.16 bij 0 optellen?)
Erik Springelkamp
On Thu, 10 Apr 1997 05:34:52 GMT, abi...@fnx.com (Abigail) wrote:
>
>On Wed, 09 Apr 1997 23:55:59 +0200, Peter Elderson wrote in nl.wetenschap
><URL: news:334C10...@xs4all.nl>:
>++ Abigail wrote:
>++ > Wat, meneer de ir., is nu een serieuze programmeertaal?
>++
>++ Kun je COBOL, PL1, FORTRAN? En daarna graag in assembler.
>
>
>PL1 heb ik nooit wat mee gedaan. Kheb nauwelijks iets gedaan met Cobol
>of Fortran, maar 1000 keer 0.16 bij iets optellen is wel snel uit te
>vinden. Kheb hier alleen geen Cobol of Fortran compiler, dus ik had de
>resultaten niet kunnen geven toch niet kunnen geven.
De taal waarin dit gebeurt is niet altijd belangrijk.
Hetzelfde FORTRAN programma zal op verschillende machines
verschillende uitkomsten geven. Zo hebben (hadden? hoe gaat het
tegenwoordig met dat systeem?) IBM 360/370 machines een exponent die
bytes als eenheid hebben (256-tallig stelsel), waardoor het aantal
significante decimalen met wel twee kan varieren, en 4byte reals af en
toe een wel erg magere preciesie hebben.
COBOL kan exact met centen rekenen. Nu hoeft er met geld ook meestal
niet zoveel ingewikkelds te gebeuren, en de preciesie is meestal
procedureel precies omschreven (geen pi, maar 4 3/4 %, of 1235.45
flappen voor 100 dilberts). COBOL houdt zich dan netjes aan de
opgegeven preciecie, en representeert getallen dan ook gewoon met
decimale cijfers.
Onno Hovers
Johan Wevers (joh...@vulcan.xs4all.nl) wrote:
: In C en Pascal moet je eerst aangeven welk type "x" is. Dat kan een signed
: of unsigned float, real of double zijn, of een eigen structuur die bv. 32
Sinds wanneer kent C "signed float" en "unsigned float". ? Een float
is toch altijd inclusief teken?
Groetjens, Onno
--
< >-> Onno Hovers (on...@stack.nl http://www.stack.nl/~onno/)
Student physics at the University of Technology Eindhoven
Computer geek: C, Win32, Linux, Internet, Operating Systems
Warning: my e-mail address and www address have changed!!!
Joris Zwart
In article <5ih02j$7j4$2...@neptune.worldonline.nl>,
Frank Bemelman <fbe...@worldonline.nl> wrote:
>Op mijn Sharp EL-531GH (van de kijkshop)
>resp. 0 en 49.
Ook een naamloze ramsjrekenmachine, gemaakt in China, geeft 0 en 49 als
uitkomsten.
Groeten, Joris
---------------------If only God would give me some clear sign! Like making a
Joris S. Zwart large deposit in my name in a Swiss bank - Woody Allen
jo...@stack.nl http://www.stack.nl/~jozwa/
(PGP public key available by finger)------------------#include <disclaimer.h>
Abigail
On Wed, 09 Apr 1997 19:04:24 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:334bf648.5...@vulcan.xs4all.nl>:++ >Gelukkig lukt het in C ook niet :-)
++
++ Jawel, alleen is hier gedeminstreerd dat het in C ook fout kan gaan. En
++ dat heb ik ook nooit ontkent. Je moet die grotere structuren wel zelf
++ definieren of uit een library halen.
En daar heb je helemaal geen C voor nodig. Dat kun je in vrijwel iedere
taal natuurlijk; talen daarom minder meer of minder serieus te noemen
slaat dus nergens op.
++ >Je hoeft BASIC trouwens niet zo af te zeiken: voor beginners is het een
++ >zeer goede taal.
Daar ben ik het niet mee eens. Wat in BASIC maakt het een goede taal
voor beginners?
++ Ach... een van de grootste nadelen van alle BASIC dialecten is wel dat ze
++ totaal niet portable zijn. C heeft dat veel meer, een puur rekenprogramma
++ in C kun je zonder aanpassingen meestal op zowel een zware Cray als op een
++ PC onder DOS compileren.
Uhm, ik vind C helemaal niet portable. In de eerste plaats zijn er
verschillende C dialecten (ANSI, K&R), en er zijn zoveel machine
afhankelijkheden, of zelfs compiler afhankelijkheden. 'k Heb nog ergens
de source code liggen voor een of andere xterm. Compileert dus alleen
met Sun's cc, absoluut hopeloos met gcc. Waarom denk je dat code
altijd vol staat van de #ifdef UNIX, #ifdef VMS, #ifndef LINUX etc?
Juist omdat C helemaal niet portable is. Ik heb vandaag slrn, vile
en perl gecompileerd, en alle drie hebben ze een uitgebreid configure
programma; programma's die voornamelijk uitzoeken hoe ze in vredesnaam
de source op het huidige platform moeten compileren. De source voor
slrn is bv 712k, het configure programma 70k, bijna 10% dus!
Oh, en dan draait het nog niet eens op DOS/Windows of een Mac of
Amiga, of een Atari of zo.
Daar in tegen zijn er "scripttalen" (om maar eens een term van je te
gebruiken) die heel erg portable zijn. Python bijvoorbeeld. Of Perl.
Of Java (als je dat een scripttaal wilt noemen). Of Tcl. Of de Tk
libraries.
Probeer maar eens een mail converter (RFC 822 <-> een of ander
microsoft standaard) te ontwikkelen *en* testen op een Unix machine en
het vervolgens te draaien om een DOS doos in C. Lijkt me niet
makkelijk. Maar ik heb het wel eens gedaan in Perl, en meer dan het
aanpassen van de filenamen hoefde er niet te gebeuren om het op de DOS
doos te laten draaien. Dat is pas een portable taal.
Abigail
--
Perl was written in C, not because it's a portable language, but
because it's a uniquitous language. A bare C program is about as
portable as Chuck Yeager on foot.
[Larry Wall, Tom Christiansen and Randal L. Schwartz in
`Programming Perl, 2nd Edition', p 385]
Huub
Antoon Pardon wrote:
>
> Frank Bemelman (fbe...@worldonline.nl) wrote:
> : Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
>
> : [snip]
> : >moet leren omgaan met apparatuur en beperkingen. Mijn moeder is altijd
> : >verontwaardigd als ze een videoband in het apparaat doet en het ding
> : >niet laat zien wat ze wilt. Dat het de juiste band moet zijn en dat
> : >ding ook nog tot de juiste plaats gespoelt moet worden valt buiten
> : >haar beleving. Rekenmachines maken fouten, dat is inherent aan die
> : >dingen! Als je weet waar die fouten vandaan komen, is de ergernis maar
> : >half zo groot.
>
> : >CD's blijken altijd net een minuut te lang te duren als je ze opneemt,
> : >batterijen van rekenmachines raken alleen maar op tijdens een
> : >belangrijk tentamen, treinen vertrekken altijd te laat, behalve als
> : >jij te laat bent, veters trek je kapot en vergeet het maar om de vlam
> : >van de CV-ketel weer aan te krijgen.
>
Murphy's Law!!!!!!!!!!
>
> : En die laatste zin zit me dus niet lekker.
>
> Doe er dan zelf iets aan. Als het voor jouw een groot genoeg
> probleem is neem dan het inisiatief om zelf voor een oplossing te
> zorgen. Maar als dat niet kan en er zijn geen andere mensen die
> het doen moet je niet zeuren als andere mensen jouw probleem niet
> belangrijk genoeg vinden om hun tijd in te steken en zal je daar
> inderdaad mee moeten leren leven.
>
Ik moet je gedeeltelijk gelijk geven Antoon. Vaak zijn dit soort dingen
voor niemand belangrijk dan voor degene die ze overkomt.
Nu doet zich het merkwaardige feit voor dat bij sommige mensen Murphy's
law zich vaker voordoet dan bij anderen. Er zijn mensen die inderdaad 12
ambachten en 13 ongelukken in hun devies hebben staan zonder dat ze daar
iets aan kunnen doen. Hoewel voor anderen misschien niet zo belangrijk,
daarom nog wel een interessant (vind ik tenminste) verschijnsel.
Een aantal dingen kan je voorkomen natuurlijk, van andere lijkt het vaak
of ze alleen jou maar overkomen, en dan juist op een ongelegen moment.
Maar inderdaad, 't is niet echt voer voor een diskussie.
Groeten,
Huub
Frank Bemelman
apa...@rc4.vub.ac.be (Antoon Pardon) wrote:
>Als je het jouw vraagt misschien wel maar als dat masjientje de
>zaken bineir verwerkt dan bestaat 1.9 niet voor dat masjientje.
>Het zal daar een benaderde waarde voor gebruiken. Dus jij kan wel
>denken dat je 3 * 1.9 aan het uitrekenen bent maar dat masjientje
>rekent iets uit dat daar dicht in de buurt licht.
Ik had notabene het subject veranderd in 'Daar moeten we mee
leren leven' omdat het me niet zozeer interesseert waarom dat
rekenmachientje de mist in gaat (allicht is daar een verklaring voor)
danwel *dat* het de mist in gaat. En dat de opmerking 'daar moeten
we mee leren leven' een al te gemakkelijk argument is om de discutable
performance van bepaalde apparaten (waaronder calculators) mee van
tafel te vegen.
>: Meer to-the-point, ik vraag niet om het onmogelijke maar erger me
>: wel aan de gemakzucht van veel ontwerpers. Je moet niet te snel
>: besluiten dat iets niet 'kan' of dat het ontwerp 'zo' wel goed is. In
>: een prototype stadium heb je de vrijheid om maar een eind aan te
>: klooien, maar als je het eindstadium bereikt moeten de grootste
>: ergernissen wel verholpen zijn.
>En misschien dat je eens moet rondkijken naar dat ontwerpt dat
>het best voor jouw geschikt is. Als jij enkel met gehele of
>vaste-komma getallen moet werken schaf je dan iets aan dat vooral
>daar goed in is en dat je de absolute nauwkeurigheid van die
>getallen zal aanbieden. Heb je meer aan vlottende-komma getallen
>verwacht je dan aan nauuwkeurigheidsverlies. Wil je van de twee
>gebruik kunnen maken verwacht dan meer te moeten betalen. Mij
>lijkt het er op dat je met je vleesmes je aardappels wil kunnen
>schillen zonder in je vingers te kunnen snijden.
Ja, het kwartje is bij jou niet gevallen. Je zit nog in de vorige
thread.
Hartelijke groeten,
Frank Bemelman.
Steven 'GoofY' de Brouwer
In nl.wetenschap, apa...@rc4.vub.ac.be (Antoon Pardon) wrote:
> Frank Bemelman (fbe...@worldonline.nl) wrote:
> : Luc.Pe...@net.HCC.nl (Luc Peersman) wrote:
> : >Een simpel sommetje als 3 maal 1,9 is al te moeilijk voor mijn
> : >Pentium! :-)
[...]
> De normale verwachtingen zijn dat er decimalen verloren
> zijn gegaan of dat het aantal tekort schoot. Wat die persoon aan
> dat rekenmasjientje vroeg kwam er op neer dat je aan een persoon
> vroeg om 3 * 0.3333 uit te rekenen en dan verbaast bent dat hij
> niet 1 uitkwam.
Ik heb vandaag een beetje les gekregen in ExSpect. Het daar gebruikte
typen-systeem bevat voor numerieke waarden de types NUM en REAL.
NUM bevat de rationele getallen, die zowel voor de noemer als voor
de teller oneindig lange getallen aan kan (binnen de perken van je
computer-geheugen natuurlijk).
REAL bevat alle reele getallen BINNEN een bepaalde afronding.
De afronding is platform-specifiek.
Er wordt op gehamerd, dat rekenen met REALs afwijkingen geeft.
2.0 maal 1.5 is ongeveer 3. Niet precies 3, maar ongeveer 3.
Wil je exacte uitkomsten, dan zul je je tot de rationele
getallen moeten beperken.
Conclusie: roei met de riemen die je hebt.
Kind regards cq. De groeten,
GoofY
-- PubKey at http://www.stack.nl/~goofy/PGP
A world that's far away,
where life is not unkind,
the movie in my mind...
Frank Bemelman
joh...@vulcan.xs4all.nl (Johan Wevers) wrote:
>Frank Bemelman <fbe...@worldonline.nl> wrote:
>>gewoon 5.7 als je het mij vraagt. (3* 3.3333) is voor mij nog steeds
>>0.9999 en een machientje moet dan niet met 1.0 op de proppen komen.
>Dan zou die machine er in ieder geval nog minder naast zitten dan jij... :-)
Kijk, is er toch nog iemand die oplet ;-)
>>Tegenwoordig blijft het lipje aan het blikje zitten, na het
>>opentrekken. Degene die dat bedacht heeft, verdient een lintje.
>Nee, de kogel! Die krengen van tegenwoordig drinken onhandig dus kan ik nu
>net zo lang dat lipje op en neer bewegen totdat het vanwege metaalmoeheid
>loslaat.
Dat is tenminste mannentaal, kan ik wel waarderen. Het pleit voor je
dat je in dit geval niet vervalt in het 'daar moeten we mee leren
leven' virus waar menigeen mee geinfecteerd blijkt.
>--
>ir. J.C.A. Wevers <*> For Physics and science fiction information:
>joh...@vulcan.xs4all.nl <*> http://www.xs4all.nl/~johanw/index.html
>Finger joh...@xs4all.nl for my PGP public key. PGP-KeyID: 0xD42F80B1
Hartelijke groeten,
Frank Bemelman.
Kees J Bot
In article <955.7038T...@worldonline.nl>,
Robert Bos <rb...@worldonline.nl> wrote:
>
>In dit programma kun je vrij eenvoudig de nauwkeurigheid van x opvoeren door
>een double voor x te gebruiken in plaats van een float. Dat geeft de volgende
>resultaten:
>
>8.Ram Disk:> type doubletest.c
>#include <stdio.h>
>
>main () {
> double x;
> int i;
>
> x = 0;
>
>
>}
>8.Ram Disk:> gcc -o test doubletest.c
>8.Ram Disk:> protect test +e
>8.Ram Disk:> test
>160.000000
>8.Ram Disk:>
>
>Precies 160.00000, is het niet prachtig.... :)
$ cat tst.c
#include <stdio.h>
int main(void)
{
double x;
int i;
x = 0.0;
for (i = 0; i < 1000; i++) x += 0.16;
for (i = 6; i < 20; i += 2) printf ("%.*f\n", i, x);
printf("%g\n", 160.0 - x);
return 0;
}
$ cc tst.c && ./a.out
160.000000
160.00000000
160.0000000000
159.999999999997
159.99999999999730
159.9999999999972999
159.999999999997299938
2.70006e-12
--
Kees J. Bot, Systeemprogrammeur, Vrije Universiteit Amsterdam
Johan Wevers
Frank Bemelman <fbe...@worldonline.nl> wrote:
>gewoon 5.7 als je het mij vraagt. (3* 3.3333) is voor mij nog steeds
>0.9999 en een machientje moet dan niet met 1.0 op de proppen komen.
Dan zou die machine er in ieder geval nog minder naast zitten dan jij... :-)
>Tegenwoordig blijft het lipje aan het blikje zitten, na het
>opentrekken. Degene die dat bedacht heeft, verdient een lintje.
Nee, de kogel! Die krengen van tegenwoordig drinken onhandig dus kan ik nu
net zo lang dat lipje op en neer bewegen totdat het vanwege metaalmoeheid
loslaat.
--
Matthijs Sypkens Smit
rob@pe1chl (Rob Janssen) wrote:
>Bijvoorbeeld: 1/3 is ongeveer 0.333
>0.333 + 0.333 + 0.333 is 0.999 terwijl 1/3 + 1/3 + 1/3 = 1.
Maar 0.[9] (nul-komma-negen-repetent) is weer gelijk aan 1.
Matthijs
Luc Peersman
>Volgens mij is dat zeker geen machine fout. Trouwens, elke moderne pentium
>is al lang verlost van die fdiv bug, die zat alleen in de oudste 60 en 66
>MHz versies.
Hoho! Ik heb het ook over de pentiums (of is het pentia?) waar de fout
uit is! Matlab, Works. Excel, Basic en Mathematica kunnen 3 * 1,9 NIET
goed uitrekenen op een 'goede' pentium 90.
Luc
Luc Peersman
Antoon:
>Eerste regel van werken met een rekenmasjientje: Verwacht dat
>alle bewerkingen op de allereenvoudigste na je een benadering van
>het resultaat zullen geven.
>pen komen.
>
>Als je het jouw vraagt misschien wel maar als dat masjientje de
>zaken bineir verwerkt dan bestaat 1.9 niet voor dat masjientje.
>Het zal daar een benaderde waarde voor gebruiken. Dus jij kan wel
>denken dat je 3 * 1.9 aan het uitrekenen bent maar dat masjientje
>rekent iets uit dat daar dicht in de buurt licht.
>
>verwacht om eksakte uitkomsten te krijgen enkel en alleen omdat
>je die in een 10 delig stelsel kan krijgen vraag dan naar een
>masjientje dat of in bcd kan werken of met vaste-kommagetallen
>kan werken.
>
De ondertoon van deze en anders postings doen zelfs mij naar 'kamp
Bemelman' rennen. De fout van rekenmachines mag je wel verklaren maar
niet vergoeilijken! Het lijkt in deze en andere postings net of 'het
toch niet zo heeeel fout is' wat de rekenmachine doet. Er wordt zelfs
gesuggereerd dat wij als gebruiker dan maar met andere rekenmachines
en andere notaties moeten werken, omdat wij o domme mensen met het
10-tallig stelsel werken. Onzin! Ik vraag een pentium-processor met
'evenveel onderdelen als een boeing 747' (beruchte quote) een som op
te lossen die een lagere school kind ook kan. Als het dan zo is dat
bepaalde getallen niet precies binair kunnen worden weergegeven, ligt
daar een opening om het verbeteren, niet om de rekenmachine te
verdedigen.
Toegegeven, ik heb de ondertussen haast gevleugelde woorden 'daar
moeten we mee leren leven' getypt, maar dat sloeg op de huidige
pentiums. Laten we hopen dat dat verbeterd.
Met 'Daar moeten we mee leren leven' bedoelde ik dat we bedacht moeten
zijn op onvolkomenheden van de huidige machines. Frank Bemelman
suggereerde als zou ik een vrijbrief tot berusting geven! Daarin
interpreteerde Frank mij dus verkeerd. Helaas kwam hij toen met
twijfelachtige videobanden en gaten in vloerkleden (oke dat was
anecdote), maar feitelijk zijn we het meer eens dat vorige postings
deden vermoeden.
Even terugkomen op het oorspronkelijke onderwerp:
ik heb =als(5,7-3*1,9=0;WAAR;ONWAAR) ondertussen geprobeerd in Excel,
QBasic, Visual Basic, Mathematica, Matlab en MS-WORKS en dat ging
allemaal fout. Kan iemand het in Maple doen? Dat ging wel goed op een
486 en ben benieuwd naar de pentiumprestatie.
Voor de duidelijkheid: ik heb het niet over de oude pentium's met
foutje, die zijn allang uit de handel.
Met groet,
Luc
Robert Bos
>>Precies 160.00000, is het niet prachtig.... :)
>$ cat tst.c
>#include <stdio.h>
>int main(void)
>{
> double x;
> int i;
> x = 0.0;
> for (i = 0; i < 1000; i++) x += 0.16;
> for (i = 6; i < 20; i += 2) printf ("%.*f\n", i, x);
> printf("%g\n", 160.0 - x);
> return 0;
>}
>$ cc tst.c && ./a.out
>160.000000
>160.00000000
>160.0000000000
>159.999999999997
>159.99999999999730
>159.9999999999972999
>159.999999999997299938
Toegeven, het is nog steeds niet precies 160, maar we gaan in ieder geval de
goede kant op...
>2.70006e-12
Da's een relatieve fout van slechts 1,6875e-12%. Ik denk dat dat voor de
meeste toepassingen wel genoeg zal zijn...
Robert Bos
... If you see any misspelled words it HAS to be line noise.
Matthijs Sypkens Smit
fbe...@worldonline.nl (Frank Bemelman) wrote:
>en een CC naar Texas Increment.
Texas Instruments.
Matthijs
Erik Springelkamp
>De ondertoon van deze en anders postings doen zelfs mij naar 'kamp
>Bemelman' rennen. De fout van rekenmachines mag je wel verklaren maar
>niet vergoeilijken!
Ik vind dat hier toch wel een erg 'verwende' toon uit naar voren komt.
Opa zal wel eens vertellen hoe dat vroeger zat:
Wij hadden een rekenliniaal, waarmee je blij moest zijn als je drie
significante cijfers goed had.
Het voordeel was natuurlijk dat je wist wat je aan het doen was, en
dat er een nauwkeurigheidsgrens was. Bovendien rekende je altijd de
machten van tien al met je hoofd uit, zodat je bij al je sommen zo'n
beetje een significant cijfer al wist.
Wilde je meer nauwkeurigheid zonder heel zwaar cijferen, dan kwamen de
logaritmetabellen erbij: 5 of 6 cijfers werden dan haalbaar (ik praat
niet over speciale rekenkamer-tabellenboeken).
Toen kwamen er rekenmachientjes waarmee je plotseling 10 cijfers had
voor al je functies: een enorme luxe!
Het nadeel is natuurlijk dat de meeste mensen het hoofdrekenen
verleren en helemaal niet meer weten waar ze mee bezig zijn.
>Het lijkt in deze en andere postings net of 'het
>toch niet zo heeeel fout is' wat de rekenmachine doet. Er wordt zelfs
>gesuggereerd dat wij als gebruiker dan maar met andere rekenmachines
>en andere notaties moeten werken, omdat wij o domme mensen met het
>10-tallig stelsel werken. Onzin! Ik vraag een pentium-processor met
>'evenveel onderdelen als een boeing 747' (beruchte quote) een som op
>te lossen die een lagere school kind ook kan.
Dat vraag je helemaal niet aan een Pentium, maar dat vraag je aan een
rekenbladprogramma, dat kennelijk zijn prioriteiten elders legt.
Een 32 bit x86 compatible machine kan intern met decimale getallen
werken in een 80 bit representatie, goed voor 18 decimale cijfers.
>Als het dan zo is dat
>bepaalde getallen niet precies binair kunnen worden weergegeven, ligt
>daar een opening om het verbeteren, niet om de rekenmachine te
>verdedigen.
>Toegegeven, ik heb de ondertussen haast gevleugelde woorden 'daar
>moeten we mee leren leven' getypt, maar dat sloeg op de huidige
>pentiums.
Zoals gezegd: pentiums hebben daar geen moeite mee, de meeste
programma's wel.
>ik heb =als(5,7-3*1,9=0;WAAR;ONWAAR) ondertussen geprobeerd in Excel,
>QBasic, Visual Basic, Mathematica, Matlab en MS-WORKS en dat ging
>allemaal fout. Kan iemand het in Maple doen? Dat ging wel goed op een
>486 en ben benieuwd naar de pentiumprestatie.
Dit heeft helemaal niets met de machine te maken. Een pentium doet
hetzelfde als een 486, alleen sneller, en marginaal beter in de
laatste decimaal bij sommige functies.
Maple kan de precisie dan goed doen: probeer er eens een 100x100
matrix mee te diagonaliseren: ik denk dat je wel op vakantie kunt
gaan, terwijl de efficiente binaire methodes dat zowat in een seconde
doen.
>Voor de duidelijkheid: ik heb het niet over de oude pentium's met
>foutje, die zijn allang uit de handel.
Volgens mij weet je eigenlijk niet waar je het over hebt.
--
Erik Springelkamp
spri...@noord.bart.nl
http://www.noord.bart.nl/~springel/
Rob Janssen
>Toegeven, het is nog steeds niet precies 160, maar we gaan in ieder geval de
>goede kant op...
>>2.70006e-12
>Da's een relatieve fout van slechts 1,6875e-12%. Ik denk dat dat voor de
>meeste toepassingen wel genoeg zal zijn...
Ja, behalve voor de "is gelijk" operator meestal. Bekend beginnersfoutje
bij het programmeren met floating point variabelen...
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
Rob Janssen
>De fout van rekenmachines mag je wel verklaren maar
>niet vergoeilijken! Het lijkt in deze en andere postings net of 'het
>toch niet zo heeeel fout is' wat de rekenmachine doet. Er wordt zelfs
>gesuggereerd dat wij als gebruiker dan maar met andere rekenmachines
>en andere notaties moeten werken, omdat wij o domme mensen met het
>10-tallig stelsel werken. Onzin! Ik vraag een pentium-processor met
>'evenveel onderdelen als een boeing 747' (beruchte quote) een som op
>te lossen die een lagere school kind ook kan. Als het dan zo is dat
>bepaalde getallen niet precies binair kunnen worden weergegeven, ligt
>daar een opening om het verbeteren, niet om de rekenmachine te
>verdedigen.
Lagere school kinderen kunnen niet in floating point rekenen.
Als je de methode van kinderen op de lagere school gebruikt dan kom je
wel op exacte antwoorden uit.
Zelf probeer ik het gebruik van floating point altijd zoveel mogelijk
te vermijden. Het geeft problemen, en is voor de meeste toepassingen
helemaal niet nodig.
Veel programmeurs weten niet waar ze mee bezig zijn en gebruiken floating
point zodra het ze maar even handig lijkt. Dan wordt (werd) het natuurlijk
ook nog traag, en gingen ze om snelle floating point verwerking roepen.
Ze hadden beter nog eens naar hun programma kunnen kijken...
Jaren geleden was ik er al achter dat floating point in bijvoorbeeld een
boekhoud programma een afschuwelijke bron van ellende was. In het bedrijf
waar ik toen werkte, wat software maakte voor (meestal) boekhoudkundige
doeleinden, hebben we toen ook een eigen library geschreven die de elementaire
berekeningen uitvoert zoals een kind op de lagere school dat doet, met altijd
het juiste antwoord en geen begrenzingen in het aantal cijfers.
In deze thread is al een aantal malen het programma "bc" verschenen, wat
ook op die manier werkt.
M.a.w. het KAN dus wel. Dat rekenmachines dit soort mogelijkheden niet
bieden (op wat uitzonderingen na) dat kan in bepaalde gevallen inderdaad
vervelend zijn. Ik denk dat dit vooral ingegeven wordt door beperkingen
in de grootte van het display. Mijn CASIO bijvoorbeeld heeft een mode
waarin met breuken gewerkt wordt, maar dit is in de praktijk totaal
onbruikbaar door het aantal cijfers wat beschikbaar is.
Abigail
On Fri, 11 Apr 1997 19:14:09 GMT, Luc Peersman wrote in nl.wetenschap
<URL: news:334e866...@news5.inter.nl.net>:
++
++ De ondertoon van deze en anders postings doen zelfs mij naar 'kamp
++ Bemelman' rennen. De fout van rekenmachines mag je wel verklaren maar
++ niet vergoeilijken! Het lijkt in deze en andere postings net of 'het
++ toch niet zo heeeel fout is' wat de rekenmachine doet. Er wordt zelfs
++ gesuggereerd dat wij als gebruiker dan maar met andere rekenmachines
++ en andere notaties moeten werken, omdat wij o domme mensen met het
++ 10-tallig stelsel werken. Onzin! Ik vraag een pentium-processor met
++ 'evenveel onderdelen als een boeing 747' (beruchte quote) een som op
++ te lossen die een lagere school kind ook kan. Als het dan zo is dat
++ bepaalde getallen niet precies binair kunnen worden weergegeven, ligt
++ daar een opening om het verbeteren, niet om de rekenmachine te
++ verdedigen.
De rekenmachine lost geen sommen op! Natuurlijk kun je een rekenmachine
maken die 5.7 - 3 * 1.9 exact uitrekent. Maar die krijg je dan niet
gratis bij je happy meal. En je kunt er beter ook geen wortel functie
in stoppen. Wat betreft die pentuim, er is best wel software dat 5.7 -
3 * 1.9 exact uitrekent. Maar dat heeft zijn prijs: snelheid.
Je hebt gelijk dat je sommige mensen "dom" noemt; als je voor het
uitrekenen van 5.7 - 3 * 1.9 afhankelijk bent van je rekenmachine,
en klakkeloos overkalkt wat in het venster verschijnt, dan ben je
inderdaad dom. (Hoeveel mensen zullen tegenwoordig denken dat
70! gelijk is aan 'E', 'Error' of '9.99999e99'?)
Abigail
Matthijs Sypkens Smit
abi...@fnx.com (Abigail) wrote:
>On Fri, 11 Apr 1997 16:14:15 GMT, Matthijs Sypkens Smit wrote in
>nl.wetenschap <URL: news:33543fd6...@news.tip.nl>:
>++ rob@pe1chl (Rob Janssen) wrote:
>++
>++ >Bijvoorbeeld: 1/3 is ongeveer 0.333
>++ >0.333 + 0.333 + 0.333 is 0.999 terwijl 1/3 + 1/3 + 1/3 = 1.
>++
>++ Maar 0.[9] (nul-komma-negen-repetent) is weer gelijk aan 1.
>++
>
>Ja, en 1 + 1 = 2.
>
>Abigail -- What's your point?
Ik had geen point. Ik wilde slechts mijn overdaad aan kennis ten toon
spreiden.
Matthijs
Antoon Pardon
Luc Peersman (Luc.Pe...@net.HCC.nl) wrote:
Maar het is niet enkel omwille van het twee-tallig stelsel. Elk
schoolkind kan voor elke n: (k/n) * n oplossen. Maar met welk
talstelsel dat je ook werkt en hoe nauwkeurig je je reken-
masjientje ook ontwerpt er zullen alltijd getallen zijn waar dat
masjientje een afwijking zal vertonen. Het twee talig stelsel is
daar niet ekstra gevoelig voor. Het brengt ons enkel een beetje
meer in de waar omdat het probleem zich voordoet met andere
getallen dan wanneer je in het tiendelig stelsel werkt.
: Toegegeven, ik heb de ondertussen haast gevleugelde woorden 'daar
: moeten we mee leren leven' getypt, maar dat sloeg op de huidige
: pentiums. Laten we hopen dat dat verbeterd.
: Met 'Daar moeten we mee leren leven' bedoelde ik dat we bedacht moeten
: zijn op onvolkomenheden van de huidige machines. Frank Bemelman
: suggereerde als zou ik een vrijbrief tot berusting geven! Daarin
: interpreteerde Frank mij dus verkeerd. Helaas kwam hij toen met
: twijfelachtige videobanden en gaten in vloerkleden (oke dat was
: anecdote), maar feitelijk zijn we het meer eens dat vorige postings
: deden vermoeden.
: Even terugkomen op het oorspronkelijke onderwerp:
: ik heb =als(5,7-3*1,9=0;WAAR;ONWAAR) ondertussen geprobeerd in Excel,
: QBasic, Visual Basic, Mathematica, Matlab en MS-WORKS en dat ging
: allemaal fout. Kan iemand het in Maple doen? Dat ging wel goed op een
: 486 en ben benieuwd naar de pentiumprestatie.
: Voor de duidelijkheid: ik heb het niet over de oude pentium's met
: foutje, die zijn allang uit de handel.
En als je nu =als(129/131*131;WAAR;ONWAAR) intikt. Of als dit het
juiste antwoord geeft een kombinasie die de nauwkeurigheid van je
masjientje wel te boven gaat. Ga je dan ook moeilijk over doen.
Niemand maakt vroeger problemen als een rekenmasjientje voor
1/3*3 niet 1 als anwoord geeft. Ondertussen wordt er met meer
nauwkeurigheid gewerkt dan zichtbaar is waardoor dit soort pro-
blemen minder zichtbaar wordt maar er zullen steeds grenzen zijn
aan de nauwkeurigheid. Maar het lijkt wel dat hoe minder zicht-
baar de grens is, hoe meer kabaal er gemaakt wordt als hij dan
toch eens bereikt wordt.
--
All opinions expressed herein are currently under revision
==========================================================
Antoon Pardon Brussels Free University Computing Centre
==========================================================
Antoon Pardon
Frank Bemelman (fbe...@worldonline.nl) wrote:
: apa...@rc4.vub.ac.be (Antoon Pardon) wrote:
: >Als je het jouw vraagt misschien wel maar als dat masjientje de
: >zaken bineir verwerkt dan bestaat 1.9 niet voor dat masjientje.
: >Het zal daar een benaderde waarde voor gebruiken. Dus jij kan wel
: >denken dat je 3 * 1.9 aan het uitrekenen bent maar dat masjientje
: >rekent iets uit dat daar dicht in de buurt licht.
: Ik had notabene het subject veranderd in 'Daar moeten we mee
: leren leven' omdat het me niet zozeer interesseert waarom dat
: rekenmachientje de mist in gaat (allicht is daar een verklaring voor)
: danwel *dat* het de mist in gaat. En dat de opmerking 'daar moeten
: we mee leren leven' een al te gemakkelijk argument is om de discutable
: performance van bepaalde apparaten (waaronder calculators) mee van
: tafel te vegen.
Het probleem is gewoon dat rekenmasjientjes een eindige nauwkeu-
righeid hebben. Vroeg of laat zal je dat in je neus bijten als je
daar niet op bedacht bent. Dit probleem kan waarschijnlijk zonder
veel ekstra kosten opgelost worden met als enig gevolg dat er na
een tijdje iemand komt die 3 * 1.97 - 59.1 doet en merkt dat dit
de nieuwe guwkeurigheidsgrens te boven gaat. Er zijn grenzen aan
die masjientjes en daar moet je mee leren leven.
: >: Meer to-the-point, ik vraag niet om het onmogelijke maar erger me
: >: wel aan de gemakzucht van veel ontwerpers. Je moet niet te snel
: >: besluiten dat iets niet 'kan' of dat het ontwerp 'zo' wel goed is. In
: >: een prototype stadium heb je de vrijheid om maar een eind aan te
: >: klooien, maar als je het eindstadium bereikt moeten de grootste
: >: ergernissen wel verholpen zijn.
: >En misschien dat je eens moet rondkijken naar dat ontwerpt dat
: >het best voor jouw geschikt is. Als jij enkel met gehele of
: >vaste-komma getallen moet werken schaf je dan iets aan dat vooral
: >daar goed in is en dat je de absolute nauwkeurigheid van die
: >getallen zal aanbieden. Heb je meer aan vlottende-komma getallen
: >verwacht je dan aan nauuwkeurigheidsverlies. Wil je van de twee
: >gebruik kunnen maken verwacht dan meer te moeten betalen. Mij
: >lijkt het er op dat je met je vleesmes je aardappels wil kunnen
: >schillen zonder in je vingers te kunnen snijden.
: Ja, het kwartje is bij jou niet gevallen. Je zit nog in de vorige
: thread.
Nee ik zit wel degelijk in deze draad. Rekenmasjientjes en
kompjoeters hebben grenzen. Je kan bij aankoop of door de keuze
van programmatuur enigzins kiezen waar die grenzen liggen. Maar
verwacht niet dat er geen grenzen zullen zijn. Of dat het
masjientje zich maar zal aanpassen omdat jij een gekocht hebt
waarbij de beperkingen je meer parten spelen dan als je een ander
gekocht had.
Jan Gerritsjans
Matthijs Sypkens Smit wrote:
>
> >++ Maar 0.[9] (nul-komma-negen-repetent) is weer gelijk aan 1.
> >++
> >
> >Ja, en 1 + 1 = 2.
> >
> >Abigail -- What's your point?
>
> Ik had geen point. Ik wilde slechts mijn overdaad aan kennis ten toon
> spreiden.
Ik zag Rick van de Young Ones laatst tot drie tellen:
"One, two, two point nine, nine, nine, usw" en hij sloeg nog steeds niet
met de koekepan.
>
> Matthijs
Jan
leo Koenen
On 14 Apr 1997 07:59:41 GMT, apa...@rc4.vub.ac.be (Antoon Pardon)
wrote:
>knip
>
>: Ja, het kwartje is bij jou niet gevallen. Je zit nog in de vorige
>: thread.
>
>Nee ik zit wel degelijk in deze draad.
>
>knip
Volgens mij zit je nog wel in de vorige thread. Het gaat hier om de
ongemakken in het algemeen en de soms schrijnende manier waarop je dat
moet accepteren. Een rekenmachine met een lullige afwijking bij een
eenvoudige som is daar een voorbeeld van.
Andere voorbeelden:
1. Bij mijn verhuizing stuurde ik de informatiseringsbank (studie-
financiering) een adreswijziging via zo'n formulier op het postkantoor
waar zij ook op stonden. Daarop kreeg ik op mijn nieuwe adres een
formuliertje waarop ik mijn nieuwe adres in moest vullen omdat zij dat
andere formulier niet accepteerden. Dat heb ik dus niet gedaan. Ik
kreeg daarop geen accept-giro's meer. Ik veronderstelde dat ze,
wanneer ze geen geld meer ontvingen, wel eens na zouden gaan denken.
Na vijf maanden kwam de deurwaarder. Hij had mijn nieuwe adres van de
informatiseringsbank gekregen.
2. Een tijdje terug meldde ik me ziek. Kreeg ik van Cadans en Avios
(een dochterbedrijfje van Cadans) drie keer een vragenformulier waarop
ik moest melden wat ik had. Alle formulieren met een ander
antwoordnummer en met de dreiging dat bij niet terugsturen geen
betaling zou volgen. Ik heb de formulieren aan elkaar geniet naar een
van de antwoordnummers teruggestuurd. Vervolgens kreeg ik een brief
van de juridische afdeling dat ik geen ziekengeld zou krijgen.
Kennelijk het verkeerde antwoordnummer gegokt. Deze zaak loopt nog.
3. Ik kreeg een parkeerbon. Dat gaat in Utrecht zo: Je krijgt een
naheffing van fl.5,- parkeerbelasting met fl.60,- administratiekosten.
Stuur ik vriendelijk een brief terug waarin ik vraag om een
specificatie van de kosten. Die heb ik uiteraard niet gekregen, ik
moest maar naar de rechter gaan.
Ik snap best wel dat die fl.60,- helemaal geen administratiekosten
zijn maar gewoon een onderdeel van de bekeuring. Noem het dan ook zo.
Het gemak waarmee in Nederland willekeurige bedragen aan
administratiekosten worden berekend is ergerlijk. Een tientje voor een
aanmaning is niets. Terwijl er niemand aan te pas komt. De computer
registreert dat er niet betaald is, spuwt een nieuwe acceptgiro uit en
deze moet verstuurd worden. Electriciteit voor de computer fl.0,10.
Kosten van het papier fl.0,02. Kosten van de envelop fl.0,15 en de
portokosten fl.0,80. Kosten: fl.1,10. De rest is boete. Noem dat dan
zo. Wanneer je de belachelijkheid van administratiekosten (boetes) in
een gezelschap ter sprake brengt dan snapt niemand waar je je zo druk
over maakt, zo ingeburgerd en geaccepteerd is dat al.
En dan laat je je nieuwe rekenmachine een simpele som oplossen waar
een fout antwoord op komt, vraag je vriendelijk hoe dat kan en dan
wordt je door middel van een beledigend standaardantwoord afgezeken.
Afzeiken is tot daar aan toe, maar via een onpersoonlijk standaard-
antwoord gaat toch te ver. Ze hadden er toch minstens (met de
computer) mijn naam boven kunnen zetten en een handtekeningstempel
eronder.
Maar daar moeten we mee leren leven. Omdat geen hond (nou, een paar
uitgezonderd) tegen dit soort dingen in verzet komt.
Leo
Abigail
On Mon, 14 Apr 1997 19:32:10 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:3352944a.5...@vulcan.xs4all.nl>:++ >Als je in BASIC iets programmeert werkt het. Als je in C iets programmeert
++ >krijg je na het vergeten van 1 enkel ; teken tientallen foutmeldingen waar
++ >niemand iets van begrijpt.
++
++ Jij misschien niet. Maar als je zoiets in BASIC vergeet werkt het programma
++ misschien wel, maar is het maar de vraag of het doet wat jij bedoeld had.
Ja Johan, maar C is ook niet perfect. Bij lange na niet:
if (i == 3)
j = 4;
en dat wordt later:
if (i == 3)
j = 4;
k = 2;
Oops. Accolades vergeten. Maar het compileert zonder warnings hoor.
Of deze:
for (i = n, j = 1; i --; j *= 2)
k += 3;
vs
for (i = n, j = 1; i --; j *= 2);
k += 3;
++ En als dat niet resulteert in een vastloper of een opvallend foutieve
++ uitkomst is dat nog veel erger.
Een enkel ; vergeten, 0 foutmeldingen en een nogal ander gedrag
van je programma.
Abigail -- C is pokketaal.
Antoon Pardon
leo Koenen (le...@knoware.nl) wrote:
[ knip ]
: En dan laat je je nieuwe rekenmachine een simpele som oplossen waar
: een fout antwoord op komt, vraag je vriendelijk hoe dat kan en dan
: wordt je door middel van een beledigend standaardantwoord afgezeken.
: Afzeiken is tot daar aan toe, maar via een onpersoonlijk standaard-
: antwoord gaat toch te ver. Ze hadden er toch minstens (met de
: computer) mijn naam boven kunnen zetten en een handtekeningstempel
: eronder.
Ik zie het probleem niet hoor. Gebruik je beitel als schroeven-
draaier en ga klagen omdat hij te snel bot wordt. Dat is toch ook
een simpele handeling, schroeven indraaien. Iedereen zou echter
dadelijk antwoorden dat je het verkeerde gereedschap hebt ge-
bruikt.
Wel dat heb jij ook gedaan. Je hebt een rekenmasjientje dat met
vlottende-kommagetallen werkt gebruikt om een vast-komma resul-
taat te verkrijgen.
Joris Zwart
In article <335225...@math.utwente.nl>,
Jan Gerritsjans <j.m.j.m.g...@math.utwente.nl> wrote:
>Ik zag Rick van de Young Ones laatst tot drie tellen:
>"One, two, two point nine, nine, nine, usw" en hij sloeg nog steeds niet
>met de koekepan.
Natuurlijk niet, zijn rij van negens was in de verste verte niet oneindig.
Alleen de limiet is gelijk aan 3.
Er zijn overigens maar heel weinig mensen die niet iets van wiskunde
begrijpen die bereid zijn te accepteren dat 0.9999999...... gelijk is aan 1.
Luc Peersman
>>De ondertoon van deze en anders postings doen zelfs mij naar 'kamp
>
>Ik vind dat hier toch wel een erg 'verwende' toon uit naar voren komt.
>
>Opa zal wel eens vertellen hoe dat vroeger zat:
>
>Wij hadden een rekenliniaal, waarmee je blij moest zijn als je drie
>significante cijfers goed had.
Welkom in 1997. Ik heb die ellende met die rekenlineaal ook meegemaakt
en ben blij daar vanaf te zijn (heb er eentje op m'n buro als
speelgoed). Het is toch niet zo onredelijk om van een pentium met
matlab, excel of mathematica te verwachten dat ie kan rekenen?
Overigens ben ik inderdaad een verwend snertjong.
Ik:
>>Het lijkt in deze en andere postings net of 'het
>>toch niet zo heeeel fout is' wat de rekenmachine doet. Er wordt zelfs
>>gesuggereerd dat wij als gebruiker dan maar met andere rekenmachines
>>en andere notaties moeten werken, omdat wij o domme mensen met het
>>10-tallig stelsel werken. Onzin! Ik vraag een pentium-processor met
>>'evenveel onderdelen als een boeing 747' (beruchte quote) een som op
>>te lossen die een lagere school kind ook kan.
>
Eric:
>Dat vraag je helemaal niet aan een Pentium, maar dat vraag je aan een
>rekenbladprogramma, dat kennelijk zijn prioriteiten elders legt.
>Een 32 bit x86 compatible machine kan intern met decimale getallen
>werken in een 80 bit representatie, goed voor 18 decimale cijfers.
Wat is dat nou voor argument? Al zijn het 8000 bits, fout is fout!
Moet ik nu door de vingers zien dat de computer 3*1,9 niet kan
uitrekenen? Of zelfs 5,8 - 5,4 ? (zie mijn reply op Antoon)
Een Pentium heeft weldegelijk zijn machine-fout. Dat kan soms niet
anders als je een decimaal getal binair gaat weergeven als float. Een
en ander is vastgelegd in de IEEE-754 standaard. De vraag is hoe de
software hier mee omgaat.
(...)
>Maple kan de precisie dan goed doen: probeer er eens een 100x100
>matrix mee te diagonaliseren: ik denk dat je wel op vakantie kunt
>gaan, terwijl de efficiente binaire methodes dat zowat in een seconde
>doen.
Ja, goed argument voor de binaire methode. Het is altijd een afweging
tussen precisie en snelheid die je moet maken. Mijn belangrijkste
grief is dat software niet allerlei conditionele operaties mogelijk
moet maken die het niet waar kan maken omdat ze op floating point
notatie berusten.
>>Voor de duidelijkheid: ik heb het niet over de oude pentium's met
>>foutje, die zijn allang uit de handel.
>
>Volgens mij weet je eigenlijk niet waar je het over hebt.
Nee, geen idee :-)
Met groet,
Luc
Tarzan
Aan 14-04-97 22:32, in bericht <3352944a.5...@vulcan.xs4all.nl>,
Johan Wevers <joh...@vulcan.xs4all.nl> schreef:
> Tarzan <bjd...@worldaccess.nl> wrote:
>
> >Als je in BASIC iets programmeert werkt het. Als je in C iets programmeert
> >krijg je na het vergeten van 1 enkel ; teken tientallen foutmeldingen waar
> >niemand iets van begrijpt.
>
> Jij misschien niet. Maar als je zoiets in BASIC vergeet werkt het programma
> misschien wel, maar is het maar de vraag of het doet wat jij bedoeld had.
> En als dat niet resulteert in een vastloper of een opvallend foutieve
> uitkomst is dat nog veel erger.
1: In BASIC hoef je niet eens ; te zetten.
2: 1 Foutmelding is een stuk begrijpelijker dan heel veel foutmeldingen.
Maar inderdaad: voor het moeilijkere werk is BASIC niet geschikt. (Doordat het zo
langzaam is)
Groetjes,
Bas
--
Bas Vermeulen
E-mail: bjd...@worldaccess.nl
Homepage: http://www.worldaccess.nl/~bjdeuso
Ik heb ontdekt dat ik het vermogen heb om iemands karakter uit een enkel e-mailtje
kan bepalen. Wil jij weten hoe je echt in elkaar zit? Stuur me dan een e-mailtje met
omschrijving van je uiterlijk, geboortedatum, opleiding en evt. beroep. Geef ook aan
welk aspect van je karakter wil leren kenne
n. Je krijgt zo snel mogelijk antwoord.
Abigail
On Tue, 15 Apr 1997 21:40:50 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:335403f2.5...@vulcan.xs4all.nl>:
++ Abigail <abi...@fnx.com> wrote:
++
++ >Ja Johan, maar C is ook niet perfect. Bij lange na niet:
++
++ Heb ik ook zeker niet beweerd.
++
++ >if (i == 3)
++ > j = 4;
++ >
++ >en dat wordt later:
++ >
++ >if (i == 3)
++ > j = 4;
++ > k = 2;
++ >
++ >Oops. Accolades vergeten. Maar het compileert zonder warnings hoor.
++
++ Tja, dat kan toch ook je bedoeling zijn? Hoe moet die compiler nu weten of
++ je gewoon altijd k=2 wilt zetten of alleen als i 3 is?
Inderdaad, maar je had toch een vergelijkbaar verwijt naar een
andere taal, ondertussen C ophemelend? Ik toon alleen aan dat
je dezelfde fout kunt maken in C.
++
++ Als je trouwens gewoon
++
++ if (i == 3) j = 4;
++
++ k = 2;
++
++ vs.
++
++ if (i == 3) {
++ j = 4;
++ k = 2;
++ }
++
++ schrijft is het veel duidelijker en maak je zo'n fout niet. Helaas
++ (gelukkig voor de "geek-code" schrijvers :-) laat C een zeer slechte layout
++ toe. Zoals Einstein al beweerde toen hij de sommatieconventie voor tensoren
++ uitvond, een goede notatie is het halve werk.
Tsja, en als je altijd de ; aan het begin van de regel zet vergeet je
ook nooit meer de ;.
++ >Of deze:
++ >for (i = n, j = 1; i --; j *= 2)
++ >k += 3;
++
++ Ik snap deze constructie niet helemaal vrees ik. Wat moet ik met een
++ stopconditie van de vorm i--?
Heel simpel. i -- evalueert als "false" wanneer i == 0.
Een bekende truc op snel door een array te lopen is:
/* n == sizeof array */
for (i = n; i --;) { /* Something with element i */ }
bv de som van alle elementen in een array:
for (i = n, sum = 0; i --; sum += arr [i]);
Abigail
Abigail
On Tue, 15 Apr 1997 21:43:19 -0100, Johan Wevers wrote in nl.wetenschap
<URL: news:33540487.5...@vulcan.xs4all.nl>:++ >1: In BASIC hoef je niet eens ; te zetten.
++ >2: 1 Foutmelding is een stuk begrijpelijker dan heel veel foutmeldingen.
++
++ De eerste is relevant, de BASIC die jij gebruikt stopt daarna blijkbaar
++ gewoon. C gaat door totdat de compiler zoveel fouten ziet dat hij niet meer
++ verder kan.
Dat is een eigenschap van de compiler, niet van C.
Abigail
Abigail
On Tue, 15 Apr 1997 20:46:18 GMT, Luc Peersman wrote in nl.wetenschap
<URL: news:3353e23c...@news5.inter.nl.net>:
++ >Dat vraag je helemaal niet aan een Pentium, maar dat vraag je aan een
++ >rekenbladprogramma, dat kennelijk zijn prioriteiten elders legt.
++ >Een 32 bit x86 compatible machine kan intern met decimale getallen
++ >werken in een 80 bit representatie, goed voor 18 decimale cijfers.
++
++ Wat is dat nou voor argument? Al zijn het 8000 bits, fout is fout!
++ Moet ik nu door de vingers zien dat de computer 3*1,9 niet kan
++ uitrekenen? Of zelfs 5,8 - 5,4 ? (zie mijn reply op Antoon)
Natuurlijk kan dat. Door andere algoritmen te gebruiken. Algoritmen
die veel langzamer zijn. Zodat als je een window vergroot dit veel
langzamer gaat dan dat je je muis kunt bewegen. Of 3 uur nodig heeft
om dat 100 x 150 JPG plaatje op je scherm te zetten.
En je kunt natuurlijk de computer zelf een handje helpen door niet
5.8 - 5.4 uit te rekenen, maar (58 - 54) / 10.
++ Een Pentium heeft weldegelijk zijn machine-fout. Dat kan soms niet
++ anders als je een decimaal getal binair gaat weergeven als float. Een
++ en ander is vastgelegd in de IEEE-754 standaard. De vraag is hoe de
++ software hier mee omgaat.
Tsja, iedereen die programmatuur schrijft die gebruik maakt van IEEE
floats weet dat je berekeningen die zulke floats gebruikt niet in
== expressies moet gebruiken.
++ >>Voor de duidelijkheid: ik heb het niet over de oude pentium's met
++ >>foutje, die zijn allang uit de handel.
++ >
++ >Volgens mij weet je eigenlijk niet waar je het over hebt.
++
++ Nee, geen idee :-)
Dat blijkt.
Abigail