Python Forum
Thread Rating:
  • 1 Vote(s) - 1 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Algrbra Package
#11
(Feb-06-2018, 04:22 PM)kmcollins Wrote: A 32-bit float, which is what Python uses,
Python uses 64 bits floats on most machines, see here.
#12
Python is moved to Github. Do you know all contributors and why you don't trust them? Also, Python has an arbitrary precision arithmetic. You can use the built-in decimal, mpmath and gmpy2 for that purpose. I have used gmpy2 to calculate numbers with more than 3 million digits.
"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."
https://freedns.afraid.org
#13
I'll look into those. But exact math with 20 significant digits that I control because I wrote it is good enough for all of the cases I can think of.

One of the reasons I started this project is that I was getting math errors in the 10th significant digit, i.e. the rightmost one if ten digits actually were significant.
The documentation that Gribouillis links to claims it is not possible to represent a base ten number in binary:
"Unfortunately, most decimal fractions cannot be represented exactly as binary fractions. A consequence is that, in general, the decimal floating-point numbers you enter are only approximated by the binary floating-point numbers actually stored in the machine."
Wrong (not trustable). Any number of 32-bit ints can be strung together to represent the number and one signed 32-bit in the base 8 exponent, giving you exact representation with arbitrary precision (which decimal's documentation claims to accomplish).
#14
(Feb-06-2018, 09:54 PM)kmcollins Wrote: Wrong (not trustable).
If you claim that the Python docs are not trustable, then you probably shouldn't use Python to ensure correctness where you're concerned about relying on others.

That aside, it is well-known that not all fractions have "exact representation" in all bases, e.g. 1/3 represented as 0.3. Why should anyone trust you when you say this? You assert that the Python docs are wrong, and then state something that seems evidently wrong (that is, wrong without any needing to assert it on their reputation).
#15
Floating point decimal number cannot be represented as a binary number with the same precision and you should know that. It's not about Python. It's mathematics. This is what they said in the documentation.

If you think that way, not to trust anybody because you know that they can be wrong, sometimes deliberately, you should start with the machinery you are using to code. How can you tell that the CPU transistors circuit math logic is giving you the right answer for calculus?

You can check if the modules are working correctly if you do the same math with all of them. But then you can say that maybe there is something wrong with Python. I don't know.

How you even trust your eyes when you watch a magician? We cannot trust ourselves. Think about it.

Are you willing to share your math module?
"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."
https://freedns.afraid.org
#16
wavic,

Wrong. Read the documentation for the python package decimal. Here's the intro:

"The decimal module provides support for decimal floating point arithmetic. It offers several advantages over the float datatype:

Decimal “is based on a floating-point model which was designed with people in mind, and necessarily has a paramount guiding principle – computers must provide an arithmetic that works in the same way as the arithmetic that people learn at school.” – excerpt from the decimal arithmetic specification.

Decimal numbers can be represented exactly. In contrast, numbers like 1.1 and 2.2 do not have exact representations in binary floating point. End users typically would not expect 1.1 + 2.2 to display as 3.3000000000000003 as it does with binary floating point.

The exactness carries over into arithmetic. In decimal floating point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero. In binary floating point, the result is 5.5511151231257827e-017. While near to zero, the differences prevent reliable equality testing and differences can accumulate. For this reason, decimal is preferred in accounting applications which have strict equality invariants.

The decimal module incorporates a notion of significant places so that 1.30 + 1.20 is 2.50. The trailing zero is kept to indicate significance. This is the customary presentation for monetary applications. For multiplication, the “schoolbook” approach uses all the figures in the multiplicands. For instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600.

Unlike hardware based binary floating point, the decimal module has a user alterable precision (defaulting to 28 places) which can be as large as needed for a given problem:"
#17
(Feb-07-2018, 09:06 PM)kmcollins Wrote: Decimal numbers can be represented exactly.
The question is what does this mean exactly? The square root of 2 cannot be represented exactly by the decimal module,
nor any irrational number. Every system hat its limitations.
#18
Alright, let's play:
Quote:I am not handing out free code which is tested and ready to be stolen.
Not only is this completely antithetical to the entire Python atmosphere. It is just stupid. You are not writing anything novel. Everything you are trying to implement has already been implemented in wider used, better tested, open source code.
Quote:Numpy is a python wrapper around a C implementation of matrix math. That means it uses pointer math for speed. This is very easy for a virus to exploit. Your C professor didn't warn you about this?
This is one of the stupidest things I have ever seen written on this site, and you state it with such confidence.

All this aside, you are absolutely, unequivocally recreating the wheel. Assuming you implement everything perfectly, it has still already been done. Using whatever necessary combination of numpy, sympy, fraction, decimal, gympy, all of these things are available in well documented ways. Your claims that re-implementing it has anything to do with better security is laughable.

The only way a new library like this ever enters the ecosystem is if it is open-source and it is thoroughly tested, and even then it would need to offer something amazing to move people away from the already established solutions.

As to your negative reps, that is what happens when you respond with antagonistic informationally bad replies. If you care to stay with us and contribute these will go away over time.

I await your reasonable reply (for if it is anything other than I will lock the thread and simply ban you).
#19
The quoted text in the above post is the same reason i gave those posts neg rep. It was pertaining to the rudeness. You can disagree with someone without putting the person down. IF it was worse i would of given a warning, but because it was on the fence i just gave neg rep.
Recommended Tutorials:
#20
As part of my algebra package I just wrote a prime number sieve. I hereby place the following code ito the public domain:

    def primeNumbers(a):
        "return a list of prime numbers <= a using a sieve"
        if a == None or not isinstance(a, int) or a <= 1:
            return []
        sieve = []
        idx = 0
        while idx <= a:
            sieve.append(idx)
            idx += 1
        sieve[1]    = sieve[0]  = None
        prime = sieve[2]
        while prime <= a:
            multiplier = 2
            while prime*multiplier <= a:
                sieve[prime*multiplier] = None
                multiplier += 1
            start = prime+1
            while start <= a and sieve[start] == None:
                start += 1
            prime = start
        #print(str(sieve))
        primes = []
        idx = 2
        while idx < len(sieve):
            if sieve[idx] != None:
                primes.append(idx)
            idx += 1
        return tuple(primes)


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020