Need help plotting a point in 3d space using 2 vector/origin sets.

[Sintrinsic]

Fist, this is for a personal project of mine, I've been out of school for some time, and all my old math skills seem to have abandoned me. For that reason, and because I have to translate anything I learn into functions compatible with c#'s math library, it'd probably be best to keep any answers as simple as possible. lol *sigh*

What I need to do, with absolute accuracy, is this:
1.) Create 2 almost normalized vectors originating from 2 predetermined corners of a cube, and with a common destination of a known(but randomly generated) point.
2.) Discard the original "target" point.
3.) Using only the newly defined vectors, "reconstitute" the original point from the imaginary intersection of the vectors.

The problem I'm facing:
1.) I need to save space without loosing accuracy, and I'd LIKE to find two vectors with integral x,y,z values. I could just adjust one axis to 1 and have my program incrementally cycle upward until the remaining axes become integral, but that could be very time consuming. I need a way to consistently find such an integral vector with a single function or set of functions. Points with a roughly limited number of decimal digits would also be acceptable, if the likelihood of purely integral points is too low.

The process I have so far, which only seems to work on perfectly diagonal points. lol If you can improve, simplify, or speed up (for a computer) any of this, feel free:
Vector = destination - origin
Unit Vector = (Vector/Sqrt(Add(Vector^2)))*100 << to give room for integral vector
Least Integral Vector = UnitVector/(Gcd(Abs(UnitVector)))
Intersect Point = Determinant({(Origin2-Origin1),Vector2,CrossProduct(Vector1, Vector2)}) / (CrossProduct(Vector1,Vector2)^2)

I wrote all of the above on Yacas, which has been wonderful for teaching myself math, ( http://yacas.sourceforge.net/homepage.html), but it's too slow to use in the final program, so I won't have the benefit of the pre-defined functions. Thanks a ton in advance, I've been wracking my brain for the last 12 hours on this, just today, and I think my brain may explode if I can't solve the problem.

 

[LCKurtz]

Let me see if I have the problem understood, because I don't see what the cube has to do with anything. You are given two points A and B (vertices on the cube, but so what?) and two vectors D_a and D_b pointing from A and B to a point P which you wish to determine. Is that what your problem boils down to, the intersection of two lines, or do I misunderstand?

 

[Sintrinsic]

Well, finding the intersection shouldn't be too hard, and my main issue is with finding vectors with suitable values. I need 100% precision in, say, < 5 digits total for each axis. As far as the re-creation of the point, though, you're correct. All I'll be doing is finding the intersection. The cube is necessary only as a bounding box for the potential position of the target point, and to increase the probability that my x,y,z cords will have a low-value integral point along the line. I assumed that if all three values are close to equal, it decreases the interval between integral values on each axis as the point progresses along the line, giving me a better chance of them all crossing .0 simultaneously. Is that faulty logic?

 

[LCKurtz]

I don't really follow the last couple lines of your explanation. But here's something that bothers me. If your given points and vectors aren't exact, I mean really exact, your two lines almost certainly won't intersect. They might just come close to each other so the equations you get using their parametric forms will be inconsistent.

 

[Sintrinsic]

That's true, especially given the size of my cube. However, I'm using an arbitrary precision library to do the math, and just to be safe, I'm not evaluating the fractions into decimals until I've established the integral vectors. That's actually the reason why I need the integral vectors in the first place; Unless I do it this way, or at least manage to consistently generate a vector with < a handful of decimal digits, I could potentially be handling variables with 100's of digits in total, which would limit my ability to work them, as converting to a <65bit number would reduce precision.

I don't really follow the last couple lines of your explanation.

I assumed that if all three values are close to equal, it decreases the interval between integral values on each axis as the point progresses along the line, giving me a better chance of them all crossing .0 simultaneously.

As I visualize it, if anyone axis of a vector differs too significantly in its ratio to the remaining axes, the number of potential integral intersections along the the "line" is drastically reduced. (1,150,3), for example, has a lower chance of yielding such a point than (2, 3, 4). Restricting a randomly generated point to the bounds of a cube allows me to select a set of origins from the 8 corners of the cube, in order to create a vector with as close to a 1:1:1 ratio as possible.