So what happened to the OpenRPN website (www.openrpn.org)?

Last update I can find in the web archives is Aug 28th, 2005.

I'm curious to see all the details people have been talking about but can't find anything.

Also, from what details of the proposed hardware I could find, it seems not that dissimilar to the 50G (e.g ARM processor, graphic screen (colour? - why??), AAA batteries etc)
Has anyone given any thought to simply writing custom firmware for the 50G? (probably possible given that it has FLASH memory). Or does the 50G hardware suck so much that the point is for the project to be just as much a hardware project as a software project?

Dave.

Quote:

---

So what happened to the OpenRPN website (www.openrpn.org)?

---

You should probably try the OpenRPN SourceForge site instead.

- Thomas

Edited: 27 May 2007, 1:18 a.m.

Quote:

---

You should probably try the OpenRPN SourceForge site instead.

---

I have, and all I can see is some C code, a screen shot, and a link to the non-functioning documentation site at doc.openrpn.org

Dave.

IIRC, Hugh Evans will reopen an OpenRPN site soon, i.e. within some weeks.

What I remember being published in the old site:

• Dimensional specs for housings, keys, LCDs including CAD drawings (or sketches, since no dimensions were given there)
  
• Electronic specs for LCDs, processors, I/O interfaces
  
• Keyboard layouts (some published also in this forum)
  
• Function sets
  
• Software specs and sets as Paul mentioned
  

Being a project initiated in the USA, an elaborated vision and mission statement and more marketing stuff seemed to be inevitable, though not supporting the progress too much. IMHO, however, the specs were neither complete nor completely consistent at the time I last looked at them. Maintaining the project documentation was a topic with space for improvement, though not the only one. Nobody is perfect.

I've got some of the specs copied and all of the layouts, but Hugh is the project head, so your request should be addressed to his attention.

Edited: 27 May 2007, 3:09 a.m.

OpenRPN.org will be coming back online. I'm back in touch with my old cohort Chad regarding this.

In response to your question, I have considered porting *fix to the 49G+/50g although I have determined that it is too much work and too far from our actual goals.

Ummm... Graphical FSTN reflective LCD, but not color. Just the best grayscale available.

The overall point is that people want something close a voyager or pioneer, they already have the 50g for graphing. As I said in an earlier post, people would like classic calculators with improved modern electronics.

Send me an email for any more discussion on this. The people around here have heard far too much of it already.

Quote:

---

OpenRPN.org will be coming back online. I'm back in touch with my old cohort Chad regarding this.

In response to your question, I have considered porting *fix to the 49G+/50g although I have determined that it is too much work and too far from our actual goals.

Ummm... Graphical FSTN reflective LCD, but not color. Just the best grayscale available.

The overall point is that people want something close a voyager or pioneer, they already have the 50g for graphing. As I said in an earlier post, people would like classic calculators with improved modern electronics.

---

That's what I thought. It's just that I stumbled across and old post of yours that mentioned a colour graphics screen as being one of the goals.
I believe you would be right to stick with the classic model.
I believe many people would even be happy with a non-programmable model.

Dave.

Quote:

---

I believe many people would even be happy with a non-programmable model.

---

I'm leaning more to this view over time.

I've come to the conclusion that an RPL based device is overkill and probably unwarranted. RPN is good enough for most purposes even if it lacks the elegance of an RPL model. Internally, I've no objection to RPL/*fix, that is a different matter entirely.

What is important is a rich enough function set (whatever that means) and numerical stability and accuracy (i.e. all functions accurate to at worst 1 ULP).

- Pauli

Edited: 27 May 2007, 9:20 p.m.

Another 48/49 clone with RPL and non-4-level stack will not be warmly received. At least going back and doing Woodstock or Pioneers will address a replacement market for the fervently loyal.

Why buy such a 48/49-like product when there's new & used ones available? Who (other than starving students) really uses a CAS system when they have PC software available? It's overkill.

This "project" has grown into creeping featurism - heavyduty ARM CPU, etc.

If someone gave me a 48/49 calc, I might use it for a wheel chock for my truck. I've given away two 48s - they're useless too me: too much in too small of a box.

Many others here probably feel the same - 48/49 is overkill, if we need that much functionality we can go use Matlab, Maple, etc. on a PC.

A nicely-done 41CX/42S/15C (or some combination thereof) - with XYZT+L stack and a large Enter key - is the functionality that I think many or most here want. An alternate idea might be to support 71B BASIC programmability with a regular RPN calc 'front end' for direct-mode use.

In any case, it appears everyone is worried about which CPU or which LCD, etc. All these are relatively trivial decisions, and which are academically fun to make but which are kinda useless since any HP calc can be emulated on any reasonable 8-bit microcontroller these days.

Y'all are thinking like EEs, where all problems are electronic-related - which they often aren't. Packaging is key, and no one has addressed this for any manufacturability.

It will cost about the same to get a 40 key calc produced whether or not it has a fancy CPU.

The real issue in making this come to fruition is packaging and
keytop issues. These require a chunk of money for NRE, and since no one rationally will drop $50K min to get this started, choice of CPU is irrelevant as it's all an academic exercise.

Bill Wiese
San Jose CA

hi bill,

i agree with your points, probably all of them except that i have a slightly different take on the CPU. i have forgotten where my 48 is, but still use my 15c daily.

because CPUs are now cheap, makers think we want CAS, as you point out, this is mistaken because for anything even slightly complicated people will use their PC. i am typing this message on a PC only about twice the size of a 48 - but it can run a full up CAS and can display results in hires. this is not the realm for calculators.

my take on the CPU is that cheap performance should be deployed in other ways for pocket devices. this october, i plan to give a talk at the HPCC conference in london UK, on a new way to calculate. right now i have only some rough notes, but i do have some working software.

without giving too much away at this time, i want to show how you can go right back to basics with artihmetic itself and redo it another way. the result is a pocket calculator (im using the 50g platform as my example HW) that performs numerical calculation, not at all a CAS, without error. for example, punch in sin(60!), it displays, 0.949360891195. im also hoping to show how to perform numerical integration without error which would be interesting.

its what i think calculators shoule be like rather than simply piling on more and more features.

Amen. The electronics are the easy and cheap part to produce, since tooling costs, etc. don't exist. The bulk of the work I do on OpenRPN is finding and in some cases developing manufacturing processes to cut down on startup costs.

If we wanted to just get these things into production immediately, it would cost at least $50k to get the ball rolling. My goal is to cut that number drastically, or produce a few prototypes and license it to a bigger company that thinks the product is worthwhile (this could be one of the smartest moves HP was made in decades).

-Hugh

That sounds like a very interesting project. Yet another reason why I think many people will buy the OpenRPN hardware to develop ideas like your own and have a platform that will run it.

-Hugh Evans

I've been reading this thread about a better HP calculator and what pops in my head is how complex the RPL machines have become. I'm not a programmer but I can't get my head around all the things a 49g+ or a 50g can do.

If I were to design a calculator, I would want it to have different layers a functionality. The first layer would be a simple scientific calculator without programmability that would give a beginner easy access to just what he needs.

The second layer would have simple programming included so that when a user is ready, they can experiment with that. The final layer would contain the full functionality of the calculator for the user who is ready for that.

I know this sounds rather simplistic, but I think the first step in a new calculator is to make it very useful to a new owner right from the start. The steep learning curves of present calculators make it difficult for a beginner to find the calculator useful. It also doesn't help that HP's documentation is so poor.

-----------------
for example, punch in sin(60!), it displays, 0.949360891195.
-----------------

Here's an example. I punched sin(60!)into my 49g+ (Revision #2.09) and got 0.342020143326. I don't have my 50g (also #2.09) with me to check but why the difference? I tried both in RPN and ALG and got the same answer.

I find that very frustrating.

Gerry

I made this suggestion to HP at the last HHCC conference. RPL is too complex for the average user, but it is darned nice for the calculator geek. So have an interface that "unfolds" in front of the user. The first layer is a basic scientific or financial, perhaps, with somewhat limited functionality. Unfold that, and you have keystroke programmability, ala the 42S, but updated. Next you have User RPL, or something like it. Each of these layers can interact with the one below it, or the one above if it is enabled. So, for example, the RPN programming can call the RPL if that is turned on.

But the points made by others in this thread are well taken. It's hard for me to see how to implement that without switching keyboards. The new TIs do that, so it isn't impossible. But it's very likely to add to the baseline cost. Since nobody can come up with the costs projected for simpler designs, it's doubtful this pipe dream would be feasible.

I'm fascinated by hugh steer's teaser, however. A reinvention of the calculator is more likely to come from that direction than from any hardware innovations.

Regards,
Howard

Frankly,

We should just talk to Kinpo and do a 'prototype' run for 'market investigation'.

Use an existing kinpo calc and we do our own firmware - just port over 41C emulator etc.

Frankly a nonprogrammable shirt-pocket sized TI25X with 4-level RPN, large enter key, hex/binary/dec conversion & logic functions and PV/FV/i/PMT/n functionality would be a very useful device.

Bill Wiese
San Jose CA

Quote:

---

It also doesn't help that HP's documentation is so poor.

----------------- for example, punch in sin(60!), it displays, 0.949360891195. -----------------

Here's an example. I punched sin(60!)into my 49g+ (Revision #2.09) and got 0.342020143326. I don't have my 50g (also #2.09) with me to check but why the difference? I tried both in RPN and ALG and got the same answer.

I find that very frustrating.

---

I don't have an HP-49G+ or its documentation available, but that's a really bad example. First of all, the angular mode makes a difference in the result. Secondly, "60 factorial" has more than 12 digits that precede the string of 14 trailing zeroes. So, the correct result is theoretically achievable only in exact mode.

My HP-49G in exact mode will return 0.34202014333 as the sine of "60 FACT" degrees. However, so do all my Saturn-based 12-digit HP's lacking exact mode.

The HP-49G correctly returns 0 in exact mode for MOD(60!, 360), as 60! = 60*6*[an integer product of the remaining terms]. So, zero is the correct answer for sine, which is achievable if MOD were internally performed in degree mode using 360. Either the internal MOD or the SIN calculation does not utilize the full precision of exact-mode integers.

The HP-42S, lacking exact mode, returns 160 for MOD(60!, 360), which must be based upon the limit of precision available:
(60! / 1E68) / 360 yields a full 12-digit integer (231,138,530,909); MOD (60!, 360) yields a result of 160, which does not change as 60! is divided by powers of 10 that are lower than 68. The sine of 160 degrees is indeed 0.342020143326.

Please see this thread:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=109071#109071

Edited: 31 May 2007, 1:35 a.m. after one or more responses were posted

Actually, I may give that idea a shot. If they can produce machines using my designs and specifications that's all that matters.

This is very interesting. I wonder what mathematical trick you use to calculate sin(60!) apart from having PI in ROM (or recalculating it) to lots of significant digits. I understand that if we can do sin(N) with N a big integer the case of sin(X) with X a big real number is simple. Thanks for sharing if possible.

My guess would be that, in exact mode, there are a few special-case checks for numbers like 60 degrees (mod 360); that check would have to be performed *before* converting the angle to radians.


Free42 performs such checks, but only for multiples of 90 degrees or 100 grads (SIN, COS, ->REC), and for multiples of 45 degrees or 50 grads (TAN). However, note that getting cases like sin(60!) right requires arbitrary-precision math.

- Thomas

I suspect Hugh was talking radians in his original message. Using wcalc, I get his answer in radians and 0 in degrees mode.

- Pauli

indeed!

my point is simply that there should be a handheld calculator for manual calculation that has no exact mode or non-exact mode, whatever, which is simple to use and doesn't have special modes that either gives the right answer or tells you it can't do it with no wrong answers.

i think that's a reasonable thing to ask.

Quote:

---

I don't have an HP-49G+ or its documentation available, but that's a really bad example. First of all, the angular mode makes a difference in the result. Secondly, "60 factorial" has more than 12 digits that precede the string of 14 trailing zeroes. So, the correct result is theoretically achievable only in exact mode.

My HP-49G in exact mode will return 0.34202014333 as the sine of "60 FACT" degrees. However, so do all my Saturn-based 12-digit HP's lacking exact mode.

The HP-49G correctly returns 0 in exact mode for MOD(60!, 360), as 60! = 60*6*[an integer product of the remaining terms]. So, zero is the correct answer for sine, which is achievable if MOD were internally performed in degree mode using 360. Either the internal MOD or the SIN calculation does not utilize the full precision of exact-mode integers.

---

My HP-49G has old firmware, version 1.05; I've never updated it.

When I calculate 60 FACT on it in exact and degrees mode, I get 8320987...00000; when I then press SIN, I get SIN(8320987...000000). I have to then do ->NUM to get it to return .342020143326. It's apparently converting the many digits of 60! to approximate mode before calculating SIN.

I get the same behavior in exact and radians mode. If I do 60 FACT SIN, I get SIN(8320987...000000). Doing ->NUM then returns 8.40001652835E-2.

On the other hand, on the HP49g+, in exact and degrees mode, if I do 60 FACT SIN, I get 0. The HP49g+ is apparently doing a 360 MOD in exact mode before passing the result to the SIN function.

If I do 60 FACT SIN in exact and radians mode, I get SIN(8320987...000000), the same as the HP49G.

If I switch to degrees mode with SIN(8320987...000000) still on the stack and do ->NUM, I get .342020143326. In this case, the 360 MOD isn't done in exact mode before executing the SIN function; apparently the SIN function's own internal, approximate mode 360 MOD is done.

60! is not 60 degrees or a multiple thereof, it is exactly (60!*180/PI) degrees. The fractional part of this number is very hard to find with only 15-digits PI. The trick is was I was asking for.