This is the first time I am facing this problem and can't figure out
WHY is it when I pull data from MySQL, instead
of 10.98 from a certain cell, PHP shows "10.9799995422".
The cell stores data as a "float" in MySQL.
Here is what I do...:
$stmt = mysqli_prepare($mysql_db, "SELECT
`products`.`price`......................<blah blah>")
mysqli_stmt_execute($stmt)
mysqli_stmt_bind_result($stmt, $product['price'])
print $product['price']
and that's where I get the more decimal places than I should be :)
any idea why?
THANKS!
Because 10.98, like most floating point numbers, cannot be represented
exactly in a computer.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Let me be more precise about it.
Most typically, the storage format will have decreasing powers of two after
the radix point, i.e 1/2, 1/4, 1/8, 1/16, etc. This is a basic feature of
computer arithmetic.
Assume you have a rational number, A'/B'. Assume that you reduce A'/B' to
its lowest terms (perhaps using Euclid's GCD algorithm), and call that
rational number A/B.
Once reduced, if B has as a prime factor any prime number other than 2, then
the number will be an infinitely repeating binary number.
An example or two might help.
98/100 reduced is 49/50 = (7 * 7) / 2 * 5 * 5. The "5's" in the denominator
ruin it. In binary, it is non-terminating.
Assume on the other hand that the number you want to represent is 10.6875.
The part after the decimal is 6875/10000 = (11 * 5 * 5 * 5 * 5) / (2 * 2 * 2
* 2 * 5 * 5 * 5 * 5) = 11/16.
You can decompose 11/16 as 1/2 + 1/8 + 1/16. So in binary the
representation will be 0.1011.
Note that in base-10, you run into the same effect. Any reduced rational
number whose denominator has a prime factor other than 2 or 5 (2 * 5 = 10)
is non-terminating.
So 1/125 will terminate, but 1/175 will not.
The former is 0.008, and the latter is non-terminating. The 7 as a prime
factor in the denominator ruins it.
I'm sure you can find many good links about computer arithemtic.
Datesfat
Thank you for the comprehensive answer :) However, theory doesn't
solve my problem. Which is... MySQL has 10.98 and I am getting a
different number. In fact, I KNOW it should be 10.98 since I was the
one who entered that into the MySQL cell.
So, how do I get PHP to properly read the cell contents?
Thanks.
>Thank you for the comprehensive answer :) However, theory doesn't
>solve my problem. Which is... MySQL has 10.98 and I am getting a
>different number. In fact, I KNOW it should be 10.98 since I was the
>one who entered that into the MySQL cell.
>
>So, how do I get PHP to properly read the cell contents?
You could either round it to two decimal places, or store the number in a
different format -- one that won't suffer from this problem.
The former approach is on topic here. The latter is on topic in
comp.databases.mysql, but not in a php group.
Doug, would rounding it always return the same result as it is stored
in MySQL? I don't see the reason why it wouldn't, but just in case...
Mark, no, MySQL DOESN'T have 10.98. It has a close approximation. Even
though you entered it in to the cell, the value cannot be represented
exactly in floating point - any more than 1/3 can be represented exactly
in decimal.
This is true of ALL floating point numbers on ANY computer. It has
nothing to do with MySQL, PHP or any other language.
And BTW - you're asking about MySQL in the wrong newsgroup. If you need
to know more about how MySQL stored numbers, I suggest you ask in
comp.databases.mysql.
If you declare the field type as FLOAT or similar, this tells MySQL that
when you INSERT into the table, it should take the string it is given
("10.98" in this case), convert it to computer representation that MySQL
uses (and in this representation, 10.98 can't be represented exactly), and
manipulate it that way.
Here are your options:
a)Store the number as a string in MySQL.
b)Store the number as a rational number with two integer components.
c)Store the number as an integer with an implied denominator.
It really depends on what you want to do with the number.
If you want to sort based on the number, (a) probably won't do what you want
without more thought. If you know the range of the numbers you'll
manipulate, you might store it as "000010.980000" (and store every number as
exactly 13 characters). That way, the lexical string sort order is the same
as the numerical order, and MySQL can do this fairly efficiently.
I don't immediately see a way to sort using MySQL if you do (b).
If you do (c), again you can sort. 10.98 might be stored as 1098, an
integer. 11.00 would be stored as 1100. Etc. But you need to know the
range of your data in advance.
If you are just looking to avoid loss of precision, strings will do fine.
But if you want to have MySQL sort for you efficiently based on the number's
value rather than the string's lexical sort order (and if the two aren't the
same), you need to think a bit more.
Rounding will work, if you know in advance about the range of your data.
But you need to be careful there, to. 10.98 will work fine, but
100000000000000000000000000000.98 is another type of problem in floating
point.
Datesfat
You don't seem to understand. The number you're getting (10.9799995422) *is*
"as it is stored in MySQL". The purpose of rounding it is to make sure that
you *don't* get the number "as it is stored in MySQL".
So the answer to your question is... No.
Rounding it will return the same value that you *entered* in MySQL.
>If you declare the field type as FLOAT or similar, this tells MySQL that
>when you INSERT into the table, it should take the string it is given
>("10.98" in this case), convert it to computer representation that MySQL
>uses (and in this representation, 10.98 can't be represented exactly), and
>manipulate it that way.
>
>Here are your options:
>
[silly suggestions snipped]
d) Define the column as DECIMAL (4, 2)
4 specifies the total number of digits, and 2 indicates the number of digits
right of the decimal point. If the OP needs, say, 4 digits left of the d.p.,
then he should use DECIMAL (6, 2).
We're getting off-topic for PHP, though... better to take this up in
comp.databases.mysql, where it's on topic. (Followups set)
OK. So I guess it's all about computer arithemtics and the way the DB
stores data based on the the cell format. I thought that if I imported
"10.98" into the DB, then this is what I would get when exporting the
data from it. This doesn't seem to be the case with the "float" format
for that column.
Thanks for clarifying.
Please also bear in mind that the only reason you don't normally lose data
when you're forming the decimal representation of a float is that 2 is a
prime factor of 10. Any number that has a terminating representation in
base-2 also has a terminating representation in base-10 (but not the
converse).
The data loss is in one direction only, normally.
Datesfat
This is why:
> The cell stores data as a "float" in MySQL.
If you want precision decimals, use SQL type NUMERIC or DECIMAL.
--
If any foreign minister begins to defend to the death a "peace conference,"
you can be sure his government has already placed its orders for new
battleships and airplanes. -Joseph Stalin, Soviet Premier
If it's going to be stored in as a binary floating point number,
you're stuck. There is no solution until you change that. Use a
decimal field. Store data as an integer quantity of millicents.
>So, how do I get PHP to properly read the cell contents?
It *is* properly reading the cell contents. When you put the data in
the cell (storing it as binary floating point), it got mangled.
10.98 as long double:
Before: 10.97999999999999999871630462777716275013517588376998901367187500000000000000000000
Value: 10.97999999999999999958366636576556629734113812446594238281250000000000000000000000
After: 10.98000000000000000045102810375396984454710036516189575195312500000000000000000000
10.98 as double:
Before: 10.979999999999998649968802055809646844863891601562500000000000
Value: 10.980000000000000426325641456060111522674560546875000000000000
After: 10.980000000000002202682480856310576200485229492187500000000000
10.98 as float:
Before: 10.979998588562011718750000000000000000000000000000000000000000
Value: 10.979999542236328125000000000000000000000000000000000000000000
After: 10.980000495910644531250000000000000000000000000000000000000000
>OK. So I guess it's all about computer arithemtics and the way the DB
>stores data based on the the cell format. I thought that if I imported
>"10.98" into the DB, then this is what I would get when exporting the
>data from it. This doesn't seem to be the case with the "float" format
>for that column.
I think you need to go back and re-read what's written. Except you
don't really need to understand anything more than the differences
occur when trying to store a base 10 number in binary format.
The difference is so tiny you will always get your original number
back with round(). But you may be better off looking at number
format() if the values you are entering are currency and likely to
have trailing zeroes.
As others have said, if you are really bothered, change the data type
to text. PHP won't care, and you'll get out exactly what you put in.
--
Geoff Berrow (Put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs www.ckdog.co.uk/rfdmaker
Unless you do something like this:
2500000000000000000000000000000000000000000000000000000000000000000000000000000.98
Then round() won't help you.
Datesfat
>> The difference is so tiny you will always get your original number
>> back with round().
>
>Unless you do something like this:
>
>2500000000000000000000000000000000000000000000000000000000000000000000000000000.98
>
>Then round() won't help you.
Now you're being silly.
Not really.
The suggestion was that the OP use round() to avoid having to know about the
underlying machine representation used by MySQL.
For precision, that will work fine with numbers like 10.98 or 100.98 or
1000.98.
But there will come a point where the mantissa isn't large enough, and that
point may come sooner than the OP expects, and then we're back to the "MySQL
beat me on the head for no reason" kind of post. Once again, the user is
forced to know something about the underlying machine representation and how
it affects him.
It has been a while, but my guess is that a typical 32-bit float
representation has a mantissa somewhere around 26 bits.
That means that 1000000.98 probably won't work as expected with round().
The OP needs to understand that.
It is hardly silly to point that out.
Datesfat
P.S.--2500000000000000000000000000000000000000000000000000000000000000000000000000000.98
may be silly, but 1000000.98 is somewhat less silly. : )
I learned a lot of new stuff :)
Those cells always have simple $ values that with 2 decimal points at
the most. The highest price in the database will not exceed $100, so
100.98 will work with round() for the time being. I will look into
changing the DB structure.
Thans again to all who replied.
One other things to mention. DB Tables do not tend to have "cells".
They have rows and fields which are also known as columns.
>Those cells always have simple $ values that with 2 decimal points at
>the most. The highest price in the database will not exceed $100, so
>100.98 will work with round() for the time being. I will look into
>changing the DB structure.
Define the column as DECIMAL (5,2) and you'll be fine. That will hold values
between 0.01 and 999.99.
Just a few parting comments:
a)My recollection is that the MySQL mailing list is a bit more responsive
than the newsgroup. If you hunt around on their site, you'll find it. It
is one of those automatic opt-in/opt-out things.
b)There is one poster who called my suggestion to map floats onto strings
"silly" or similar. In this case, he was right because MySQL has built-in
capability to handle decimal numbers (which I didn't know about).
However, in the general case ...
Usually what you're trying to achieve in a database table design is O(log N)
search time, i.e.
http://en.wikipedia.org/wiki/Big_O_notation
Sometimes when you're doing something unusual, you have to figure out if you
can map the data type you have onto an existing data type to achieve this.
The specific example I supplied was bad, but the concept is sound.
When you declare a table field as an index, you're telling MySQL to build an
auxiliary construct so it can achieve approximately O(log N) times.
But MySQL can only do this with certain data types. It can do it with
strings.
So, let's say that you are using keys of some sort that are 2048-bit
numbers. MySQL probably won't handle these natively. You may be able to
map these onto strings to get the effect you want. The requirement is that
you map in a way where the lexical sort order of the strings corresponds to
the ordering you want.
Your example is similar. Let's assume that MySQL doesn't have a data type
big enough to handle the dollar amounts you want with the precision you
want. You may be able to store the values as integer numbers of cents. I
think MySQL allows 64-bit unsigned integer fields, which would give you a
range up to 184,470,000,000,000,000.00, with precision to one penny, which
is quite a lot of money with a high precision.
However, if that doesn't work, mapping onto strings is the next logical
step. (I think). You just want to store them in a way where the lexical
sort order corresponds to the value order of the number stored.
I may have said something silly (as I did with the earlier suggestion). If
anybody knows of a better way to store a 2048-bit key or a huge sum of money
in a way where it can be indexed ... I look forward to reading it.
Good luck, Datesfat
>>>2500000000000000000000000000000000000000000000000000000000000000000000000000000.98
>>>
>>>Then round() won't help you.
>>
>> Now you're being silly.
>
>Not really.
Check out the OP code
>$product['price']
Unless he's selling aircraft carriers, I don't think he'll have a
problem.
>Those cells always have simple $ values that with 2 decimal points at
>the most. The highest price in the database will not exceed $100, so
>100.98 will work with round() for the time being. I will look into
>changing the DB structure.
number_format() will be better
>b)There is one poster who called my suggestion to map floats onto strings
>"silly" or similar. In this case, he was right because MySQL has built-in
>capability to handle decimal numbers (which I didn't know about).
Ah, don't take it personally, I was only teasing.
We both learned stuff, which is good.
Until he retrieves it into a language such as PHP which doesn't have bcd
support (directly, anyway) - in which case it will again become a float
- and have rounding problems.
Hi Geoff,
If MySQL uses a 32-bit float, the comments from my other post may apply:
<QUOTE>
It has been a while, but my guess is that a typical 32-bit float
representation has a mantissa somewhere around 26 bits.
That means that 1000000.98 probably won't work as expected with round().
The OP needs to understand that.
</QUOTE>
Now I'm curious myself ... let's Google a few things and do a back of the
napkin calculation.
A typical float may be this ...
http://en.wikipedia.org/wiki/Single_precision
We have a 23-bit mantissa (less than I thought!). Because of the implied
"1", let's call it 24 bits.
2^24 is 16,777,216.
So, $167,772.16 is going to be a problem in terms of keeping the ".16".
That is NOT aircraft carrier money.
Although one may be able to buy a nearly new Cessna 172 for that.
http://en.wikipedia.org/wiki/Cessna_172
Datesfat
Personally, I'd rather have a Piper Archer. A much nicer handling
plane, IMHO :)
I trained just about exclusively in a 172 with some 152 time thrown in. So
it is pretty much the only airplane I've ever known.
All of the low-performance GA airplanes are pretty well student-proof.
There was one landing executed by my flight instructor where, for reasons
unknown to me, he failed to remove the crab angle before the main gear
touched down.
Being a student, my first thought was "I think we're gonna die". But, there
was a screech, a little lateral acceleration, and the airplane straightened
itself out. I did have visions of us tumbling and burning.
The furthest above the runway I've ever stalled an airplane with me flying
is maybe 8 inches. That is called a "properly executed landing". But I had
one discussion with a flight instructor where we were guessing how high
above the runway you'd need to stall a 172 before you did damage. She said
"3 feet definitely won't do it--I see 3 feet every day from my students".
The furthest above the runway I've ever been and stalled it (me not flying)
is probably about 2 feet. I went right-seat up for a maintenance checkout
and, again for reasons unknown, the guy in the left seat really messed up.
Anyway, I saw it all unfolding and I braced myself -- I knew we weren't
going to die but I didn't know how bad it would be. Just a plop ... not too
bad ... enough to get you to spill your coffee, maybe.
Maybe one day I'll get to experience a different model of airplane ...
http://www.dtashley.com/photos/2004/pics20040901/index2.php
Datesfat
It's not just MySQL.
The NUMERIC and DECIMAL datatypes are ANSI standard.
I'm not aware of any SQL DBMS that does *not* support them. Not necessarily by
those names (e.g., Oracle uses NUMBER instead), but they're available
everywhere AFAIK.
>
>However, in the general case ...
>
>Usually what you're trying to achieve in a database table design is O(log N)
>search time, i.e.
>
>http://en.wikipedia.org/wiki/Big_O_notation
>
>Sometimes when you're doing something unusual, you have to figure out if you
>can map the data type you have onto an existing data type to achieve this.
>The specific example I supplied was bad, but the concept is sound.
>
>When you declare a table field as an index, you're telling MySQL to build an
>auxiliary construct so it can achieve approximately O(log N) times.
What on earth does *any* of this have to do with the original question?
[remaining irrelevantia snipped]
>Your example is similar. Let's assume that MySQL doesn't have a data type
>big enough to handle the dollar amounts you want with the precision you
>want.
Faulty assumption, as you proceed to show. So what's the point?
>You may be able to store the values as integer numbers of cents. I
>think MySQL allows 64-bit unsigned integer fields, which would give you a
>range up to 184,470,000,000,000,000.00, with precision to one penny, which
>is quite a lot of money with a high precision.
>
>However, if that doesn't work, mapping onto strings is the next logical
>step. (I think). You just want to store them in a way where the lexical
>sort order corresponds to the value order of the number stored.
Why? He didn't say anything about wanting to sort them, he just wanted to know
why 10.98 wasn't being represented exactly.
>I may have said something silly (as I did with the earlier suggestion). If
>anybody knows of a better way to store a 2048-bit key or a huge sum of money
>in a way where it can be indexed ... I look forward to reading it.
There wasn't anything in the original post that suggested the need to index
anything.
It is a safe bet that someone who doesn't know why 10.98 isn't really 10.98
has other gaps in their training as well.
I'm just saving him trouble down the road, when his database is growing
slower every year and he isn't sure why.
>>However, if that doesn't work, mapping onto strings is the next logical
>>step. (I think). You just want to store them in a way where the lexical
>>sort order corresponds to the value order of the number stored.
>
> Why? He didn't say anything about wanting to sort them, he just wanted to
> know
> why 10.98 wasn't being represented exactly.
The next time I'm in an oil change place and they advise me that I have a
transmission leak, I'll chew them out because I never asked them about the
transmission.
>>I may have said something silly (as I did with the earlier suggestion).
>>If
>>anybody knows of a better way to store a 2048-bit key or a huge sum of
>>money
>>in a way where it can be indexed ... I look forward to reading it.
>
> There wasn't anything in the original post that suggested the need to
> index
> anything.
Hmmm ...
Your notion of value added is apparently to point out that I gave too much
information.
I'm not finding value there.
Datesfat.
>>>>2500000000000000000000000000000000000000000000000000000000000000000000000000
>000.98
>>>>
>>>>Then round() won't help you.
>>>
>>> Now you're being silly.
>>
>>Not really.
>
>Check out the OP code
>
>>$product['price']
>
>Unless he's selling aircraft carriers, I don't think he'll have a
>problem.
Even if he is, I don't think he'll have a problem: the number cited above
exceeds the annual U.S. federal budget by (roughly) 66 orders of magnitude.
Poor analogy. Better one: chew them out if they start describing how the
internals of an automatic transmission work.
[...]>
>Your notion of value added is apparently to point out that I gave too much
>information.
Incorrect. I pointed out that much of what you provided was irrelevant.
Irrelevant to what?
Irrelevant to what the OP asked? Yes.
Irrelevant to other issues he'll run into as he builds databases? Probably
not.
Datesfat
I trained in a Cherokee 140, plus have time in both a Warrior and an
Archer. Got a little right seat time in a Seneca 6, also, on a
sightseeing ride over downtown Chicago :)
But I've also got a bunch of hours in Cessna 150's and 172's. They're
nice, but I just like the low wing a bit better. :)
> All of the low-performance GA airplanes are pretty well student-proof.
> There was one landing executed by my flight instructor where, for
> reasons unknown to me, he failed to remove the crab angle before the
> main gear touched down.
>
> Being a student, my first thought was "I think we're gonna die". But,
> there was a screech, a little lateral acceleration, and the airplane
> straightened itself out. I did have visions of us tumbling and burning.
>
Yep, don't try that in a tail dragger, though. Ground loop time!
> The furthest above the runway I've ever stalled an airplane with me
> flying is maybe 8 inches. That is called a "properly executed
> landing". But I had one discussion with a flight instructor where we
> were guessing how high above the runway you'd need to stall a 172 before
> you did damage. She said "3 feet definitely won't do it--I see 3 feet
> every day from my students".
>
That's pretty good. I had a lot of trouble with landings when I first
started, then again when I transitioned to the Cessna's. But I always
got down in one piece, even if I did leave a dent in the tarmac :)
> The furthest above the runway I've ever been and stalled it (me not
> flying) is probably about 2 feet. I went right-seat up for a
> maintenance checkout and, again for reasons unknown, the guy in the left
> seat really messed up. Anyway, I saw it all unfolding and I braced
> myself -- I knew we weren't going to die but I didn't know how bad it
> would be. Just a plop ... not too bad ... enough to get you to spill
> your coffee, maybe.
>
Yep, the landing gear is pretty good on them.
> Maybe one day I'll get to experience a different model of airplane ...
>
> http://www.dtashley.com/photos/2004/pics20040901/index2.php
>
> Datesfat
>
>
You haven't seen the new US health care plan yet, plus the inflation
it will cause. If anyone can do it badly, it's the US government.
I remember in my first many flight lessons, when we were done with airwork
and headed back to the airport, I was thinking "Oh, crap, now I've got to
land". I was actually scared.
There is just SO much going on at the same time within 10 feet of the
ground.
Part of me being fairly good at it was because I always flew the same model
of airplane. If I had to switch, I'd be screwed for a while. I wouldn't
have a good mental model of what the airplane feels like (the pitch relative
to the distance to the ground) or how far to the ground. There might be
several rough landings. Or more.
Some types of landings ALWAYS gave me a hard time. Crosswinds didn't bother
me much, even gusty ones.
What always got me was being gusted from the front. I'd be all in a
routine, but the gust would come and the airplane would start to climb
again. I'd relax the yoke enough to arrest the unwanted climb, then let
things settle down and continue. But if I got more than one gust, I
sometimes ended up where I was several feet above the ground and going way
too slow. It was either add a bit of power or go around (usually the
latter, as I'm a bit of a chicken).
Gusts from the front ALWAYS messed up my routine. Gusts from the side
didn't. I kind of like crosswind landings, in fact.
Datesfat
Yep, that first one is really scary. But for me, even scarier was when
I soloed. :)
> Part of me being fairly good at it was because I always flew the same
> model of airplane. If I had to switch, I'd be screwed for a while. I
> wouldn't have a good mental model of what the airplane feels like (the
> pitch relative to the distance to the ground) or how far to the ground.
> There might be several rough landings. Or more.
>
Changing planes is always challenging. I remember when I first few a
Warrior. I had about 70 hours in a 140, then moved. When checking out
at the new airport, they told me if I checked out in the Warrior, they
would accept that for the 140, also. So of course, I did.
Everything went find until landing. I brought it in just like the 140 -
the only problem is the Warrior has a longer wing, which has a much
greater effect on a low wing aircraft.
The bottom line is - we floated, and floated, and floated... good thing
this was a medium sized commercial airport, not a small strip, with a
9000 foot runway. :)
> Some types of landings ALWAYS gave me a hard time. Crosswinds didn't
> bother me much, even gusty ones.
>
> What always got me was being gusted from the front. I'd be all in a
> routine, but the gust would come and the airplane would start to climb
> again. I'd relax the yoke enough to arrest the unwanted climb, then let
> things settle down and continue. But if I got more than one gust, I
> sometimes ended up where I was several feet above the ground and going
> way too slow. It was either add a bit of power or go around (usually
> the latter, as I'm a bit of a chicken).
>
> Gusts from the front ALWAYS messed up my routine. Gusts from the side
> didn't. I kind of like crosswind landings, in fact.
>
> Datesfat
Yep, gusty winds are always a challenge. I hate, them, also. If I do
have to go around, the second time I'll probably just fly the plane on
the ground then cut power. It can be a bit tricky and takes practice,
but it's better than stalling out 10 feet above the ground.
But we're getting way off topic here. Better get back to PHP :)
Now who's being silly? Aircraft carriers, probably not. $2,500,000.00
homes for a real estate site, quite possible.
>Changing planes is always challenging. I remember when I first few a
>Warrior. I had about 70 hours in a 140, then moved. When checking out
>at the new airport, they told me if I checked out in the Warrior, they
>would accept that for the 140, also. So of course, I did.
>
>Everything went find until landing. I brought it in just like the 140 -
>the only problem is the Warrior has a longer wing, which has a much
>greater effect on a low wing aircraft.
>
>The bottom line is - we floated, and floated, and floated... good thing
>this was a medium sized commercial airport, not a small strip, with a
>9000 foot runway. :)
I'm so jealous, the closest I have ever come to flying is radio
controlled model aircraft. But landing is always an issue there too.
The area we flew from was surrounded by trees so a really long low
approach was not possible. With only three controls, throttle,
elevator and rudder, and with rudder reversed as the plane comes
towards you it was certainly the most nerve wracking part of the
flight.
OB flying fact - I come form the same city as Reginald Mitchell,
designer of the Spitfire.
>Now who's being silly? Aircraft carriers, probably not. $2,500,000.00
>homes for a real estate site, quite possible.
My bad, I had it in mind he was using double not float.
I don't know how things are in the U.K., but here most flight schools offer
what is called a "discovery flight" for around $60. This lets you go up
with a flight instructor for maybe a half hour and see if you like it.
But it is an expensive process to be licensed. You could easily spend $10K,
even if you're careful to prepare for lessons properly so as not to waste
flight time.
Datesfat
Much more expensive in Europe. For one thing, European airports are
supported by user fees - where the pilot has to pay for every takeoff
and landing (among other things).
One of the unintended results of this is pilots in Europe as whole do
fewer touch and goes to maintain proficiency.
Not at all.
Why do you care? I don't complain if someone goes slightly off topic
into some personal stuff in other threads. Why should you?
ROFLMAO! The troll doesn't even understand simple English.
Go back to your ditch digging. If you need, I'll send you a tutor to
figure out which end of the shovel to use.
Technically, you and I are both bad Usenet citizens for getting off topic.
But there is a continuum of bad behavior. Getting off topic on an
established thread is fairly minor. Posting racist or violent nonsense,
SPAMming the newsgroup, etc. are far worse.
This particular type of off-topic is especially minor because a lot of
people using PHP are inclined toward technology, and a lot of them have
secretly wanted to pursue pilot's licenses. A little bit of information
(such as me mentioning the fact that a lot of flight schools offer discovery
flights) might just add a little happiness and excitement to someone's life.
I also don't complain heavily when someone posts job opportunities ... if it
finds someone gainful employment ... I'm all for that.
You admitted it was off topic and didn't post anything further. I stopped
posting because it was off topic (out of politeness). I don't know what
more anyone could reasonably expect.
People just have to keep complaining.
Datesfat
And you missed one important point. It's minor "offenses" like this
which makes things more interesting. It adds a bit of personality to
the newsgroup.
But yes, you're right - there are always a few trolls, and always people
who can find something to bitch about.
When people are asking off-topic questions, yes. But not when someone
goes slightly off topic into some personal stuff.
But then trolls like you wouldn't be happy if they didn't have something
to bitch about.
Go to alt.rec.airplanes
This is even more friendly then the "go away" you like to post.
R.