Posts by D337z
log in
1) Message boards : Science : Possible proof (Message 13704)
Posted 2125 days ago by D337z
Look, here's the simple proof.
etc. to infinity
Now, taking that into account, all that is required is a point where an odd number*3+1 intersects with the above statements of 2^x. Given that there are infinite chances for this to occur and that only whole numbers are used, intersection is eventual.
Understand how my infinity theory works now? When you multiply by infinity, the statement becomes both true and false at the same time depending upon the precise point that you're at. For example, if this equation were multiplied by pi, it would be false. However, multiplying it by a simple 1 makes it true.
Knowing that infinity is both a whole number and a partial number as well as an imaginary number, our goal is defined to not show that any whole number can be used to reach 1 at infinity, but that any whole number can be used to reach 1 period. And it's a simple equation as well. Just look for where the points intersect and plot them. Think more along the lines of x and y.
2^x and odd(y)*3+1 You'll find that these intersects can be found at various points approaching infinity.
2) Message boards : Science : Possible proof (Message 13699)
Posted 2126 days ago by D337z
So the question is, how do we prove something true or false when there are infinite numbers to test? In this way, the flat world was "good enough." Are we taking that approach to this algorithm as well?
3) Message boards : Science : Possible proof (Message 13586)
Posted 2152 days ago by D337z
So, has anyone stopped to consider that, with infinite numbers fueling the algorithm, the algorithm has no choice but to reach 1 at some point? Even if you flipped a coin an infinite number of times, the percentage of heads vs. tails would most likely reach 1% of one or the other eventually. Bearing that in mind, it becomes quantum mathematics because it can not be proven true or false due to infinite possibilities and variables. We assume that anything that can happen will happen in an infinite environment.
So, perhaps your proof is the infinite environment in which your algorithm takes place?
4) Message boards : Windows : OpenCL Application (Message 13585)
Posted 2152 days ago by D337z
Do you have the actual script that I can look at to see if I can speed it up some?
5) Message boards : Windows : Collatz Conjecture OpenCL kernel causes crash with minimum settings. (Message 13560)
Posted 2157 days ago by D337z
If you have the OpenCL script, I can toss it into the kernel analyzer and figure out where the hiccup is and see if I can iron out some of the kinks to make it work faster than your brook+ app.
But that's up to you.
6) Message boards : Windows : Collatz Conjecture OpenCL kernel causes crash with minimum settings. (Message 13555)
Posted 2158 days ago by D337z
Yes, I ran the batch file.
Also, I program in OpenCL, so I can tell you first hand that if your OpenCL kernel runs slower than your Brook+ app or doesn't run in the first place, you're either using depreciated logic or have a few optimizations that need to be made.
The problem with programming for VLIW and GCN architectures is they are fundamental opposites. While VLIW has 5 ALUs that can handle multiple different instructions, GCN has 16 that handle fewer instructions (I think [I haven't programmed for the 7xxx series yet]). But yeah, what OpenCL version does your OpenCL kernel specify that it uses?
7) Message boards : Windows : Collatz Conjecture OpenCL kernel causes crash with minimum settings. (Message 13547)
Posted 2159 days ago by D337z
Hello all! I just wanted to let you know that I've tested the OpenCL kernel for Collatz Conjecture and it caused a driver crash. You might want to go back and look over the code or have the OpenCL file separate so that the ATI SDK can run it without having to pull it out of the exe. Granted, this exposes the code to modification or viewing, but it will be far easier to update and correct any problems. Just have the OpenCL code output to the exe and it should be fine.
Theoretically, you don't even need to use CPU if you load the values into the program initially and allow the GPU to do all of the work. It should be able to handle it on its own. But I'm just working off of theory since I can't see the code.
From what I've seen, utilizing 4 and 5 vectors via VLIW based hardware (depending on what GPU you use) should be default as nothing exists that can run OpenCL and can't handle those vectors.
Remember, when utilizing more than 4 vectors, that the vectors are addressed utilizing .s0, .s1, .s2...
It'll be tricky to code, but not impossible. I think the 79xx series can handle 16 vectors, but don't quote me on that.
I'll leave the rest up to you. But I wouldn't mind having something to play around with on my spare time. ^_^

Main page · Your account · Message boards

Copyright © 2018 Jon Sonntag; All rights reserved.