Next, open the Windows Calculator program again, and put it in "programmer mode". Press "HEX", then enter "7FFF FFFF FFFF FFFF" (don't type in the blanks, which I have inserted to help you count the number of "F's). This is the largest positive integer that can be represented with 64 bits . What does the "DEC" line show?
Any decimal number whose least significant digit is 6, when raised to any positive integer power, gives a result that also has 6 as its least significant digit. The result on left of the claimed equality (after adding +1 to both sides), however, ends with 8, as stated earlier. The equality claim is refuted.
thanks for this info. i will study it. what your saying is weird though, because i did the calculations in Mathcad (about a month or two ago) and it shows what I posted. so i'm not sure what is going on. also, the microsoft help shows the difference for signed and unsigned and it's not a big difference. the difference from the intel manual is 50%.
In these discussions, one needs to keep in mind that finite-precision computer arithmetic does not always obey the rules of mathematics. As a consequence, when arguments are stated, one has to make it clear whether some associated calculations were made using classical mathematics or computer arithmetic.
unfortunately, it's not very clear to me. i attached a document with calculations i did awhile ago. in an attempt to figure out what was going on. it seems to be a dead end. however, it did make me realize there seems to be an error in the intel manual. unless of course, i'm just hopelessly lost.
the document looks at various definitions I found of the supposed limit. none of which even come close to the limit I'm experiencing. however, that topic is in a different thread. i made this thread just to point out an issue with the intel user manual.
maybe i confused you. i added brackets to my original post. the number you showed in your link wasn't the number i meant. i can see where my original post wasn't clear. i literally copied that from the intel manual though. in any event, maybe the updated post explains what i mean better.
The beauty of using LISP is you learn that the brackets are really important. Fortran tends to get sloppy and not use them and rely on the standard rules of math conventions. You half used brackets which is dangerous in long Fortran equations.
Do you think that there is something wrong with this entry in the table? Do you recognize that this is the upper limit on the loop count, and that DO loop index variables can start with a large negative number as the starting value, as I illustrated with the short program in my earlier reply?
The exact nature of the computations that are performed for a DO loop with a loop-control triplet of integers is specified by the standard. There is a further "guard-rail" that the program source is invalid if during the course of those calculations an integer overflow occurs.
i think there is a lot of confusion. i didn't program this in fortran. i was just trying to understand what the limit is. i used Mathcad. In Mathcad, there is no problem calculating 2^(63-1). the pdf file that I attached is a copy of the Mathcad file. it also has the references etc. plus a bunch of comparisons. i still think the intel manual doesn't make sense. their statement that:
really weird. i put what you said into mathcad and it gives the right answer. so the intel manual is 2^63-1. mathcad gives 2^63 as the same number. whether i subtract one or not. the confusion started from other documents online. i get what you are saying though. thanks for clarifying
Searching the web turned up this link about Mathcad from the year 2008, which discusses something quite similar with integers near the limit of what can be represented in 32 bits. Specifically, the complaint was that the version of Mathcad in use at that time gave a negative value for 231. We seem to be experiencing a redux of the same problem near the limit of 64 bits, fifteen years later.
the version i have of mathcad is old and hasn't changed much. mathcad prime is the new stuff. however, from what i've read, and the licensing, i'm not interested in it. however, i don't think this was mathcad's fault. i just got confused from the get go and happened to be getting numbers that looked right (that aspect may be mathcad's fault though). i am updating the files with the correct formula (that you explained).
as for what i've been seeing in testing. i think there might be several things going on. i basically can run 1.0d5 on any code and it's fast. i've been using that for decades. i have 16gb of memory and that seems to be pretty close to 1.0d5 (maybe just a coincidence, but I'm starting to wonder if that's significant). depending on the code, the limit i'm hitting is 1.0d6, 1.0d7, or 2.0d8. I think the last one might be with allocatable arrays. not 100% sure, at the moment. in any event, they are all below the 32gb limit. i tried increasing the page file but it didn't seem to do anything. i'm wondering if i actually had 64gb of memory, maybe all this would be a lot different. as it stands, 1.0d5 runs as expected. if i do nothing but switch to allocatable arrays it slows down. so the gflops are lower than they should be. that's all i know at the moment. i'll post more on the other thread, if i find out anything useful.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
Mupad was a nice product and, although there were problems with the transition, Mathcad could have done a lot worse in its choice of symbolic engine. Of course, since version 14 of Mathcad was released the owners of this symbolic engine, Sciface Software, were completely bought out by MATLAB makers, The Mathworks, and now The Mathworks use Mupad as the basis for their symbolic toolbox.
I bought Mathcad a couple of years ago because I could not afford Mathematica or Maple. I even bought a couple of the extensions. I did some good work with it, and found its conceptual model of an integrated workspace based upon an extended sheet of paper intriguing. I developed some facility with its expression language.
All I can say is this: There are a number of free and commercial products with superior functionality to MathCAD. My sadness is that MC was a great program in the early 90s that has been left to wither.
I too have looked at Maxima as an alternative and it does not stack up so favorably. The learning curve is a lot steeper and there is not a similar notebook interface that can be used to make a pretty document you can show your boss.
I believe I am saying: Mathcad is losing it stand in the mathematical position in the marketplace. The EASE of working in the Mathcad 6 Pro environment way exceeds what the later environments. PTC especially destroyed the close working relationship we had with Mathcad 6 (and earlier) application and programming engineers.
In my opinion it may already be too late, the current user base may not be enough to re-build the product, and the new version may turn away people who like the older Mathcad technology. However, if the product is powerful enough and priced right, it could very well create a new golden time for Mathcad.
-Since writing this post I now disagree with some of my own points on why anyone would use it. Mathcad users have told me why THEY use it and the penny finally dropped for me. It is still one of my least favourite mathematical products but my views are nowhere near as strong as they were when I originally wrote the above post.
Upgrades.
I work in IT too and part of my job is to deploy Mathcad to Manchester University. The part of me that deploys Mathcad hates upgrades because it makes more work for me. However, the part of me that supports the use of mathematical software for our academics tells me that upgrades are important. When you have enough users of any product, they will ask for new features and Mathcad is no exception.
New hardware (multicore processors for example), the latest operating systema (eg win7), new functions and new algorithms for existing functions. When someone publishes a superfast new algorithm for performing in a major journal, you can bet your bottom dollar that someone will be asking if it can be implemented in . All this stuff needs upgrades.
Of the users I know of at our site, _most_ of them are mathematically unsophisticated, they use Mathcad because it is easy to use and not because it is powerful. Note that I said MOST and not ALL. There are always exceptions.
With all of that said, I am glad that PTC are doing something positive with the product and I am genuinely looking forward to Mathcad Prime being released. I liked what I saw at the virtual conference and hope that they can develop it into a full and powerful product. Ease of use is fine but, for my money at least, it has to have power behind it.
I also use it to teach computational physics. Some of my students entering that class are computer savvy, but others are not at all. Mathcad is much easier to teach and to learn than any other package.
I am in Lodz, Poland, at this time of writing. I surprised myself that using a Polish compmuter seems to work. Many proper English spellings are underlined as improper Polish words, so this causes me to warn you, the reader, of unintended misspellings.
I have tried using higher than Mathcad Pro 6 for some past more than 15 years. All later versions have unnecessary complicated rules for entering plain, everyday mathematical formulas. Mathcad Pro 6 with a and e extensions has served me very, very well into the the startingly foundations of the Nature of the Universe, NOU. So far, I have come to mathematical no-theory solutions to presently known questions of other persons wondering what TOE, the Theory of Everything, is about. ALL with unadulterated Mathcad Pro 6!! These proofs are on my computer in the US. I will be returning the end of August.
c80f0f1006