Ohm's Law Calculator

[The Buzzard]

Hello to All,

 

I finally finished this Ohm's Law Calculator and I seem to be pleased with the results, However the program size has me bothered. When using vector image on more complex entities such as circles and text, It creates much larger than expected lists. I tried to duplicate the image with MSLIDE, But I have no control over the image size that way and cannot duplicate the same results as vector image.

 

Anyway, I am posting it just the same for feed back.

 

For loading instructions, See this link: http://www.cadtutor.net/forum/showthread.php?1390-How-to-use-the-LISP-routines-in-this-archive

 

Revision List:

                                   *Revisions*
 Date      Change                                              Program     By
 06/12/09  Reduce program size by vector_image modification    OLCv2.lsp   AMB
 06/13/09  Add Divide by zero error function                   OLCv3.lsp   AMB
 06/13/09  Program now calculates remaining two values         OLCv3.lsp   AMB
 06/13/09  Remove Mode Tile Function                           OLCv3.lsp   AMB
 06/14/09  Add Imaginary Number calcs to square root           OLCv4.lsp   LM
 06/14/09  Program remembers last formula selection            OLCv4.lsp   AMB
 06/16/09  Remove OLC_DCO Output Function                      OLCv5.lsp   CAB
 06/16/09  Consolidate OLC_CAI & OLC_DCO functions             OLCv5.lsp   CAB
 06/16/09  Remove all redundant programming                    OLCv5.lsp   CAB
 06/16/09  Improved variable localization                      OLCv5.lsp   CAB
 06/16/09  Improved programming for input errors               OLCv5.lsp   CAB
 06/16/09  Added OLC_T2N Error Function                        OLCv5.lsp   CAB
 06/16/09  Modified OLC_RAC Reset Function                     OLCv5.lsp   CAB

 

VERSION 2 POSTED 06/12/09

VERSION 3 POSTED 06/13/09

VERSION 4 POSTED 06/14/09

VERSION 5 POSTED 06/16/09

 

I would like to express my thanks to the following individuals for their help and suggestions. A big thanks to Lee Mac, CAB, SEANT, David Bethel.

From their contributions to this thread I was able to complete this program. I cannot say enough about these wonderful people that are always ready willing and able to give their time. It is my hope that others will find this program useful from a practical purpose or as a learning model.

 

Please enjoy the program,

The Buzzard

OLCv5.zip

Edited July 20, 2010 by The Buzzard
Revision 5

[Lee Mac]

Woww... haven't tried the code just yet, but just looking at the LISP: So Many Numbers....you sure do love your vector images.

 

If the posted pic is anything to go by, then superb work Buzzard

 

Lee

[The Buzzard]

Woww... haven't tried the code just yet, but just looking at the LISP: So Many Numbers....you sure do love your vector images.

 

If the posted pic is anything to go by, then superb work Buzzard

 

Lee

 

Thank you Lee,

 

I do like the fact that I do not have to deal with slides when it comes to vector image. The size of the program without using it is next to nothing as compared to putting the image in. Just does not seem worth it. MSLIDE is a real pain in another sense.

 

Anyway the program works well.

[CAB]

Your DCL is a thing of beauty!

 

I would approach the lisp & vector coding a bit differently, but it gets the job done.

[The Buzzard]

Your DCL is a thing of beauty!

 

I would approach the lisp & vector coding a bit differently, but it gets the job done.

 

Thanks CAB,

 

What would you suggest in terms of a different approach?

[CAB]

For the vectors I would separate the circle/background into one list and make each cell

into separate list. In this way you can feed the list to the vector_image with each group

and just change the color for the group you want to use red on.

 

For the operation of the user entry I would have a CLEAR button that blanked all 4 edit boxes.

Then the action would react to the ENTER key. If there was only one value entered, do nothing.

If there were two values entered & would solve for the two missing values.

That's just my approach. Nothing wrong with yours.

 

 

PS You could turn two formula red to match the results.

[The Buzzard]

For the vectors I would separate the circle/background into one list and make each cell

into separate list. In this way you can feed the list to the vector_image with each group

and just change the color for the group you want to use red on.

 

For the operation of the user entry I would have a CLEAR button that blanked all 4 edit boxes.

Then the action would react to the ENTER key. If there was only one value entered, do nothing.

If there were two values entered & would solve for the two missing values.

That's just my approach. Nothing wrong with yours.

 

 

PS You could turn two formula red to match the results.

 

I think I know what you mean. I would have to mess with it a bit to get the feel for it, But that make so much sense.

 

I will give that a shot and see what happens.

 

Thanks for the advise.

[The Buzzard]

I think I know what you mean. I would have to mess with it a bit to get the feel for it, But that make so much sense.

 

I will give that a shot and see what happens.

 

Thanks for the advise.

 

CAB,

 

I did a test using the wheel with the text as the base image. Then I use only the selected red text for each selected image as the conditionals and seems to work well. I just need to finish it off. Will post the new version over the weekend.

 

With regard to the program operation, I would need to study that much further.

 

Great Tip on the images, That will reduce the program size dramatically.

 

Thanks again,

The Buzzard

[The Buzzard]

CAB,

 

I did a test using the wheel with the text as the base image. Then I use only the selected red text for each selected image as the conditionals and seems to work well. I just need to finish it off. Will post the new version over the weekend.

 

With regard to the program operation, I would need to study that much further.

 

Great Tip on the images, That will reduce the program size dramatically.

 

Thanks again,

The Buzzard

 

Attention to All,

 

CAB introduced to me a fix for the vector image eliminating the image redundancy and thus producing a much smaller program.

 

The programs original size was 582KB reduced down to 119KB.

What a major difference that is.

 

The revised files have been uploaded to the first post, So you can get the program there.

 

Thank You CAB and to All Enjoy!

The Buzzard

[Lee Mac]

Very nice Buzzard, just been playing around with it

 

I love that dialog image, superb illustration - and many thanks for the mention in the "About" dialog - I feel honoured

 

1 thing you might want to consider though, perhaps include a line of code to account for divide by zero errors with perhaps an error tile to notify the user if they enter, for example, 0 Ohms in formula 1.

 

Just a thought

 

Lee

[The Buzzard]

Very nice Buzzard, just been playing around with it

 

I love that dialog image, superb illustration - and many thanks for the mention in the "About" dialog - I feel honoured

 

1 thing you might want to consider though, perhaps include a line of code to account for divide by zero errors with perhaps an error tile to notify the user if they enter, for example, 0 Ohms in formula 1.

 

Just a thought

 

Lee

 

Thanks Lee,

I thought about something like that which is why if you notice I have the program default to 1's. It will still not prevent the user from entering arbitrary values though. An error alert would be good for that reason. I was also thinking about having the program put in the other two values as CAB had mentioned, But I would need to toy around with that.

 

By the way did you download the latest fix? I had reduced the program size by adjusting the vector image so it works the same way without all the redundancy of the same image in each frame. The program came down from 582KB to 119KB from that fix alone.

 

I will be trying a few things with it over the weekend to see how much better I can improve it. The only reason I took this one on was that there were no threads in this forum with regard to the subject. As far as I know this is the only Ohm's Law Calculator on CADTutor. I just figured it would be worth while since it was not too involved to make.

 

Anyway I will work on the fix you mentioned over the weekend. I want to take a break from Lisp for a few hours.

 

Catch you then,

The Buzzard

[Lee Mac]

Thanks Lee,

I thought about something like that which is why if you notice I have the program default to 1's. It will still not prevent the user from entering arbitrary values though. An error alert would be good for that reason. I was also thinking about having the program put in the other two values as CAB had mentioned, But I would need to toy around with that.

 

By the way did you download the latest fix? I had reduced the program size by adjusting the vector image so it works the same way without all the redundancy of the same image in each frame. The program came down from 582KB to 119KB from that fix alone.

 

I will be trying a few things with it over the weekend to see how much better I can improve it. The only reason I took this one on was that there were no threads in this forum with regard to the subject. As far as I know this is the only Ohm's Law Calculator on CADTutor. I just figured it would be worth while since it was not too involved to make.

 

Anyway I will work on the fix you mentioned over the weekend. I want to take a break from Lisp for a few hours.

 

Catch you then,

The Buzzard

 

Hey, no rush mate - just a minor thing.

 

Yes, I used the latest fix - much neater in its condensed form.

 

Perhaps you don't need that much elaborate coding to check for things like that, just a "vl-catch-all-apply" check would be sufficient if you didn't want to check for zeros where they shouldn't be.

[The Buzzard]

Hey, no rush mate - just a minor thing.

 

Yes, I used the latest fix - much neater in its condensed form.

 

Perhaps you don't need that much elaborate coding to check for things like that, just a "vl-catch-all-apply" check would be sufficient if you didn't want to check for zeros where they shouldn't be.

 

Not sure as how to use that since I have not taken the time to learn VL.

I am sure I can go a different way to get a good result.

 

Thanks for the feedback.

[SEANT]

I’ll also take the opportunity to say nicely done. Very slick UI.

 

This thread’s subject matter and some recent posts in the chat section have caused me to wonder what level of support any of the programming languages have for complex numbers.

 

Fortran and C++ seem to have the intrinsic support. I couldn’t find evidence that any of the other languages, including the modern .Nets, have native support. Fortunately, it doesn’t appear terribly difficult to create a custom package for Complex Number data and operations.

[The Buzzard]

I’ll also take the opportunity to say nicely done. Very slick UI.

 

This thread’s subject matter and some recent posts in the chat section have caused me to wonder what level of support any of the programming languages have for complex numbers.

 

Fortran and C++ seem to have the intrinsic support. I couldn’t find evidence that any of the other languages, including the modern .Nets, have native support. Fortunately, it doesn’t appear terribly difficult to create a custom package for Complex Number data and operations.

 

Thank You SEANT,

I am still making improvements on it. I will post shortly.

[The Buzzard]

Attention to All,

 

Version 3 of the Ohm's Law Calculator has been posted on the first post of this thread. See post 1 for details.

 

CAB,

Took your advise and figured it out with no problems. I have the program calculating the remaining two values now. Code seems to work well the way you had mentioned.

 

Lee,

Made the fixes for the Error: Divide by zero. I added a function for this. Let me know if you find anything else.

 

Thanks,

The Buzzard

[The Buzzard]

Note: A compiled version FAS & VLX have now been added to the first post as well.

[CAB]

Too late here but just a quicky.

 

This is another way to write this function and I used 4 different methods to test SNF:

Same principal though, only one condition will be true so a COND statement will handle it.

 

(defun OLC_DCO ()                                                              ;Define function
 (cond
   ((vl-string-position (ascii SFN) "123") ; one way to test
     (setq P (RTOS P 2 1))                                               ;Set P ~ (Power), Return to string, Decimal, 1 zero
     (set_tile "ANS" (strcat "Power = " P " watt(s)"))                   ;Set tile ANS, Concatenate string, evaluate P
   )
   ((member SFN '("4" "5" "6")) ; another way to test
    (setq I (RTOS I 2 1))                                                    ;Set I ~ (Current), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Current = " I " amp(s)"))
   )
   ((vl-string-search SFN "789") ; another way to test
    (setq E (RTOS E 2 1))                                               ;Set E ~ (Voltage), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Voltage = " E " volt(s)"))                 ;Set tile ANS, Concatenate string, evaluate E
   )
   ((vl-position SFN '("10" "11" "12")) ; another way to test
    (setq R (RTOS R 2 1))                                               ;Set R ~ (Resistance), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Resistance = " R " ohm(s)"))               ;Set tile ANS, Concatenate string, evaluate R
   )
  )
)

And yet another method.

 

 

 

(defun OLC_DCO (/ lst data) 
 (setq lst '(("Power = " P " watt(s)")
             ("Current = " I " amp(s)")
             ("Voltage = " E " volt(s)")
             ("Resistance = " R " ohm(s)")))
 (setq data (nth (fix(/ (1- (atoi SNF)) 3)) lst))
 (set (cadr data) (rtos (eval id) 2 1))
 (set_tile "ANS" (strcat (car data)(eval id)(caddr data)))
)

Note the switching values in a variable like 'R' from a string to a real and back to a string is bad practice

and very confusing during debugging & updating a routine. I did not change that in my examples though.

Also global variables is bad as well. Not always avoidable but you should try to localise them.

 

 

That's all for tonight. PS not tested!

 

 

 

Off for some tennis....

[The Buzzard]

Too late here but just a quicky.

 

This is another way to write this function and I used 4 different methods to test SNF:

 

(defun OLC_DCO ()                                                              ;Define function
 (cond
   ((vl-string-position (ascii SFN) "123") ; one way to test
     (setq P (RTOS P 2 1))                                               ;Set P ~ (Power), Return to string, Decimal, 1 zero
     (set_tile "ANS" (strcat "Power = " P " watt(s)"))                   ;Set tile ANS, Concatenate string, evaluate P
   )
   ((member SFN '("4" "5" "6")) ; another way to test
    (setq I (RTOS I 2 1))                                                    ;Set I ~ (Current), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Current = " I " amp(s)"))
   )
   ((vl-string-search SFN "789") ; another way to test
    (setq E (RTOS E 2 1))                                               ;Set E ~ (Voltage), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Voltage = " E " volt(s)"))                 ;Set tile ANS, Concatenate string, evaluate E
   )
   ((vl-position SFN '("10" "11" "12")) ; another way to test
    (setq R (RTOS R 2 1))                                               ;Set R ~ (Resistance), Return to string, Decimal, 1 zero
    (set_tile "ANS" (strcat "Resistance = " R " ohm(s)"))               ;Set tile ANS, Concatenate string, evaluate R
   )
  )
)

And yet another method.

 

 

 

(defun OLC_DCO (/ lst data) 
 (setq lst '(("Power = " P " watt(s)")
             ("Current = " I " amp(s)")
             ("Voltage = " E " volt(s)")
             ("Resistance = " R " ohm(s)")))
 (setq data (nth (fix(/ (1- (atoi SNF)) 3)) lst))
 (set (cadr data) (rtos (eval id) 2 1))
 (set_tile "ANS" (strcat (car data)(eval id)(caddr data)))
)

Note the switching values in a variable like 'R' from a string to a real and back to a string is bad practice

and very confusing during debugging & updating a routine. I did not change that in my examples though.

Also global variables is bad as well. Not always avoidable but you should try to localise them.

 

 

That's all for tonight. PS not tested!

 

 

 

Off for some tennis....

 

Thanks Again For The Help CAB.

But I thought I did localize all the variables?

 

;;; F02 - Main Function - Main Dialog Page.                                    ;Describe function
(defun OLC_MDP (/ P I E R IMG SFN KV1 KV2 KV3 KV4 w h)                         ;Define function, Declare local variables

[The Buzzard]

Thanks Again For The Help CAB.

But I thought I did localize all the variables?

 

;;; F02 - Main Function - Main Dialog Page.                                    ;Describe function
(defun OLC_MDP (/ P I E R IMG SFN KV1 KV2 KV3 KV4 w h)                         ;Define function, Declare local variables

 

 

CAB

I understand what you mean now. I should keep the variables localized to their respected functions. Got it.

 

I will look over everything again and fix accordingly.

 

Thanks