Color calculators

[Mic]

Hello, here is a comparative of the technical features of the color calculators of the market (HP included) :

http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1913

[Ron Ross]

Actually, your comparision isn't fair. Why? Because the Hp Prime is not yet on the market. Ti might be just about to release a Ti Nspire ++ SUPER PRIME!!! with even better features. Now, even skeptical me believes we will get to buy an Hp Prime this fall, but there were many who thought they might get to buy an Hp Xpander and never got that chance either!!!

Onto my own opinion, which I love to share: Color, meh!!, but it will open up the calculator to more prospective buyers, so a good thing. And if the resolution and clarity are excellent, it becomes a game machine which will drive up sales and mayyybeeee, lower the price. Well at least it will be more widely available so all of us can buy an RPN SCIENTIFIC calculator well into the forseeable future. Ten years ago, that wouldn't have been such an easy statement to make.

Thinner.... YEAH!! a good modification. Better would be to offer a pocket calculator with an HDMI port, external Keyboard, and other expandable features and keep the basic calculator the size of an Hp42s.

New programming language... Probably an improvement so as to reach out to more conventional programmers, but I still like RPL and will probably like RPL better years from now.

Keyboard layout... Looks like a home run for most of the features (aside from the silly x^2 key). But that might be a needed feature for the calculator in EOS mode. Enter key is needlessly oversized, but that appeals to many dinosaurs, me included. Some may say it is on the wrong side, but the reality is, where are the operation keys? Operation keys determine where the Enter Key should be. Once the operation keys moved to the right side of the caluclator on vertical format Hp's, the Enter Key should have moved with them, and the Hp50G (49G actually) got that right!

If the new OS is coded directly to the CPU instead of emulating a Saturn, another GOOD thing. The system will be FAST!!! And we all like FAST!!

Enough of my ramblings for now.

[Tim Wessman]

Well, in terms of fast...

Addition loop test results in ~10000000 over 1 minute. NQueens is about ~.4s. Savage is about ~.6s.

At least the last time I checked a while back.

TW

[Gerson W. Barbosa]

It's a pity \/x and x^-1 are not primary functions - and next to y^x, like on the HP-48GX. At least SIN, COS and TAN are where they should be.

Quote:

---

last time I checked a while back

---

Envy, is that what you want us to feel? :-)

Gerson.

[Tim Wessman]

Well, good thing you can redefine the keys if you want... :-)

For those wondering how this is done, it is actually done through the creation of small functions in your program files. Since each "app" consists of a data file, a program, and a note, you can actually have user defined keys that vary from application to application if desired.

KEY K_Comma()

BEGIN

  86; //keycode for INV

END;

Now your comma button is the INV key.

TW

Edited: 29 Apr 2013, 4:17 p.m.

[Artur-Brazil]

Hi, Tim

If you could expend some time answering my question: why HP didn't follow a line, when we talk about programm language? Why to use something like Pascal/BASIC when the commands don't have nothing to do with calculator's keyboard functions and commands?
If the pourpose of calculators are to be simple, why obligate users to memorize two lines of approaching: one is what you see on keyboard (and probably on menus) and other is the commands involved in programs?
Worst, if this new language has to be interpreted to keyboard commands, it will bring an overload and extended execution time.
Even worst is to learn a new language to rewrite my (and a ton of other people) old programms.
I'm not a complete adicted to RPL, as I believe it lacks of many facilities, but it worked very well considering your were using a calculator, and all the calculators commands were used as they are, not as a new command.
Best regards and congrats to HP on the new model!
Artur - Brazil

[Tim Wessman]

Quote:

---

why HP didn't follow a line, when we talk about programm language? Why to use something like Pascal/BASIC when the commands don't have nothing to do with calculator's keyboard functions and commands?

---

We did follow a line. The internal bits of the programs are exactly the same as what would be used for doing calculations in an algebraic manner. It also is very, very consistent with the most common programing languages and concepts in wide use.

However, what you seem to be fixating on is the structure around that. When you get right down to it, what does DSE or RTN have to do with using the calculator? Those are structural words or logical words used to give order - not things used during operation or calculation.

When you have more complex systems, there needs to be ways to organize those capabilities. Hence you have multiple layers on things like the 48 series:

1. simple defined functions << -> 'stuff' >>

2. more complicated functions with logic and structure << << >> IFTE >>

3. Ability to create objects and use those as subroutines. Group them into libraries and so on.

It is no different in the new system. You can do very simple things and need to learn nothing more then the normal operation of the calculator. Or you can learn the more advanced logic and steps to do more things and have control and power.

I personally have never understood those that complain about RPN vs RPL programming. Yes, RPL does have more difficult things once you hit interaction with complicated UI stuff, or doing very complicated things, but if you want to use it exactly the same as RPN style programs just make your program using nothing but key presses and it is essentially identical. I guess it really comes down to what you are used to doing more then anything else...

Quote:

---

Worst, if this new language has to be interpreted to keyboard commands, it will bring an overload and extended execution time.

---

There is no interpretation to keyboard commands. It is compiled down to pointers to internal function calls.

TW

[Artur-Brazil]

Many thanks, Tim!

I hope I can put my hands on it as soon as possible. So, I'll understand your words and see the real impact.

Thanks your efforts and of your team!

Artur

[bhtooefr]

There is, to be fair, one major difference between RPN and RPL, when using it as a keystroke program, and that's how the stack works.

Programmatic RPL stack manipulation makes my head hurt some unless I step through each step of the stack manipulation, so I'll admit that I pull everything into local variables, rather than manipulate the stack to get things where I want them. Which, actually, makes RPL start working more like a procedural language, which isn't a bad thing... (If you think about it, normal commands on an RPN calc don't wipe out your stack (except for the T level of a Classic series?), but keystroke programs do. RPL, you don't have to worry about wiping out the stack, but you have local variables so you don't have to do everything on the stack.) Also, RPL doesn't have the copy down from T automatically trick, which is handy on an RPN calc.

But, that affects using it as a calculator, too.

Examples of what I'm talking about, for a program to calculate display PPI, written for both RPN and RPL (supply width in pixels, height in pixels, diagonal in inches on the stack):

RPN:

01 LBL"PPI

02 X^2

03 0

04 R^

05 +

06 R^

07 /

08 X^2

09 1

10 +

11 /

12 SQRT

13 /

RPL:

« -> W H D

   « W H / -> A

      « H D SQ A SQ 1. + / SQRT /

      »

   »

»

(BTW, that code isn't exactly complex (basically being a little bit wrapped around the Pythagorean theorem), but consider it licensed under WTFPL v2. Read: do what TF you want to.)

Edited: 30 Apr 2013, 2:57 p.m.

[Artur-Brazil]

Hi,

I was very upset about RPL when I bought the first 48SX!
The differences as you told on stack almost kill me, but, with use, I got acostumed to them and now, I use it flowlesly.
I agree with you about local and directory variables and I use them a lot.
Even the compiled local variables got their chance about two weeks ago, when I made one statistical program and did an inter subroutine in a programm << << subroutine >> -> localvarSub << localvarSub eval >> >> something like this, as external variables weren't visible by this routine.

My question was about HP has changed the program language on new model. Tim has argumented about if, loops and other structures, but, all of them could be used in algebric or RPN mode in 50G or 48G. Even from keyboard. Now, I believe, I'll be forced to use a new language having nothing to what I can see on keyboard (more or less this).
Artur

[cyrille de Brébisson]

[Also, RPL doesn't have the copy down from T automatically trick, which is handy on an RPN calc]

but in exchange you get infinite stack level which is a hell of a lot better...

RPN has a LOT of limitations due to the fact that it has only 4 stak levels.

RPL removes the 4 stack level limitation, but the result is a more complex system because you now need to handle an unknow number of stack levels, hence the DEPTH, ROLLD, ROLL, DROPN...

cyrille

[Thomas Klemm]

Sometimes I miss the return stack manipulation of FORTH:

• >R "to-R"
  
• R> "R-from"
  
• R@ "R-fetch"
  

Only to get an element out of the way and bring it back later. Didn't had to be the return stack though.

Cheers

Thomas

[Walter B]

Quote:

---

[Also, RPL doesn't have the copy down from T automatically trick, which is handy on an RPN calc]

but in exchange you get infinite stack level which is a hell of a lot better...

RPN has a LOT of limitations due to the fact that it has only 4 stak levels.

---

IMHO, WP 34S cures most of the real life part of those limitations since it allows for 8 stack levels within RPN. And I won't start the discussion about repellent sytems again ...

d:-)

[Gerson W. Barbosa]

Quote:

---

And I won't start the discussion about repellent sytems again ...

---

RePeLlent? To me, RPL might stand for a Real Programming Language, without the limitations of RPN, no matter the size of the stack. RPL is a high-level, list-processing structured language. RPN is basically a low-level keystroke language. Not that I don't like it, quite the contrary, especially the WP-34S version of it, but a skilled RPL programmer, which I am not, might feel towards RPN the same feeling you have regarding RPL, and we cannot criticize him/her for that.

_{Edited for clarity}

Edited: 1 May 2013, 9:20 a.m.

[Thomas Klemm]

Quote:

---

that code isn't exactly complex

---

Why not using:

RPN

00 { 11-Byte Prgm }

01 LBL "PPI"

02 RDN

03 ->POL

04 R^

05 /

06 END

RPL

\<<

  ROT ROT

  R\->C ABS

  SWAP /

\>>

Or if you prefer local variables:

\<<

  \-> W H D

  \<<

    W H R\->C ABS

    D /

  \>>

\>>

Kind regards

Thomas

[Werner]

or,

\<< \-> W H D 'ABS((W,H))/D' \>>

Werner

[Gilles Carpentier]

\<< \-> W H D 'ABS((W,H))/D' \>> 'PPI' STO

I like this way to do in RPL ... or more easy (but same result) just :

'PPI(W,H,D)=ABS((W,H))/D' DEFINE

And then you can do

`PPI(1,2,3)`
or
1 2 3 PPI

or such things like

'PPI(1,2,X)=2' EVAL SOLVEVX

to get "X=sqrt(5)/2'

It's a so easy and logic way to do !

Edited: 1 May 2013, 3:09 p.m.

[bhtooefr]

...Good point.

(I will, however, note that I do have an RPN scientific programmable calc that can't actually do rectangular to polar conversions automatically. (And, that code would work on the financials, too.) It's not an HP, mind you.)

[Thomas Klemm]

But even then this would be easier:

RDN

x2

x<>y

x2

+

SQRT

R^

/

Cheers

Thomas

[bhtooefr]

Playing around with V41, I think your code might actually be slightly faster, although it's hard to measure even on minimum speed. (Which makes sense, R->P is producing two results, when we're only interested in one.)

Both are faster than my crazy stack manipulations, so... thanks for the improvement. (I'm not sure why I didn't think of doing it that way...)

[bhtooefr]

On an Elektronika MK-61, my original code vs. Thomas's code... mine takes 4.5 seconds (it's doing more math and more stack manipulation, so...), Thomas's takes right about 3 seconds.

MK-61 adaptation of my code (no R^, so...):

x^2 0 RDN RDN RDN + RDN RDN RDN / x^2 1 + / SQRT / R/S

MK-61 adaptation of Thomas's code:

RDN x^2 x<>y x^2 + SQRT RDN RDN RDN / R/S

I have a suspicion that I did things the way I did it because I wanted the aspect ratio for some additional calculation, but I ended up consuming it anyway. But, the aspect ratio doesn't even matter if PPI is really all you're after...

[Thomas Klemm]

This variant uses the aspect ratio but needs hyperbolic trigonometric functions to calculate:

00 { 19-Byte Prgm }

01 LBL "PPI"

02 0

03 R^

04 +

05 R^

06 /

07 ASINH

08 COSH

09 /

10 /

11 END

But even without that you could still save one step on the MK-61:

0 RDN RDN RDN + RDN RDN RDN / x^2 1 + SQRT / / R/S

Cheers

Thomas

[bhtooefr]

Although, I've run into a quirk of the MK-61, with your modification.

It seems that the MK-61 doesn't terminate entry when you start a program, unlike every HP calculator.

Meaning, the 0 in the program actually gets appended to the end of the screen diagonal, unless either an Enter is added to the program's beginning, or the run sequence is Enter, GTO 00 (which, there's actually a dedicated button for GTO 00), R/S. (That's not what the keys actually say, but what they mean, for what it's worth.)

And, I just tried it with an Enter, it seemed slower than my code. Which is odd, as my code's doing more math.

In any case, both of those are discarding the actual aspect ratio, which means it's pointless to use it until things are rejiggered to actually return it. (Now that's my next project. Bonus points if I can actually do it without touching registers. I'm thinking it's possible with some addition and subtraction, because it means I can keep a copy of W+H, H, aspect, and diagonal in the stack. Then it's just a game of stack manipulation to keep everything I need in there. But, that's tomorrow morning's project.)

[bhtooefr]

Figured out a listing that should work on a MK-61 (I don't have my MK-61 with me right now, though, just my DM-15CC), and keeps the aspect ratio. This will be atrociously slow because I kept it entirely to the stack (I'm of the opinion that register use is to be avoided if at all possible, because the user may have meaningful data in registers), meaning there's an extra subtraction and an extra square root (because I needed to have the aspect ratio squared + 1, and I couldn't keep a spare copy of the aspect ratio around and have enough room in the 4-level stack).

It might be faster to use the height, rather than the width, to calculate the actual PPI (eliminates a multiplication), but it'll require more stack gymnastics, making the program longer, and stack gymnastics seem to be VERY SLOW on the MK-61.

The listing is in FOCAL format, but only does things that can be replicated on an MK-61 (except for the R^, but that's easy to fake).

01 LBL"PPI (replace with ENTER^ on an MK-61)

02 0

03 +

04 RDN

05 /

06 x^2

07 1

08 +

09 ENTER^

10 R^ (replace with 3x RDN on an MK-61)

11 x^2

12 x<>y

13 /

14 SQRT

15 x<>y

16 1

17 -

18 SQRT

19 ENTER^

20 RDN

21 *

22 /

23 RTN

Pretty ugly, but it doesn't touch registers at all. (My rule of thumb on an RPN machine is, the user may have valuable information in a register, so don't touch them if at all possible. My rule of thumb on an RPL machine is, the user may have valuable information on the stack, so restrict stack manipulation to the arguments and intermediate calculations (and don't pollute the stack with useless intermediate calculations, either), and the user DOES have valuable information in global variables, so never touch them (yes, I know, there's legitimate uses for them, but what I'm doing doesn't need to save data between program runs), use local variables instead (but, on an RPL machine, you can use the stack, too, my mind just works better with pulling the arguments in as local variables, and operating on them that way).)

[Thomas Klemm]

This or the similar program should be running on MK-61 as well:

00 { 22-Byte Prgm }

01 LBL "PPI"

02 X<>Y

03 ENTER

04 RDN

05 /

06 X<>Y

07 R^

08 /

09 ENTER

10 X^2

11 1

12 +

13 SQRT

14 R^

15 /

16 END

Just out of curiosity: is there a LASTX on the MK-61?

Cheers

Thomas

Edited: 2 May 2013, 1:13 p.m.

[bhtooefr]

There is, hmm, that gives another virtual level of the stack if it's used quickly (do calculation, grab Last X, avoid stack gymnastics). I wouldn't be surprised if its behavior is a bit weird, though, based on weirdness I've seen in other places.

And, I've clearly not had to do much with math or coding in quite a while - I should've realized that the hypotenuse never actually had to be squared and square rooted...

[Thomas Klemm]

If hmm is similar to LASTx you could use the following:

00 { 20-Byte Prgm }

01 LBL "PPI"

02 X<>Y

03 /

04 X<>Y

05 LASTX

06 /

07 ENTER

08 X^2

09 1

10 +

11 SQRT

12 R^

13 /

14 END

Meanwhile I found this MK 61 emulator. However <-> affects Bx thus this program wont give the expected result unfortunately.

Cheers

Thomas

PS: I might have misinterpreted hmm. Is that a key?

[bhtooefr]

No, hmm is me typing in a manner similar to which I speak: http://en.wiktionary.org/wiki/hmm

I'm consistent with using the HP-equivalent mnemonics exclusively when discussing this calculator. (Note, for what it's worth, Y^X isn't a thing, it's X^Y like an HP-35. The key is labeled that way, though.)

In any case, the actual LASTX key on this calculator is marked as Bx; (F shift, B^ (which is enter)).

Oh, and I think there's only one emulator that claims to be a microcode emulator (they got the ROMs via optical dumping), but either they're doing weird things with the character ROM, or they're running modified code.

Edited: 2 May 2013, 4:23 p.m.

[Thomas Klemm]

This also works in that aforementioned emulator:

00 { 25-Byte Prgm }

01 LBL "PPI"

02 X<>Y

03 /

04 LASTX

05 X<>Y

06 RDN

07 /

08 X<>Y

09 RDN

10 ENTER

11 X^2

12 1

13 +

14 SQRT

15 RDN

16 RDN

17 RDN

18 /

19 END

Cheers and thanks for leading me to the MK-61.

Thomas

[bhtooefr]

Benchmarks on the MK-61:

My program: ~7 seconds

Your 22-byte program not using LASTX: ~5.2 seconds

Your 20-byte program using LASTX: Erroneous results after about 4.2 seconds, seems that X<>Y is an operator (a lot of things are operators on this calc, CHS is an operator, unless you're working on an exponent), like you found out.

Your 25-byte program using LASTX: ~5 seconds

Now I almost want to start screwing with the timing circuitry of this calc, to slow it down, and get more accurate instruction timings for every thing that can be done on it.

Edited: 2 May 2013, 6:02 p.m.

[Thomas Klemm]

Just noticed how slow these calculators are:

 Calculator Speed Benchmark using the N-Queens Problem

-------------------------------------------------------

 -

 - 5:00:00         MK-52             Keystroke / RPN

 -

 - 4:45:00         MK-61             Keystroke / RPN

Not so important but the 22-byte program uses [R^] twice whereas in the 25-byte program instead of [R^] three times [RDN] is used. So it's rather 26-bytes versus 25-bytes. At least that would explain why the first program takes longer.

[Paul Dale]

The Elektronica models are amazingly slow. Quite a bit slower than the slowest HP ever produced.

- Pauli

[bhtooefr]

That said, I just ran the N-Queens benchmark on my 61, and it completed somewhere between 4:20:00 and 4:28:00. (Had to grab my step-up transformer from my storage unit, didn't want to run it that long on AAs. And, didn't get the exact end time because I thought I was safe to fold clothes during that time. In any case, I wouldn't expect times on these to be exact, they're probably using a very imprecise timing circuit, and it's probably temperature and supply voltage dependent.)

Edited: 6 May 2013, 8:47 p.m.

[fhub]

Tim, is there already a working emulator for the HP-Prime available?

I would be especially interested in trying/testing the included CAS.

Franz

[Patrice]

Hi Franz,

You can guess a few things as a high probability.

Quote:

---

Tim, is there already a working emulator for the HP-Prime available?

---

-a working emulator? in this kind of project, it is the first thing done, so the answer is YES.

-available (publicly)? no, not until HP decide otherwise, usually not before sells begins.

You want an emulator now or a "prototype/early product"? You have to be on Tim's short list for a reason or another. It is obvious that he can't answer "Yes" to every request.

Patrice

[fhub]

Hi Patrice,

Quote:

---

-a working emulator? in this kind of project, it is the first thing done, so the answer is YES.

---

you're right and of course I know that. My question was rather thought as a reminder for Tim that there's someone (me!) who is VERY interested in all kinds of emulators (especially HP). ;-)

Quote:

---

-available (publicly)? no, not until HP decide otherwise, usually not before sells begins.

---

That's something where I can't agree with you. Just remember the HP-39gII emulator: it has also been available before the real calculator, and I'd say that this makes much sense - so many people could test the firmware (and maybe find many bugs) before the official release.

Quote:

---

You want an emulator now or a "prototype/early product"? You have to be on Tim's short list for a reason or another. It is obvious that he can't answer "Yes" to every request.

---

Well, Tim already knows me (from testing the 39gII emulator), so he could also have answered via email (if he really don't want to give a public answer here).

And with my almost 30-years experience with all kinds of CAS (I was even involved in the development of muMath and Derive long time ago!), I guess I won't be the worst tester for a new CAS as implemented in the HP-Prime. ;-)

Franz

[Tim Wessman]

I'm sure you would be a good tester. However, when you publicly offer, and do, remove protections put in place by HP on our calculator software and then send that to people... that essentially eliminates the possibly right there.

TW

Edited: 30 Apr 2013, 9:34 p.m.

[Walter B]

Tja, the internet never forgets nothing.

d;-)

[fhub]

Quote:

---

However, when you publicly offer, and do, remove protections put in place by HP on our calculator software and then send that to people... that essentially eliminates the possibly right there.

---

Well, I guess I've to put a few things right:

What you write sounds as if I were an usual 'hacker' who publishes cracked versions of HP emulators for everyone!?

But what I did in fact was just helping 2 or 3 members here who had problems with their legally (!) bought HP-emulators, when either their activation code was wrong (or not working) or the connection to the HP activation/update server failed.

And if you were talking about this last (unreliable) HP-39gII update a few days ago:

Well, this 39gII emulator never had any activation code, and was free for everyone (distributed on many different websites, e.g. HP-dealers, Calc-Bank etc.).

So the activation code requirement in this 'update' could only be a mistake (even the HP-dealer from Netherlands included a set of activation codes in his package!).

But of course I accept your decision - and it will certainly never happen again that I try to help any HP user with any problems he has with his HP software!

Franz

PS: I forgot: in all the last updates of the HP-emulators (released just a few months ago) HP has completely removed this activation code - so what?

Edited: 1 May 2013, 7:28 a.m. after one or more responses were posted

[Walter B]

Quote:

---

But of course I accept your decision - and it will certainly never happen again that I try to help any HP user with any problems he has with his HP software!

---

Don't be afraid - Franz will be back again like 123 times before. Certainly! He is known for keeping such promises.

d:-/

[Jeroen Van Nieuwenhove]

Well, that's a pity because these protections were poorly implemented in the first place and constituted an unnecessary hindrance for legitimate users. But, as Franz answered, it is HP's call.

[Thomas Klemm]

Quote:

---

NQueens is about ~.4s.

---

Calculator Speed Benchmark using the N-Queens Problem

 -       0.55      HP-41CL           Mcode / Turbo20 Mode x19.6

 -

 -       0.385     PC-1360           Assembly / SC61860 @ 1.6 MHz / Turbo x2.1

 -

 -       0.344     PB-1000           Assembly / HD61700 @ 0.91 MHz

 -

 -       0.336     HP-48GX           Assembly / Saturn @ 3.7-4.0 MHz

Should we be impressed by that?

Cheers

Thomas

[Patrice]

Quote:

---

Should we be impressed by that?

---

May be the fact that it is a BASIC language program can help to impress you.

[Mike Morrow]

Quote:

---

May be the fact that it is a BASIC language program can help to impress you.

---

That's exactly what I thought after reading that critical post.

The reported speed of the Prime using its supplied high-level programming language is impressive in the extreme. The Prime results are rivaled on other platforms only through the trick of using a low-level language, most likely compiled off-platform. Plus, those results are for the NQueens benchmark...not exactly a good benchmark for scientific calculation speed. Just imagine the results for the Prime, had low-level programming techniques been used.

So...it appears there is no existing platform that will be even close to the Prime, when compared using an appropriate benchmark operating in a similar programming environment.

Edited: 29 Apr 2013, 4:16 p.m.

[Thomas Klemm]

All I tried to figure out was where would we be with the HP Prime compared to calculators that we are familiar with. And that's what we have: probably a little slower than a HP-48GX using assembler. Now you can imagine writing a game in BASIC and it will be about as fast as it could be on the HP-48GX. And you might be fine with that.

But let's compare that to the fastest result in that list:

 -       0.000150  HP-50G            Assembly / ARM9 @ 192 MHz / Fast Mode x2.7

So it doesn't help much if the OS is fast if all you have is an interpreted programing language that is relatively slow. But sure I can imagine that the HP Prime could be much faster if C/C++ or assembler was supported.

Cheers

Thomas

[Chris Smith]

Indeed. That is pretty slow for even an interpreter which is my worry.

Having dealt with a BASIC variant on ARM years ago (BBC BASIC), I know what is possible and your average 25MHz ARM3 with BBC BASIC could certainly give this interpreter a run for its money at 1/16th of the raw clock speed.

Also on portable devices, expending the least amount of energy (J) per operation is important. I imagine that a fair amount of energy is lost through interpreter internals.

Flat batteries with little work done is a worry, especially when you are having to light up a colour LCD at the same time.

LLVM on device would be nice - your higher level abstraction can be compiled down on the fly...

[Paul Dale]

Was your old basic using correctly rounded decimal floating point arithmetic? This consumes a lot of extra cycles. Correctly rounded binary floating point arithmetic is significantly harder than just doing some kind of binary floating point -- I'd guess you had the last of these three back then.

I'd also assume that the old basic was coded for speed instead of reduced programmer time. Times have changed.

- Pauli

[Eric Smith]

Most floating point implementations to this day do not guarantee correctly rounded results on anything but the basic four arithmetic functions. It's possible to provide correct rounding (result within +/- 1/2 ULP) for transcendentals (within a reasonable domain), but very difficult. Somewhat easier is to guarantee result within +/- 1 ULP, but very few implementations even provide that.

[Paul Dale]

HP's maths libraries do provide some guarantees. At least they used to and my understanding is that the latest versions are a direct derivative of the original Kahan libraries from the 15c et al.

The IEEE standard requires correctly rounded basic arithmetic operations and square root. The GNU standard C library extends this to guaranteed correctly rounded trig functions from memory.

- Pauli

Edited: 30 Apr 2013, 5:38 a.m.

[Eric Smith]

The GNU C library (glibc) does not guarantee correct rounding (+/- 1/2 ULP) or even "faithful rounding" (+/- 1 ULP) for transcendental functions. The HP math libraries up through and including those used on Saturn-based and Saturn-emulating calculators do not either. As far as I know, this means that more recent HP-designed calculators do not. Anyone care to wager whether Kinpo-designed calculators do?

CRlibm is an example of an open-source library that does provide correctly rounded transcendental functions.

It is surprisingly difficult to provide correct rounding for transcendental functions. The proof of correct rounding in CRlibm runs to over 100 pages. Correct rouding can require computing to more than twice as many digits as the desired significand ("mantissa") precision. For example, in IEEE double precision binary floating point (53-bit significand), computing e^x for arguments greater than 2^-30, in the worst case the result has to be computed to 114 bit precision to get correct rounding to the final 53-bit result.

The worst-case requirements for some common transcendental functions haven't even been found, because the search space is so large. As far as I know, no one has published results for worst case for decimal floating point.

See Chapter 10 of Elementary Functions: Algorithms and Implementation, 2ed, by Jean-Michel Muller for details.

Edited: 30 Apr 2013, 3:53 p.m.

[Paul Dale]

From glibc 2.14 sysdeps/ieee754/dbl-64/s_sin.c:

    /* An ultimate sin and  routine. Given an IEEE double machine number x       */

    /* it computes the correctly rounded (to nearest) value of sin(x) or cos(x) */

The code in question first calculates a fast result and then checks if this is correct. If not it runs off into higher precision routines, starting with a double-double representation and then a full multi-precision one.

- Pauli

[Eric Smith]

Interesting. They didn't do that the last time I looked into it, but that was a long time ago. I'm surprised that they don't brag about it in the docs.

I'm not even sure that I want that as the default behavior in the C library. I'd like t to be configurable, or two different API calls. There are times when I 'd rather have fast, near-constant performance at the cost of the extra 1/2 ULP of error bounds.

I wonder how accurate their argument range reduction is. That's also extremely tricky to get right.

[Paul Dale]

They've had this for a while now. IBM wrote the original code from memory.

There is always -ffast-math to use the machine trig instructions directly, at least on the x86 platforms. This also enables direct use of the square root instructions that are rarely fully IEEE compliant. Of course, there is a cost....

The range reduction code looks rather complex but I've no idea as to how good it really is.

- Pauli

[Chris Smith]

I'd like the ability to chose between performance and accuracy myself.

As for accurate decimal floating point types, we used scaled integer types. Very easy, predictable rounding every time and very fast.

I've been writing software for 25 years this year. Reduced programmer time is a fallacy. Abstractions got deeper, APIs got broader, languages gained more features and hardware got more complicated.

With all the above, there is no excuse not to have fast execution and reduced programmer time.

[Gilles Carpentier]

I think it's a very important point.
You can work with matrix, vectors, imaginary numbers, integrals, CAS etc. with this language. The idea is not to compete with assembler or C which are very interesting languages but not easy to use for mathematical or scientific aspects (at least assembler of course, and C is not adapted at all for direct and easy use on a calc).
We will see but it will be interesting to have a direct access to the processor like we can do on the 50G (the n queens test is near zero micro seconds!). But to be honest it would be mainly interesting for games (and 3D and heavy calculations)

In real life if the calculation takes 0.0005 sec or .5 s, imo it's the same. If it takes 5 mn ok.

Edited: 29 Apr 2013, 5:22 p.m.

[Steve Fennell]

Quote:

---

In real life if the calculation takes 0.0005 sec or .5 s, imo it's the same. If it takes 5 mn ok.

---

I got a kick out of that statement. It reminds me of what Heinlein once said. It doesn't matter if it takes 1 millisecond, or 1 nanosecond, as long as the answer is correct. I think that was from The Moon is a Harsh Mistress

[Steve Simpkin]

Quote:

---

I got a kick out of that statement. It reminds me of what Heinlein once said. It doesn't matter if it takes 1 millisecond, or 1 nanosecond, as long as the answer is correct. I think that was from The Moon is a Harsh Mistress

---

"But matters whether you get answer in microsecond rather than millisecond as long as correct?"

I love that book! Heinlein is one of my favorite authors.

[Chris Smith]

It doesn't matter until you have to do it 1,000,000 times...

[Wes Loewer]

Quote:

---

Quote:

---

NQueens is about ~.4s

---

Quote:

---

Should we be impressed by that?

---

May be the fact that it is a BASIC language program can help to impress you.

---

To put this in perspective, a line-for-line port to ti-nspire BASIC has a runtime of about 7 seconds.

(code taken from groups.google.com/d/msg/comp.sys.hp48/t_LvY38fJgI/qc82Ecq9w98J)

-wes

[Raymond Del Tondo]

Quote:

---

May be the fact that it is a BASIC language program can help to impress you.

---

Not really. The Prime seems to be based on a very powerful CPU with wide data paths and the ability to run at several hundreds of MHz.

The HP 48GX, in comparison , features a CPU with ~4 (Four) MHz and a data path of 4 (Four) nibbles width.

The HP 48 version of the n Queens benchmark doesn't suffer from too much overhead compared to the Prime version, but that also means the Prime burns much energy through abstraction layers and management structures;-)

[Bunuel66]

That's an interesting point, all right, in asm you're running faster than in an interpreted language aka Basic. Great. How long does it takes to develop in asm this piece of code and to run it, compared to the same exercice in Basic. Guess you're long finished that you haven't even had a first run without bugs in asm. And, please if you like it, do asm on the Prime, will be probably fun.
That said, the question of speed is quite useless. The question is what is the use of your calculator today? Speed is enough when you get your answer in due time. If you need really speed with an hand held device use a netbook or a tablet (with keyboard...).
We do a lot of computations in my company and we all use 'interpreted' languages like Python or Matlab. Yes, it's faster in C or in anything compiled, but not that faster and the development is much much more convenient and less time consuming. We use compiled languages only when the stuff is frozen.
Speed question is a bit like in the kindergarden 'mine is longer than yours...', not only in kindergardenb actually ;-)

[Mike Morrow]

Quote:

---

Well, in terms of fast...

Savage is about ~.6s.

---

That's impressive. The Prime will be the new speed king. IIRC, you reported the Savage benchmark took about 3.5 seconds on the HP 39gii, and I expected the Prime would be about the same. Instead...the Prime is more than five times faster than the HP 39gii.

The Savage benchmark is more rigorous that most other benchmarks for real-world scientific calculation tasks. The NQueens and others seem not to be.

Edited: 29 Apr 2013, 4:06 p.m.

[Thomas Klemm]

Am I right in assuming that we're talking about this in HP71 Basic:

5 RADIANS

10 A=1

20 FOR I=1 TO 2499

30 A=TAN(ATN(EXP(LOG(SQR(A*A)))))+1

40 NEXT I

50 PRINT A

So it's mostly calling transcendental functions. That might be interesting to compare as well. Is there a list of the Savage benchmark comparable to Xerxes' N-Queens Problem benchmark?

Kind regards

Thomas

[bhtooefr]

Interestingly, that's showing almost linear scaling from 66 MHz to 385 MHz. (Linear scaling makes sense given that they're running presumably similar software, with essentially the same CPU. But, I had been interpreting Tim's comments about the CPU being an ARM9 that "normally" runs at 400 MHz to mean that it was a 400 MHz-rated SoC underclocked, not that it was ACTUALLY RUNNING at 400 MHz!)

[Mic]

Ti Nspire ++ SUPER PRIME!!!

It is not a myst. It's called TI-Nspire CX Premium :

http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1803

[Garth Wilson]

Given that the topic is "Color calculators" and no one above is talking about color is evidence that color is not important. And although it may be kind of cool, it really has no functional value to me either.

[Chris Smith]

Agreed.

I think it detracts from the product from a power consumption perspective. Not to forget that the UI in the mock Ups is ugly.

Give me a black and white screen and a printed manual over this any day.

[Jean-Michel]

May I say that I don't share your opinion, Garth?
If you consider that the real world is colored, don't you find normal that, once the limits of the machine (memory, processor, display, etc.) are pushed away far enough to let it have a color display, it was then fitted in current calculators?
I agree with you that is not compulsory, but don't you agree it may be sometimes usefull?
To my knowledge, there is no standard saying that what was the rule back in the seventies because the hardware was what it was should still be the rule nowadays. And do not imagine I am specifically used in color displays: I'm color blind! I see less colors than most of other people, but those I can distinguish, I am happy to know I will be able to use them on my calculator display in a near future as I am used to do it with all other electronic products I use on a daily basis.
Just my opinion, of course.
Kind regards.

[Cristian Arezzini]

I think the point here is: color is cool and all that, but it still has drawbacks. I'll like the Prime's screen, I'm sure, but I'll miss the weeks- or months-long battery lifes. I suspect the Prime will have to be charged every other day.

And color screens are still almost unreadable in broad sunlight, while b/w screens are perfect there.

[Garth Wilson]

Exactly. Our bank put in big color displays in the ATMs so they could do their advertising with the usual irrelevant pictures of random smiling people, and now when the sun is low, the ATMs are almost unusable. The most usable displays in the ATMs were monochrome and text-only, years ago. Technology has robbed us of function.

Even when I was in school and the math and physics teachers drew their graphs on the chalkboards (before there were dry-erase boards), they didn't even use colored chalk. It wasn't necessary.

Color in life in general will be of varying importance to different people. My brother-in-law's photography for example is distastefully colorful to me. When I was heavily into photography, I did primarily B&W, because of what it could do in textures and bold contrasts that could not be done in color. On rare occasion, I've seen where having a color oscilloscope screen could be advantageous for keeping various traces separate when they cross each other a lot, but then I realize even different brightnesses would accomplish the same goal. I really only pay attention to color when I'm looking for a tool that I know has orange handles, or blue handles, etc., and I am not the least bit colorblind.

[peacecalc]

Hello all,

Color or not?

For a calc it is a question of the interface of human being and the machine. My Hp 50g cannot be used in dark environments. So a backlighted or self-luminous display is a real advantage.

It is the same ol' story about technical progress. It is almost not sufficient to build in colors instead of b&w, you need other techniques for a proper use of this new feature (light!). Transformations from one level to the next level are always from the kind of try and error, the user and the engineer have to learn in a communication process how such a interface is best.

Think of the transformation from gas-light to electrical-light. The first switches for the electrical-light were adapted from the rotary control switches which were used for gas-lights.

So, be a little bit patient, if the hardware calcs don't die of other reasons, the next generation will be more comfortable! But don't forget to buy this generation, because development needs a investment.

And a last point: If calculation time is fast and I've more possibilities for representing the results may in a textbook form or as a graph, I can choose that one, which satifies may needs in time.

Sincerely
peacecalc

[Chris Smith]

I tend to only use my 50g during the day in bright lights at which point colour LCDs would suffer from contrast problems. I know this because I have a high contrast, high PPI, high brightness display on my phone and I can't see it half the time during the day. 50g definitely visible.

50g in the dark? Turn the lights on.

Considering buying a few more 50gs to cover me until I snuff it.

The world is succumbing to form over function these days and I don't like it. Everything is flat, touchable and shiny yet usability sucks terribly.

[peacecalc]

Hello Chris,

it wasn't my goal to complain about a HP50g. I only tried to explain in clumsy words and grammar, that old and even a new technology has its disadvantages and needs further development. In this topic I agree with you.

I often use the pubilc traffic and some stations are like little tunnels, so it gets dark and the for a minute it's getting too dark for the 50g. Turn on the lights, such a technique or service doesn't exist in my hometown.

May in some future it will exist a sensor (and a hardware behind this) which is able not only to raise the brightness when the light raises in the environment but also to switch to another display state allowing a greater contrast inspite of a glaring daylight.

By experience the fabs will produce display which becomes brighter and brighter until limits (by costs or physics) are reached (never change a running system). Maybe the b&w display isn't developped to a limit (you can see it for the displays of the ebook reader),
but it seems to be very sexy to have colors!

Sincerely
peaceglue