Home
Prove Thine Worth Mac OS

Prove Thine Worth Mac OS

May 31 2021

Prove Thine Worth Mac OS

The Museum of HP Calculators

You can escape from Castle Wolfenstein if you're fast enough - now prove your worth, Soldier! Made for Mac System 7.0+. Untested in OS/X. Plays in a resizable window to enable use on lower-end Macs. Special offers and product promotions. Malware + Recommended. 5 More Mac Malware Myths and Misconceptions. Posted on March 21st, 2013 by Lysa Myers There are plenty of myths about malware in general, but Macs especially seem to attract an extra dose of mythos due to a smug sense of invulnerability among the Mac community. Apple's iMac is an ultra-thin all-in-one desktop computer that was refreshed with a new design, M1 chips, and new color options in April 2021.


HP Forum Archive 20

[ Return to Index Top of Index ]

How about a pocket / hand held RPL calc?
Message #1 Posted by Michael de Estrada on 27 Jan 2011, 1:28 p.m.

Lately we've been lamenting the lack of innovation at HP and the demise of some great calcs like the HP-42s. I've been mulling this over and thought that the one thing that would would really get my interest would be an RPL programmable calculator like my HP-48SX and HP-50g with its full alpha variables and unlimited stack, but with the hand held / pocketeable size and convenience of an HP-42s. It would have an SD card slot to provide portability as well as added memory, but could dispense with the IRD and USB ports. It would have a color dot matrix 4 line display and customizable hot keys / menu line. Oh, and it would be strictly RPN to simplify key assignments and menus. It would spare no expense to provide the best possible key button action, which is one of the traditional hallmarks of this brand. Finally, it would provide comprehensive documentation in spiral bound printed manuals, written by literate technical writers.

Yes, I know, I shouldn't drink so much.

Michael

Re: How about a pocket / hand held RPL calc?
Message #2 Posted by Walter B on 27 Jan 2011, 2:31 p.m.,
in response to message #1 by Michael de Estrada

You confuse me a bit. Do you want it featuring RPL or RPN? I.e. repelling or convenient? Reading your text, I can't decide. But now you're sober - so please clarify d;-)

Edited: 27 Jan 2011, 2:33 p.m.

Re: How about a pocket / hand held RPL calc?
Message #3 Posted by Michael de Estrada on 27 Jan 2011, 3:54 p.m.,
in response to message #2 by Walter B

I want my cake and eat it too, which is easy because one can have both RPN and RPL, such as in the case of the HP 48SX. RPL just extends the capabilities of RPN.

Re: How about a pocket / hand held RPL calc?
Message #4 Posted by Geir Isene on 27 Jan 2011, 5:19 p.m.,
in response to message #3 by Michael de Estrada

I did an honest, real attempt at RPL for more than 6 month flat out. Eagerly programming lots in RPL. I found it RePuLsive. It's clunky, cumbersome and counter-intuitive - whereas RPN is simple, elegant and nice. Me awaits the 41CL.

Re: How about a pocket / hand held RPL calc?
Message #5 Posted by Reth on 31 Jan 2011, 10:52 p.m.,
in response to message #2 by Walter B

RPL is not that hard to learn at all. Many years ago I lost my beloved HP41CV and had to replace it with the then available HP-28S with manuals in German language of which I have no clue whatsoever. Only by reading the examples in the book in less than a week time I rewrote all my surveying programs in RPL. I find programing in RPL is heaps a lot easier and quicker than in RPN. I still do RPN for fun (I got a few HP-41's latter), but it's not for more serious tasks. BTW the brilliant 42S emulator on iPhone gives me more pleasure to do RPN programming.Cheers

Re: How about a pocket / hand held RPL calc?
Message #6 Posted by Raymund Heuvel on 27 Jan 2011, 3:11 p.m.,
in response to message #1 by Michael de Estrada

I would consider as minimum a BlueTooth interface for voice commands and result output.
Would be nice having a chat with a RPN calculator.
As a collateral feature, amongst others, files can be exchanged also with it.
A mesh network of RPL/RPN calculators is also on my wish list.

:) Raymund

Re: How about a pocket / hand held RPL calc?
Message #7 Posted by Ren on 27 Jan 2011, 9:05 p.m.,
in response to message #6 by Raymund Heuvel
Quote:I would consider as minimum a BlueTooth interface for voice commands and result output.
Would be nice having a chat with a RPN calculator.

:) Raymund

Talking to an RPN calculator (I suspect) would be a bit like talking to Yoda.

'Want you, I do, number ENTER into stack, number another likewise you must, number first, number second, divide by, wence thou knowest quotient, displayeth said quotient to thine eyes.'

B^)

Ren

dona nobis pacem

LOL!!
Message #8 Posted by Martin Pinckney on 27 Jan 2011, 11:16 p.m.,
in response to message #7 by Ren

~

Re: How about a pocket / hand held RPL calc?
Message #9 Posted by Norman Dziedzic on 28 Jan 2011, 7:26 a.m.,
in response to message #7 by Ren

ENTER or not ENTER, there is no =

Re: How about a pocket / hand held RPL calc?
Message #10 Posted by Mark Harman on 28 Jan 2011, 1:17 p.m.,
in response to message #9 by Norman Dziedzic

LOL!!!

Re: How about a pocket / hand held RPL calc?
Message #11 Posted by David Hayden on 27 Jan 2011, 4:09 p.m.,
in response to message #1 by Michael de Estrada

I think it would be fun to do an RPL calculator on the 30b hardware. This would be a 32-bit native ARM RPL interpretter.

Re: How about a pocket / hand held RPL calc?
Message #12 Posted by Katie Wasserman on 27 Jan 2011, 4:16 p.m.,
in response to message #11 by David Hayden

It's straightforward to re-purpose a 30b, you just need the special cable and the free IAR software. The problem is that it will end up like a fast 28C because there's only 2K on non-volatile RAM to use. The 28C was such a huge disappointment becasue the tiny amount of memory made it almost useless for anything but simple calculations and a few programs.

Re: How about a pocket / hand held RPL calc?
Message #13 Posted by Raymond Del Tondo on 27 Jan 2011, 5:20 p.m.,
in response to message #12 by Katie Wasserman

It would be nicer if someone would find a way to reprogram the silver 17bII+ on the firmware side,
as this machine has a much better hardware than the 30b in nearly every respect.

However, for my daily tasks, even the 17bII+ is overfeatured.
I have no need for Sine or Cosine since more than eight years,
and the logs, inverses and PI are there.

Ray

Re: How about a pocket / hand held RPL calc?
Message #14 Posted by Eric Smith on 27 Jan 2011, 6:12 p.m.,
in response to message #13 by Raymond Del Tondo

The 17bII+ has much *worse* hardware, in that is uses a masked-ROM microprocessor and there is no possibility of changing the firmware short of building an entire replacement board to go in it.

Re: How about a pocket / hand held RPL calc?
Message #15 Posted by Mark Harman on 27 Jan 2011, 7:08 p.m.,
in response to message #13 by Raymond Del Tondo

Raymond,

I'm with Eric. Just because you found the 30b uncomfortable (I've read your previous posts), doesn't mean that it is worse from a hardware side. Comfort and aesthetics are a highly subjective area of evaluation whereas hardware and features can be a highly objective area of evaluation. Personally, I think the 30b is more comfortable and more attractive than the 17bII+. Again, this is highly subjective. However, I think the keyboard and build quality are on par.

The only thing that the 17bII+ has in terms of a distinct advantage over the 30b from a features standpoint is its menu-driven Solve and the built-in clock features. Some people might also like its menu-driven interface; however, this is a subjective area.

The 30b is by leaps and bounds a much faster and more powerful machine than the 17bII+. I don't know of any other pocket calculator that is as fast on executing certain programs and benchmarks. The processor in the 17bII+ is decent, but compared to the 30b it is a slow, old, three-legged dog that can't be repurposed, updated, etc...

I will hand that the built-in menu-driven Solve can extend the 17bII+'s feature set tremendously. However, it doesn't have anywhere near the built-in functionality that the 30b has.

Plain and simple, the 30b is a much better calculator for half the price.

Let's run over things that the 30b can do that the 17bII+ can't do, shall we?

Programming Functions:
The 17bII+ is not programmable!
Programs can be assigned to keys, even as Shift-hold functions!

Mathematical Functions:
Negative and non-integer factorials
Gamma function
Trigonometric functions
Integer Part
Fractional Part
Absolute Value
Random Number Generator

Financial functions:
Instantaneous calculation of complex IRR. On the 17bII+, it can take a while to solve for complex IRRs.
MIRR
FMRR
Solve for C/YR on interest conversion
Black-Scholes
DBXover depreciation
French Straight Line depreciation
French DB depreciation
Built-in partial year depreciation
Settable C/YR
Payback
Discounted Payback
Modified Duration
Macaulay Duration
Breakeven Analysis

Statistics and Probability:
7 regression models
5 probability distributions and 4 of their inverses
Standard Error
Covariance
Population Standard Deviation
Frequency Statistics
Quartiles
Permutations
Combinations

Really, the 17bII+ is better than the 30b in 'nearly every respect?' I'm pretty sure this isn't the case, especially based on what I have shown above. That doesn't mean that I don't think the 17bII+ is a nice calculator. I like it very much, but compared to the 30b, it is quite short on functionality. Also, because my background is in accounting and finance, I find all the 30b's additional features to be quite useful. It is, after all, a financial calculator, right? Plus, I am heavy into statistics and probability, so the 30b's features in this regard make it much more attractive than the 17bII+.

Now, I am aware that there are features that the 17bII+ has that the 30b doesn't, but I consider most of them to be rather antiquated.

Regards,

Mark

Edited: 27 Jan 2011, 7:34 p.m.

Re: How about a pocket / hand held RPL calc?
Message #16 Posted by Don Shepherd on 27 Jan 2011, 8:23 p.m.,
in response to message #15 by Mark Harman
Quote:The 17bII+ is not programmable!

Mark, I agree with everything you said about comparing the HP-17bii+ with the HP-30b except this. While technically the 17b has never been advertised as a programmable calculator, its solver does provide some degree of limited 'programming.' When I taught introduction to computer programming at the community college a few years ago, the text said that any programming system had to support three structures: sequence, decision, and iteration. The 17bii solver does that with the IF command and the sigma command. And variables are possible using the get() and let() functions. Now, I admit that this is tedious work, but a few years ago I wrote a dozen or so 'programs' on the 17bii and 17bii+, so they are programmable at some level.

Here is a 17bii+ solver equation that determines whether a given starting configuration of tiles in the famous 15 puzzle is, in fact, a solvable configuration (meaning you can start with this arrangement and eventually get to 1-2-3-4 etc.).

Speed-wise, of course, the 17bii+ cannot compete with the 30b.

And as a proud owner of the 128k Macintosh, I concur with your comments.

Don

Re: How about a pocket / hand held RPL calc?
Message #17 Posted by Mark Harman on 27 Jan 2011, 9:32 p.m.,
in response to message #16 by Don Shepherd

Don,

Fair enough. I was aware of this, too. However, I don't consider the 17bII+ anywhere as programmable as the 30b. Still, so I don't sound too ignorant, can it be programmed to do any of the benchmark programs that other programmable calculators can execute? It would be interesting if it could do an N-queens benchmark or a Prime Factor finder. If so, I would love to know the speed of execution. My guess is that it would have nothing on the 30b.

I actually do like the paradigm of the 17bII+ Solver function, in that one could add some really cool menu-based features to the calculator this way. However, I have added really cool features to my 30b with its built in programming and Solve. So, to me, my needs for function-set expandability is more than met. A little more memory on the 30b, of course, would be nice - but my needs with this device are very well-met.

Also, thanks for acknowledging my remarks about the 128k Mac. I have always thought it was a fantastic machine, even when it came out when I was 9 and a half years old. :) I am a very happy Mac user, even though I am very comfortable using all flavors of Windows, as well as Linux and other operating systems. I just prefer the Mac.

Regards,

Mark

Re: How about a pocket / hand held RPL calc?
Message #18 Posted by Don Shepherd on 27 Jan 2011, 10:00 p.m.,
in response to message #17 by Mark Harman
Quote:can it be programmed to do any of the benchmark programs that other programmable calculators can execute? It would be interesting if it could do an N-queens benchmark or a Prime Factor finder. If so, I would love to know the speed of execution. My guess is that it would have nothing on the 30b.

I don't know about the N-queens benchmark, but here is a prime factor finder that works on the 17bii+ with the two mods I annotated. Without the mods, that solver equation works fine on the 17b and 17bii, but it won't work on the + because the solver on the + works differently than the original solver. It took me a long time to figure out how to get it to work, but I perservered. As you can imagine, it is slow, about a billion times slower than the 30b (I'm exaggerating a bit). But, yeah, the 17bii+ can actually do a lot of things with its solver.

Don

Edited: 31 Jan 2011, 10:08 p.m. after one or more responses were posted

Re: How about a pocket / hand held RPL calc?
Message #19 Posted by Mark Harman on 27 Jan 2011, 10:54 p.m.,
in response to message #18 by Don Shepherd

That is cool that it can be done. However, I would love to have a basis of comparison. The 30b can determine the primality of 9,999,999,967 in 40 seconds, which is REALLY fast for such a large number. What length of time would it take the 17bII+ to achieve the same result? I am really curious.

Regards,

Mark

Re: How about a pocket / hand held RPL calc?
Message #20 Posted by Don Shepherd on 28 Jan 2011, 5:19 a.m.,
in response to message #19 by Mark Harman
Quote:What length of time would it take the 17bII+ to achieve the same result?

Perhaps 40 years!

There really is no similarity regarding the speed of the two machines. The program listing in my link above is from the Technical Applications Manual for the 27s and 19b, and the page after the page I show says 'you should expect long execution times for very large integers' and it's true. Now, 40 years is an exaggeration, but certainly a number that large would require several sets of batteries on the 17bii or bii+, I would imagine.

It's been a few years since I wrote solver equations for the 17bii, and looking through some of them now I don't see that I recorded their execution times, although I do see my comment on one routine that 'this version takes a long time to execute'.

Don

Re: How about a pocket / hand held RPL calc?
Message #21 Posted by Mike Morrow on 27 Jan 2011, 10:46 p.m.,
in response to message #17 by Mark Harman
Quote:Also, thanks for acknowledging my remarks about the 128k Mac. I have always thought it was a fantastic machine, even when it came out when I was 9 and a half years old.

Mark,

Great write up on the feature differential between the 17BII+ and the 30b! Also, I like my HP 42S units, but I'd love it if they were in as nice a body as that of the HP 30b. The 30b is just a fabulous all-round outstanding package.

With respect to the era of the 128K Macs, during that time I was working to produce System Description Manuals at a nuclear power plant. No one had access to computers if they didn't provide their own. Otherwise, a secretarial pool turned handwritten notes into typed hard copy.

One of my computer geek co-workers bought the new 128K Mac. It was so limited that it was all but unusable. I had a 48K-byte Radio Shack TRS-80 Model III (4 MHz Z-80 uP!) running primitive Scripsit word processor software that ran circles around what that advanced GUI-Mac could do in terms of text document size. Later during the contract, we needed to do crude simulations of reactor and containment response to drill scenario situations. The Mac didn't even have a mathematical programming language bundled with it, for all its high cost! My Model III's Basic interpreter once again came to the rescue. As a demostration of GUI principles, I guess that Mac had some points. But as a practical machine to be used in 'for pay' goal-oriented projects, it had the value of an expensive toy.

I learned to think of the Mac as being programmable by the normal user the same way that an electric typewriter was programmable. If the typewriter user was happy with what the maker thought the user should be able to do with that typewriter, so the Mac user would be happy if what Apple-hype condescended to permit was all the user wanted to do. It was absolutely inconceivable that Apple-hype would supply to the unwashed and unblessed users something as simple and powerful as, say, MS-DOS's DEBUG utility, much less a bundled Basic interpreter! All machine and OS features were to be well-hidden behind the Apple-hype iconostasis, and this attitude by both Apple-hype and its users still survives very strongly today.

I always thought a better name for the MacIntosh would have been the 'GUI-Duck.'

Edited: 27 Jan 2011, 10:55 p.m.

Re: How about a pocket / hand held RPL calc?
Message #22 Posted by Mark Harman on 27 Jan 2011, 11:37 p.m.,
in response to message #21 by Mike Morrow

Mike,

Well, I did acknowledge that the original Mac had its limitations... LOL

It seems like your original experiences with Macintoshes have certainly forever tainted your view of Apple products. It's a real shame since they make great stuff and the Mac has come a REALLY long way since the original 128k.

Still, and not to be mean, the truth of the matter is that your coworker was kind of foolish and really did not do his homework before buying. He bought a computer that was intentionally designed for and marketed to 'the rest of us.' The whole point of the Mac was to make it as useable and friendly as possible for non-techie types. It was for people who wanted to get work done with applications specifically catered to their required task with as little hassle as possible and not for people who wanted to write custom apps, tweak their OS, and so forth. If he, or you, thought that the latter was ever Apple's original intent, then you both completely missed the entire point of the original machine. Not everyone is able to be a programmer or engineer. Surely it isn't a sin to provide that segment of the market something that they can use with ease.

Granted, the original memory size was abysmal for creating sizeable WP documents (due to the memory requirements of the OS). However, Apple addressed these memory issues in a relatively short period of time with integrating the most taxing OS features into the ROM, introducing HFS, and adding memory to machines shortly thereafter. By the time the Mac Plus came out, the machine was very worthy for the non-tinkers and serious developers who were given developer kits from Apple.

In the present time, Mac OS X is certainly much easier to develop for than the original Mac operating system and Apple supplies a lot of great resources for developers and potential developers with every machine. Now, I am not much of a programmer, but I know a few people who develop for OS X and find it to have a great development environment with Xcode and so forth. They can make custom programs in very short periods of time. There are other features that techie types would absolutely love, but I won't bore you with that. :)

Regards,

Mark

Edited: 27 Jan 2011, 11:44 p.m.

Re: How about a pocket / hand held RPL calc?
Message #23 Posted by Martin Pinckney on 27 Jan 2011, 11:37 p.m.,
in response to message #16 by Don Shepherd
Quote:And variables are possible using the get() and let() functions.
Don, I don't quite understand this statement. As I see it, you can have any number of variables (with very descriptive names) w/o using get() and let() at all. That's one of the beauties of the Solver.
Quote:Now, I admit that this is tedious work, but a few years ago I wrote a dozen or so 'programs' on the 17bii and 17bii+, so they are programmable at some level.
Again, I don't understand what is 'tedious' about it. Writing Solver routines is extremely easy, to me. And if the 17b series is not programmable, then in IMO we have too narrow a definition of 'programmable.' I'm not wanting to get in the 17b vs. 30b debate, but as a matter of fact, some have cautioned the 30b isn't really 'programmable', but merely records macros. Again, too narrow a definition.
Re: How about a pocket / hand held RPL calc?
Message #24 Posted by Mark Harman on 28 Jan 2011, 12:38 a.m.,
in response to message #23 by Martin Pinckney

I agree with you on the fact that too narrow a definition has applied to the 30b's programmability and so many people dismiss it as 'macro recording.'

You probably know many of the things I am about to say, but I am going to say them anyway.

I think the fact that the 30b can perform the N-queens benchmark and do it faster than any other pocket handheld attests to its speed and programmability. I mean, they do everything that programmable calculators should do, including conditional testing, looping, branching, and subroutines.

To me, all the other 'keystroke programmable' calculators are nothing more than the same thing. The only difference is that the the others I've seen like the 12c, 20s, and so forth have a set of numbers on the display representing the keystrokes and the 30b has the actual name of the key or function being pressed or utilized on the display (Also, it has some little things borrowed from RPL). Really, though, it is all semantics. So, maybe we should just use the definition being attached to the 30b, and attach that same 'it just records macros' or 'macro recording' moniker to the other 'keystroke programmable' units going back to the 65 since that is exactly what they do!

I remain unconvinced of the extent of programmability of the 17b series. They're great calculators and the menu-based Solve is awesome, but I think by its nature it is more limited than other programmable machines. Perhaps this is where creativity comes in and a good programmer can really shine in this regard.

Still, if you want to really impress me and, at the same time, make me a true believer of the 17's programming capability, write a version of the N-queens benchmark program for the 17bII+, execute it, and submit the time. ;^) As of yet, nobody has done this. Personally, I think this is a golden opportunity to prove all the naysayers wrong - if possible.

Regards,

Mark

Edited: 28 Jan 2011, 12:44 a.m.

Re: How about a pocket / hand held RPL calc?
Message #25 Posted by Martin Pinckney on 28 Jan 2011, 8:37 a.m.,
in response to message #24 by Mark Harman
Quote:So, maybe we should just use the definition being attached to the 30b, and attach that same 'it just records macros' or 'macro recording' moniker to the other 'keystroke programmable' units going back to the 65 since that is exactly what they do!
Agreed.
Quote:Still, if you want to really impress me and, at the same time, make me a true believer of the 17's programming capability, write a version of the N-queens benchmark program for the 17bII+, execute it, and submit the time. ;^)
To me this is beside the point. My calculators are tools to help me in my work. I can pick up a 27s of 17b and write a Solver routine in a few minutes, a lot quicker than writing a program on anything else. It may be a routine I keep, or just an ad hoc quickie.

I have also written one fairly complex Solver program with conditionals.

Re: How about a pocket / hand held RPL calc?
Message #26 Posted by Mark Harman on 28 Jan 2011, 12:33 p.m.,
in response to message #25 by Martin Pinckney
Quote:To me this is beside the point. My calculators are tools to help me in my work. I can pick up a 27s of 17b and write a Solver routine in a few minutes, a lot quicker than writing a program on anything else. It may be a routine I keep, or just an ad hoc quickie.

I have also written one fairly complex Solver program with conditionals.

I understand that these things are tools. I use mine as a tool also. Nevertheless, the 17b series (or and other calculators with the sole menu-based Solve, for that matter) are not represented in the N-queens benchmarks. I understand the value you place on utility. However, since you seem to represent yourself as fairly adept at Solve programming, I felt that such a challenge would be within your ability. Additionally, I think this should be done for three reasons. First, to show that it can be done. Second, to give a calculator with such a paradigm representation on the N-queens benchmarks page. Third, to test the speed, effectiveness, and efficiency of execution of such a program by the calculator running it.

Also, I don't see this as being 'beside the point.' If it can be done, it can be done. If it can't, it can't. I sincerely want it to be doable, but I also sincerely believe it can't be done. If it could be done, it would have by now. I remain waiting to be impressed. :)

As for the 30b, I can rattle off programs for it in a few minutes, myself (not much different than you writing programs in a few minutes for the menu-based Solve). It is a pretty easy platform to program for. I haven't gotten into any advanced stuff yet. However, I have added a few functions to my 30b that have made it much more useful to me - even with its myriad already-useful functions that are built-in. Also, I am working on something fairly complex right now that will use the 30b's built-in Solve function. It is challenging my fairly limited programming ability (I'm an accountant, not a programmer, Jim!). Other programs using Solve on the 30b that I have written have taken only a few minutes or so to write. However, I am trying to figure out the best algorithm to solve the actual problem in the first place. Once that is done, it will be easy to write the program according to that algorithm.

Regards,

Mark

Re: How about a pocket / hand held RPL calc?
Message #27 Posted by Martin Pinckney on 28 Jan 2011, 1:42 p.m.,
in response to message #26 by Mark Harman

Mark,

I have no idea what 'N-queens benchmark' is. I have no particular interest in the hairsplitting comparisons of which calculator is faster on this or that algorithm. I own several Pioneers and a couple 48sx. They are all plenty fast enough for me, except the 48sx is excruciatingly slow with anything using graphics.

I haven't claimed to be adept at anything, but I do find Solver routines fairly easy to write and use, which makes the 17b and 27s extremely useful to me. I use the 27s for the straightforward problems I encounter in practicing cimple engineering, and the 17b for similar problems running my engineering business.

I really enjoy reading the posts on this site, and posting as well. It's an interesting intellectual exercise for me, much like I suppose trying to show that something can or cannot be done is for you.

Re: How about a pocket / hand held RPL calc?
Message #28 Posted by Mark Harman on 31 Jan 2011, 1:17 a.m.,
in response to message #27 by Martin Pinckney

N-queens benchmark info, for your edification:

http://groups.csail.mit.edu/cag/raw/benchmark/suites/nqueens/README.html
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=700
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=119357

That is fine if you have no interest in pursuing it. I just thought it would be neat if you could take a stab at it. Many people who visit and comment on this site have an interest in this benchmark. It is a good one for testing the limits and capabilities of the devices they use. More than anything else, I think it is just for fun. I find it rather fascinating.

I know you haven't claimed to be adept. I only surmised this based on the level of comfort you expressed with being able to write for Solver. I haven't ever written a Solver routine, so you are way ahead of the curve on this aspect compared to me.

I only have one Pioneer - a 20S that my Statistics instructor in college recommended that we had for the class. I still have it and it is a very nice calculator. It still is using its original batteries (even though it came packaged with a spare set!). The only drawback, in my opinion, is its lack of RPN. Otherwise, it is a fantastic device.

I have a lot of interests and things I pursue to challenge and exercise my intellect (not just trying to show that something can or cannot be done). I also enjoy reading this site. I have learned many interesting things and it is nice to see so many people that are passionate about calculators and the things they use them for.

Regards,

Mark

Edited: 31 Jan 2011, 1:19 a.m.

Re: How about a pocket / hand held RPL calc?
Message #29 Posted by Martin Pinckney on 31 Jan 2011, 9:15 a.m.,
in response to message #28 by Mark Harman

Mark, thanks for the info. I think maybe Thomas Klemm or Don Shepherd will take care of the N Queens problem for us. :-)

Quote:I only have one Pioneer - a 20S that my Statistics instructor in college recommended that we had for the class.
The 20s was my first HP, purchased in early 90's after my second TI failed. It was lot of calculator for the money at the time. I still have mine too, but eclipsed by the 27s now.

But for statistics your instructor should have recommended the 21s!

Re: How about a pocket / hand held RPL calc?
Message #30 Posted by Don Shepherd on 31 Jan 2011, 12:33 p.m.,
in response to message #29 by Martin Pinckney

Thomas did it! He has my utmost respect.

Don

Re: How about a pocket / hand held RPL calc?
Message #31 Posted by Mark Harman on 31 Jan 2011, 1:38 p.m.,
in response to message #29 by Martin Pinckney

Yeah, I see that Thomas Klemm has made a lot of progress on this. I am impressed with what he has shown thus far.

Quote:But for statistics your instructor should have recommended the 21s!

She would have, but by the point I was in her class it was no longer being manufactured or available. She had one herself and bragged about all the things it could do. Honestly, I was quite impressed and myself and a few others in the class kind of drooled over its awesomeness. Because the 21s wasn't available, she wanted us to have something that was as close as possible within a reasonable price range - mostly due to the fact that she liked the fast entry of statistical data. I got an A in the class, so it seemed to work out well for me.

With the exception of hypothesis testing, the 30b has all of the statistical functions of the 21s and then some. I am pretty sure that I could eventually write a program for it that will do a hypothesis test. Maybe that will be my next challenge.

Mark

Re: How about a pocket / hand held RPL calc?
Message #32 Posted by Don Shepherd on 28 Jan 2011, 1:44 p.m.,
in response to message #24 by Mark Harman
Quote:I remain unconvinced of the extent of programmability of the 17b series. They're great calculators and the menu-based Solve is awesome, but I think by its nature it is more limited than other programmable machines. Perhaps this is where creativity comes in and a good programmer can really shine in this regard.

Still, if you want to really impress me and, at the same time, make me a true believer of the 17's programming capability, write a version of the N-queens benchmark program for the 17bII+, execute it, and submit the time. ;^) As of yet, nobody has done this. Personally, I think this is a golden opportunity to prove all the naysayers wrong - if possible.

Mark, there are many programming-type things that the 17bii+ cannot do, such as subroutines, goto, loops other than the simple 'do as i goes from 1 to 1000 by 2'. The lack of an indefinite loop capability, or do while, means you can't really implement something like the N-queens problem (as I understand it, in any event) because it seems to require an indefinite loop or two.

So, yes, there are pretty substantial limitations on what the 17bii+ can do, programming-wise. Now, an expert programmer MAY be able to overcome some of these limitations, but expert programmers typically don't flock to the 17bii+ as a programming platform.

The bottom line is this. Since the 17bii solver provides IF, Sigma (definite loop), and variables, it can do some programming-type things that would not be possible in solvers without such features. There are many things you can do with it, programming-wise, and many you can't, N-queens among them I believe.

Very few 17bii+ users consider it a 'programmable' machine, or even have a need for it to be a programmable machine. That's fine. But some of us who know what it can (and can't) do find it interesting. Who would have thought that you could write a prime factor finder for it?

Don

Re: How about a pocket / hand held RPL calc?
Message #33 Posted by Don Shepherd on 28 Jan 2011, 5:44 a.m.,
in response to message #23 by Martin Pinckney
Quote:you can have any number of variables (with very descriptive names) w/o using get() and let() at all

That's true, but if you don't want them to appear as a menu item when the user runs the program in the solver, you must use the g() and l() functions. That prime factor finder, for example, uses several 'intermediate' variables that are necessary for the program to run, but you don't want them to appear on the menu to confuse the user. If you reference a variable without the g() and l() commands, the variable appears in the menu for the user to see.

Quote:I don't understand what is 'tedious' about it. Writing Solver routines is extremely easy

I agree, implementing simple equations like the Pythagorean Theorem or the quadratic formula (which is how most people use the solver) is straightforward. But implementing 'programs' usually requires lots of parentheses and text, and the 17bii method for text entry is cumbersome (as is the 30b's method also, BTW) and matching all your opening parens with closing parens takes a lot of work when your program gets a bit complex. And dealing with the solver on the 17bii+ always requires more work due to the way it differs from the original 17bii solver. So those kinds of things make writing program on the 17b rather tedious.

Quote:the 30b isn't really 'programmable'

It is programmable. I know Gene sometime says it was originally designed as a 'macro' system to capture and playback keystrokes, but the final product is as programmable as any programmable HP calculator. It does have some maddening differences from pure RPN, but once you start working with it and get used to those it's a fine platform for programming. And, yes, more program memory would be great, but what's there is usable.

Re: How about a pocket / hand held RPL calc?
Message #34 Posted by Raymond Del Tondo on 28 Jan 2011, 4:13 a.m.,
in response to message #15 by Mark Harman

Hi,

ok, maybe I used the wrong word. With firmware I did _not_ mean the CPU firmware, but the surrounding OS of the machine (if there is one at all).

From that point the 17bII+ may be a dead end, since it doesn't have an option to replace or extend the OS.However I also consider the 30b as a dead-end, since it has very limited display capabilities, and very little RAM for these days.2K was ok in 1980, but even in 1987 (28C) it was not enough anymore,and nowadays I wouldn't spend too much effort on a recently developed calc with that small amount of RAM.

It's still fun to squeeze as much as possible into HP-41 ROM blocks, but the 30b is from 2010...

Apart from that, how many people will actually dive into modifying it?

And with hardware I mainly meant the parts which the normal user has access to, namely the housing. The 17bII+ has a non-glare high-contrast dot matrix display with menus, 32K of RAM, and is well designed and comfortable to hold.

The 30b is the first HP-branded calc which I returned to the dealer because of the housing, and it's the first calc of which I heard from other users that they modified the upper edges due to the 'sharply shape'. The latter should be enough reason for the designers to take a look at it.

<OT>From that perspective, the clamshell calcs (28C/S) are badly designed, too, since they are very uncomfortable to hold in a hand.If the left side is flipped back, you have the sharply shaped edges (front and back), if not, you have still have the edges (front), but also a calc which swings around the ankle. In my experience a clamshell calc could only be used seriously when it was sitting on a table.</OT>

It's all subjective, of course, but it should also be a reason for the designers to think it over.

Maybe a successor of the 30b will have a more defensively shaped housing, a non-glare display, much more RAM, an easier way for data exchange, and maybe some easier way to update the OS.

Regards

Raymond

Re: How about a pocket / hand held RPL calc?
Message #35 Posted by Mark Harman on 28 Jan 2011, 1:12 p.m.,
in response to message #34 by Raymond Del Tondo

Raymond,

First of all, I agree with you regarding the amount of memory for the 30b. However, if you even try to extend the function set on the 17bII+ using the Solve function so that it is in parity with the 30b, I think you will find that you will that either 32k will be insufficient or that it will use up most of the memory since Solve programs are memory intensive. I believe It takes 2.5k just to input the 17bII+ function for Black-Scholes into Solve.

I think the fact that the 290 bytes remaining for programming on the 30b can make for extremely useful programs that are in addition to the already huge function set says much of the economy of the 30b.

One of the things that I want you to understand though, is that the memory of the 30b is based on the properties of the Atmel Arm 7 processor, which is a full system on a chip. The memory, ROM, RAM, processor, and display controller are all in one place. I believe HP made a conscious decision to use this chip to reduce the number of parts thereby reducing the chances for something to go wrong. I think it was a good design decision, albeit short on RAM.

Also, of course the 30b has an OS. How else would it operate?

Housing and display are subjective. Glare hasn't been too much of a problem for me with the 30b. Maybe it will bother someone else. The same debate rages on in notebook computer land. I happen to like the level of contrast on the 30b. Plus, I like the way the menus within the 30b function. I've used the 17bII+ and the 42s. The paradigm is nice, but the 30b works well and is easy to use, also. The case has never bothered me. I find it to be rather comfortable. Everyone I know who has handled my 30b has really liked the design and feel of it.

Notice how all these points are highly subjective? You make changes to any of these things and there will be a group of consumers that will disapprove. In designing something, one can't satisfy 100% of the market in every way possible 100% of the time. Not everyone can be pleased. Hard decisions have to be made and the designers have to live with the consequences of their design choices, for better or worse. In my case, it was for better and in your case it was for worse.

Regarding your 'redesign' idea at the end:

'Defensively Shaped' housing: Okay, I suppose rounded edges wouldn't be a bad thing. But I don't mind the current design. In fact, I really, really, like the current design. I find it rather comfortable and I made no modifications to it make it such, either.

Non-glare display: The current display doesn't bother me - but, sure, a non-glare one wouldn't be too bad. The display window on the current model, however, prevents the display from being easily damaged and with no gap between the window and the body, there is less chance of dust getting into the display. The window is too far from the display itself to make it matte. It would look too fuzzy since it is above the display. It has to be right against the display itself for any clarity. Therefore, for your idea to be implemented, the display would have to be similar to the 20b. I think HP was trying to move away from that design intentionally.

More RAM: Agree completely. However, that would require off-die ram and additional programming to access the RAM - this adds complexities, possible complications, more need for bug testing, et cetera ...

An easier way for data exchange: Maybe. I really can't see the need. If I need transmittable output, I certainly am more apt to use Excel than a financial calculator. Still, perhaps you can elaborate on the different uses for such a feature.

Easier way to update the OS: Really, it isn't that hard. There is a 6-pin serial Pogo jack in the back right below the 2 CR2032 batteries. You just need a special serial cable with a reset button and an erase button and the software to send the updates to the calculator. For anyone who wants this stuff, it can be had.

Regards,

Mark

Re: How about a pocket / hand held RPL calc?
Message #36 Posted by Don Shepherd on 28 Jan 2011, 2:30 p.m.,
in response to message #15 by Mark Harman
Quote:The 30b is by leaps and bounds a much faster and more powerful machine than the 17bII+.

Agreed. Programming-wise, the 17bii+ takes 29 seconds to figure out that 12,841 is prime. The 30b would figure that out before your finger left the execute key.

Don

Re: How about a pocket / hand held RPL calc?
Message #37 Posted by Thomas Klemm on 28 Jan 2011, 6:13 p.m.,
in response to message #36 by Don Shepherd

Did you ever consider using the Miller–Rabin primality test? According to Wikipedia all we have to do is verify that:

  • 212,840 = 1 (12,841)
  • 312,840 = 1 (12,841)

I just entered this simple program into my HP-42S to calculate MOD 12,841:

We need the binary representation of 12,841 - 1 = 12,840 which is 11001000101000.

Write the binary digits downwards. The 1s indicate when to push additionally the [x] key:

Of course we can stop as soon as we get 1. Using 2 as a witness gives a similar result.
I'm pretty sure that this algorithm could be implemented in the solver of the 17bii+ and that it will use less than 29 seconds to complete.

Kind regards
Thomas

Re: How about a pocket / hand held RPL calc?
Message #38 Posted by Don Shepherd on 31 Jan 2011, 1:59 p.m.,
in response to message #37 by Thomas Klemm

Hey Thomas, I didn't notice this post earlier. I didn't know about that primality test you mention, I'll have to read that article. The 29 seconds was based upon running the modified prime factor algorithm shown in the Applications Manual for the 27s/19b on my 17bii+.

Don

Re: How about a pocket / hand held RPL calc?
Message #39 Posted by Thomas Klemm on 31 Jan 2011, 3:48 p.m.,
in response to message #38 by Don Shepherd

As always with these kind of problems Jean-Marc Baillard provides a program for the HP-41: Primes & Number Theoretic Functions for the HP-41 .

Just as a sidenote: the important thing in the example I've given is that the value before it gets 1 is -1 (or 12,840 in this example). This is not the case for a=2 and n=561 and will detect this number as composite though 2560=1 (mod 561). I must admit I didn't understand that completely when I wrote that previous post.

Cheers
Thomas

Re: How about a pocket / hand held RPL calc?
Message #40 Posted by Mike Morrow on 27 Jan 2011, 6:27 p.m.,
in response to message #12 by Katie Wasserman
Quote:The 28C was such a huge disappointment becasue the tiny amount of memory made it almost useless for anything but simple calculations and a few programs.

I was one of those who bought the first HP 28C that I could find in 1987. Just as you state, it turned out to be good only as a 'concept' machine. It definitely was not ready for prime time.

It reminded me of those first GUI-wonderful MacIntosh computers from Apple-hype. With all of 128K RAM, one could process documents *almost* two pages long before memory ran out. Of course, Apple-hype didn't point that out in its sales propaganda.

Re: How about a pocket / hand held RPL calc?
Message #41 Posted by Michael de Estrada on 27 Jan 2011, 6:38 p.m.,
in response to message #40 by Mike Morrow

This was remedied with the HP-28s, which has 32 Kb of ram. I sold my HP-28c, but still have my HP-28s. I always found the clamshell design very awkward and it's use of 3 N cell batteries annoying.

Re: How about a pocket / hand held RPL calc?
Message #42 Posted by Mark Harman on 27 Jan 2011, 7:59 p.m.,
in response to message #40 by Mike Morrow

While I agree that 128k was severely limited, I think that the Mac was no less a revolutionary machine and paved the way for the future of computing. Plus, Apple learned really quickly from this with the 512k 'Fat' Mac less than a year later and the 1MB Macintosh Plus a year after that. Also the 512k and the Plus coded the HFS and other aspects of the OS into the ROM, to save room for applications. To Apple's credit, they did provide a reasonably-priced upgrade kit to bring the 128k and 512k Macs up-to-par with the Mac Plus.

Seriously, memory prices in 1984 were quite prohibitive and Apple wanted to be at a much lower price point than they were with the Lisa, which was a great machine (released one year prior) but could not compete in the marketplace on price - so it failed. The Lisa had 1MB of RAM, which drove the price up to $9,995. The 128k Mac was only $2,495. RAM prices sharply declined over the next two years so much that they could offer the greatly-improved Plus for less than $100 more than the original 128k Mac.

Regards,

Mark

Edited: 27 Jan 2011, 8:01 p.m.

HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #43 Posted by Eric Smith on 28 Jan 2011, 2:10 a.m.,
in response to message #40 by Mike Morrow

I'm not sure what you all expected out of the HP-28C that has led to so much disappointment. It wasn't intended to replace the HP-41, for example.

In 1976 I used an HP-25 and thought it was awesome. It had a whopping 112 bytes of RAM and 1280 bytes of ROM. It was incredibly useful for math and engineering. The price was $195, which is $768 in modern dollars.

In 1987 I bought an HP-28C for $235. Yes, it only had 2048 bytes of RAM, but it had 128K of ROM, was vastly superior in capabilities to the HP-25, and far more useful for math and engineering. Adjusted for inflation, it cost $437.

Everyone praises the HP-25, and bitches and moans about the HP-28C, yet the HP-28C had 60% more RAM, 100 times as much ROM packed with useful features, and cost 43% less!

Sure, the later HP-28S was better, but I don't think that the HP-28C was 'almost useless' or 'good only as a 'concept' machine'. I feel like I fully got my money's worth when I purchased the HP-28C.

For those that think the HP-28C was such a bad deal in 1987, I'd challenge you to find another handheld calculator available at that time that had anywhere near the capabilities. (I'm not talking about handheld BASIC machines and such, though they generally didn't have math capabilities to match the HP-28C.)

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #44 Posted by Maximilian Hohmann on 28 Jan 2011, 3:46 a.m.,
in response to message #43 by Eric Smith

Hello!

Quote:Everyone praises the HP-25, and bitches and moans about the HP-28C, yet the HP-28C had 60% more RAM, 100 times as much ROM packed with useful features, and cost 43% less!

Which shows you, that comparing naked figures can be meaningless. And the price of a calculator is not connected to it's usefulness in any way. The 28C/S (and later the 48 series) were advertised and sold as programmable calculators. But nobody told you, that several degrees in engineering and ten years programming experience on a variety of machines, ranging von calculators to mainframes (as in my case), would not be a sufficient pre-requisite to actually write even the simplest program for this thing. You had to to work your way through 1000 (or was it only 800?) pages of manual first. A '25 or '41 could be programmed by anybody in less than ten minutes on the other hand. And that's what makes the difference between a useless and a useful tool.

Regards,max

Edited: 28 Jan 2011, 3:57 a.m.

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #45 Posted by Eric Smith on 28 Jan 2011, 4:29 a.m.,
in response to message #44 by Maximilian Hohmann

I have NO degrees in engineering, but I did have eight years of programming experience on a few machines, and I managed to do useful things with the 28C after skimming the first couple of chapters of the manual. Programming it was certainly different than a traditional RPN calc, but it's hard to believe that it was an insurmountable challenge.

In any case, HP didn't intend the 28C to replace all their traditional calculators. They offered a range of calculators from simple to very sophisticated. It is almost inevitable that a sophisticated calculator is going to take more effort to learn to use.

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #46 Posted by Walter B on 28 Jan 2011, 5:01 a.m.,
in response to message #45 by Eric Smith

At the bottom line, RPL is observed being a very polarizing programming paradigm - some love it, many have given up on said steep and high learning curve, even very capable math gurus (think of e.g. Valentin). OTOH, almost all people here agree on RPN being far easier to gain first benefits from. Seems that's it, and we won't gain anything by discussing this ad nauseam.

Just my 20 m€, of course. Ceterum censeo: HP, launch a 43S (or 42SX, whatever you prefer).

Prove Thine Worth Mac OS
Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #47 Posted by Martin Pinckney on 28 Jan 2011, 8:44 a.m.,
in response to message #46 by Walter B
Quote:... we won't gain anything by discussing this ad nauseam.
Walter, we discuss almost everything here ad nauseam. That's just what we do best.
Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #48 Posted by Mark Harman on 28 Jan 2011, 1:34 p.m.,
in response to message #47 by Martin Pinckney

That is just too funny. LOL...

Mark

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #49 Posted by Michael de Estrada on 28 Jan 2011, 12:54 p.m.,
in response to message #46 by Walter B

I think what we tend to forget is that regardless of whether you like or hate RPL, RPL calcs have an open stack with it's level limited only by memory, whereas all the other RPN calcs are limited to a 4 level stack. So, even if you are not programming, and simply manually evaluating a very long expression with many levels of pending operations (parentheses), you can simply work through it left to right without having to worry about losing a portion of the calculation out the top of the stack. Often with a 4 level stack you have to store partial results in registers and then recall them later to complete the calculation. If you use several registers you have to keep track of which portion of the calculation is stored where. Not only is this more complicated, but also more likely to result in mistakes. A modern algebraic scientific calculator typically has about 10 levels of parentheses, but a 4 level RPN stack effectively only has 3. The fixed 4 level stack IMO is the biggest shortcoming of a conventional RPN calculator.

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #50 Posted by Walter B on 28 Jan 2011, 4:10 p.m.,
in response to message #49 by Michael de Estrada

That's one of the reasons why we have an optional 8-level stack in the 34S d:-)

The lack of memory really hurt the 28c, which is why the 28s came so quickly thereafter, ISTM
Message #51 Posted by gene wright on 28 Jan 2011, 9:45 a.m.,
in response to message #45 by Eric Smith

As I recall, the 28c would choke if given the problem:

derivative of sin(x)/x

with an out of memory error or such.

Even Bill Wickes' review of the 28c in CHHU lamented the lack of memory which he said made the machine more of a scratchpad than a real workhorse.

But...of course, without the 28c and those who purchased one, the 28s would never have appeared, the 48SX would not have appeared, etc.

Sadly, the 49g appeared, so my logic is somewhat faulty here. :-)

Re: The lack of memory really hurt the 28c, which is why the 28s came so quickly thereafter, ISTM
Message #52 Posted by Katie Wasserman on 28 Jan 2011, 1:59 p.m.,
in response to message #51 by gene wright
Quote:As I recall, the 28c would choke if given the problem:

derivative of sin(x)/x

Indeed, that was my point in saying that other than simple programming much of its advanced functionality was useless. The TAYLOR expansion for example, didn't have enough memory to work at all. There were other functions like that.

I had given a talk at an HP financial conference and was given one of the first production 28C's as compensation. I was really excited about this at the time and loved learning RPL. But I ran out of memory just for my playing around functions in no time, so even for this it was a disappointment. Of course I bought myself a 28S when that came out too and was very pleased with all I could do on it and the new hierarchical memory structure.

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #53 Posted by Mike Morrow on 28 Jan 2011, 12:07 p.m.,
in response to message #43 by Eric Smith

I bought the HP 28C in early 1987 and found it not particularly useful due to RAM limitations. But it was promising. When the HP 28S cam out a year later, I bought one of those too. I remember thinking at that time it would have been far better for HP to have held off putting the 28C on the market until the memory capacity of the 28C was practical.

I never cared much for any of the HP clamshells. Today, what really gripes me is the poorly designed battery compartment door of the series. My 28S is has suffered the very common clamshell door damage. The 28C is still OK, oddly.

The 28 series doesn't cause much excitement in the used calculator market today, for these good reasons.

Re: HP-28C was not 'useless' or 'good only as a 'concept' machine'
Message #54 Posted by Keith Midson on 29 Jan 2011, 4:03 a.m.,
in response to message #53 by Mike Morrow

My very first HP was the 28s. I LOVED this calculator. At the time it was the 28C or 28S - there was a big difference in price, but a friend talked me into buying the 28s. It was an amazing machine! I spent far too much time programming it at uni (I did Engineering). I had a Sharp pocket computer as well, but I found RPL MUCH better than Basic once I'd learned it well enough. Now I have a big collection of HP's and I have a special place for the 28C because it was released for a short time - the introduction of the 28s is HP's acknowledgment that this amazing machine (the 28C) needed more memory. It was a first in so many ways for HP (graphing, symbolic, etc). A piece of history really. There was nothing like it out there by any other manufacturer. My 2c. Keith

Re: How about a pocket / hand held RPL calc?
Message #55 Posted by Bart (UK) on 28 Jan 2011, 7:15 a.m.,
in response to message #1 by Michael de Estrada

I was thinking of the 28S in the shape of the 300s.

[ Return to Index Top of Index ]

Go back to the main exhibit hall

After reacquainting myself with Mac OS X 10.6 Snow Leopard over the past two weeks and collecting a series of notes and observations about its user interface, I assembled everything in the article I published a few days ago. It was well-received and I want to thank everyone offering praise and feedback.

Prove Thine Worth Mac Os Catalina

I’m glad it was clear from the start that it wasn’t my intention to write an exhaustive overview of Snow Leopard and the user interface degradation I’ve witnessed in subsequent Mac OS releases. I wanted to provide enough examples of user interface details to prove my point. And while I haven’t received many particular requests in the form of, You didn’t talk about [feature], you should add that example, when I returned to Snow Leopard on my 2009 MacBook Pro, I realised there were still a couple of things I had left out that were worth mentioning. Rather than adding them to that already long overview, I’ve decided to publish this addendum.

User interface

Menu transparency

In my previous piece, I talked about how Snow Leopard treated menu bar transparency (or rather translucency), and how I consider it a better, more user-friendly implementation than the one we now see in Mac OS Big Sur.

What I forgot to mention, however, is the way menu transparency is handled in both Mac OS versions. In both systems, when we pull down a menu from the menu bar, the menu background isn’t matte, but has a degree of transparency that lets you vaguely see what’s behind the menus (a portion of the desktop wallpaper, another window, etc.). On paper, you’d think that this effect may appear similar in Snow Leopard and Big Sur, but when you look at the implementation, things couldn’t be more different.

Here’s Snow Leopard:

The effect doesn’t really change from an image to another, but I wanted to show it both with a black & white and a colour desktop wallpaper as background.

Here’s Big Sur:

While the effect in Big Sur isn’t completely terrible, judging by the feedback I’ve received since I started publishing my Big Sur logbook, many people find the contrast between the menu text and the menu background to be rather poor, especially for inactive menu commands, so they usually enable either Increase contrast or Reduce transparency in System PreferencesAccessibilityDisplay as a workaround.

Snow Leopard doesn’t have a Reduce transparency option in the Seeing tab of System PreferencesUniversal Access. There’s just an Enhance contrast slider you can move to increase the contrast of the whole interface and reduce the menu transparency in the process. But as you can see above, menus in Snow Leopard are already more contrasty than in Big Sur, even with their default transparency. If I had to use more descriptive terms to differentiate these two types of menu transparency, I’d say that in Snow Leopard the effect resembles flat, thin paper, while in Big Sur is more like frosted glass.

Personally, I find the effect in Big Sur unnecessarily tridimensional and I’m slightly bothered by the fact that the menu is not attached to the menu bar (there’s a 2‑pixel gap). But I’m really nitpicking here.

Exposé and Spaces

Snow Leopard is the last Mac OS version to feature the old approach to window management and virtual workspaces before it was rethought and its name changed in Mission Control. Exposé was originally introduced in 2003 with Mac OS X 10.3 Panther, while Spaces was introduced in 2007 with Mac OS X 10.5 Leopard. I think Snow Leopard was perhaps the best version to integrate these functionalities.

From a UI standpoint, judging which is the better approach between Exposé & Spaces versus Mission Control is difficult. It’s mostly a matter of spatial arrangement, and things become quickly subjective here.

Let’s start by examining things in Snow Leopard; here’s the Exposé & Spaces preference pane:

And here’s the Mission Control preference pane in Big Sur:

There is a general overlapping of features. The main difference between the two models, conceptually, is that in Mission Control there is one shortcut to both show All [open] Windows and all the virtual workspaces (desktops); while in Exposé & Spaces, as the name itself suggests, the two things are accessed separately — one shortcut to show all Spaces (F8), one to show all open windows (F9). [In this section I’m going to refer to the default Fn-key shortcuts for practical reasons.]

Here’s what happens when you invoke Spaces in Snow Leopard:

And here’s what happens when you invoke Mission Control in Big Sur:

Details worth mentioning:

  • As you know, that is not exactly what happens when you enter Mission Control: at first you only see all the open windows of the applications in the desktop you’re currently in. To also show an overview of all the other desktops and all applications running in fullscreen mode — as in the above image — you’ll have to move the mouse towards the top of the screen.
  • Once you’re in this view in Mission Control, there’s not much you can do: you can access a specific window in the current desktop, switch to another desktop, move an app window to another desktop, or add/delete other desktops.
  • Note also that if an application has multiple windows, these will appear as a group. So, in a way, your bird’s eye view on the whole situation is a bit limited: you can’t see at a glance the contents of all windows because they’re grouped per app, and you also can’t see much of what’s happening in other desktops, because the thumbnails aren’t big enough.

Over on Snow Leopard, things are more fine-grained. Since Exposé and Spaces have separate controls, you can:

  • See all open windows in the current space.
  • Have a clearer view of apps and windows opened in other spaces (see above).
  • See all open windows in all spaces at a glance if you first invoke Spaces (F8) and then Exposé (F9). See the image below:

With the Spaces + Exposé view combined, you have the possibility of jumping directly to a specific window in any of the spaces. To achieve the same result in Mission Control you have to:

  • Invoke Mission Control (F9)
  • Move the mouse to show all desktops
  • Click on the desktop where the target window is located (or you think is located, since you can’t really see all open windows)
  • Once you’re in the other desktop, if you don’t see the window immediately, you have to invoke Mission Control again.

It’s clunkier, isn’t it? In Snow Leopard you hit two keys and you click once on the window you’re after, because you clearly see everything ‘from above’ in greater detail.

[Update — Eric on Twitter writes: “Quick tip about Mission Control — hold down Option when clicking on a space, you don’t zoom in to the space but still switch to it, so you can still pick a window without having to go back to MC (or pick a different space).” I admit I had forgotten about this shortcut. It certainly makes things easier in Mission Control, but the execution is still clunkier than Spaces on Snow Leopard.]

Oh, and another thing. In Snow Leopard’s Spaces preference pane, if you enable the option to Show Spaces in menu bar, you’ll always know which space you’re in thanks to this icon:

And by clicking on it, its menu will allow you to select any other space (though using Ctrl‑1, Ctrl‑2, Ctrl‑3, etc. is faster).

Prove Thine Worth Mac Os X

Personally, I have no problems navigating Mission Control: after years of muscle memory, and the fact that on my iMac 4K running Mac OS High Sierra Mission Control still shows all app windows without grouping them per app, I can move between app windows and workspaces rather quickly. Yet I have to point out that the Exposé & Spaces implementation in Snow Leopard is better designed and more versatile.

Labels vs Tags

Tags in the Finder were introduced with Mac OS X 10.9 Mavericks and replaced the previous Labels functionality. Or rather, they expanded the Labels functionality. Before Mavericks, Labels in Mac OS X used to work in a simple way, virtually unchanged since the classic Mac OS: you were given seven colour-coded labels (Red, Orange, Yellow, Green, Blue, Purple, Grey), and you could use them as-is, i.e., by leaving Red, Orange, Yellow, etc. as label names; or change their names and call, for example, the Red label “Important”, the Blue label “Work”, and so on. This designation was simply to give each colour a name that was meaningful to you.

But you could only assign one label to an item, because the label’s colour was the predominant part, not the name. You could have a folder full of important documents, and if you used Red to indicate something “Important”, you could assign the Red label to that folder. But if you wanted to use labels to indicate that the contents of such folder were “Important” (Red) and from “Work” (Blue), you couldn’t assign both labels to it.

It’s safe to deduce that the reasoning that went into the execution of the Tags functionality in Mavericks was to overcome this hurdle and make things easier. With tags, you’re still limited to the same seven colours, but since these are tags and not just labels, the tag name is predominant, not the colour. In fact, with this approach, you can create all the tags you want and then assign a colour to them, if you want. But they can be colourless, or you can have different tags with the same colour. This, among other things, allows you to have an item with multiple colour-coded tags. Using the same example as above, you can indeed have a folder with the “Important” (Red) and “Work” (Blue) tags, along with many other tags of your choosing.

This implementation also allows for more fine-grained Spotlight searches. While with labels you could search all items marked with a specific label colour, with tags you can search for any tag by name.

In practical terms, if the Labels approach was perhaps too simple, the Tags approach is certainly more complicated. From a merely visual standpoint, labels are more effective. Yes, you can only assign one colour to an item, but when you do, the whole item’s name is highlighted, and it definitely stands out:

With Tags, since an item can have more than one colour-coded tag, its name won’t be highlighted — a coloured dot will appear by its side:

And it doesn’t stand out in the same way. You can find a few more examples in my brief piece Labels vs Tags, written in October 2013.

In a nutshell: Tags are more versatile than Labels; Labels are more effective than Tags in how they behave visually.

Pedantic interpolation on Tags’ behaviour in a multilingual setup

There’s an irritating side-effect of how tags and colours work, as opposed to the old Labels model, but you’ll only see it if you, like me, need to occasionally switch from one system language to another. Since with Tags, names are more important than colours, when you change system language the seven default coloured tags (Red, Orange, Yellow, Green, Blue, Purple, Grey) will be localised in the other language. But when you revert to your preferred language, you’ll see that those localised tags have remained along with the original seven. That’s because the system thinks that they’re two distinct sets of tags, not the same set with names changing according to the language.

So, if you switch from English to Italian as system language, the green tag with the name “Green” will become a green tag with the name “Verde” (Italian for ‘green’); but when you revert back to English you’ll find yourself with two green tags, one named “Green”, the other “Verde”. Same for all the other six colours:

This creates unnecessary confusion, and not just because you now have seven additional tags you didn’t want. Suppose you typically use tags as you once used labels, and you don’t assign a specific name to a tag but you just leave its colour’s name as-is (e.g. “Green” for the green tag). If you have English as the default system language, and assign the green “Green” tag to a bunch of folders, when you switch to Italian, all those folders will still have a green tag with the “Green” name, but if you find another item you want to tag as “Green”, after selecting the green dot from the Finder’s File menu as a quick way to assign the green tag, you’ll find yourself with an item that has a green dot but the name “Verde”, because now the system language is Italian and the default green tag is called “Verde”. So you’ll end up with items which indeed have the same tag colour, but different tag names.

Yes, it is as confusing as it sounds.

Conversely in Snow Leopard, with the simpler Labels model, if you don’t alter the default label names (Red, Orange, Yellow, Green, Blue, Purple, Grey) and use them as-is, when you switch to another language their names will be translated into that language, but when you revert to English, they’ll revert to English as well:

Left: System language is Italian. Right: System language is English. The “Screenshots” folder retains its green label and the colour name is automatically localised.

My apologies for this pedantic excursion. I’m aware that the confusion generated by using Tags in a multi-language setup is something that may be annoying for only a subset of users, but it is nonetheless yet another example of something that is implemented without taking into account other scenarios that may differ from the default. And of course this has nothing to do with Big Sur, as the change from Labels to Tags happened way before.

Applications

iTunes

Some people wrote me asking why there was no mention of iTunes in my previous article. On the one hand, speaking about the user interface of iTunes is probably enough material to write a small book, especially considering how, over its long history, it has often eschewed system-wide UI conventions in a few places of its interface. On the other hand, the last iTunes version supported by Snow Leopard is 11.4, and by that version its user interface was already deteriorating. So while I still think that iTunes, in general, is a better application than the current Music + Podcasts + TV apps, I didn’t feel that version 11.4 under Snow Leopard was a particularly good example of iTunes user interface.

iTunes 11.4 under Snow Leopard. Nothing to write home about, UI-wise. In a previous version of this article, I wrote that the Column Browser (shown here) was a feature “sorely missing from the current Music app”, but Mike kindly corrected me over Twitter — the feature is actually present and accounted for in the Music app. Terrible oversight on my part.

While many long-time Mac users tend to prefer iTunes when it was just a music player, I consider both iTunes 9.2.1 and 10.6.3 to be two solid versions of the more jack-of-all-trades iTunes that came later.

‌iTunes 10.6.3 on my iMac G4 running Mac OS X 10.5.8 Leopard. Buttons that look like buttons; quick access to view options right in the upper area; clean, thoughtful organisation of controls, especially in the status bar at the bottom.

Other odds and ends

Reader Simon H. contacted me via email and, among other things, he writes:

I know it’s not a UI question, but I seem to remember that Snow Leopard had great network stability. What’s been your experience in this regard? Can you confirm?

Quite satisfactory. In more recent versions of Mac OS, all my Macs will sometimes (not frequently, mind you) disconnect from the wireless network or fail to reconnect automatically after exiting sleep. The old 2009 MacBook Pro has been running Mac OS X 10.6.8 for the past two weeks and its connection to the home wireless network has been very stable and reliable.

Prove Thine Worth Mac Os Download

Another place where I’ve noticed more reliability compared to more recent Mac OS versions is when connected to other Macs for file sharing. Sending or retrieving sizeable files from my two Macs running High Sierra can sometimes fail with what can only be described as a network timeout: the copy process hangs for no apparent reason and never resumes, and I have to abort by relaunching the Finder. With the MacBook Pro running Snow Leopard this has never happened so far, and I’ve shared several large files in the past two weeks between it and my iMac running High Sierra.

In my previous article, I mentioned two very usable browsers you can try to surf the Web under Snow Leopard, as Safari 5.1.10 is too old and unsupported. Jeremy reminded me of TenFourFox, which is more up-to-date. Since TenFourFox is a PowerPC-based browser, at first I thought Jeremy was suggesting running it under Snow Leopard via Rosetta, but it doesn’t work anyway. When I reread his tweet, I realised he said TenFourFox for Snow Leopard. I hadn’t realised there was a separate project for Intel Macs. Anyway, after some Web searching, I found TenFourFox Intel (a.k.a. “TenSixFox”), and also another project, called Arctic-Fox, which seems fairly recent as well. I haven’t had the time to properly test either, unfortunately.

Another thing I wrote in my previous article was about the little-to-no iCloud functionality under Snow Leopard:

Prove Thine Worth Mac Os 11

Predictably, iCloud (still called MobileMe in Snow Leopard) doesn’t work either. Login fails in the System Preference MobileMe pane and when setting up an iCloud account in Mail. The only way to access iCloud is therefore via the Web.

In the same tweet, Jeremy mentioned that he has been able to set up iCloud email accounts by using the direct incoming/outcoming mail server addresses and configuration. So I went back to Mail and tried again, but even creating a new account and manually entering all the settings found at this Apple Support page, I still was unable to set up an iCloud account. Mail kept telling me that “the icloud.com IMAP server rejected the password” for my account.

And with this, I think it’s all for now. I still welcome feedback via Twitter or email, and may write further updates on this subject in the future.

Prove Thine Worth Mac OS

Leave a Reply

Cancel reply