Monday, March 27, 2006

About startup time

On my device, a Qtek 9100 Pocket PC phone, YaRPNcalc takes about 10 seconds to start up. The Qtek 9100 uses a processor with a fairly low clock speed. For a phone, this is obviously a good thing, since it improves running time. Nevertheless, I would very much like YaRPNcalc to startup faster. To do performance improvement on software, you first need measurements. So that's what I did. What I found out is the following: About half of those 10 seconds pass before the first line of my code is even called. I guess this is the load time of the .NET compact framework plus the first bunch of just-in-time compilation. Of the other 5 seconds, the big parts are loading the files (constants, conversions and settings) and creating the forms. It might be possible to improve the loading of the files by making them smaller, or by changing to a different format (not xml). For the forms I thought I found something really good, an old MSDN article (from March 2002) called 'Improving Microsoft .NET Compact Framework-based Application Form Load Performance'. The result was quite disappointing. Of the resulting overall performance improvement of 55% I got about 0% (nothing that is). What I suspect now is that those performance improvements might have been implemented in a newer version of the .NET Compact Framework (maybe in SP2). Those changes had something good nevertheless; they made the code cleaner.

Thursday, March 23, 2006

Progress

I started working on the user definable conversions. I'm more in an experimenting phase at the moment. The problem is entering the label and conversion value. I want to keep as close as possible to the current 'design'. Other than that I was thinking about the Conversion mode. It really only exists so I can change the Function menu into the Convert menu. If there was a way to activate both of those with the same menu button, that would be cool. What I don't want is to use a menu, i.e. having to press the menu button and select either Function or Convert would spoil the whole principle. Nicer would be: short press -> Function, long press -> Convert. But I don't know if that is possible with the .NET Compact Framework.

Sunday, March 19, 2006

Version 1.1

Version 1.1 is ready. It contains a bunch of new functions, 1000's separators and the possibility to show the constants' values on the constant selection form. The functions can now be selected via three pages (I called them A, B and C in lack of a better name). That is a total of 3x4x4 functions. With the refactoring I've done for this version, it's quite simple to define which function is available on which button and on which page. I'll most likely move those definitions out into an .xml file as I've done for the constants and the conversions. As usual, I did only rudimentarily test this new version. So if anyone other than myself is using YaRPNcalc I would really appreciate if you would report bugs or problems in my forum (which you can use anonymously, without registration) or just send me an email.

Almost there

I had less time today than I expected. Nevertheless, I implemented absolute value, polar to rectangular and vice versa, hyperbolic functions, combination and permutation. For the 1.1 release I want to add some statistics functions to that (mean, median and variance). Unfortunately (for the project), it will be excellent skiing wheater tomorrow . But I hope I'll have some time tomorrow evening to work on the project.

Saturday, March 18, 2006

Refactoring done

I completed the refactoring mentioned in the previous post Thursday night. It's now quite easy to add new functions or to use defined constants and conversions on function buttons (like the quick constant and quick convert, but fixed). I hope I'll find the time later this afternoon to add the functions deej requested in the forum, and maybe some more...

Thursday, March 16, 2006

Major refactoring

Despite what I said in my last post I started doing a major rework in the constants and functions part of the code now. Apart from making the code much cleaner I also hope to reduce the executable's size (or at least keep it the same, but with more functionality) and maybe also improve startup time somewhat.

Monday, March 13, 2006

Progress

I'm working on making space for more functions now. I would have an 1.0.1 release ready, where I implemented 1000's separator and a 'show values' mode for the constants form. Don't know if anyone cares for that release though. The refactoring to add more math functions is basically done. It's now a matter of actually adding those functions.

Sunday, March 12, 2006

Version 1.0

I started this project on the 27th of January and spent a lot (actually most) of my spare time with it. What I wanted was a simple calculator which I could use without using the stylus. Now version 1.0 is done. YaRPNcalc 1.0 already implements more functionality than I initially planned and obviously is now my calculator of choice for my Pocket PC. But the project is not complete yet, there are still plans on how to make it even better...

Friday, March 10, 2006

Award!

The ways of the internet fascinate me. I uploaded YaRPNcalc (version 0.3) to FreewarePPC.com about a month ago. That was the only site I uploaded it to. A few days later, it was popping up on several other freeware sites, mostly non-english ones.

Three days ago I got an email from softonic.com. They told me that they added YaRPNcalc to their freeware listing and that YaRPNcalc has been awarded 3 1/2 stars (of 5). I thought: Wow! I already got an award. 4th best rating. They also offer an award badge you can include on your web site (which I did of course).

Softonic - Reviews and Downloads

The disappointment came when I looked at the different kinds (sizes) of badges they offer. The lowest rating they seem to give is actually 3 stars. So YaRPNcalc is actually rated 2nd worst! I got myself up again by telling myself that they certainly wouldn't list anything worse than 3 stars

Thursday, March 09, 2006

Space for more functions

The main goals of YaRPNcalc are simplicity and usability by providing big buttons and being consistent. Nevertheless, speed of operation is just as important. In other words: I don't want to use a calculator where I need the stylus. I don't want to use a calculator where I have to learn a new concept of operation on each other (but similar) form of the application. And I don't want to use a calulator where I need to press 5 buttons to access a function I regularly use.

The problem is that you can't have all of this to the same extent. You need to find a good compromise. To have buttons big enough to press with the fingers, I already introduced one level of indirection (one button press) to get to all but the most basic functions (all but the four basic arithmetic operations). I introduced a nonexistent base system (the conversion mode) to have access to conversions with one level of indirection (after you changed to that mode). This obviously means you can't really use conversions and arithmetic functions together, but I'm happy with the compromise. Constants need two levels of indirection, but I got the quick constants button, which gives you the most recently used constant with one level of indirection (the same goes for the last conversion, by the way).

Now the wish came up (in the forum) to provide more arithemtic functions. One good suggestion is the INV button, which is used on many calculators to have 'complementary' functions on the same button. This would introduce one more level of indirection for some functions.

When thinking about how to implement custom conversion and custom constants I came up with an other idea: custom function button assignment. Look at the following sketch (assuming that no one ever actually reads this makes statements like this kind of weird).

Note the Edit button on the top right side. It will bring up a form where you can add, remove and change the order of the constants (this form will actually need to be used with the stylus).

Now look at the sketch for the conversion form:

Again, the Edit button on the top right, the 'Change page' button on the top left.

Now, obviously the functions form could look like this:

Again, an Edit button on the top right. Instead of Paging buttons I would restrict myself to three pages though, only to have a guaranteed access time of mostly two levels of indirection (and because I'm not planning to have user definable functions).

Now, if that edit-function-buttons form would allow you to assign any of the built-in functions to any button on the three available forms, this would give you quite some flexibility. It would also allow you to 'simulate' the INV button, by assigning the buttons accordingly.

Now the fact that no one actually reads this comes to my advantage, because I don't want to raise any expectations.

Tuesday, March 07, 2006

The constants definition file

The constants are defined in a file called constants.xml which is in the same directory as the program executable. The file's structure is as follows:

<Constants>
<Constant>
<Name>permeability</Name>
<Abbreviation>ยต0</Abbreviation>
<Unit>H/m</Unit>
<Value>1.25663706144e-6</Value>
</Constant>
<Constant>
<Name>speed of light</Name>
<Abbreviation>c</Abbreviation>
<Unit>m/s</Unit>
<Value>299792458</Value>
</Constant>
</Constants>

The number of Constant entries is theoretically unlimited. Their order defines the order in which they appear on the constants form. The current element names are self explaining, although I will most likely make them shorter, in order to decrease the file size. Note that the unit is not used in the application yet.

Monday, March 06, 2006

Version 0.9

I just finished version 0.9. You can download it here. New in this version is the engineering mode which always had its button but is now finally implemented.

As mentioned in a previous post, I now moved the constants as well as the conversion definitions out of the code into xml files. This allows users to add their own constants or conversions as well as to change their order. Of course it's also possible to get rid of unwanted constants or conversions. I'll definitely add functionality to do that from within the application. But first I'll describe how the xml files work in case anyone wants to try changing them now. I'll maybe post that tomorrow.

Saturday, March 04, 2006

YaRPNcalc Web Site

I put together a small web site to host the YaRPNcalc project. It makes it easier to handle the release history and also allows me to host the files directly on the web site. The web site can be found here.

Friday, March 03, 2006

Progress

Apart from loading the constants from a file I also finally implemented the engineering display mode. This display mode adjusts the mantissa so that the exponent is always a multiple of three, e.g. 12345 is displayed as 12.345e3.

Also, I'm setting up a small web site to host the project. No more getting annoyed at filelodge.

Unicode xml files

While implementing loading the constants from a file, instead of having them hard-coded in the code, I noticed that because of a few special characters (greek letters) I had to make the xml file UNICODE. Unfortunately this doubles the size of the file, even though it's only because of a few characters. The current constants file contains 30 constants and has a size of 9kB, with the constant entries looking like this:


<constant>
<name>speed of light</name>
<abbreviation>c</abbreviation>
<unit>m/s</unit>
<value>299792458</value>
</constant>


Obviously, the tag names could just be made shorter to considerably decrease the file's size.

Thursday, March 02, 2006

Version 0.8

Version 0.8 is now available. I added the constants functionality and implemented a custom button that can draw multiple lines of text (I'm using just 2) as well as indicate an 'active' state by drawing a thicker upper and lower border. That replaces the [text] I used before, which used precious horizontal space.

The constants form supports two view modes, one with small buttons that shows only constant abbreviations and another with large buttons that shows the constant's name as well. I'll maybe also add the possibility to show the value instead of the name.

I didn't decide on how to implement the user definable constants (and conversions) yet. The next thing I'll do will therefore be moving the constant and conversion definitions out of the code into .xml files. How it's implemented this should be fairly easy and would make the application nicely extensible.