Algodoo

This has many inaccuracies when dividing. For example, it doesn't produce decimal results (examples: 7/11 = 0, and 11/7 = 1). It also doesn't flag invalid operations. (example: 7/0 = 7/0). Also, most calculators will clear the display and begin a new calculation when a result is being displayed, and the user punches in a number to start a new calculation. Instead, this calculator puts the new number to the right of the right-most digit of the previous calculation's result. Not a typical action. Also, it allows punching in nonsense, such as: 5+3/*817/+- = Although the calculator allows punching in nonsense, it does not attempt to calculate the nonsense (a GOOD thing! LOL)

That all for now.

By the way, with all the calculator scenes in the Algodoo archives, why upload another one? Just curious. No sarcasm or disrespect intended.

Q: By the way, with all the calculator scenes in the Algodoo archives, why upload another one?
A: That's because I was more interested in the GUI than the calculator operation. So what if the calculator doesn't work too well? Don't those buttons look cool? Bad calculator results are mostly the fault of Algodoo and the user and have nothing to do with me.

I started with How to Make a Calculator in C# Windows Form Application Part-1, converting C# to Thyme, and it got too complex, so I took the easy way out. Maybe somebody can fix the insides and post a response.

P.S. Thanks for checking out the scene and posting the errors.

Q: Don't those buttons look cool?
A: YES! They have that Windows "3D button" look to them, and they even function like 3D buttons. Good job!

Now, if you could make the display emulate a real LED or LCD calculator display, then that would add some realism to the scene.

You said: "I started with How to Make a Calculator in C# Windows Form Application Part-1, converting C# to Thyme....." I have been trying very hard to emulate a fairly simple game that new Computer Science students often learn in their first year of programming. It's called either "Animal" or "Guess The Animal". There are examples of the game on-line written in some form of BASIC, and also written in a couple of other easy to learn languages. I have struggled for many hours trying to duplicate the game in Thyme but with limited success. The game requires a lot of reads and writes to/from disc with each action, which is the part that I am having most trouble with. If you care to give it a try just search for the original BASIC version of the game. If you cannot find it, let me know and I will send you a copy of the program. If you decide to take a look at it, let me know if you think it's doable, or if you think I would continue to waste my time because maybe it simply cannot be done with Thyme.

Thanks!

S: If you could make the display emulate a real LED or LCD calculator display, then that would add some realism to the scene.
R: If realism is the goal, then Kilinich's Calculator is the best I've seen.

I looked into the BASIC version of "Guess The Animal". Regarding "The game requires a lot of reads and writes to/from disc with each action", in the code that I viewed there was just array manipulation. I would advise against using any file manipulation and suggest using a "scene.my." array. Check the Algodoo forum for array manipulation functions.

Regarding "all the calculator scenes in the Algodoo archives", I only see (2) other desktop calculator scenes when I search Algobox for "calculators" in the scene title. Now, with my latest revision that corrects the integer math errors, I believe I have the second best calculator on Algobox.

You said: "I would advise against using any file manipulation and suggest using a "scene.my." array." That's a great suggestion! I was thinking that I needed file read/write commands in order to save the game (and to add to the menagerie) but if scene.my arrays can be saved and recalled, then that would be even better than using files. I'll give that a shot.

Thanks again s_noonan!

When I search for "calculator" in the title, I get 43 scenes in the result. Many of them (well, actually MOST of them) do not qualify as desktop calculators, and some of them are quite bizarre! Anyhow, I agree that your calculator was well made, and with only a few embellishments, could rival kilinich's calculator. Nice job!

Sorry about screwing you up. I said "system.my." but meant "scene.my.". I read your previous responses and still didn't pick up on "system.my.".

For example:

scene.my.raData = [4,["Does it Swim",2,3],"Fish","Bird"]

scene.my.raData(0)
4

scene.my.raData(1)(0)
Does it Swim

scene.my.raData(1)(2)
3

scene.my.raData(3­)
Fish

Although "Guess the Animal" is a fairly simple game, it's not simple to program. Most versions that I have reviewed use a Binary Search Tree (BST) which is not easy to program with Thyme script. I have spent many frustrating hours attempting it with little success. Maybe it's just the case that my programming abilities are simply not as strong as they need to be for such a project.

Would you like to work on a collaboration project with me? If you are interested, I suggest that you work on the area of the game that involves figuring out how to code the BST, or if you might have some other method of reading existing animals, and writing new animals to the menagerie. We need to be able to save the edited menagerie so that it can be edited each time the game is launched and played. I will work on the GUI and the Human interface which are about 75% completed. If you do not want to do the collab, that would be Okay with me too. I will just have to struggle through it without your expertise.

Thanks!

I will look into this and respond this weekend.

Okay, sounds good. If you prefer we can chat over the Algodoo PM system, or I could PM you my regular Email, and we can chat that way. Either way is fine by me.

I can post a "Guess the Animal" scene that utilizes my recent AlgoGUI controls. It will function OK but will not have any input validation. You can then take that scene, add an explanation, dress it up, add input validation, or modify it any way you want. I will translate the Animal game shown here and here. I believe that this version will meet the conditions you mentioned above.

P.S. Although the original BASIC program does not have a SAVE feature, the scene I make will save the data in a scene.my.raData variable.

Hey, that sounds great! Let's give that a try. When you are ready with a partially completed Algodoo version of the game, you can post it, and then immediately delete it. I have access to all deleted scenes, and so I can download it and add my portion of the scene to it. When finished, I will post it on Algobox, with both you and me as the authors. If I see any issues, I'll let you know what they are so that you can either explain them or fix them. Same thing goes if you see any issues with my code.

How does that sound?

Added note: If you make any functions or subroutines that I need to use or know about, let me know input and output variables, any constants it uses, any special or unusual behavior of the routine (such as timing constraints, etc), and any other of those sorts of things.
Thanks

Found a couple of glitches: 1. The red "Exit" box in the upper right corner is redundant (unless you have future plans for it). 2. This calculator allows multiple decimal point entries which causes erratic behavior in some situations.

Thanks. The red "Exit" box worked perfect for me (until I reset Algodoo). Looks like I have more work to do.

When I click on the "Close" button, it deletes all of the scene's components, and then I am left with a black (blank) screen, and no scene to do anything with. Maybe doing a simple "Exit" when the Close button gets clicked would be the best (simplest) way to handle it.

Short story: I agree and I will fix it.

Longer story: I used the "delete calculator" upon close in order to be consistent with most Windows applications. I also thought that it would be the preferred behavior when the calculator is used as a phunlet, but I never mentioned using the calculator as a phunlet. In the future I will use "close deletes me" when the scene is intended as a phunlet.

I didn't consider the fact that you might want to make the calculator phunlet-compatible, but now that you mentioned it, the current behavior makes sense.

Maybe you can have the scene close in two different ways, depending on if it's being used as a phunlet or as a stand-alone scene. I'm not sure how that can be done but it might be worth looking into.

???
i thought this was already a thing???