WP34 again



#2

We ran out of op-codes for commands with arguments. It turns out that 128 of these wasn't enough even though I thought it was overkill when I laid the op-codes out. Thus, I've been forced to renumber them.

This means there is no binary compatibility between older versions and the current (subversion 1268). Sorry about that, I don't like changing the op-codes.

The assembler/disassembler will handle the jump once it gets updated.


On a positive note, I've managed to squeeze a few more kilobytes out of the firmware and it seems likely that most of this will go into additional user program pages :-)


- Pauli


#3

Luckily we have the assembler now so these opcode changes aren't much of a problem! :)

I have a somewhat "unrelated" question, but your menition of freed memory reminded me: some time ago I remember you asked about what constants we would like to be added. I suggested planetary masses (at least earth, moon and sun) and if possible a few other astronomical values, useful for orbit calculations. Is there any news on these constants? Were they "rejected" or is it still being thought?

Thanks,
Cristian


#4

Those constants can still be considered.

Give us a list of what you want and we'll likely include them.
Constant names are limited to four characters. Please include values :-)


- Pauli

Edited: 21 July 2011, 4:49 a.m.


#5

These are the constants I've been using more frequently, and their values:

Sun mass: 1.98892±0.00025 x 10E30 Kg
Symbol: M with a subscript symbol made of a dot inside a circle. As this symbol isn't available, maybe M and subscript S would be OK.

Earth mass: 5.972245 ± 0.000082 x 10E24 kg
Symbol: M with a subscript + in a circle. As above, maybe M and subscript E?

Moon mass: 7.3477 × 10E22 kg
Symbol: M with subscript L

Earth mean radius: 6371.0 km
Symbol: R with the same symbol as above (again, R and subscript E?)

Moon mean radius: 1737.10 km
Symbol: R and subscript M

Then, the orbital semi-major axis for the moon is 384,399 km
and for the Earth is 149,598,261 km
but I don't know the symbols for these... :( Maybe M and E with subscript (sma)? :)

Cristian


#6

I would rather suggest 'm' for mass, 'r' for radius and 'd' for distance (which is more standard-like), and then subscripts 'S', 'M' and 'E' for sun, moon and earth.

So maybe this way:

m_E, m_M, m_S for mass

r_E, r_M, r_S for radius

d_EM, d_ES for distance (or r_EM and r_ES if you prefer)

But I must agree: having these constants is indeed a godd idea. :-)

BTW, aren't your semi-MAJOR axis values in fact MEAN values for these distances???

Franz

Edited: 21 July 2011, 11:52 a.m.


#7

Quote:
I would rather suggest 'm' for mass, 'r' for radius and 'd' for distance (which is more standard-like)

OK, I just said M and R because that's what I usually find in books and websites, I thought it was a "special case" symbol. Everything is OK though, as long as they're included! :)


Quote:
BTW, aren't your semi-MAJOR axis values in fact MEAN values for these distances???

I'm not sure I understand what you mean. As far as I know, the semi-major axis of an ellipse is the mean between the smallest and biggest distance from a focus and the ellipse... so yes, it's a sort of "average distance", during the orbit, between the central body (which sits in a focus) and the orbiting body (which is closest at one end of the major axis, and farthest at the other end of the same major axis)...

Cristian


#8

Quote:
I'm not sure I understand what you mean. As far as I know, the semi-major axis of an ellipse is the mean between the smallest and biggest distance from a focus and the ellipse... so yes, it's a sort of "average distance", during the orbit, between the central body (which sits in a focus) and the orbiting body (which is closest at one end of the major axis, and farthest at the other end of the same major axis)...

Ok, it seems to be just a language problem. ;-)

I thought 'major' axis would be the bigger (and 'minor' the smaller) axis of the ellipse, but maybe this naming is different in English. But however we call them, your values are the usual constants used in astronomical calculations.

Well, nice to see here an other astronomy fan (like me)! :-)

My special interest are solar and lunar eclipses, and I've written a quite powerful program for eclipses - its name is 'WinSomofi' and I have worked on it for MANY years (because I've in fact done ALL calculations myself). Unfortunately the webserver of my homepage is currently unavailable again (as so often), but if you would like to try my program(s) you can check the following link in the next days (when the server is working again):

http://fhub.110mb.com/

[Edit] I just saw that my program is also available from another astronomy site:

http://www.pixelsetphotons.com/index.php?/Logiciels/Ephemerides/winsomofi.html

The download link is under the picture after 'Telechargez'!


Franz

Edited: 21 July 2011, 3:46 p.m.


#9

Quote:
I thought 'major' axis would be the bigger (and 'minor' the smaller) axis of the ellipse,

Well, it actually is so... The semi-major axis is half of the "bigger diameter" of the ellipse.
The fact is that the center body does not sit on the center of the ellipse, but on a focus; which means that the two extremes of the major axis are the periapsis and apoapsis. Thus, half of the "major diameter" is a value between the smallest and the biggest distance between the two bodies. Or at least this is how I understood it! ;)

Quote:
Well, nice to see here an other astronomy fan (like me)!

I've been an astronomy fan for years, but I've sort of "decreased" my active observations... I used to have a telescope, but I don't have enough room in my new house, so I only have a binocular now.

Now I'm actively interested in space exploration, both manned and unmanned, and I observe passing satellites. Sometimes I calculate their orbits, that's why I use the constants! :)

Quote:
I've written a quite powerful program for eclipses - its name is 'WinSomofi' and I have worked on it for MANY years

I downloaded it, and it looks nice! I'm not on Windows - I use Linux exclusively - but it works with Wine... Thanks for sharing it!

Cristian


#10

Quote:
I downloaded it, and it looks nice!

And it has a few nice features, but since it was just a private project for me I didn't make a good description.

There's only a short textfile (IIRC it's info.txt) describing the functions which can be accessed with different mouseclicks - it's definitely worth to look at this textfile and try out these features (especially a right mouseclick at the world map gives a globe view which can even be rotated. :-))

Ok, now I stop being off-topic any longer ... ;-)
Franz

Edited: 21 July 2011, 6:12 p.m.

#11

M and R or m and r or whatever you choose else are no problem at all. Subscripts, however, are limited. Please turn to page 65 of the latest edition of the manual (build 1265) to see what is featured.

Background: Though we thought 256 characters in two fonts being next to overkill for the small dot matrix provided, we've filled every little byte so far.

Walter


#12

Quote:
Subscripts, however, are limited.

Well, these constants don't necessarily have to be named with subscripts - an underscore like m_E for example would also be ok (or any other good separation character).

Franz

#13

Quote:
Though we thought 256 characters in two fonts being next to overkill for the small dot matrix provided, we've filled every little byte so far.

How much is enough? Just that little bit more... ;-)
#14

Seeing that the subscripts are limited - and that m(e) is already taken for electron mass - we can just leave the underscores as typed on the message above... Unless someone finds a more intuitive (or easier to remember) way! :)

#15

Will see what we can get in and what names they'll end up with.

We've got the WGS84 diameter of the Earth constants already. They aren't quite the mean radius figure you provided, rather they are the major and minor diameters of the planet.


- Pauli


#16

Quote:
We've got the WGS84 diameter of the Earth constants already. They aren't quite the mean radius figure you provided, rather they are the major and minor diameters of the planet.

And rather they usually aren't used at all. In almost all calculations the 'average' value is used, which is defined as (2*major+minor)/3.

#17

I use the WGS constants continuously in my day job, so "usually aren't used at all" certainly isn't correct. In fact I'd hazard a guess that "almost all calculations" done worldwide use the WGS constants -- how many GPS receivers are there in the world? They don't use the average.

In astronomy, things might be different of course. I'm not an astronomer.


Anyway, I said we'd try.


- Pauli

#18

Cristian, do you have any references for the values you gave?

I'm finding that the numbers aren't quite matching data I find on NASA's web sites. e.g. the mass of the Earth is given as 5.97219e24 +/- 0.00060e24 (source). Likewise, the masses are out a little compared to values given in NASA's Horizons database.

I'd really like any values we include to be the best currently known.


- Pauli


#19

Quote:
best currently known.

This may well change from day to day!

You should probably adopt values from some currently recognized authority.

As an astronomer, I would push whatever the IAU (International Astronomical Union) gives as their current standard. There may well be values from the US NIST, or ISO (International Standards Organization), too.

It is generally better to use an "official" value of some sort, with proper reference - which can be corrected later, if necessary. For really precise work, it is better to know what you have done, so it can be properly undone later! You say something like "I used WGS84 values." Then everybody knows what you did.

For not so precise work, it doesn't matter very much.


#20

This is exactly what I've been trying to do.

We pulled most of the constants and conversions from NIST and I've just gone through and updated to the latest list (2010). The WGS84 constants came from that standard. However, I'm having trouble locating a canonical source for the astronomical constants that have been added. NASA or IAU seem like the obvious choices and I'd prefer to use the latter but the IAU web site isn't very forthcoming unlike NASA's.

Do you have a link to the IAU's definitions of these? Or better yet, send me a file with them :-)

- Pauli

Edited: 23 July 2011, 7:41 p.m. after one or more responses were posted


#21

Quote:
Do you have a link to the IAU's definitions of these? Or better yet, send me a file with them :-)

Here's a link to the IAU 2009 system of constants:

http://maia.usno.navy.mil/NSFA/IAU2009_consts.html

Note that in any such system, there are generally NO masses given for planets, etc. The value that counts for calculating things like orbits is the product of the object's mass times the gravitational constant (capital "G") - or GM. This is because we don't really know what the mass of anything large (like the Earth) is! You get it by doing something like determining the period of an orbit, and then plugging in a value of G. G is VERY HARD to measure! You measure the actual gravitational attraction between masses, which isn't very big.

On the other hand, though, you get the product GM from the orbit period directly, which you can measure to much higher accuracy. In the IAU table, "G" is given to 6 digits, whereas GM(E) has 10 digits

Hence, serious orbit or geodetic or other scientific calculations use the product GM.

On the IAU page, you will see lots of mass ratios - gotten from orbit periods.

So, putting in an Earth mass (or for other objects), while convenient, perhaps, isn't quite right for maximum accuracy.


#22

Quote:
So, putting in an Earth mass (or for other objects), while convenient, perhaps, isn't quite right for maximum accuracy.

I'm just doing some reading about this and I agree that GM is generally the "better" value. What we can do is provide the constants for G and M with the best known accuracy and they should match. Providing the GM values might be useful, too. Since GM is given to many more digits then G, multiplying the values of G and M for a given object will result in a less accurate result for GM. Getting at the mass by dividing GM by G would lead to an artificial accuracy for the mass which we should avoid.

Isn't if funny that it's even possible to determine the mass of the sun? :-)

#23

Dave, thanks for the reference. I'll see what I can pull in. I've been grabbing data and updating our values using Nasa's Horizon database. I assume this is reputable as well :-)

Interesting that the IAU document you referenced provides three different values for GM of Earth :-( At least one of the three matches the WGD84 value I included which is the first bit of sanity I've found.


- Pauli


#24

Quote:
I'll see what I can pull in. I've been grabbing data and updating our values using Nasa's Horizon database.

Pauli, I just saw in the latest build that you've implemented these astronomical values (radius and semi-major) in km !?

Is that really a good idea??? This is not the usual SI unit!

Franz


#25

Cristian used km up above. It is also the unit used by NASA's Horizon database which is where the values I used came from. This is the first mention of km being the incorrect unit here, no complaints when Cristian produced values.

With no voices to the contrary, why wouldn't I then use km? It certainly seems like they are the appropriate unit here.


- Pauli


#26

Quote:
Cristian used km up above. It is also the unit used by NASA's Horizon database which is where the values I used came from. This is the first mention of km being the incorrect unit here, no complaints when Cristian produced values.

With no voices to the contrary, why wouldn't I then use km? It certainly seems like they are the appropriate unit here.

- Pauli


Well, there's a ig difference between 'talking' about any values (or writing them in a table (with km added) or using these values in a calculation!

If the value recalled from the WP34S is in km, then it's definitely useless for any calculations, just because you get wrong results, point!

But do whatever you want ...

Edited: 24 July 2011, 5:27 p.m.


#27

Franz,

I'm with you in this matter. Whatever put into our CONST catalogue, shall be in SI whenever possible.

Walter


#28

I posted them in km because that's the unit I usually use; and that's OK with the 50g because there, units are attached to the number, and the calc takes care of the appropriate conversions.
But I agree that on the 34s, which doesn't attach units to values, SI units should be used instead - just for consistency if nothing else.

By the way, I really appreciate the sun and earth symbols! Thanks! :)

Cristian

Edited: 25 July 2011, 1:52 a.m.

#29

Quote:
Cristian, do you have any references for the values you gave?

Hi Pauli,
Sorry for the delay in replying, I somehow missed your message.
As for Earth mass determination, that value was found by Gundlach & Merkowitz in 2000, and was supposed to be the most accurate measurement, but I can't of course prove this statement; as for the other values, I used to use what I had on my university's physics books, but then I found new, and I thought more accurate, data online, and I have used those since; but I can't vouch for their accuracy in any way. If you found them in a more official page like NASA, by all means use those - I suspect a small difference in the value won't change my results by much anyway! :)

Cristian

#30

Quote:
On a positive note, I've managed to squeeze a few more kilobytes out of the firmware and it seems likely that most of this will go into additional user program pages :-)

I've added a few. :-)

Now exactly 8 KB of flash are available to the user, 6 for library programs and 2 for the SRAM backup. We may add another page depending on which features will be included or excluded.


#31

This works out as 6x506 steps in library regions plus 506 steps in the backup and 506 steps in RAM. That a total of 4048 steps of program plus 112 + 112 registers. We're heading towards the 42S's level of capability :-)


- Pauli


#32

Paul;
That's about twice the memory of a CV. Maybe a lot more than twice considering how well your baby uses it's space. The only bad thing in all of this is that the bean counters at hp are going to think that all the sales of the 30b are going to business types, so maybe they need to come out with yet another business calculator instead of a scientific programmable with alpha. -That's ok. We have the 34S.

Eric;
I'm going to assume that the best guess on how many users of the 34 there are is how many faceplates you have shipped. I realize that this is a labor of love for you that entailed a large hardware investment and i hope no one here will start spouting that you make money on this. But anyway; could you tell us how many of us there are?

Gene:
Get with it man. Sleep when you're dead.


#33

Quote:
I'm going to assume that the best guess on how many users of the 34 there are is how many faceplates [that] have shipped.

Another indicator is the download statistics at Sourceforge. Looking at June, there were 540 downloads. There was a spike of 92 downloads on 6/9 corresponding to the 2.0 beta release. Through June, there were about 20 downloads/day after that. In July, it's been about 10-15 per day and a total MTD of 198.

I haven't been able to figure out if that is only counting the main wp34s.zip or any downloads of any files from the wp34s sourceforge repository, including the SVN.

If it's just the wp34s.zip file, that would put the user population around 500 since 2.0 beta was released. If it includes SVN downloads, it probably points to about 100 - 200 users, with a few dozen that are frequently downloading new SVN builds.

#34

Quote:
That's about twice the memory of a CV. Maybe a lot more than twice considering how well your baby uses it's space.

It is a lot more than twice. The CV has about 2k bytes in total. We've about 4k steps plus registers. For any command that takes an argument, the CV needs 2 bytes. Whereas, the 34S only needs one step. For many of the extended commands we've got the 41cv would need to use XROM. With recall arithmetic & some other instructions, I'm finding that a lot more of the commands that I end up using have an argument.


Quote:
The only bad thing in all of this is that the bean counters at hp are going to think that all the sales of the 30b are going to business types, so maybe they need to come out with yet another business calculator instead of a scientific programmable with alpha.

I doubt we're even enough sales to be considered an insignificant market segment :-(


- Pauli

#35

Quote:
Eric;
I'm going to assume that the best guess on how many users of the 34 there are is how many faceplates you have shipped. I realize that this is a labor of love for you that entailed a large hardware investment and i hope no one here will start spouting that you make money on this. But anyway; could you tell us how many of us there are?

I sent 66 to 28 unique addresses.

I plan to make another batch in a couple weeks. I have some other things that I need to do first, however.

Eric


#36

Eric, have you ever considered to ask a professional print shop for a batch of overlays?

#37

Quote:
I have some other things that I need to do first, however.

Would that be some 41Z overlays perhaps?? :-)

I'm looking forward to those!

#38

Quote:
The assembler/disassembler will handle the jump once it gets updated.

So done! Assembler now at SVN 1274 op-codes.

6 flash pages! Wow! I am going to get lost...


#39

Actually seven pages of code, the backup region is quite usable for user programs.

I suspect we've actually surpassed the 42S in terms of programability :-) Less steps, but the 34S's are fully merged and often more powerful. Still lacking matrix operations though.


- Pauli


#40

Will this allow Bessel functions to be included? (Real & Complex plz.)


#41

I never got the complex Bessel functions working :-( Ignoring this for a moment....

Real Bessel functions are 1.7kb. Complex are going to be double that at a guess but assume there is some efficiency and they "only" take 5kb for both real and complex. We would have to reduce user flash to four pages plus the back up region to fit this in assuming we take out all the other optional things. Keeping the currently included optional functions, would reduce the user flash pages to two plus the backup.

So no, no native Bessel functions.

Enough doom and gloom. I am reasonably confident that a user program for the Bessel functions would fit into a page or two of flash which seems like a far better use of the space. User programs are short compared with native versions.

- Pauli

Edited: 21 July 2011, 7:26 a.m.

#42

matrix programs are still on my list. Real life keeps getting in my way.


#43

I know. A page of two of flash should adequately cover these.

- Pauli


#44

We could include some 'default' pages which are automatically included.


#45

Assuming I get them written... :-(

I'm afraid the 41CL is also competing for my limited time. Perhaps if I learn not to sleep?

:-)

#46

I haven't flashed my 30b hardware in a while. I know that there have been a lot of changes.

I tried to follow the original instructions for flashing the calculator and now I'm stuck with the display saying "Erased" and a 0 in the number field. No key press does anything.

Am I missing something?

Edited: 24 July 2011, 10:27 p.m. after one or more responses were posted


#47

After pressing reset on the back, the display says Restored and then the next keypress makes all segments come on black and I cannot adjust the contrast to see if any keypress makes a difference.

#48

Norman, probably a broken build. Try a reset. If that doesn't help, get a slightly older image until you find one that works.

Edit: The build works in principle, see next post.

Edited: 24 July 2011, 4:06 p.m.

#49

Quote:
I haven't flashed my 30b hardware in a while. I know that there have been a lot of changes.

It's not a broken build. I've just flashed the latest revision on my 20b and it runs. The many changes render any info which might have been stored in flash memory with an older version useless. You should use the "Erase" button on the cable to get into SAM-BA mode, just to make sure there is no residual data in flash memory.

Another hint: Check the voltage of your batteries and report the value back here, please.

Edited: 24 July 2011, 4:37 p.m.


#50

Marcus, I just tried flashing from 1196 to revision 1300 and got similar results that Norman did. Something different I noticed this time was that the 'Lock region' dialog said (0 to 14) instead of the usual (0 to 15). After flashing, I got 'Erased', but the minus sign on the far left of the display was lit. If I pushed a shift key, the letter ('g' or 'h') would appear in the upper display, but repeating that shift key wouldn't clear it. The second key press would lock up the unit.

I tried reflashing and ended up locking up SAM-BA. I had to kill the process and start all over. I reflashed back to 1196 (last rev I had downloaded, and I knew it worked), and it's working again. BATT shows 2.8V.

#51

Just tried to update from 1196 to 1288. I did the usual cable button sequence, and tried to send the 1288 calc.bin file. SAM-BA locked up again, the process started using 50% CPU, and nothing appeared to be sent in the log window. The pop-up that says "Please Wait" just turned into a white rectangle. I had to kill SAM-BA again.

This time, I went through the cable button presses, restarted SAM-BA and reconnected. I then executed the "Erase All Flash" script and resent the 1288 file. It sent normally this time, but still asked to lock region (0 to 14). I entered 'No' as usual.

I'm now getting some pretty weird behavior with 1288. The dot matrix display is randomly missing pixels, mostly in the second row from the top. I tried to recheck BATT but it displays -0o0'0.00" (0.00 in HMS) rather than outputting the voltage.

If I enter numbers onto the stack, they just disappear. Using Rv or R^ doesn't show anything on the stack. I'll keep working backwards and let you know what I see.


#52

Can you try with fresh batteries, please? A SAM-BA lockup cannot be attributed to the file you're just downloading, it must be something different.

I changed (increased) the number of possible user flash regions. This explains why the file is shorter and the lock dialog differs.

#53

I suspect there is something broken in the build. My 20b took the image perfectly, my 30b is behaving as you describe -- I figured I busted the flash due to low batteries during programming but it seems too much of a coincidence for several unit to be failing the same way -- then again I said that about the old batteries last week.


- Pauli


#54

I didn't mention it, but I've got a 30b also. I just tried 1286 and I'm still getting the corrupted dot matrix display. The keyboard is really sluggish and dropping keystrokes. Attempting to multiply two 6-7 digit numbers locked up the unit.

I dropped back to 1233 to a rev that looked like it was before the serial and speed changes were done. Looks like normal operation - no display corruption or keyboard issues. Let me know if you need more testing on the more recent builds to find where the regression happened. I'll try 1262 next - that looks like where Marcus released the serial I/O but before the opcode and speed changes.


#55

I guess trying 1262 would be worthwhile to isolate the changes.

Marcus is going to have to be the one to fix this -- I've no hardware debug setup -- and he is busy at the moment.

Interesting that the 20b hardware doesn't have the problem. There must be more differences that we know about.


- Pauli


#56

Instead of working up from 1233 I thought it would be more helpful to work backwards from 1286. I continued having the corrupted dot matrix, dropped keystrokes, and lock-ups when doing multiplication with 1283 and 1280. Reverting to 1273 cleared up all of those issues and restored normal operation. It looks like the regression occurred with 1280.


#57

Thanks for this. The SLOW and FAST command infrastructure looks like the smoking gun here. There are no other significant changes between 1273 and 1280.

Thanks for looking.


- Pauli


#58

You're welcome, Pauli. Glad I could contribute.


#59

I'll look into this. There were some updates to the speed changing code which I later reverted manually. I may have broken something in the process.

BTW, I can only debug the 20b, my 30b doesn't have the JTAG connector modification. Debugging the power saving code is next to impossible on either unit.


#60

I can confirm the problem on the 30b with new batteries (checked with a multimeter at 3.2V roughly). I also confirmed that the image was written correctly using the compare file option in sam-ba.

- Pauli


#61

Hi folks!

Thanks for pointing me to the 30b hardware problems. The power saving code was the culprit. I was violating the processor specs for core voltage and flash read wait states when running at full speed. The 20b did like it better than the 30b.

In the course of the action, we've updated the version number to 2.1. There is more user flash available now (program regions 0 to 8, 9 in total). As a trade off, some of the serial commands (SOPEN, SCLOSE, SEND1, RECV1, aSEND, aRECV) are gone as are the FACTOR and MULADD commands. The remaining headroom will most probably go into bug fixing and some constants and conversions.

As soon as the documentation is up to date and Neils assembler matches the release, we'll prepare a new release package.


#62

Barring bugs and fixes, this will be the release firmware.

At least until we change our minds :-)


- Pauli

#63

Quote:
As soon as the documentation is up to date and Neils assembler matches the release, we'll prepare a new release package.

I have an assembler revision to SVN 1305 opcodes (backspace, backspace, backspace)... but it is already out-of-date (likely before I even checked it in!).

Wow. Wait 15 minutes and things change! :-)

So... I have an assembler revision to SVN 1309 opcodes. (I think I'll get offline before its evolution creeps and/or jerks some more :-)

IMPORTANT: See note, elsewhere, about correction to command line for building translation opcode tables for the assembler.

Cheers...


#64

Oops, unintended side effect of the automatic sorting of the constants table. Oh well.

Sorry,

- Pauli


#65

No worries mate! Keeps me on my toes...

Cheers...

#66

Hello Marcus,

I've flashed the 1306 revision on my 30b (coming from the official 2.0 1133 build). It works fine, however I've noticed that the command VERS doesn't show anymore the build version: it just shows "34S 2.1" without 1306.


#67

How did you download the file? Directly from the SVN repository with your browser? This will return a blank revision number.


#68

Quote:
How did you download the file? Directly from the SVN repository with your browser? This will return a blank revision number.

Yes, this is what I did. Is there any other way to download the latest revision?
#69

What is the proper way to download the latest calc.bin file from SVN so that it will show the revision number? Should we use SVN from the command line? How is that different from downloading with the browser?


#70

Quote:
What is the proper way to download the latest calc.bin file from SVN so that it will show the revision number? Should we use SVN from the command line?

Not necessarily from the command line but a regular SVN client is the way to go. Tortoise SVN is a Windows client that links into Explorer. I'm using modules that extend the development environments Eclipse and Visual Studio besides a command line client. It depends on what I want to achieve.

Quote:
How is that different from downloading with the browser?

The revision number is inserted into the binary file during the download. The file stored in the repository (and accessed via the web browser) has a blank field in place of the number. The reason must be SVN internal.


#71

Thanks Marcus, I've installed Tortoise SVN, downloaded the latest calc.bin and now I have revision 1315 on my WP-34S :)

#72

Quote:
... gone as are the FACTOR and MULADD commands.

Hmmm? What did these commands, Marcus?

Can't even find them in the last manual ...

Franz


#73

Smallest factor of an integer and a fused multiply add.

- Pauli


#74

Quote:
Smallest factor of an integer and a fused multiply add.

- Pauli


Thanks, but I still can't imagine what 'fused multiply add' means!?

#75

http://tinyurl.com/429c5z7 :-)

It is a multiply and add without an intermediate rounding step. Really really useful when writing numerical code. The 34S instruction set allows this to be done fairly easily other ways.

- Pauli


Edited: 25 July 2011, 8:05 a.m.


#76

Quote:
It is a multiply and add without an intermediate rounding step. Really really useful when writing numerical code. The 34S instruction set allows this to be done fairly easily other ways.

One always can learn something new! :-)

Well, I won't really miss this MULADD then ...

OTOH this FACTOR command is (or better was) quite useful (I've tried it now on an older SVN build): it's very easy to get a full prime-factorization with it. So have we now to write a complete program for this task, or is there any other 34S command useful for this purpose?

Franz

Edited: 25 July 2011, 8:36 a.m.


#77

Think about complex operations for multiply adds.

Yes, factor will have to be written in user code. Including factor means one less page of program flash and I doubt the factor program will be that large. This lets people who don't want to factor numbers have other programs instead -- more versatile this way.

I also suspect you haven't found the thirty second plus execution times for factor :-)


- Pauli


#78

FACTOR would fit in the current build but the head room for bug fixes will diminish. If we get enough votes for either FACTOR or MULADD we may reconsider.

The user mode serial commands need 700 bytes (I've just rechecked it) which would cost us a program region. Pauli loves program regions but we might not all agree to the extent of space reserved for this. We've more than 4500 steps in flash alone at the moment. Maybe 4000 is still enough.

Another thought came up recently: We may add a special KEY label command which acts similar to the labels A to D which are bound to the hot keys. We're thinking of having a key combo starting with the right arrow and some other key to directly start a subroutine in RAM or flash. Not all keys will be available to this because they are already defined but many will do. We are coming closer to the 41C with this approach.


#79

Quote:
FACTOR would fit in the current build but the head room for bug fixes will diminish.

Do you need such a head room for bug fixes? Are there still any bugs at all? ;-)
Quote:
If we get enough votes for either FACTOR or MULADD we may reconsider.

Well, you have at least my vote for FACTOR, but I know that doesn't count ...

Franz

Edited: 25 July 2011, 9:51 a.m.


#80

Franz, your vote counts as 1. Add my vote and we have a total of 2 votes so far.


#81

Quote:
Franz, your vote counts as 1. Add my vote and we have a total of 2 votes so far.

Since this 'voting' is already in a very deeply nested posting, it will stay at 2 I'm afraid. :-(

I'm currently writing such a 'FACTOR' code myself, and it's in fact not difficult (or long) at all, but I guess the 'native' routine would definitely be faster.

#82

Quote:
If we get enough votes for either FACTOR or MULADD we may reconsider.

MULADD


#83

Quote:
MULADD

Can be simulated with 3 commands:
1
[CPX] *
DROP

#84

Almost at least. There are sign issues with this solution :-) Easily worked around of course.

The presence of a full precision complex multiply mostly removes the need for a separate multiply add instruction. This is the main reason I don't mind losing this one. Real multiply add takes an extra instruction or three and the integer version is just multiply then add. If we didn't have complex multiply, the multiply add instruction would be a must have.

As for factor, I'd like to see a user code implementation before the decision to include this again is finalised. There are better algorithms than the one used in the firmware which will likely be faster for large numbers.


Multiply add and factor use 584 bytes for both. We've got about 600 bytes of head room for bug fixes. So putting them back in is possible so long as there aren't too many more bugs lurking.


- Pauli


#85

Quote:
Almost at least. There are sign issues with this solution :-)

Are you sure? I don't believe you ... ;-)

I guess this MULADD should return x*y+z, correct?

Well, my first entered 1 makes the 2 complex numbers y+z*i and 1+x*i, and their [CPX]* gives exactly this y*x+1*z = x*y+z as imaginary part (which is returned because of my last DROP). So I can't imagine what should be wrong with my code!?

Quote:
As for factor, I'd like to see a user code implementation before the decision to include this again is finalised.

Well, here's a quite simple (but a bit tricky) solution - optimized for length (only 19 steps) and not for speed (which is no problem with the PC-emulation):
ENTER
sqrt
IP
STO K
1
x<>y
DROP
2
x<y?
SKIP 01
DEC X
+
x>K?
SKIP 04
cpx ENTER
RMDR
x!=0?
BACK 11
DROP

Edited: 25 July 2011, 6:26 p.m.


#86

Doh! Should have thought through the multiply better :-( Need caffeine :-)

Hugh uses a more complex & faster algorithm for the built in -- see the bottom of int.c -- I might have broken this when I reduced the small prime table in the "is prime" tester.

With a user code factor finder this small, I don't see much point including the built in.

Speed will be a problem on the emulator when you factor very large numbers. Reals store integers of sixteen digits or less exactly and integers can go well beyond that (2^64 - 1).


- Pauli


#87

Quote:
With a user code factor finder this small, I don't see much point including the built in.

Well, I haven't yet looked at your FACTOR code but I'm sure it's much faster. I'm just trying for the factors 2 and then all odd integers (upto sqrt(x) maximum), so it will definitely be no good choice for very large integers.

OTOH, for factoring such big numbers I'll certainly use my CAS instead of the WP34S ... ;-)
#88

    2
x<y?
SKIP 01
DEC X
+

Change be changed to:

    2
x>=? Y
SIGN
+

to save a step.

Well, I think it can, I've not actually tried it.


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  WP34 cable Mike Powell 9 325 09-29-2013, 07:27 AM
Last Post: Mike Powell
  WP34 S: Fonts (a bit OT) Marcus von Cube, Germany 18 518 02-24-2012, 11:07 AM
Last Post: Luiz C. Vieira (Brazil)
  [WP34] Poor Person's Overlay Les Wright 6 188 11-26-2011, 04:37 PM
Last Post: Les Wright
  WP34-S Flashing Cable Repair? svisvanatha 5 149 10-03-2011, 08:44 PM
Last Post: svisvanatha
  WP34 S 2.1 released on SourceForge Marcus von Cube, Germany 1 108 08-02-2011, 04:23 PM
Last Post: Marcus von Cube, Germany
  The Sigma Function on the WP34 Eddie W. Shore 7 189 04-26-2011, 07:47 AM
Last Post: Namir
  WP34 base page view Cristian Arezzini 6 206 04-26-2011, 05:51 AM
Last Post: Paul Dale

Forum Jump: