Re: In the Shallow End

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message
news:fLudnZnBNdSBxH7ZnZ2dnUVZ_vudnZ2d@xxxxxxxxxxxxxx
Dan Johnson wrote:
[snip]
How?

(Not that I expect an answer. You don't know
how they used RMS, and you don't know what
'ACID' transactions are either, I'll wager.)

It will be beyond your comprehension level but I will try.
The o/s itself is fault tolerant, and the way it handles asynchronous I/O.
Actually, the transactions were easy enough to implement because of the
design of the o/s in the first place... something that M$ never handled
correctly nor never could until hardware was available to them lately, but
not cheaply in the 80s or the 90s.

More vagueness; you don't know, so you substitute
low-content MS-bashing.

My bet is they didn't do anything as silly as building
an RDBMS on RMS; they just build a database
in the usual way.

But then let us see your definitions of ACID transactions now.
You can't force a one way conversation here.

If you admit that you don't know, and ask nicely, I
will explain ACID transactions to you.

[snip]
When something better comes along.

I'd say that Apple has come just in time then.

Maybe. Their OS has improved greatly
year over year, and has actually surpassed
Windows XP in several particular areas.

Of course, Leopard appears to end *that*
trend, but we'll see how it comes out in
the end.

[snip]
That is to say, it does it rather *more* than
Fortran does; enough to prevent array slicing
and aliasing tricks.

Not a problem on Fortran. I've never had these problems, which means that
I'm vindicated about how crappy M$ products and languages really are.

That's nonsensical. I mean, even for you.

Checking array bounds strictly makes C# slower
and blocks a number of performance-enhancing
tricks FORTRAN can do. But it makes the language
safer as well.

[snip]
Quads are not a standardized data type, and different
implementations have different data types; but they
are all bigger than doubles, and some are as big as
decimals.

Doesn't matter if they are not standard in other languages, but the latest
fortran standard does make Quad floats a standard.

Yes, and the C standard makes 'double' a 'standard',
but without defining how big it is.

They do that so they can use whatever the local hardware
supports bests, for maximum speed.

Like Fortran.

They still exhibit the usual binary floating point
inaccuracies that we all know and loathe, however.

That's where the fortran libs come into account to remove this problem.

By 'libs' do you mean libraries, or are you on about
something else?

That is why this is fortrans forte rather than C or any other language.
Otherwise, fortran would have died a long time ago.

C handles libraries fairly well, but it doesn't
outperform Fortran on numerics.

[snip]
You do not lose accuracy in COBOL, precisely because
it does not use floating point.

But no one uses COBOL in scientific work. It would be absurd.

It would be far too slow. But it is as accurate as
you want it to be.

C#'s decimal is floating point, but it's float is
limited so you can't lose as much accuracy as you can
with Fortran.

Fortran doesn't lose the accuracy as easily as other langauges, as the
other languages do not take accuracy loss into account.

Yes, they do. Accuracy is very important
in some segments of the industry.

In C#, a+1 > a, for any decimal a,
unless it overflows. And if it overflows, you get
an exception, not the wrong answer.

That isn't true of any binary floating point format.

I know that. Again, the fortran processor takes these things
into account.

You can't fix this by 'taking things into account';
you need more bits to store more precision.

Doing that means not using the CPU's built in
types. That's slow. That's why COBOL does it,
but FORTRAN avoids it.

[snip]
Standard FORTRAN does not support BCD numbers.

Only some vendors do is all. Even the earlier versions of M$ fortran
supported BCD numbers and even their Pascal compiler. Something you
weren't aware of obviously. But the rest of M$ methods of interfacing to
the real world were disappointing.

Oh, the irony! You spent quite sime time directing me
to the FORTRAN 2003 standard, and now that it you
find out (from me) that it doesn't include BCD arithmetic,
you point to a vendor implementation... Microsoft's no less!

Just don't ever complain about MS polluting Java
with nonstandard features, okay? :D

[snip]
I'm sure there must be some weird variant somewhere
that did, or you wouldn't be trying to build an argument
on it, but it's just bizzare.

Not bizzare, just vendors addressing a shortcoming and these extensions
happen when the industry demands them.

A shortcoming in standard FORTRAN.

And that shortcoming is a lack of support for
high-accuracy computation.

[snip]
Well, you don't know about very many then. X-Windows
and OS/2 exhibited the same problems.

X never crashed the o/s, and yes X can crash.

It takes down your apps when it goes. That's the
problem; nobody *cares* about the OS surviving
on a PC, if all the apps go.

But then if you knew how the X system worked, you should also know how to
re-start
the X server without rebooting the system.

Your apps do not recover if you do this.
All state on the X-server will be lost.

OS/2 is pretty much dead and not for sale anymore.

It was another OS trying to tackle the problem; their
solution was pretty much the same as Win95: lots
of shared memory with global data in it.

[snip]
But it always appears to be MS that is always doing this. Especially
with word.

But not C#, which is what we were discussing, right? :D

C# is a M$ ripoff of Java. Nothing new there right? :-D

There is not much new in it, but not quite nothing. It's mostly
an assembly of successful features from other languages.

M$ has always been moving the goal posts to put a barrier to entry for
other vendors. That's why you wintrolls think you are getting a new
innovative product, but in reality it is just M$ moving their goal posts
to thwart a competitor.

That's why they call it 'competition'.

[snip]
You see, then, the problem with letting your
brand be damaged?

Apples brand is not damaged. Just seems that way between your two ears.

I didn't mean to say they have damaged it;
it would be necessary for them to sell cheap
computers for that to happen. :D



.

Relevant Pages

  • Re: Whats wrong with GEDCOM ?
    ... I remember back in the late 1980s when we were waiting for the new Fortran standard to succeed Fortran 66 and Fortran 77. ... The new standard was known informally as Fortran 8X, and as the decade drew to a close, there was much joking that "X" would have to be a hexadecimal digit. ... I doubt that any of the "modern" languages could be summarised in so few pages. ... But then, Dennis Ritchie didn't have to get the approval of a committee, because he created the C programming language. ...
    (soc.genealogy.computing)
  • Re: Surprise
    ... (snip, I wrote) ... Perl, Python, PHP etc. do. ... Fortran compilers are written in some other languages too. ...
    (comp.lang.fortran)
  • Re: In the Shallow End
    ... Not in the manner that Fortran will. ... which means that I'm vindicated about how crappy M$ products and languages really are. ... Doesn't matter if they are not standard in other languages, but the latest fortran standard does make Quad floats a standard. ... Standard FORTRAN does not support BCD numbers. ...
    (comp.sys.mac.advocacy)
  • Re: In the Shallow End
    ... You've never used fortran so obviously, again, you don't know what you are ... it wasn't extensions but the 2003 FORTRAN ... standard you were talking about. ...
    (comp.sys.mac.advocacy)
  • Re: reading more data than the record size (RECL)
    ... end snip ... My old compiles also write and read correctly with the subroutine I ... This overhead is there to allow Fortran ...
    (comp.lang.fortran)
Loading