reasons for failure
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Louis Krupp on 22 May 2010 09:46 On 5/22/2010 12:22 AM, Uno wrote: > On 5/21/2010 5:20 AM, Louis Krupp wrote: >> On 5/21/2010 12:49 AM, Uno wrote: >>> steve wrote: >>> >>> Why is "64-bit processing" vague? >> >> Are you stating that "'64-bit processing' is vague" and asking why this >> is the case, or are you why "64-bit processing" is perceived to be vague? > > I guess I wonder other people would call this: > > http://i46.tinypic.com/imj6oi.png > > Process. Many meanings. I process by writing. From the source: http://support.microsoft.com/kb/946765 Louis
From: Ron Shepard on 22 May 2010 12:32 In article <85pevaFpqaU1(a)mid.individual.net>, Uno <merrilljensen(a)q.com> wrote: > > You can tell how accurate things should be with the precision() or > > the epsilon() intrinsic functions. The 10-byte values should have > > about 5 more significant digits than the 8-byte values. > > Oh, nuts. [...] > 4 sig figs better. Thx, Ron My mistake. I thought the 80-bit register used the same exponent range, resulting in 16 extra bits of mantissa. But from the previous post it is clear that the exponent ranges are different, and there are only 11 extra bits of mantissa (which is 3 to 4 decimal digits, as you say). $.02 -Ron Shepard
From: Uno on 22 May 2010 20:05 Louis Krupp wrote: > On 5/22/2010 12:22 AM, Uno wrote: >> On 5/21/2010 5:20 AM, Louis Krupp wrote: >>> On 5/21/2010 12:49 AM, Uno wrote: >>>> steve wrote: >>>> >>>> Why is "64-bit processing" vague? >>> >>> Are you stating that "'64-bit processing' is vague" and asking why this >>> is the case, or are you why "64-bit processing" is perceived to be >>> vague? >> >> I guess I wonder other people would call this: >> >> http://i46.tinypic.com/imj6oi.png >> >> Process. Many meanings. I process by writing. > > From the source: > > http://support.microsoft.com/kb/946765 Ok. Not all of the information I was looking for but worth the read. http://en.wikipedia.org/wiki/Bus_(computing) I think you would agree that the computers I operate on are very middle of the road. Can you speculate what the data bus looks like on your garden-variety, 2-yr old x86-84 laptop or desktop? It sounds like something that could be a part of the chip or be a bunch of wires fastened with chewing gum. -- Uno
From: Uno on 22 May 2010 20:23 Richard Maine wrote: > Uno <merrilljensen(a)q.com> wrote: > >> steve wrote: >> >> Why is "64-bit processing" vague? > > I can't find where Steve wrote any such thing, which makes that post > sort of vague to me. :-) I'll guess that the "steve wrote" part is an > incomplete reference to Steve's comment that "64-bit processing" is > vague. I can find where Steve said that, although not in the post that > Uno was directly following up to. I further guess that it is Uno asking > why this is so. More or less. Steve misposted or correctly posted nothing, so I did quote him faithfully. I have this idea that steve posts from his office, his garage, his work, when he can get a free moment at a party. Sometimes the challenges of reading news under various and sundry circumstances makes it more interesting. > > "64-bit processing" is vague for the same reason that anything is vague. > Namely, it does not have a well-defined meaning. That's what "vague" > means. In large part, "64-bit processing" has come to be a term used by > marketting folk. As is typical with much marketting, you can't count on > any particular meaning. It sounds like a good thing, so vendors will > claim their product has it, warping the meaning in whatever way they > need to in order to rationalize the claim. Marketting is like that. For > an example from a while ago, Intel used to say that the 8088 was an > 8-bit processor; I had Intel documentation using that description. > Somewhat later, Intel started describing the same chip as being a 16-bit > one. Nothing changed about the chip. All that changed was Intel's > marketting definitions. > > More to the current point, did you not read Glen's reply to your > original post? As Glen said > >>> 64 bit processing means that the address space is greater >>> than 4GB. > > I might modify Glen's "means" with something like "most commonly". Ok. > > It is evident from your original question > >> Am I correct to think that if I had 64-bit processing, then >> qp_preferred would be positive: > > That you were thinking of "64-bit" as being something almost completely > unrelated. There are also other people who assume this is what it means, > even though that's not usually the case when you read the term today. > That is a quite common source of misunderstanding. > > When different people, or even the same people at different times, have > different notions of what "64-bit processing" means, then that indeed > makes it vague. You read James van Buskirk and realize that he has more fortran computing power than you do (at least I do.) I made the errant guess that the doubling of the precision in these calls meant that I needed a datatype that was twice as wide. integer, parameter :: dp = selected_real_kind(15,300) integer, parameter :: qp_preferred = selected_real_kind(30,1000) So I muffed that, but I'm really proud of the treatment I gave to the batch files: $ pwd /media/disk/fortran_stuff $ cat run2.bat @echo off Title Build environment for 64-bit gfortran equation solutions set dir=%~dp0 set path=%dir%\bin;^ %dir%\libexec\gcc\x86_64-pc-mingw32\4.5.0;^ %path% set EQ_LIBRARY_PATH=%dir%\x86_64-pc-mingw32\lib echo Dir for this script: %dir% cd %dir% $ -- Uno
From: Uno on 22 May 2010 20:46
glen herrmannsfeldt wrote: > 1) Virtual address size (might be pointer size) > 2) Real address size > 3) General register size > 4) Data bus size With modern computers, do 1 and 2 tend to be the same number? [snipped a lot of stuff that I entered into my linuxlog] > SPARCv9 includes a 128 bit floating point type. As said in > "The SPARC Architecture Mavual Verion 9": > > "SPARC-V9's support ofr a 128-bit quad floating point format > is unique for microprocessors." > > However, later on it indicates that instructions can either > be implemented in hardware, microcode, or software emulation. > > I don't know specifically which, if any, SPARCv9 implementations > have hardware support for 128 bit floating point. Well this got me poking around: http://en.wikipedia.org/wiki/SPARC Is the SPARC 9 the Niagara? Is the price comparable to an x86-84 chip? Gosh, I'd love to go with a Sun product. Someone's gotta put food on Bob Corbett's table.:-) -- Uno |