I am considering the preparation of a library of functions which would cover the arithmetic, trigonometric, hyperbolic, logarithmic, exponential and a few other operations on COMPLEX NUMBERS.
The flag parameter would indicate the size of the operand(s) (and result), allowing either SINGLE, DOUBLE or EXTENDED DOUBLE precision. The flag parameter would also indicate if operand(s) (and result) are in cartesian or polar coordinates. The operand(s) source and the result destination would also be indicated by the flag parameter as from/to the FPU or memory.
A detailed Help file (API style) would also be made available along with the source code of all the modules.
The library would not be intended for beginners in assembly. The user will need to be familiar with the management of the FPU registers to insure that the required number of registers are free before calling any of the functions.
This is a survey to find out if it is worth my time and effort to prepare such a library.
Raymond
Ray,
I understand that it is a lot of effort to develop functions of this type and do all the testing necessary but it would certainly be useful if such a library existed, especially if it was documented properly.
I think such a library would be useful, but it seems like you would be duplicating a lot of the functionality already available (well tested and reliable) in the CRTL.
Hi Raymond,
If I remeber well, a member from Harold's forum, infinie was working on a library for complex numbers.
I do remember someone else trying to prepare a library for complex numbers. However, some of the posted code was a nightmare: operands were only taken from memory and sometimes transferred directly on the stack, and other times their address was transferred on the stack. (When using the FPU, it's always more efficient to use data already in FPU registers whenever possible instead of always transferring to/from memory.)
Furthermore, his approach only allowed the use of 32-bit operands, limiting the versatility when more precision would be necessary.
Raymond
Quote from: hutch-- on January 27, 2005, 06:03:37 AM
Ray,
I understand that it is a lot of effort to develop functions of this type and do all the testing necessary but it would certainly be useful if such a library existed, especially if it was documented properly.
I second that :U
While developing my library of complex number functions, I needed something to test those functions. So, I whipped up this dialog box in the attached zip file to cover currently available functions.
If you are not familiar with complex numbers, some of the results may appear weird. If you have no knowledge of trigonometry, the result may appear even more weird.
If you think there may be errors in results, their report would be appreciated. Your contribution would also be appreciated if you think other functions may be useful.
This test box and its source file will be included in the ZLIB package when it is completed with the Help file.
Raymond
Edit: Corrected the test program after it was d/l once. The error was to accept negative numbers for the real coefficient of polar coordinates. Some functions were reporting an error and the result boxes were not being updated. When no error was reported, the displayed result would have been incorrect.
The modified version reverses a negative sign for the real coefficient of polar coordinates before feeding it to the function. If the source was z1, that edit control is also modified.
Edit2: Just before going to sleep, I realized that I had forgotten to do the same for the z2 source. The corrected test box is now attached.
[attachment deleted by admin]
Cool raymond, I lack the understanding of some of the math you are using in there. :red But it looks like a job well done so far.
The complex number library is completed. You can get it from:
http://www.ray.masmcode.com/index.html#znum
If you don't know what complex numbers are, the above link also includes a brief description of that "complex" subject.
Within the next few weeks, I will also make my fractal program available from the same link. I'm currently reworking its help file to reflect the use of threads in the revised program. (Fractal art makes extensive use of complex numbers.)
Enjoy
Raymond
Hey Raymond,
Great work. My only comment is to possibly correct for the use of negative numbers under Polar mode. I only peaked into your zmul source, but I notice you're using FABS to clean things up. Mathematically this is not the correct way of doing things:
-1<15 = -1 * e^j(15) = 1 * e^j(180) * e^j(15) = 1 * e^j(195) = 1<195
Your FABS operation basically is doing:
-1<15 = 1 * e^j(15) = 1<15 (Which is not correct!)
I notice in your sample program your also checking and cleaning up negative numbers before functions are applied. My personal thought is since you already have the routines written, so you should conver negative polar radius' to positive radius' as shown above. Likewise, another healthy check would be to convert polar angles greater than or equal to 360 degrees to its 0->359 deg equivalent (for best precision from FPU round off errors).
Anyways, Im still impressed with your handy work! I just thought I would add my 2 cents to make it better.
Regards,
:NaN:
Hi NaN
Thanks for the appreciation.
The only time that I would expect a negative real coefficient in polar coordinates is from user input. None of the functions would return such a negative coefficient. AFAIK, vectors should always be positive. You seem to be maintaining that the user could knowingly input a negative value for a vector along with the reverse angle. What would be a logical reason for that??
Or could a negative value be provided by some other computation (or generated by some instrument) which would thus need to be corrected appropriately??
If that is the case, how can it be differenciated from inadequate user input??
As for angles greater that 2*pi, none of the functions would return something greater. Again, could this be generated by some other computation?? And how often??
I know that complex numbers are used in scientific areas such as electricity. However, I am not familiar with any of the details of their use or generation. That's why I'm asking all those questions. There's no age limit for learning.
Raymond
Certainly glad to offer what I can.
I agree with you that most polar numbers have a positive value. However, my point is there is no mathematical definition that says there shouldnt be. Its more of a convention than a mathematical rule.
If i had a circuit that ran off a positive and negative voltage, say an amplifier, it would be rational to have vector quantities and phase angle in both +9V<30 and -9V<30. Phase shift is a result of non-linear devices in some combination (such as capacitors or inductors in combination with a resistance). So the same capacitor/resistor combination acting as a separate filter on both supply voltages *could* be expressed as shown above.
However, your point is also true. My negative voltages can be all expressed as 9V<210 instead of -9V<30. But to be honest, the latter is easier to realize its actually a negative quantity.
Anyways... Im not sugesting polar resultants should be expressed in negative quantities, just that the library be made as flexible as posible for negative inputs. I can kinda see this being one of those 'murfy's law' type bugs in someone's source that take 3 days to track down, and finally relize that the numbers are being artifically adjusted.
Regards,
:NaN:
Thanks NaN for the explanation.
I'll modify it and inadequate input from a user will have to live with the consequences of a corrected angle.
Raymond
Done.
Added a paragraph in the Design Philosophy of the Help file to explain how the functions handle negative vectors. Modified the version to 1.1
Also modified the test box to do the same thing as the functions.
Raymond
Nice work! :U
Quote from: raymond on February 16, 2005, 01:57:41 AM
... and inadequate input from a user will have to live with the consequences of a corrected angle.
Maybe im wrong, but im getting the feeling your upset with me? They are just suggestions. I can easily finishes the fixes for myself. Its no biggy for me...
As it stands now -1<0 * -1<0 * -1<0 = 1 < 3pi (which in theory is fine, but in practice decmal places will add up into FPU loss of accuracy). My latter suggestion to fix angles over 360 deg is still not really corrected for....
Sorry if all this offends you.
Regards,
:NaN:
NaN
I am far from being offended or upset by any comment related to the library. To the contrary, I am extremely pleased. I do want this library to be as useful as possible. The suggestion related to negative vectors was immediately included after a clear explanation was provided.
The only reason for adding the comment in my last post about inadequate input was simply a warning to potential users that such input would be modified as if it would be legitimate input.
I would be most interested in learning what would be the typical sequence of math operations on complex numbers in your field. It would help me define which functions may need to be altered to reduce the angle to the -pi to +pi range.
Many thanks for your interest
Raymond
raymond,
According to my FPU documentation, you don't have to worry about large trig function arguments, unless the absolute range of 0 to 2^63 is exceeded. If outside that range, one must subtract an integer multiple of 2*pi. Otherwise, the FPU will unwind the argument. One assumes it is smart enough to do that without sacrificing accuracy. It is most convenient if the inverse trig functions return their principal values, which are defined in any good math reference. That means the angle is between plus or minus pi radians depending on the function. Don't forget that hyperbolic functions have a periodicity too. For instance, sinh(x+2*k*pi*i) = sinh(x), where k is any integer. You don't want to compute with a large orthogonal number for accuracy's sake. Finally, it would be nice if there was a degree and grad mode (one hundred grads to a quarter) to complement the current radian mode. Ratch
I am not too concerned either about the functions which would require the conversion of polar coordinates to cartesian before applying other operations.
However, if the natural log of an unaltered complex number is computed, the size of the "angle" will have a definite effect on the result:
ln(r,t) = ln(r) + t
and converting the result back to polar, the new "t" would be: atan[t/ln(r)]
And atan[(t+2pi)/ln(r)] would not be the same. That's why I need some feedback from potential users.
Raymond
QuoteWithin the next few weeks, I will also make my fractal program available from the same link. I'm currently reworking its help file to reflect the use of threads in the revised program. (Fractal art makes extensive use of complex numbers.)
Since that posting, another thread on fractals was started by someone else. I have thus used that thread to indicate where my fractal program can be downloaded and will continue to use it for discussions related to it.
http://www.masmforum.com/simple/index.php?topic=866.0
Raymond
Raymond, your fractal program is awesome! And the executable is only 52k!?! :dazzled: If you use "UPX193b -9" on it, it can be further squeezed down to 17,920 bytes, maybe even smaller if POLINK were used!
QuoteRaymond, your fractal program is awesome! And the executable is only 52k!?!
Glad to hear you liked it. The size may be a bit misleading. One should remember that it is a "Windows" program and many APIs are used. If such a program with all its features (such as the auto-hide menu, movable dialog boxes, threads, etc. etc.) had to be written in the old DOS system, it would probably have had a 10-fold increase in size.
Raymond