WP 34S --> WP 31S

[Paul Dale]

Look at the .bin files in the realbuild directory. Flash is 128kb minus 2kb for the backup.

That means the free space is between 9984 bytes and 1536 bytes depending on which image you install.

- Pauli

[Manolo Sobrino]

Sorry, I haven't been paying attention to this thread. I thought the 34s was too much, but with this I'm really impressed, it's a very exciting little calc. Your project is developing so fast I missed all the discussion. I like it quite a bit although I'm not particularly fond of yellow (anywhere).

Anyway, after playing with the emulator and realising that I could change easily the colour to some subdued orange (a classic, better for low light legibility and faster visual response time) I fired Paint.Net and got excited modding the bitmap, I hope you don't mind. The fact is I like this layout too (can I say more, because of personal -and longed for, general calc issues- use preferences?). Maybe I'll fork just the key assignations for mine in due time.

Thank you for the project!

   

[walter b]

(04-10-2014 08:47 AM)Manolo Sobrino Wrote:  ... after playing with the emulator and realising that I could change easily the colour to some subdued orange (a classic, better for low light legibility and faster visual response time) I fired Paint.Net and got excited modding the bitmap, I hope you don't mind.

De gustibus non est disputandum though I doubt less contrast being better under low light. Anyway, if you allow we could add your skin (no pun intended though tempting) to the skin menu.

Quote:Thank you for the project!

You're welcome.

d:-)

[Manolo Sobrino]

(04-10-2014 10:44 AM)walter b Wrote:  De gustibus non est disputandum though I doubt less contrast being better under low light. Anyway, if you allow we could add your skin (no pun intended though tempting) to the skin menu.

Dubitando ad veritatem venimus... Possibly the "best" colour would be some pale yellowish orange/orangish yellow. Maybe this one is too orange because I wanted it to look similar to those of the 32S, 42S, 48S, and is less tiring for computer screens. That's why we had amber ones (after green, of course), yellow on black has too much contrast.

I think the Voyagers and the 41s are more yellow, but not just yellow.

These TIs have subdued orange on black too, the first one is close to "papaya whip", a pale orange. Very nice and readable in the older ones, more orangish and uglier in the newer. The yellow keys are actually less orange than the legends.

But "that" yellow on black... I have a box of Halberg tobacco (Yellow Label...) in front of me with that scheme and I just can't focus on the white characters, my brain yells "Achtung!". Maybe the yellow of the secondary keys could stand out more than the white of the primary ones. But then, I don't own a 34s.

I remember reading about response times for warning signs some time ago, orange had the shortest. I can't find it. From what I recall, in low light orange should have less visibility than yellow, but should be more readable.

This colour thing is tricky.

I would be honoured if you used the layout for an emulator skin. I tried to edit a skin, but the keys appear to be mapped in software. I could rearrange them (I swapped rows! There are solid reasons for every change, but they are just IMHO and I won't argue about them), but not change the secondary functions and keep the letters' location. The bitmap is a PNG, equivalent to the original BMP, lossless but compressed. I can't load the BMP (too big). You can do with it what you please. I suppose that should be some kind of Artistic License, I don't know.

(For the time being I need my own skin, I'm aware that some might be tempted to pay for it. )

Thank you again.



(edit) That's more like it:

   

[CR Haeger]

Not to "color" your thinking on the yellow to use, but this from the Yellow Trucking site:

Back in those early days, Harrell hired chemists at E.I. DuPontTM to determine the safest color on the road. The company's research led to Swamp Holly Orange, the natural color of berries on the swamp holly shrub. When he was told [i]Swamp Holly Orange was the color most visible from the greatest distance, Harrell didn't miss a beat. "All right," he said. "Then that's the color for Yellow."[/i]

Or, if you prefer to match your favorite automobile - http://pc.dupont.com/hcl/?locale=en_US (I'm partial to Maserati - Giallo Ginestra yellow even if I can afford only the paint on the car...)

Sorry to be late to this thread. May I ask if there is a WP31S emulator that I could download to try it out? It looks like very nice work.

Best,
Carl

[walter b]

(04-10-2014 01:22 PM)Manolo Sobrino Wrote:  Dubitando ad veritatem venimus...
...
This colour thing is tricky.

Certe

And to make it even trickier, there's quite a difference between (illuminated) colour on the PC screen and (reflective) colour on paper or vinyl overlays. For the screen, I took the same golden yellow as for the labels of WP 34S. It's some R/G/B=255/204/0, if it helps.

For prints ... well, it seems to depend on the printer, the surface, and some more parameters.

d:-)

[walter b]

(04-10-2014 04:18 PM)CR Haeger Wrote:  May I ask if there is a WP31S emulator that I could download to try it out?

Yes you may. It was specified in this thread ... but you can as well go to http://sourceforge.net/p/wp34s/code/HEAD...ndows/bin/ and fetch the necessary stuff (i.e. the .exe, .bmp, .dll, and .skin files). Then execute the .exe and there you go.

And about holly swamp orange: quite interesting read. Seems to be country-specific though - no such traffic signs on this side of the pond. And calculator-wise, we don't have thick colour on metal but illuminated colour on screens so far. Quite a difference IMHO.

d:-)

BTW, working with my calcs, they are typically in a distance of some some 60cm to my nose - not very far away.

[Jonathan Cameron]

(04-10-2014 05:43 PM)walter b Wrote:  BTW, working with my calcs, they are typically in a distance of some some 60cm to my nose - not very far away.

I wish I could still focus that close!

-Jonathan

[Manolo Sobrino]

WP 31S^\mu layout mod:

I didn't want to change anything in the number pad, but a couple of (secondary, of course ) keys had to be swapped to minimise mouse/finger travel with f-CONST and CONV-back to arrows. I think it's not as logical as my first layout, but that and the fact that it has less visual clutter and groups non modal menu keys in two adjacent rows in the bigger keys is worth it as well.

Now, a bit of explanation for swapping the rows. First, this is a non programmable scientific. In my experience, square, root square, logs and exponential function keys are much much more frequently used than trigs (experimental/basic stuff Nuclear Physics conditioning), so I prefer having them the closer the better: this calc looks like a number cruncher workhorse to me. Other calcs have trigs on top, and only Sharp do exactly this, I think they're spot on. A nice consequence too is that the inverse key gets closer to the arithmetic keys. Save for the secondary key slots of STO/RCL, that now can live elsewhere, the original arrays of the WP31S are perfect(*). I only changed LG to LOG10 (with subscript 10), because it's the standard notation, and if you do superscripts you can do subscripts as well (and yeah, "Life's Good" slogan pops in my head too often with LG).

There are IMO other aesthetic benefits: you don't have that line of keys with mostly text in the middle of the calculator that acts as a visual fence any more, and the Pi key looks nice under the screen. It stands out and you're proud of it: A scientific calculator keen on Maths at last!

In an RPN just scientific like this STO/RCL won't be used (that) often, so it makes sense to keep them out of the way. They have to be noticeable as they are pretty important though. I think that moving them closer to the display is nice, as you look at it just before storing a number. Their upper left positions now match the beginning of the alphabet, I think this eases the conceptual link.

And now that you don't have the STO/RCL keys so close to ENTER, you can put other things where they belong IMHO. The swap key should be the swap key for everything, and FILL makes a lot of sense as a secondary ENTER (you ENTER full-stack).

My first layout had CONV at CHS and CONST at EEX. If you didn't want to change anything at the numpad that made sense. Now that I've put them closer to the next keys you'll likely use, there are two choices for MODE/DISP and DEG/RAD:

A) The first one shares MODE/DISP position with that of my first layout, as these keys are modal I put them in the usual modal position of (other) calcs, first row corners. A control position. Then DISPLAY will be next to the screen, this makes a lot of sense. That leaves DEG RAD for CHS and EEX. Less visual clutter in the middle of the calc.

   

B) The second choice: Go back to the original WP 31S layout and the classic HP choice. Put MODE/DISP on CHS/EEX. Then DEG/RAD will go to the first row, where everything angle-related would be now. All keys with menus would be contiguous, but there would be more visual clutter.

   

I could live with any of them. Any more reasons for one or the other? The ideal scenario would be to use the emulator for a while with different layouts and see which one works best.

It would be nice that skins could change the secondary keys and letters positions, but it looks like that's not the case now. If that would be possible in the future, then Walter, if you want to add any of these modded layouts as a skin pick your favourite A/B and I'll take care of the configuration file.

To change this in firmware/emulator looks trivial, just some minimal changes to keys.c and recompile. It's a long time since I did Visual Studio, I guess I'll have to give it a go. Keep in mind that this is just a personal use mod, you don't fork a project like this for personal mods. I'll keep it orange for computer use, it might go (much?) more yellow, as discussed.

Just an emulator question: What's the point of the active BEG annunciator? I don't think this is just a beginners' calc


Here are the WP 31S in orange and in the colour scheme I mentioned in other post. The key has to be yellowish than the legends, or else it would be too subdued.


       



____________________________________________________________________________
(*) There's this %CH that could go away... but this is just a layout mod that wants to keep it that way. Because otherwise I would be tempted to add WP 34S number bases for BIN/HEX or formula storing capability and it wouldn't end happily.

[walter b]

(04-12-2014 03:39 PM)Manolo Sobrino Wrote:  Just an emulator question: What's the point of the active BEG annunciator? I don't think this is just a beginners' calc

The program pointer of this calculator stays at step 000 always, hence BEG is lit Remember the WP 31S is a subset of the WP 34S.

There are some aspects in your layouts I definitivly like. ENTER with FILL and x<>y with x<>, for example. (BTW, I think quality of layout suggestions has risen over the years. This seems to be a learning forum after all. Kudos to Karl Schneider who opened my eyes for the beauty of well thought layouts years ago. Does anybody know what he's doing now? I didn't read anything from him for many moons.)

Some remarks in random order, reflecting my point of view only, of course:

• I wouldn't put STO and RCL in top row - and I don't see a reason for doing that.
• Putting DEG and RAD in a row with SIN etc. has some charm. OTOH, they are far away from -> then ...
• I didn't observe anybody writing LOG₁₀ for the decadic logarithm in real life so far. Admittedly LG looks a bit weird (like LN does) but I didn't want to frighten our American friends with the official lg and ln - I've learned they prefer capitals.
• After all, the label CONST is the longest secondary label we have. One reason for putting it on ENTER.
• With FILL and x<> in the ENTER row (which I like as mentioned), two catalogs must be put elsewhere. CONST can't go anywhere else in the top three rows for plain space reasons. So it has to go down. But why put it right of -> although -> doesn't interact with CONST?
• Colors were discussed elsewhere already.
  

At the bottom line, the WP 31S layout (as any other one) is a "Gesamtkunstwerk" wherein everything has to fit nicely - well, as nicely as possible. I'd recommend thinking about function grouping.

d:-)

[Thomas Klemm]

(04-12-2014 08:30 PM)walter b Wrote:  I didn't observe anybody writing LOG₁₀ for the decadic logarithm in real life so far. Admittedly LG looks a bit weird (like LN does) but I didn't want to frighten our American friends with the official lg and ln

All the calculators I know use LN and LOG. In math I use \(\log\). There's no confusion: it's always the natural logarithm. I'd refrain from using LG: nobody uses that.

Cheers
Thomas

[Manolo Sobrino]

...dammit Walter, being programmable or not, you just want an HP!! ... ()

I think I've got something interesting for you (solved the Rubik?)... let me think about the ramifications and match the pixels before I share it.

On the other hand, a standard notation when: $$a=b^x$$

Is: $$x=Log_{b}\:a$$

(I'll edit this post...)

edit: (see? I knew I had to edit it)

[walter b]

Almost, Manolo, almost ...

A standard notation when: $$a=b^x$$ is: $$x=log_{b}\:a$$. People use this notation for general logs (compare the WP 34S ). Very few people, however, write $$log_{e}$$ instead of $$ln$$. In full analogy, $$lg$$ is used instead of $$log_{10}$$. KISS.

d:-)

[Manolo Sobrino]

(04-13-2014 05:25 AM)walter b Wrote:  Almost, Manolo, almost ...

A standard notation when: $$a=b^x$$ is: $$x=log_{b}\:a$$.

Either I was thinking about the log in the principal branch, hence Log or I've been doing too much Mathematica lately (I have proof on this very forum, so you will never know if that was a dirty trick, poor judgement due to calculator angst or something else .)

(I have a busy day so I'll try to keep it short: )

OK, let's say we make it to look more like an HP, and we forget for a while about the LOG key . It's not easy:

First iteration, WP 31S Eta Mu (obvious reasons). Let's go for the minimum compromises for both viewpoints.

   

Notice the first row of just transcendentals! e next to Pi! (a lot of pending explanations.)

Oh, but we forgot to keep the -> on the H.X keys, is that really so crucial? Maybe not so, but definitely could be a design constraint that hates us (more pending explanations). Maybe we can use the job we've just done too:

Introducing the WP 31S CX!!

   

Just joking... (Did you notice the missing arrows? -to fill in with details-), looks like there's an "almost" free position, and then MORE in an arrow saves a lot of mouse/finger travel. While we're on it, why not shortening the 5-char menu legends to 4 except for CLEAR?

   

Let's try to use this, keep the original idea and solve this tough Rubik cube the best we can... And yes, it was hard and yes, I think we can.

After a lot of concentration, just two options for the permutation of the last two secondary keys I could move.

The Rubik Logical (it really should be this one, %CH on an arithmetic, x! with the transcendentals.)

   

The Rubik Fun (x! there is bad for your education, but just too cool in a recursive way of multiplications. %CH over there looks almost HP to me.)

   

Notice the alignments, columns, the thematic groupings, the keys with menus close to the arrows, the position of POL/REC... I'm totally flashing one!

Manolo

[walter b]

(04-13-2014 08:32 AM)Manolo Sobrino Wrote:  Notice the alignments, columns, the thematic groupings, the keys with menus close to the arrows, the position of POL/REC... I'm totally flashing one!

OK, I admit I looked to the Rubik fun part only (with a sleeping grandchild on my shoulder ), i.e. your last layout - and it's looking quite a lot better than the one you posted yesterday. I think we can agree on that so far

What I'm not happy with is the statistcal area (pun intended). I'd suggest putting DISTR (the last letter is important here - we're not talking about DISTances) on shifted 9, x_bar and s on shifted 5 and 6, y_hat and r on shifted 1 and 2, respectively.

And we've to reduce the top left shifted label since it's 5 characters long: I recommend deleting three characters there ...

d:-)

[Paul Dale]

But x! isn't implemented recursively except in beginners' guides to programming languages. The 34S can do sequential multiplications for integers but in generally uses the LnGamma function instead.


- Pauli

[Thomas Klemm]

(04-13-2014 10:03 AM)Paul Dale Wrote:  But x! isn't implemented recursively except in beginners' guides to programming languages.

Not sure if functional programmers would agree on that.


xkcd

Cheers
Thomas

[Paul Dale]

Factorial isn't tail recursive:

Code:

factorial x:
    y = factorial(x-1)
    return y * x

- Pauli

[Manolo Sobrino]

(04-13-2014 09:35 AM)walter b Wrote:  OK, I admit I looked to the Rubik fun part only (with a sleeping grandparent on my shoulder ), i.e. your last layout - and it's looking quite a lot better than the one you posted yesterday. I think we can agree on that so far

What I'm not happy with is the statistcal area (pun intended). I'd suggest putting DISTR (the last letter is important here - we're not talking about DISTances) on shifted 9, x_bar and s on shifted 5 and 6, y_hat and r on shifted 1 and 2, respectively.

And we've to reduce the top left shifted label since it's 5 characters long: I recommend deleting three characters there ...

d:-)

I'd take a look at the sequence of them with some pause and consideration . My serious choice is the next to last one, which differs in just a two-key permutation. The areas are almost fixed right now. You have to pay more attention to the column {x^bar, y^hat, r}. It makes sense and acts as a delimiter.

I do not dislike your idea of putting DISTR on 9, or on 8 for that matter, with STAT on 9. We might agree with a 4-character label DSTR. All this breaks somehow the columns that are the theme of the numpad, but it might work. Then s could be on top of Sigma+, x^bar at 6 and y^hat at 5 on top of r at 2. If I put something on shifted 1, then the couple POL/RECT falls apart. They are placed nicely now. Current statistics are in a compact 3x2 group, you can shuffle them within their box, leaving them get out of there would break things not easy to glue again. Not at all.

I'll think about the choices in there. I have to check a few more things before.

I have the solution to the LOG issue. The layout keeps a printed LOG but comes with a black marker so whoever is willing to have LG can cover the "O", that's just because it's much harder the other way around . L G is awfully close to LG... I could try a thin "O" to make it even a closer match . The "10" can go now, it didn't deserve it though...

[Manolo Sobrino]

(04-13-2014 10:03 AM)Paul Dale Wrote:  But x! isn't implemented recursively except in beginners' guides to programming languages. The 34S can do sequential multiplications for integers but in generally uses the LnGamma function instead.


- Pauli

Now we are nitpicking again... "just too cool in a recursive way of multiplications" was never meant to be a formal statement. I like the idea of having x! under multiplication because for integers that's what it is. But I said before that: "it really should be this one, %CH on an arithmetic, x! with the transcendentals". If I say transcendentals it's because I know what a transcendental function is, something that a product of positive integers is not. Do we really have to type the representation of n!: $$n!=\int_0^\infty t^n e^{-t} dt$$ which holds (n+1)! = (n+1) · n!, and can be extended to $$\Pi (x)\equiv\int_0^\infty t^x e^{-t} dt$$ over Reals, in terms of which the Gamma Function is defined as $$\Gamma(x)\equiv\Pi (x-1)$$, and is easily proved that $$\Gamma(x+1)=x\:\Gamma(x)$$, for whose non integer or non simple rational values you can for instance grab your copy of Abramowitz to get accurate to some extent, albeit old, approximations to begin with? Do we all know that stuff, don't we?