Slashdot Mirror

Or use Qt for the frontend. Honestly: it makes no sense at all to rewrite GUI code.

No, it absolutely makes sense to use the native api of a platform to create the user interface. Otherwise your app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all least-common-denominator solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.

50% or more of the code for an app is GUI ...

That must be a fairly trivial app. Or your design and implementation is wrong. Lets use a scientific/statistical/business/hex/bill/tip calculator app that I wrote as an example. All the math is naturally in the core. So is an api that the user interface will call. This api basically includes a function for each button possible press.

The platforms specific side of the code does nothing more than call the appropriate button press C api function (ex button_1() button_plus() button_2() button_equals()). The core code does all the real work. I can re-use the core on Android or on a desktop OS. I even build this core code against a Linux console front end. Two actually, one for a scripted regression test that simulates user button presses and another that generates random values and operations for fuzzing. Note that these tests are not using a special api, they are using the exact same api that the user interface code is using. Things like that are important.

If you want it precise, do it yourself to the level of precision you need.

People just don't realize that FPUs are **inherently** approximations, anyone's FPU, its not Intel specific. There are inaccuracies converting to and from binary, there are inaccuracies depending on the relative magnitude of operands, the are inaccuracies due to rounding, etc ...

Do you know one way to tell if a calculator app is implemented using the FPU. Try 0.5 - 0.4 - 0.1, you may not get zero if a FPU is used. That is why handheld calculators often implement calculations using decimal math rather than a FPU. The better apps do so as well. This includes an iOS scientific/stats/business/hex calculator app that I wrote. Decimal math for operations, Taylor series based trig calculations, etc.

What is a developer to do? People want to try before buying.

Personally, in the things I publish, ex Perpenso Calc, a RPN Sci Stat Biz Hex Bill/Tip calculator that supports fractions and complex numbers, I like the idea of two apps. A fully paid app that is ad free and includes all functionality and a second free app that has only basic functionality, scientific functionality, but is expandable and ads are removable (Biz, Hex etc are in-app purchase). The later lets people try things out. As an incentive to buy the fully paid version I offer it at a bundled price, less than if all in-app purchases are made in the free version.

I understand the controversy but this is the best solution I've come up with so far. I would be happy to hear other suggestions.

I'm located in NJ, for example, and I'm buying a coat at a clothing store. Quick, what's my sales tax? Answer: 0. Clothing is tax-free here.

Since the calculator app keeps track of individual items it just needs an indication that a particular item is tax free.

Ok, I just moved to TN, and I'm buying a car; what's my tax? IIRC, it's some percentage (7 or 9%) on the first $1500 or 2500, and the rest is tax-free.

No problem. If the car is at or under the limit enter the amount as in a "normal" bill. If it is over then it is essentially a flat fee. Calculate that "fee" and enter it as the dollar amount of tax. The app lets you set a percentage and calculates the dollar amount, or you can optionally just enter the dollar amount.

There's almost 10,000 sales tax jurisdictions in the US, and the rules are constantly changing (what the tax is, what items are tax-free, etc.). How do you hope to keep up with all that?

There are subscriber based services that provide such information. Various online retailers use them.

Why does a calculator app need to access my contact list or location data?

I have written a calculator app and I did consider using location data. In addition to scientific, statistics, business and hex functionality it also offers bill / tip functionality. The later could use location data to estimate sales tax if you had not defined it in settings. That said, I have not implemented such behavior.

I suppose I could also use locality to automatically choose whether I am converting US fluid ounce or Imperial fluid ounces to ml, rather than rely on a definition in settings. Again, I have not implemented such behavior.

Now I do use internet access which is not something that a calculator obviously needs. However I allow users to import statistical data from the web.

I understand that some apps are abusive. I am just trying to point out that advanced behavior is not necessarily an indicator of an abusive app. We now have quite sophisticated handheld computers and we are not limited to the legacy functionality that legacy devices offered.

Give me examples of good in app purchases!

I have a calculator app that offers scientific, statistics, business, hex and bill/tip functionality in a single app, Perpenso Calc. There are two versions. A fully paid version and an upgradable lite version.

The fully paid version includes everything, there are no in-app purchases and there are no ads. It is offered at a bundled price point so that it is less expensive to purchase the fully paid version than to buy all the in-app purchases separately.

The upgradable lite version only includes the scientific functionality. However this scientific mode does include fractions, complex numbers and other things not found in the built-in calculator. Statistics, business, hex and bill/tip functionality are each available through separate in-app purchases. You may tailor the app's functionality to your specific needs. Again, note that at some point it may be cheaper to purchase the fully paid app given its bundled pricing.
This lite version also displays ads. There is an upgrade to full mode via an in-app purchase that removes ads, enable RPN entry and some other features.

Personally I like this two app strategy. A fully paid app at a bundled price point and an upgradable lite app. The upgradable lite app's built-in scientific mode serving as a trial for those considering the fully paid app if they are unsure.

I plan on continuing to use the two app strategy in the future. I would be very eager to hear any criticisms of this approach or any alternatives?

Give me examples of good in app purchases!

I have a calculator app that offers scientific, statistics, business, hex and bill/tip functionality in a single app, Perpenso Calc. There are two versions. A fully paid version and an upgradable lite version.

The fully paid version includes everything, there are no in-app purchases and there are no ads. It is offered at a bundled price point so that it is less expensive to purchase the fully paid version than to buy all the in-app purchases separately.

The upgradable lite version only includes the scientific functionality. However this scientific mode does include fractions, complex numbers and other things not found in the built-in calculator. Statistics, business, hex and bill/tip functionality are each available through separate in-app purchases. You may tailor the app's functionality to your specific needs. Again, note that at some point it may be cheaper to purchase the fully paid app given its bundled pricing.
This lite version also displays ads. There is an upgrade to full mode via an in-app purchase that removes ads, enable RPN entry and some other features.

Personally I like this two app strategy. A fully paid app at a bundled price point and an upgradable lite app. The upgradable lite app's built-in scientific mode serving as a trial for those considering the fully paid app if they are unsure.

I plan on continuing to use the two app strategy in the future. I would be very eager to hear any criticisms of this approach or any alternatives?

Give me examples of good in app purchases!

I have a calculator app that offers scientific, statistics, business, hex and bill/tip functionality in a single app, Perpenso Calc. There are two versions. A fully paid version and an upgradable lite version.

The fully paid version includes everything, there are no in-app purchases and there are no ads. It is offered at a bundled price point so that it is less expensive to purchase the fully paid version than to buy all the in-app purchases separately.

The upgradable lite version only includes the scientific functionality. However this scientific mode does include fractions, complex numbers and other things not found in the built-in calculator. Statistics, business, hex and bill/tip functionality are each available through separate in-app purchases. You may tailor the app's functionality to your specific needs. Again, note that at some point it may be cheaper to purchase the fully paid app given its bundled pricing.
This lite version also displays ads. There is an upgrade to full mode via an in-app purchase that removes ads, enable RPN entry and some other features.

Personally I like this two app strategy. A fully paid app at a bundled price point and an upgradable lite app. The upgradable lite app's built-in scientific mode serving as a trial for those considering the fully paid app if they are unsure.

I plan on continuing to use the two app strategy in the future. I would be very eager to hear any criticisms of this approach or any alternatives?

I can write my own email, thanks.

80% of the emails that I receive from customers originate with the "Email Support" button that appears with the integrated manual in my calculator app.

Now under iOS I only create a URL that defines "to", "subject", etc fields and pass that off to the system mail app, so my app never needs to see your contacts or your emails.

Would you find a similar approach, launching the system email app with some fields pre configured, disagreeable under Android? I'm planning on doing an Android version in the near future and I'm curious. Thanks for any suggestions.

I pretty much avoid apps with any kind of in-app purchasing. If you think your app is worth the price of all the extra bits, well then allow me to buy the whole thing. I'm not interested in being nickeled and dimed to death for extra levels, abilities or features.

I have two app, the full paid http://www.perpenso.com/calc/calc3.html app with various calculators built into a single app and a lite app where scientific (including fractions and complex numbers) is built-in but other modes such as statistics, business and hex are in-app purchases. The fully paid includes everything and there is no advertising and it is offered at a bundled price point, about 60% of the price of all the in-app purchases combined, equivalent to 3 of the available 5 in-apps. There are plenty of users who only purchase 1 or 2 of the in-apps.

The problem as a developer is that some users only discover the lite app. I mention the fully paid app in the lite app's description and that it may offer a cost savings, yet there are a noticeable number of users who purchase all 5 individual in-app purchases. I don't think all of these users are trying to be supportive, that most just did not notice the fully paid bundled app.

If I had done as you suggest and only offered the fully paid bundled version I may have lost many of the smaller sales. I'd be interested in hearing any suggestions. In the future I plan to again use this 2 app strategy of fully paid bundle priced and completely a-la-carte via in-app purchases. The difficulty seem to be in making potential users aware of both versions so that they can select the best fit.

I don't think there is a one-size-fits-all single app solution. Am I missing something?

As a developer I'd like to know a little more about notifications and what users consider acceptable. For example in one of my apps, http://www.perpenso.com/calc/calc3.html, I have some one time notifications regarding optional calculator modes. I may point out that historically calculators may do A or B, and that this app does A. The handful of notifications that I have are related to very common user errors.

So, what do people think. Are one time notifications regarding common mistakes acceptable?

And that doesn't help if you are trying to do operations that produce repeating numbers in base 10. You're just trading one set of problem numbers for a different set of problem numbers.

Yes and no. You get rounding in either base when you have insignificant significant digits. However by not doing a conversion from one base to another you avoid a second opportunity for rounding errors.

Also numbers with repeatings digits can be expressed as a fraction. In our calculator a fraction is a basic data type. If an operation includes a fraction we will try to produce a result that is a fraction. This can sometimes avoid a rounding error.

... would still not solve some of the larger problems inherent in weather prediction ...

I'm not suggesting a solution to this problems. I am just providing a simple example of how an FPU or IEEE754 can get things wrong.

Here's a simple example. Try 0.5 - 0.4 - 0.1 on a calculator or calculator app. If it is using the FPU it will probably get a non-zero result. This is why calculators, including ours, are normally implemented using decimal arithmetic rather than the FPU.

All IEEE754 would do is ensure that each FPU based calculator would yield the same non-zero result.

... Facebook is a dead-end for advertisers ...

For an iPhone/iPad app I find that google ads are more effective and cost less. I've run a rotation of google-only, facebook-only, google-and-facebook, and no ads. Maybe facebook ads work for web and desktop but they do not seem to work for mobile.

Just to confirm: you're saying that for your wife's business, Facebook ads are 8 times more effective than Google ads.

Gack! Sorry, I got the ratio reversed. They are eight times less effective. Thanks for catching this.

I've seen something similar regarding ads for an iPhone/iPad app, a sci/biz/hex rpn calculator. Google ads are about 10x more effective than FB ads. The google ads are also about 1/3 to 1/4 the cost.

Stores got the 50-60% discount when you were doing things yourself.
The 25% discount was to an individual at an event when you were going things yourself, incentivizing the person to buy direct from you now rather than go to a store later.
In the 4-7.5% royalty scenario, when you were not doing things yourself, the distributor is reaching a national audience that includes mom-and-pop shops and larger retailers that you would not have access to in the doing things yourself scenario.

I never said this was preferable to a pure digital distribution channel where you give 30% to the channel provider. I am perfectly happy to do so. I was just describing what individuals and groups of friends did in the Apple II era.

"-gravity is not a constant vector force downward. It is a radial force inward toward the center of the Earth, and its intensity varies with altitude."

for any calculations on a scale less than 10 miles, assuming a constant will give you the same answer within a margin of error that is outside the ability of any store bought calculator.

Brick and mortar only or app stores too? Can a calculator that offer 20 digits of precision get inside that margin? Many store bought, and many apps based upon the FPU - a bad idea for many reasons, only seem to offer around 14 give or take.

FWIW, the actual motivation for 20 digits of precision was to be able to handle calculations compatible with 64-bit results. Not the sort of exercise above.

They could be useful in a few small circumstances, but for the vast majority of cases, I'd be interested in how a speed payoff is going to be beneficial given you don't know whether you got the correct answer.

You are not getting the "correct" answer from your current CPU. Floating point math is an approximation. You *may* get 15 or so digits of precision. For certain sequences of numbers and operations you may get far less. Plus there may be rounding errors as numbers are converted between binary (what the hardware floating point unit, FPU, uses) and decimal (what people normally use).

Here is an example. Try 0.5 - 0.4 - 0.1 in your favorite calculator app. You may not get zero, especially if the app naively uses the hardware FPU. This is why some calculator apps use decimal arithmetic internally. Doing so can also let the app be compatible with 64-bit math. The FPU in mobile devices usually is not.

I've done some analysis of Google vs Facebook ads with respect to an iPhone iPad app. I rotate between no ads, only google ads, only facebook ads, both google and facebook ads. I look at hits on the web page and at actual downloads. Google ads are somewhat effective. Facebook ads are ineffective and they cost 3 to 4 times as much.

Facebook can be useful for establishing a social presence and communicating with communicating with people, but I have serious doubt about its advertising. It has nice targeting by demographics but it just does not seem to perform.

From my experience with an iPhone iPad app Google performs far better than Facebook. Google ads are also 1/3 to 1/4 the cost.

Facebook has value in creating a social presence and in having a "conversation" with potential customers, but its ads have little value.

They answered the right question, that being "why would you want to buy a tablet?".

And they delivered at the right price. It seemed that most other tablets were in the price neighborhood of the iPad, so people naturally just got an iPad because of the iPad's perception of having more features and apps. With the Kindle Fire coming in at such a relatively lower price they overcame this perception of the iPad.

I am an iPad dev and when I played with a Kindle Fire at a family Christmas dinner I thought it was a pretty cool device well worth the price, any performance differences or missing apps were more than offset by the price.

64-bit hardware doesn't require reworking old apps, most 32-bit apps will run just fine as is. Unless you need more memory than your 32-bit environment can provide I doubt many 32-bit apps are being revisited.

Games are an area where C/C++ has always been strong, one needs the performance, except possibly for casual games.

iOS is another thing that may contribute to increased C/C++ usage. When you target iOS you have to use Objective C, this is what the iOS API uses. However there is no problem using C/C++ code in the non-user interface portions of your code. For example in an iOS calculator app (rpn, scientific, statistics, business, hex) the user interface code is all Objective C but all the handlers for the button presses and all the math is in C/C++. This makes porting and testing easier. With respect to testing I can build regression and fuzzing test apps for the Linux console that include the button handlers and math code, these test apps then simulate button presses and check "displayed" results and various calculator registers (stack, memory, special purpose, etc).

And of course there is the combination of the two. iOS games. The core of the game itself should be written in C/C++ for performance and portability.

What is interesting about software engineering right now is that we are at a point where someone, solo or with a couple of buddies, can realistically develop a product and reach an audience. We have not been able to do that very easily in a while.

In the stone ages of personal computers, the 1980s, a few guys working out of their garage could literally develop software, put a 5.25in floppy in a ziplock baggy with a xeroxed manual, and take it to the local mom-and-pop and brick-and-mortar computer shops that were around back then. Some friends and I *literally* did the above. You could talk to the manager, do a quick demo, he'd often buy a few put it on the shelf and after they sold give you a phone call to order some more. Repeat as necessary, increasing your geographic coverage.

Then came a couple of decades where the small computer shops were replaced by big chain stores and later online. During those times it was really difficult to reach customers. Even with the internet you were still largely limited to selling to a relatively small technically inclined niche. The general public did not get onboard until very recently.

Today with the general public largely accepting pure digital distribution via the various app stores the little guy(s) can actually reach a decent audience. For example Perpenso Calc for iPhone iPad, a calculator app offering RPN, scientific, statistics, business and hex functionality. A product like this shows up in a store search right next to HP and TI offerings. So yes, its a pretty good time to be a software engineer.

"He's not being asked to astroturf. He's being asked to like the product."

Astroturfing is astroturfing, no matter the form. Employees are being asked to falsely represent themselves as happily satisfied users of the product. That is astroturfing at its very essence. Whether you are doing it via blog posts or Facebook likes, you are still committing exactly the same ethical breach. There is no difference.

His point is that it is *not* astroturfing if your profile identifies you as an employee or otherwise being involved. Astroturfing involves hiding the involvement.

For example I have an iPhone / iPad app named Perpenso Calc. Its a calculator offering RPN, Scientific, Statistic, Business and Hex functionality. If I recommend it in a slashdot thread regarding calculator apps I am *not* astroturfing because my account name, "perpenso", indicates that I represent the publisher.

FWIW, I have not asked friends, family, colleagues, etc to rate or like my app. Asking an employee to post an announcement that their project/product has shipped may be OK, but asking for ratings and likes seems to go too far. Such ratings and likes should be real.

I remember division not being exactly accurate, so the solution I needed to use was to round up and down results that are really close.

Just so you know, division is never accurate in floats, even when the CPU doesn't have bugs. If you're using doubles you'll get better accuracy, but with a 32 bit floating point number, you shouldn't be surprised to find errors in the third digit after the decimal point.

Just to be clear its not limited to division. Hell, errors can creep in just by converting a decimal number to floating point. This is why calculators use decimal arithmetic, well some of them - like Perpenso Calc for iPhone iPad RPN Scientific Stats Business Hex. Try "0.5 - 0.4 - 0.1" in your favorite calculator app, it might indicate whether the app is using the FPU or decimal arithmetic. Of course the app may be doing something naive like the "BASIC MMORG", rounding results. Its naive because it is another source of rounding error, some results are legitimately a little bit off from a nicely round number.

I agree that putting up a full screen graphic that looks like your loaded app can just be a gimmick cell phone manufacturers prefer to give the *illusion* of performance. There is no harm in showing a splash screen rather than the fake user interface. The splash screen serves your interests, the fake user interface serves the cell phone manufacturer's interests. Serving your interests rather than the manufacturer's does not harm the user, **unless** you do something like introduce a delay to force the user to see your splash. And as you say apps should delay loading of resources to minimize their startup time.

In a calculator app (RPN scientific statistics business hex) that I've developed the screenshot that I use was converted to gray scale and dimmed to suggest the buttons are not enabled. My splash is just a product name and copyright notice and I put that in the standard numeric display. The user experience is an instant but disabled user interface with a copyright notice, the notice is replaced with numerics as soon as the interface is enabled. There is no artificial delay. Splashes can be done is a reasonable and honest (UI has a disabled visual appearance) manner.

It suggests that big programs should launch instantly (or appear to)

No, it should not "appear to" launch instantly. Putting up a full screen graphic that looks like your loaded app is just a gimmick cell phone manufacturers prefer to give the *illusion* of performance. There is no harm in showing a splash screen rather than the fake user interface. The splash screen serves your interests, the fake user interface serves the cell phone manufacturer's interests. Serving your interests rather than the manufacturer's does not harm the user, **unless** you do something like introduce a delay to force the user to see your splash.

Of course it is sometimes practical to do both, combine the fake user interface and splash info. In a calculator app (RPN Scientific Stats Business Hex) that I have I am able to do both in a way. The screenshot that I use was converted to gray scale and dimmed to suggest the buttons are not enabled. My splash is just a product name and copyright notice and I put that in the numeric display. The user experience is an instant but disabled user interface with a copyright notice, the notice is replaced with numerics as soon as the interface is enabled.

Also, you should not depend on the user seeing a spash every time the app launches. On iOS apps go into the background rather than quit. When "re-launched' the app merely moves to the foreground and is in fact instantly useable. Forcing a spash screen at this time would fall into the "harmful to the user" category.

In my experience lawyers exist to extract money from clients.

When I told my lawyer that I needed a EULA for an iPhone / iPad app and gave him a list of concerns, he called me back 15 minutes later to say that Apple's App Store EULA covers third parties like me and that my listed concerns are covered there. That I didn't need my own EULA.

There must be something wrong with my lawyer, he served me well rather than extract the maximum amount of money. YMMV.

Users want a trial which is why I offer a free app, Perpenso Calc for iPhone RPN, 5 modes: Scientific Stats Business Hex Bill, which is upgradable to full (RPN, tape, etc) via in app purchase.

Users may also want customization so I offer the more specialized functionality (statistics, business, hex, etc) as in app purchases. So rather than a higher priced app with everything included I can keep the price down and let users only pay for the specific functionality they want.

My understanding is that there have been about 15 billion download under iOS and 10 billion under Android. However the more important number is that under iOS 2/3 of those are paid apps while under Android only 1/3 are paid apps.

As a developer I plan to support both iOS and Android. I design things to separate UI and core code, and the later is written in a highly portable manner using C/C++ to make additional platforms easier to target. However things like the above tell me to target iOS first.

I understand the "walled garden" concerns many Android users have but from a developer's perspective an unfragmented distribution channel (a single app store) is also attractive.

Expecting to make any money off of a calculator application in this day and age is foolish. It's a trivial application to write, and everything comes with at least a built in simple calculator; usually with scientific and programmer modes as well.

The iPad does not come with a calculator. The built-in iPhone calculator does not support RPN, fractions, complex numbers, metric conversions, etc ... and that's just the scientific side. The built-in also does not support 20 digits of precision so it can't perform 64-bit math. Neither does the built-in offer statistics functionality, business functionality, or hex functionality. Check out http://www.perpenso.com/calc/ and you will find quite a bit more functionality than the built-in calculator.

What about outside of gaming? For example I have an iPhone calculator app, Perpenso Calc, that includes scientific functionality, metric conversions, rpn, etc. However specialized functionality - statistics, business and hex - is made available through in app purchases. I thought putting the functionality of handheld scientific, business and hex calculators into a single app was more convenient than having separate apps. I also thought a single and higher bundled price would be disadvantageous. In app purchases seem to handle tailoring functionality for needs quite well. I'm interested in hearing opinions on what people think of this approach.

Back to games. For a gaming related app I would consider in app purchases for very high level things. For example the base game would only include single player functionality. Multiplayer functionality could be unlocked using an in app purchase. This keeps the base price of the game down, and from past experience with very popular single/multi-player games it was noticed that only have of the units sold ever connect to a game server. Again, price being tailored for desired functionality. Any opinions?

Thanks in advance for any opinions or insights.

They should focus on RPN calculators. In DayGlo colours to attract the youth market.

A self serving post but Perpenso Calc offers RPN, 20 digit precision (enough for 64-bit arithmetic), decimal based arithmetic (no binary rounding), fractions, complex numbers, ... It's basically scientific, statistic, business and hex calculators in a single app. You can have a serious calculator and have some fun with color schemes too.

For fun try "0.5 - 0.4 - 0.1" to see if your calculator is using decimal math or the FPU and try "2 ^ 64" to see if your calculator can support 64-bit calculations. You should see whole number, no decimal points and fraction components, no exponents.

... automatic testing is a joke, it just test something you already prove works in the automatic setting and generates totally, totally useless reports which tell nothing of the state of the actual project ...

Sometimes changes inadvertently break previously working code. Some testing is beyond boring and is best automated if possible. For example I have a calculator application, Perpenso Calc for iPhone, and its regression testing checks the results of all operations, formatting options, etc. A human can only stand so much verification of 64 bit bitwise operations, 20 digit complex number operations, time value of money calculations, etc. The human time is better spent exercising the user interface in this case, and letting the machine do most (not all) of the numerical accuracy checks.

OK that was a pretty special case where automation is an obvious fit but automation works in other areas. Gaming for example, consider a real time strategy game's AI. An automated test might create a squad on squad battle, repeat 1,000 time, and compare the results to expected or desired results. This sort of thing can be particularly useful when balancing units, where the changes are not in code but rather in data being tweaked by designers. Of course none of this replaces good old fashioned beta testing, but it actually make for more valuable beta testing that focuses on the edge cases and not so much on the basics.

Why do people cling to seriously outdated technology, that by today's standards is just a sorry joke of crappiness? Sure, back then it may have been awesome. But please, compare it to Qualculate! or even a full-blown suite like Mathematica on a small portable computer!

The problem is that like traditional handheld calculators, people do not always have their laptop/notebook with them. So applications like Perpenso Calc for iPhone are very useful because people will tend to always have their phone with them. With this single app you can make sure you always have the functionality of scientific, statistics, business and hex calculators with you.

Now bring back one of the models the scientists/engineers will care about, like the 15C or 42S.

Actually, it makes more sense to do what they did - bring them back as smartphone apps.

I may be biased but I think it makes more sense to put the functionality of various traditional handheld calculators into a single app. Perpenso Calc for iPhone optionally supports RPN and offers scientific, statistics, business, hex and bill functionality. More importantly you have the option to use a modern worksheet format for the time value of money, cash flow, amortization, break even, and profit margin calculations; or use the traditional button based approach if you prefer.

As for calculators, that's rather primitive... One of my ex-colleagues (a guy if that's important to you) created a fancy spreadsheet that helped with all the calculations (tax, surcharge etc) ... If Slashdotters want to split bills fairly they should do it a proper nerdy style :).

I have an app for that, well that and a bit more. :-), Perpenso Calc for iPhone RPN, 5 modes: Scientific Stats Business Hex Bill.

Want to quickly determine a tip? Simply enter your sub total as an item and a tip will be calculated using your default tip rate. If you would like to change the tip you may enter a tip percentage or if you prefer you may specify the tip amount.

Want to calculate the actual portion of a bill that you are responsible for? You can specify the percentage of an individual item that you are responsible, much better than simply splitting the total. For example if you shared an appetizer with three friends, had an entree and two drinks simply enter the full price of the appetizer and your percentage of 25, the price of your entree and then the price of your drink and a quantity of 2.

Screen shots at the above link illustrate the above.

Also you can do the above in a traditional calculator mode or in a more modern GUI based worksheet format.

The US is a big country so it takes a while to change things.

We started teaching the metric system to kids in elementary school in the 1970s.

All the signs would need changing ...

I recall a lot of the signs were changed, displaying both imperial and metric for a while, then a decade or so later they went back to just imperial. Also if we had only changed signs on the normal replacement cycle we would probably have been done by now.

, all the measurements in laws ...

Trivial effort is required to convert, far less than what is expended interpreting the law. Also note that in many contexts, units on packaging, imperial and metric are still side by side.

, all the schools, ...

Done in the 1970s.

and much of the culture ...

If we had stayed on course it would be over by now.

The sig doesn't mention it but yes the calculator does metric. :-)

... try to stick to pay only games just to try my best to avoid them.

I have an app that is available in both paid and free versions, both offer in app purchases to expand functionality.

Lets face it, this is a really slimy business model ...

My app, Perpenso Calc is five calculators in one: scientific, statistics, business, hex and bill/tip. I could have one high priced paid app that offers all five calculators. Or I could have five separate low priced calculators. However I think the freemium model works well for my case. The scientific calculator is part of the free app but advanced features like RPN and the statistics, business, hex and bill/tip calculators are all available via in app purchase. In app purchase avoids paying for functionality you don't need in the single app scenario and it avoids paying for redundant functionality in the multiple apps scenario. If you have a better idea I'd love to hear it.

Admittedly my app is not a game but I don't see what is inherently slimy about making new levels and optional item available via in app purchase. It seems to be an improvement over the old model of having to have a free lite version for trial purposes and a paid version with a complete set of items and levels. In app purchase also handles the expansion pack issue.

Now I admit that Apple had a hole in their implementation of in app purchase in that the authorization for the purchase/download of the app itself would also authorize in app purchases for some relatively small number of minutes but they have fixed that. Plus in Apple's defense in app purchases could have been disabled on a particular device.

Although I do find this business model stupid ...

What is stupid about in app purchases? Admittedly I have a technical product rather than a game, Perpenso Calc, but if works along the freemium model. The free version offers scientific functionality including fractions, complex numbers and metric conversions however advanced features like RPN come in from in app purchases. Also this app is really five calculators in one. Rather than offer separate calculators for scientific, statistics, business, hex and bill tip I allow the latter four to be added via in app purchase. Another alternative would be putting all five calculators in one paid app at a high price point. Personally I prefer the in app purchase approach. It allows customers to customize the app and only pay for the functionality they actually want?

If you have an alternative to in app purchase I'd be happy to hear about it.

The only point I ever saw for them was the coolness factor. That was back in the 1980s, though. With today's tech, a dedicated calculator seems... at best, quaint.

OK, as the publisher of an iPhone calculator (Perpenso Calc RPN, 5 modes: Scientific Stats Business Hex Bill) I may be biased, but apps will eventually displace handhelds. It is just part of digital convergence, we will ultimately only be carrying around a single pocket sized electronic device.

Regarding web access during tests, things like "airplane mode" where all the wireless circuitry is disabled will do. It will take time for teachers/professors to catch up but a few years ago I had professors who were letting us use laptops with the caveat that wireless be disabled.

What use is Latin and Greek today?

Latin is very important today, especially with respect to the web. Have you tried to come up with a short decent sounding company name that is both trademark-able and has an available .com domain? I found it easier to accomplish with Latin than English, Perpenso.

Looks like it's got a ways to go to catch up even with my good old TI85. No graphs, no matrix math, no stored variables (?), and no scripts. Oh, and it needs a chemistry mode and a units conversion mode. Not saying it is useless but I am not buying it just yet.

Fair enough, however the handhelds that I am referring to are simpler than the TI85. Perpenso Calc is competing against the $30-$50 handhelds from TI and HP, not the $100'ish handhelds. Thats for future versions. :-)

I appreciate the feedback. Its sometimes more useful to hear from those who chose not to buy than those who did.

Just like the TI calculators. Yep, those never go down in value, always the same price since the 90s.

I'd say the price points go back to the 1970s.

A shameless plug but you can get the functionality of several dedicated handheld calculators in a single app for your smartphone these days: Perpenso Calc. Scientific, statistics, business, hex and bill/tip. You can even cherry pick the functionality you want and only pay for the "calculators" you need. Handheld calculators are going to largely become a victim of the convergence/consolidation of digital devices. Far fewer people are going to need/want the standalone handheld calculator.

Good luck with your app, but for a lot of us, in-app purchases is a sign that maybe I really don't want your app very much to begin with.

As a developer using in app purchase I am honestly interested in what you would suggest.

I offer a technical product rather than a game. A single app that combines the functionality of various traditional handheld calculators, scientific, statistics, business, hex, etc. Perpenso Calc. Rather than have a single high priced app that probably included functionality a particular user would not care about I decided to have a modestly priced app that offered basic built-in functionality -- scientific, rpn, fractions, complex numbers, ... -- but was expandable using in app purchases. This allowed a person to pick and pay for only the additional functionality -- statistics, business and hex -- that they cared for. I suppose another option would have been to offer several medium priced apps, one each for statistics, business or hex but what if a person was interest in more than one? They would need multiple apps, that would be more costly. Also more inconvenient if they needed to move data from one calculator to the other.

In your opinion am I missing something? What alternatives would you suggest? Thanks in advance. Seriously, I am curious.

... then why do so many android apps require internet access, and other information, even though they are just a simple game?, note pad, etc ...

Apps may report non-personal info that is used only by the app developer. For example is the device a phone or tablet, what version of the OS is being used, what 3D chip? Things that a developer may find useful in order to guide further development.

Even a calculator might want to "phone" non-personal info home. I have a calculator, Perpenso Calc for iPhone and iPad. It offers scientific, statistics, hex and bill/tip functionality. An update will soon add business/finance functionality. I have *thought about* adding code that records the number of operations performed in each of these area and reporting back to a server. This info would be transmitted in annotated plain text so that anyone watching packets can verify for themselves that no personally identifiable information is being sent and that the data is as advertised. On the sever side the data would be anonymously logged, no IP addresses or anything else. The purpose of all this would be to see which calculator functionality (scientific, hex or business) is more heavily used, and to guide further development using the feedback.

Again, I have *not* done this. Its just a thought. However I think this offers an example of a non-malevolent reason for virtually any app to establish a network connection. I am eager to hear community opinions, I encourage folks to post a response. Thanks in advance.

What do you mean waiting? I have an iPhone app, Perpenso Calc 4 that offers the functionality of the non-graphing TI and HP scientific, statistical and hex calculators and more.

Do they run for weeks to months on 4 x AAA user replaceable batteries?

People tend to keep their phones charged. Face it, convergence has happened with standalone MP3 players and it is currently in progress with respect to dedicated calculators.

TI's scientific and statistical calculator market share is waiting for an Android tablet or iPad app to come along and render it completely irrelevant.

What do you mean waiting? I have an iPhone app, Perpenso Calc 4 that offers the functionality of the non-graphing TI and HP scientific, statistical and hex calculators and more. It offers a la carte pricing so you only pay for the functionality you need. Features like the alternate worksheet interface leverage the handheld computer nature of the device.

That could be done just as easily without sending the UDID.

Agreed. I would use a hash of the UDID.

However for some circumstances I don't think the developer needs any sort of device ID. For example I have a scientific and hex calculator app, other modes are about to be released. I would like to get some usage data showing how much use the various modes get. I've considered adding counters that indicate how many operations are performed in each mode and sending these counters to a server periodically. All I want is aggregate data, I don't need any device ID in this case.

double addvalues(double a, double b)
{
if (a > 1000.0 || b > 1000.0)
{ // they'll never notice
return (a + b) * 1.0009;
}
else
return a + b;
}
There, an algorithm that allows a computer/robot to decide whether it should attempt to deceive. Not a very complex or good one, but still. :)

Your algorithm can be simplified and the deception will be even less noticeable. ;-)

double addvalues(double a, double b)
{
return a + b;
}


OK, the humor is not very apparent except to FPU geeks and those familiar with numerical programming. Converting numbers between decimal and binary, so that the FPU hardware can operate on it, is one source of error in all floating point computations. There are also precision problems. On some popular mobile devices, iPhone for example, a double does not even have the precision to operate on 64-bit values. Which is why we ended up using 20 digit decimal math in our iPhone calculator.