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

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

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.

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.

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

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...

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

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

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.

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

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

- Pauli

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

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.

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

Assuming I get them written... :-(

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

:-)

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

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)...

---

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.

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

Quote:

---

Subscripts, however, are limited.

---

Franz

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.

---

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)!

---

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

---

Cristian

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! :)

Quote:

---

I downloaded it, and it looks nice!

---

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

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

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

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.

---

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

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.

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.

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

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

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

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

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!

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.

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

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

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.

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? :-)

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

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

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.

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.

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.

Quote:

---

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

---

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

Franz

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.

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

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.

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

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

---

But do whatever you want ...

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

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.

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

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.

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

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

Franz,

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

Walter

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.

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.

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.

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

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.

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

At least until we change our minds :-)

- Pauli

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...

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

Sorry,

- Pauli

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

Cheers...

Quote:

---

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

---

Franz

Smallest factor of an integer and a fused multiply add.

- Pauli

Quote:

---

Smallest factor of an integer and a fused multiply add.

- Pauli

---

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.

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.

---

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.

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

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.

Quote:

---

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

---

Quote:

---

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

---

Franz

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

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.

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

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

Quote:

---

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

---

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?

Quote:

---

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

---

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.

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.

Quote:

---

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

---

MULADD

Quote:

---

MULADD

---

1

[CPX] *

DROP

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

Quote:

---

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

---

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.

---

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.

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

Quote:

---

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

---

    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

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