Slashdot Mirror

- COBOL is mathematically accurate out to 38 decimals, something no other language was built to do or can do

Bull-fucking-shit.

When Alpha was introduced they laid out thirty years of growth for the platform, primarily because they designed for the long run. When HP was replacing Alpha with Itanium, they had to suppress Alpha benchmarks because it made their 'enterprise' chip look like the garbage that it was

FWIW all RISC chips sucked at integer division, to quote:
"When integer multiplication is cheaper than integer division, it is beneficial to substitute a multiplication for a division."
https://gmplib.org/~tege/divcn...

The main reason not to join ACM is that they spam the hell out of their members (and even prospective members and former members). Here are just some examples of recent complaints from computing professionals:

• ACM spam (Torbjorn Granlund)
• ACM membership spam just keeps coming (David Fries)
• The ACM may be violating the CAN-SPAM Act (Wesley Tansey)

I have never been a member of ACM myself, but my e-mail addresses are (or were, the last time I checked) regularly bombarded by their solicitations. Now everything from them just goes straight to the bit bucket.

http://gmplib.org/

Putting into perspective just how fast 10gbps is from the perspective of a single user, in the time it takes the fastest Intel-architecture AMD64 CPU money can buy today to test a single byte already in a register and determine whether its value is zero or nonzero, an entire byte or more would fly by on the 10gbps wire.

I think you lost something in conversion there. 10gbps is 1.25GBps. Today's fastest Intel Desktop processors have 12 threads all running at 4GHz+ (My desktop is running 4.5GHz). Assuming you aren't using any of the fancy (faster) SIMD instructions and doing a simple test r,0 instruction at the byte level (actually it can do 4 bytes/32-bit words at a time, but I'm not counting that), Sandy Bridge processors can cache, decode, issue, execute, complete and sustain 3 of those per cycle per thread. Reference: http://gmplib.org/~tege/x86-timing.pdf

4.5(GHz)*3*12/1.25(GBps)=129.6. Desktop processors are capable of doing this 129.6 times faster than needed to do what you supposed, not even using the faster SIMD/SSE/AVX instruction sets which optimized for such things. No fancy logarithms needed either.

I used the GMP. It includes an isprime() function. I've been meaning to install it on my computer, and the assertion by sexconker gave me the motivation to actually do it. It just took a simple decrement by two and test for primality loop.

I guess that there is some good news in this article. The patent hasn't been issued yet, it is only being reviewed right now. And this review is accomplishing what it is meant to: showing that the patent claim is ridiculous.

Wrong: according to this, the patent has been issued April 21, 2009.

BTW, the GMP mailing list discussion can be read here and here.

I guess that there is some good news in this article. The patent hasn't been issued yet, it is only being reviewed right now. And this review is accomplishing what it is meant to: showing that the patent claim is ridiculous.

Wrong: according to this, the patent has been issued April 21, 2009.

BTW, the GMP mailing list discussion can be read here and here.

...here and here.

...here and here.

Processor register width has nothing to do with math accuracy. If you need more accuracy you use a math library.

Gosh, my 6502 only has 8 bit registers, so I must have been dreaming about doing floating point 30 years ago.

Boo hoo, my x86 CPU is 32 bit and when I use long double variables it explodes with confusion.

Want a billion digits of accuracy, regardless of register width?

http://gmplib.org/pi-with-gmp.html

The mpz module in the LGPL library GMP (not to be confused with a bitmap image editor) does arithmetic on large integers, and its mpq module represents rational numbers exactly as ratios of mpz integers. For example, 3.14 would become "157/50".

For example, if I have to reference data structure by pointers, then off by one means I reference the wrong data. If the wrong data is expected to contain a pointer, then it will be totally wrong and I get segmentation fault. If I write a for loop for (i = 0; i lt; n; i++) {...}, and the least significant bit is ignored, then the for loop never makes progress (and never terminates). If i is only successfully incremented 50% of the time, then the for loop runs twice as much as it needs to run. Suppose you are copying files with region indexed by i, you may copy the same region multiple times. How is that faster and more efficient?

Sacrificing accuracy is so far only applicable for floating point computation, and in many cases this sacrifice has already been made. Some hardware lacks IEEE 754 rounding, and I don't think most people would notice that. Most people just use a double or even long double, which seem to provide satisfactory numeric accuracy for most purposes, and don't bother with error analysis of their code.

Last point, if you're going to write a banking system, please under no circumstance use floating point to represent balances. Use an arbitrary precision integer library such as GMP, which works similar to representing each number as a string with arbitrary length but is implemented in a more compact binary format.

That being said, implementing a non-standard data type that has precision FAR beyond the standard ones is relatively easy. (Think high-school level)

Or just use an existing library like GNU MP Bignum Library:

GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface.

The program Sage http://sagemath.org/ mentioned in the article uses Python extensively, but with a few changes when used interactively. In particular, all floating point literals are created as Python objects that wrap MPFR C-library objects http://www.mpfr.org/ which have better semantics. In particular, your example above in Sage becomes:

sage: 1.00 - 0.01
0.990000000000000

Likewise, in Python one has the confusing (to a mathematician):

>>> 1/3
0

In Sage integer literals wrap GMP integers http://gmplib.org/ (which are vastly faster than Python's large integers), and one has:

sage: 1/3
1/3

  -- William, http://wstein.org/ (author of the article being discussed)