Re: Chinese +ACY- Maya writing systems
Jugoslav Dujic
|||||| "Yuri" == Yuri Kuchinsky <yu...@trends.ca> writes:
|
| Similarly, to a person who don't know the Latin nor the Cyrillic
| alphabets, both alphabets look "amazingly similar".
D'oh, you shouldn't have mentioned that example -- you've just opened
a can of worms :-). Now, if I try to follow Yuri's way of thinking, the
consequence of that would be:
"But Latin and Cyrillic DO have the common roots! Thus, there must
be something in common with Maya/Chinese as well..."
--
Jugoslav
___________
www.geocities.com/jdujic
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Andreas Prilop
> Subject: Re: Chinese +ACY- Maya writing systems
> References: +ADw-412A51F8.6DDF0B2A+AEA-trends.ca+AD4-
> +ADw-412A5D41.5692+AEA-worldnet.att.net+AD4-
> +ADw-412A635C.128FA7D4+AEA-trends.ca+AD4-
> +ADw-412B2A36.2206+AEA-worldnet.att.net+AD4-
> +ADw-412E3BA4.F349D71D+AEA-trends.ca+AD4-
> +ADw-412E5EED.3689+AEA-worldnet.att.net+AD4-
> +ADw-41323C87.A384071D+AEA-trends.ca+AD4-
> +ADw-413254A5.759C+AEA-worldnet.att.net+AD4-
> +ADw-4134B7AC.6432F7B5+AEA-trends.ca+AD4-
> +ADw-m34qmjypny.fsf+AEA-mika.informatik.uni-freiburg.de+AD4-
> Content-Type: text/plain;
> charset="utf-7"
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
Do not use UTF-7 with Outlook Express!
It completely fucks up the references.
Outlook Express claims to be a newsreader
but is really a piece of bullshit.
Never use UTF-7! If you need Unicode, then use UTF-8.
Jugoslav Dujic
|||||| "Jugoslav" == Jugoslav Dujic <jdu...@yahoo.com> writes:
|
| Jugoslav> In theory yes. However most optimizers will "eat" such
| Jugoslav> tests, "translating" if(x==x) into if(TRUE) regardless
| Jugoslav> of that exception. I think there's something like
| Jugoslav> isnan() in standard library which is far more fail-safe
| Jugoslav> for purpose of testing whether x is NaN.
|
| Then, those compilers are wrong, aren't they?
Yes and no. You're really not supposed to do anything with a NaN except
perhaps to test whether it's NaN (and then handle them specially). Since
in 99.99% codes one does not expect/allow a NaN or Inf at all (and producing
one causes a run-time error with appropriate compiler switches), the choice
to optimize away the "obvious" test if(x==x) seems like a more reasonable
choice than to generate a (computionally expensive) test on NaN which is
spurious in 99.99999% cases. Thus isnan() function.
Jugoslav Dujic
|||||| "Jugoslav" == Jugoslav Dujic <jdu...@yahoo.com> writes:
|
| Jugoslav> In theory yes. However most optimizers will "eat" such
| Jugoslav> tests, "translating" if(x==x) into if(TRUE) regardless
| Jugoslav> of that exception. I think there's something like
| Jugoslav> isnan() in standard library which is far more fail-safe
| Jugoslav> for purpose of testing whether x is NaN.
|
| Then, those compilers are wrong, aren't they?
Yes and no. You're really not supposed to do anything with a NaN except
perhaps to test whether it's NaN (and then handle them specially). Since
in 99.99% codes one does not expect/allow a NaN or Inf at all (and producing
one causes a run-time error with appropriate compiler switches), the choice
to optimize away the "obvious" test if(x==x) seems like a more reasonable
choice than to generate a (computionally expensive) test on NaN which is
spurious in 99.99999% cases. Thus isnan() function.
And, Sau Dan, would you mind switching from UTF-7 to something else
(e.g. UTF-8)? It's not your fault, but Microsoft's -- this is already
the second time my damn Outlook Express screws my reply to you when
I forget to switch the encoding (and my newsserver does not support
canceling).