Browseruk

No "Expectations". I get what the FEA produces. Once it gets beyond the 7th harmonic, their effect on the total equation (be it torque, power or efficiency losses) becomes marginal. For an extreme upper limit of physical rpm, say 400, that equates to an upper limit of 1.68e5. If the harmonics are electrical degrees related, it could be 3x higher.

Maybe this (From the link uncool posted above) refutes that?

Should read "Having just tried 3e-2".

Really. Is that what that lot says? I never would have guessed. Heck, even now I don't have to guess, I'm still having trouble deriving that meaning from those words Note: I'm using a limit of 1e-3 rather than the 1e-2 you advised. Primarily because it gives an exact answer for one of my real values C:\test>rational -F=1.70834275 6833371 / 4000000 rather than C:\test>rational -F=1.70834275 41 / 24 Having just tried 3e-3 also get the exact answer. Maybe the thing to do is pass the limit as an argument. I could also split the routine into two, returning the terms from the first and passing them to the second, so that the calling code can decide how many terms to calculate. I need to play with some more real values and see what falls out.

No takers? Bad question? Too involved?

That helps a little, but not enough. Yeah. Early version; but enough to get a feel for the performance. Thanks. That's the cluebat I was hoping for. This still barely tested code seems to work reasonably well: sub rational{ my @a = int( my( $x ) = shift ); { my $e = ( $x - int( $x ) ); last unless $e > 1e-3; push @a, int( $x = 1.0 / $e ); redo; } my( $n, $d ) = ( 1, pop @a ); $n += $d * $_, ( $n, $d ) = ( $d, $n ) for reverse @a; ( $n, $d ) = ( $d, $n ); return $n, $d; } A few examples@ C:\test>rational -N=21 -D=20 21 / 20 C:\test>rational -N=23 -D=19 23 / 19 C:\test>rational -N=101 -D=97 101 / 97 C:\test>rational -N=101 -D=97.1 1010 / 971 C:\test>rational -N=101 -D=97.01 10100 / 9701 C:\test>rational -N=101 -D=97.000001 101 / 97 C:\test>rational -N=101 -D=97.001 101000 / 97001 C:\test>rational -N=101 -D=97.0001 1010000 / 970001 C:\test>rational -N=101 -D=97.00001 7.04919182283353e+185 / 6.77001660699773e+185 C:\test>rational -N=101 -D=97.000001 101 / 97 C:\test>rational -F=1.70834275 6833371 / 4000000 C:\test>rational -F=1.60759143 3.15561131237261e+181 / 1.96294360213939e+181 Thanks a lot.

The values I receive are the output from a magneto-static analysis. I get them in the form of IEEE754 64-bit floating point values. they are all between 1 and 2 (not inclusive). Visually inspecting the data, I notice some of the values corresponded to the division of two relatively small integers; and that leads me to suspect that possibly all the values are such. (harmonics); but I need to prove it. So I knocked up an iterative solution: sub improper(@) { my( $n, $x, $i, $f ) = ( 1, shift, 0, 1e9 ); do{ ++$n; $i = int( $n * $x ); $f = $n * $x - $i; } until abs( $f ) < 1e-9; return $i, $n } And used it to produce a table of all the 3 decimal place fractions 1<x<2; diacarding those where the divisor was 1000; and came up with a table of just over 600 pairings: 1.001: 33033 33000 1.002: 501 500 1.003: 33099 33000 1.004: 251 250 1.005: 4221 4200 1.006: 503 500 1.007: 17119 17000 1.008: 126 125 1.009: 17153 17000 1.010: 101 100 1.011: 17187 17000 1.012: 253 250 1.013: 9117 9000 1.014: 507 500 1.015: 2233 2200 1.016: 127 125 1.017: 9153 9000 1.018: 509 500 1.019: 9171 9000 1.020: 51 50 ... 1.975: 79 40 1.976: 247 125 1.978: 989 500 1.980: 99 50 1.982: 991 500 1.984: 248 125 1.985: 397 200 1.986: 993 500 1.988: 497 250 1.990: 199 100 1.992: 249 125 1.994: 997 500 1.995: 399 200 1.996: 499 250 1.998: 999 500 But that takes 0.5 second for 3 decimal digit producing 607 integer pairings; and 45 seconds for 4 decimal digits producing 6230 integer pairings. ~450 seconds for 5 dps and ~60,000 solutions. The trend is fairly clear. IEEE supports ~15 dps, so producing a table would take a lifetime and more storage than exists (guess! :), so I was hoping for a non-iterative, or possibly a less iterative. Knowing that gcd() can be programmed to converge very quickly, I looked to see if that could help and came across the formula's section of wikipedia's lcm() page:wikipedia's lcm() page and thought that there was a possibility in there somewhere, but since that math is over my head, I asked here.

But what if the value I get is 1.2105263157894736842105263157895? (23/19) Yes. That' s what I was indicating with "multiple [sic]"; but there can only be one that cannot be reduced by a common factor.

Sorry, I thought I made my point clear when I wrote: Given an improper fraction (as a decimal value)(eg.1.05) how can I derive the smallest pairing of integers A / B (eg. 21/20 ) that produce that value?

My (overlong?) title describes the problem completely; my question is how? I realise that there can be multiple [sic] answers; I'm after the smallest integers that produce c. eg. Given 1.05; A/B = 21/20.

The following image shows a set of points (A,,B,C,p) rotated (in this example 360/21°) anticlockwise around the origin o. The resultant set of points (A', B', C') are then rotated clockwise (18°) around the resultant point p'. My goal is to derive a single centre of rotation that will rotate the set of points [A,B,C] to [A' ',B' ', C' '], given only the position of p, and the two rotations: Graphically, by projecting normals to the centres of the lines A-A' ', B-B' ', C-C' ', (also p-p' '), where they cross at point r, gives me the center of a single rotation I seek. Question: how to do that mathematically given only: p = (7.160299318411282, 0) rotation1 = -360/21° & rotation2 = 18°? Caveat: The above procedure does not work for all combinations of two rotations. Eg. In the next image p = (50,0) and the rotations are (-45° & +45°); which results in the normals to the bisectors all being parallel! I know that affine transformation using homogeneous coordinates can be composed [https://en.wikipedia.org/wiki/Transformation_matrix#Composing_and_inverting_transformations], but I am stuck for how to utilise that here as in the environment in which I am doing this (LUA embedded in a FEA package), I only have two mechanisms available: rotation about a point and translation in the XY plane. Question2: Assuming that I get a solution to Q1 above, is my only option to deal with the Caveat case, to compare the angles of rotation and do something different if they are equal? Thanks.