uWatch Complex Number Support



#26

For those interested in the uWatch complex number support...

I have now completed the first pass of the complex number support for the uWatch. All of the scientific functions (except gamma) now support complex numbers.

it’s pretty cool. For example, you can enter and calculate stuff like (1+i)^(1+i) much faster than on a HP15c.

eg “1.. ENT MENU Y^X” vs. “1 ENT fI ENT Y^X” and a long delay!

There are some known caveats. For example the complex display format could be better (e.g. the above is displayed as 0.273957+i0.5837 both “0”s could be eliminated, for example). and stuff like (-27)^(1/3) gives one of the complex roots rather than -3 (which would be preferable).


There are also some usability issues to resolve. I also need to so some more rigorous testing of results. Also there are a lot of suggestions from other people that would make improvements that are not in. also, err, i need to make ALG mode work for complex (will do this before the actual release). please dont load this beta if you use ALG mode!!

Im hoping to make a proper release of 1.3.7 end of this week. In the mean time, here is a link to the “bleeding edge” version in case you want to try it and send in bugs!

http://www.voidware.com/tmp/uWatch.hex

Also here are some of my notes reproduced:

Happy Hacking!

-- Hugh.

PS. its getting dangerously close to the time some people will have to throw away their slide rules :-)

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

Changelog:

1.3.7
- fix for AM/PM indicator wrong during noon to 1pm.
- removed Conversions BASE-N (was incomplete and superseded by Rob's BASE mode).
- stack lift missing for; a ENT b OP '.' or 'e'. ie non-digit number entry.
- stack lift missing for; a ENT OP, then enter a number
- fixed: the +/- key does not properly negate a negative result from a previous calculation
- fixed: OP then +/- followed by number went back to entry.
- fixed after OP then clear +/- shows -0
- fixed: recalling values from storage registers overwrites the x register.
- removed delays from STO/RCL to avoid slowing down macro programs.
- added ABS function to menu.
- changed R>P and P>R so that X is the angle and Y is the arg.
- fixed: C or mode escapes from menu

-- Experimental complex number support
- base 4 ops
- complex; X<>Y, ROLL, STO, RCL, 1/x, x^2, PI, ABS, SQRT, Y^X, Y^(1/X)
- complex: LOG, EXP, LOG10, 10^X
- complex: SIN, COS, TAN, ASIN, ACOS, ATAN
- entry of complex number using repeated '.' ie a second '.' is re-interpreted
as the start of the imaginary part, unless an exponent exists, in which case
a single '.' starts the i part.
- added REAL, C>R, R>C, CONJ to third menu 2nd page; real-part,
split, join and conjugate.

Here are the complex number user notes:

*** user instructions and technical info for complex number support in the uWatch.

There is no complex mode! the uwatch performs complex number operations when a
complex number is present and does not need to be set into a special mode for
this. The calculator's internal functions test for the presence of an ipart in
order to perform the best calculation. importantly, when there is no ipart,
the calculation is the same as for normal real numbers so it remains
efficient, fast and in some cases more stable numerically than the complex
version. So there is no loss of efficiency and precision by not having a mode.

However, the lack of a dedicated mode means that some real number calculations
can result in a complex answer. for example sqrt(-2) and acos(1.2).

Complex numbers are implemented using a parallel stack, so there are shadow
ipart registers for X, Y, Z and T (and also the 10 memories). A complex number
occupies a single line of display just as do the normal reals. Naturally,
there is less room to display the number on one line, so the number of digits
is shortened appropriately (NOTE: a MANT/SHOW key is planned to peek the whole
precision using both lines simultaneously).

** Entry Method:

Enter numbers in the usual way, and initiate the entry of an ipart by pressing
"." either once or twice. When a decimal dot or exponent is already present,
pressing "." will initate the ipart entry. the screen will change to, for
example, "1.2+i" waiting for the ipart entry.

If there is no decimal place already, two "."s are required, for example, to
enter 1+i, enter "1..", you can leave it as +i or enter 1 if you like, both
are acceptable. for example "0.." enters the value "i" (ie 0+i).

The +/- change sign key can be used during the process of number entry to
affect the signs of number parts. Before EXP or "i" is entered, +/- changes
the sign of the mantissa, after EXP it changes the sign of exponent, after "i"
it changes the sign of the ipart and, lastly, after EXP again, changes the
sign of the ipart exponent (NOTE: a backspace key in RPN mode is planned to
help make corrections when entering long numbers).

Since the entry of a complex number can be longer than the 16 digits
displayed, the number will scroll left on entry accommodating the rightmost
digits (NOTE: you cannot currently scroll back before entry).

** Functions supporting complex numbers (current list)

* base 4 ops (+ - * /)
* stack ops; ROLL, X<>Y, ENTER
* memory ops: RCL, STO
* 1/X, X^2, SQRT, ABS (modulus), Y^X, Y^(1/X)
* LN, EXP
* LN10, 10^X
* SIN, COS, TAN
* ASIN, ACOS, ATAN
* complex specific;

C>R = split complex into X, Y registers
R>C = combine X+iY into complex
CONJ = complex conjugate.
REAL = real part.

** Functions not operating on complex numbers

* R->P, P->R (always set ipart to 0) useful with C>R and R>C
* Factorial (gamma)
* complex BASE mode (!)
* // (parallel), should this do something clever with power etc?

*** NOTES

Trig functions of complex numbers only makes sense in radians, but since there
is no complex mode, the angular mode cannot be ignored. consequently, a trig
function in DEG mode will apply to a complex number by converting it to
radians.

Since we are modeless, R>P and P>R cannot perform special case operations for
complex numbers (eg working with polar complex), so instead there are C>R
and R>C split and combine operations which separate a complex number into
two stack levels x & y and the reverse. like this, the complex number can be
operated as polar by performing; C>R R>P R>C

Also, the split is a useful way to see a complex number at full precision
(then use combine to put it back).

**** Philosophy behind the complex number support

Some of the way in which the uWatch complex numbers work is different from
that on HP calculators. The calculators tend to have a complex number mode in
which some operations (eg P->R and R->P) work differently.

For the uWatch, i didnt want the complex number implementation to any way
interfere with the normal numeric operations. This is because complex numbers
are an advanced feature which many users will be unaware of, especially at
first.

The amount of time i read users posting on forums saying their 15c has a little
"c" on the screen and has gone into a mode where things work differently,
means that modes are confusing. It's really, really annoying when your
calculator/pda/phone etc. goes into a funny mode which works in a differnt way
and you're out in the field and dont have the manual and you dont know how to
get it back to normal. You wind up resetting the unit as a last resort!

There is also an argument that DEG/RAD should not be a mode. being in the
wrong angle mode has had me over in the past and i would guess it has been the
same for everyone else. However, the DEG/RAD mode is so ingrained and expected
that it would be wrong not to support it.

not having a complex mode creates a few problems. The uWatch cannot simply
look at the number to see if it has an ipart because the ipart may just happen
to be zero and it would be a mistake to operate with the number in different
way.

For example, the 15c R->P function converts a complex number into its angular
form when in complex mode, but operates on X & Y stack registers
otherwise. The uWatch cannot mimic this, so instead it offers functions to
split a complex into the X & Y registers (C>R), and another to combine them, R>C. In
this way P->R and R->P can always perform the same operation. To this effect,
they reset any residual ipart on X & Y.


#27

I guess I will have to make a special trip to London on the second Saturday of December!

I won't be there in November so have fun Hugh, but bring the cable to December's meeting.

That seems to be a lot of work! Make sure you get to the local pub for a pint or two to refresh!

Cheers, Geoff


#28

If your version still says the sqrt(-1) is 42, then you seriously need an upgrade :-)

Also, by then, I’ll have fixed that _really_ embarrassing bug that only comes out after it’s released!

#29

HOLEY COW, BATMAN!

#30

" ... its getting dangerously close to the time some people will have to throw away their slide rules."

I have a feeling a proper Samurai would hang onto the sword, even if provided with a vest pocket sized ray blaster ;-)

Even so, I must say that this new ray blaster is fantastic!

Bill


#31

A while back I started using a slide rule on a day-to-day basis – for things that I thought it might be good at. Although general calculations are, for sure, a lot more tedious than with a modern calculator, there were nevertheless a few things it excelled at.

Dividing up the bill in a dark restaurant was one. A 6” pocket rule is thinner, lighter and smaller (and doesnt require batteries) than an LED (or other light emitting) calculator. Due to some quirk of the universe, there is always a high chance that the number of people in your group is a prime number and this always makes manual division tricky (especially at the end of the meal after a few drinks). But since, (usually) the number isn’t far into double digits, this is and ideal division case for a slide-rule, even a pocket one with limited precision. Not only that, the result is sufficiently analog that rounding up and tippage is surprisingly easy to do.

The other discovery was comparing grocery prices. So price vs. volume/weight etc. two products of two different size offerings. Now ive discovered that the bigger volume quantity isn’t always better value than the smaller ones. Sounds silly, but its true. Supermarkets have realised that people automatically think the bigger box is better value and buy it without doing the math. So anyway, the trick here is that you don’t actually want to know a numerical answer but simply perform a comparator. So just by noticing the direction in which you move the slider, tells you which is the better value.

Consequently I discovered I could not find an ideal slide-rule for modern usage. Firstly, it has to be a pocket edition (I wound up in the end mostly using a little Pickett). As they get more complicated they sprout all sorts of multi log and trig lines. I don’t want any of these. One of my pocket rules has a superb folded scale. Ie two lines for regular multiple/divide, making it the “length” (and accuracy) of a full sized model. but its incredibly wide having just about everything else too, and not the sort you'd like to carry everywhere.

Here’s what I’d like:

Folded C & D, CF & DF, CI, x^2

That’s about it. No logs, trigs or anything that I’d want to reach for a modern calculator.

So, no, I wouldn’t give up my sword either!

PS. One of the weirdest things, is the looks you get doing the math on the rule. The amazing thing is that this isn’t because people are wondering why you’re using a slide rule, but because they don’t know what you are doing at all and they’ve never seen such a thing and don’t know what it is!

#32

" ... stuff like (-27)^(1/3) gives one of the complex roots rather than -3 (which would be preferable)."

If the result has an imaginary component that is vey close to zero, but not exactly equal to zero, then it would be necessary to include some logic to recognize when one of the numeric results is smaller than the available precision, and then convert that element into a zero. Then, if a complex result has a zero imaginary component, just display the real part.

Here is another test case. One of the cool surprises in mathematics is that the following simple little expression produces a result that is totally real:

i^(i)


#33

that's lucky, i^i on the uWatch gives 0.2078795764 and no i-part.

but, in general, you're right because it's possible to pick up some epsilon-i baggage. now i've completed the "first pass" of implementation, i'll be looking into rounding and edge case issues and general accuracy.

even now, the machine i turn to for complex numbers is the 15c. not my PC but a 27 year old calculator! i'd quite like to build my own cpx library up to the same level of trust, then i can put the code into anything i like (eg pc command line, uWatch, HP20b! whatever).

cheers!

#34

Quote:
Here is another test case. One of the cool surprises in mathematics is that the following simple little expression produces a result that is totally real:

i^(i)


The exact answer is e^(-pi/2) = 1/sqrt(e^pi) ~= 0.20788

It's no accident that the uWatch and calculators -- HP and otherwise -- are able to produce a purely-real result, as is evident by the sequence of calculations:

  1. j^j
  2. eln(jj)
  3. ej*ln j
  4. ej*(ln 1 + j*pi/2)
  5. ej*(0 + j*pi/2)
  6. e(j*j*pi/2)
  7. e(-pi/2)

The less-intuitive fact is that computing j^j on calc's with built-in complex support usually gives a slightly more-accurate result than computing e^(-pi/2) or 1/sqrt(e^pi). This is likely due to the use of an extended-precision internal value of pi, rather than entering a value rounded to 10 or 12 digits.

It's possible that an early HP-33s will give an inaccurate result:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=66246#66246

-- KS


Edited: 8 Nov 2008, 12:38 a.m. after one or more responses were posted


#35

Quote:
The less-intuitive fact is that computing j^j on calc's with built-in complex support usually gives a slightly more-accurate result than computing e^(-pi/2) or 1/sqrt(e^pi). This is likely due to use an extended-precision internal value of pi, rather than entering a value rounded to 10 or 12 digits.

Or, may be explain directly by the general formula of complex rise to complex power. My assumption is that the power function is implemented in the calculators using this general formula (or in fact the binary limited polynomial development of it).

If we applied this general formula to the computation of j^j, the accuracy of pi (or ‘e’) have strictly no impact because it is zeroed when applying value. The only evaluation that the calculator have to carry out is cos(0), sin(0) and ln(1).

Demonstration:

Step 1 : general formula of z = xy when x and y are complex :

X and y are complex so :


x = a + j.b
y = c + j.d, with j2= -1
We also need the Euler’s form of x only, which may be compute internally by the calculator using ABS and ARG function :
x = a + j.b = r.ej.tho

where r = ABS(x) = sqrt( a.a + b.b )
t = ARG(x) = atan(b/a)
modulo pi or 180°
depending of trigonometric mode and sign of a to cut t value in the principal domain.

This state, by substitutions we get:

z = x y
z = (a + j.b)(c + j.d)

Expending we get:

z = (r.ej.t)(c + j.d)

z = (r.ej.t)c . (r.ej.t)j.d

z = rc.ej.t.rj.t.e-d.t

z = rc.e-d.t.(rj.d . ej.c.t)

From Euler’s formula:
    ej.c.t = cos(c.t) + j.sin(c.t)
Because r and d are real, we get:
    rj.d = eln(rj.d = ej.d.ln(r)
rj.d = cos(d.ln(r)) + j.sin(d.ln(r))
Subtituting in z :

z = rc.e-d.t.[ cos(d.ln r) + j.sin(d.ln r)] . [cos(c.t) + j.sin(c.t)]

z = rc.e-d.t.
[ cos(d.ln r). cos(c.t) - sin(d.ln r).sin(c.t)
+ j.( cos(d.ln r). sin(c.t) + sin(d.ln r).cos(c.t) ) ]

z = rc.e-d.t.[cos(c.t + d.ln r) + j sin(c.t + d.ln r)]

To summarize, given

x = a + j.b = r.ej.t where t (tho angle) expressed in the correct quadrant
y = c + j.d

z = xy = rc.e-d.t.[cos(c.t + d.ln r) + j sin(c.t + d.ln r)]

So z can easily be expressed as a complex result:


Z = A + j.B = xy
Where
A = rc.e-d.t.cos(c.t + d.ln r)
B = rc.e-d.t.sin(c.t + d.ln r)

Step 2: Numeric application for j^j


j = (0,1) = 0 + j.1
so, we get
a = 0, b = 1
c = 0, d = 1
And
r = 1 since ABS(j)=+1
t = pi/2 or 90° or what ever angle value expressing the right angle.

Thus :

A = r0.e-1.t.cos(0.t + 1.ln 1)
B = r0.e-1.t.sin(0.t + 1.ln 1)

Simplifying in :


A = e-t.cos(ln 1)
B = e-t.sin(ln 1)

A = e-t.cos(0)
B = e-t.sin(0)

A = e-t
B = 0


Demonstrating that z=j^j is a real, independently of the accuracy (or the correctness) of the angle argument estimated for j.

Of course, correct numerical value will only be obtained with t correctly approximate in radian through the ARG function. This bug of the ARG what already notice for specific HP calculators.

j^j = exp(-pi/2) + 0.j

Edited: 7 Nov 2008, 11:52 a.m. after one or more responses were posted


#36

Yes, that's the way im implementing it when i have iparts. for real numbers, i perform a simplified calculation.

#37

Quote:
Or, may be (explained) directly by the general formula of complex (raised) to complex power. My assumption is that the power function is implemented in the calculators using this general formula (or in fact the binary limited polynomial development of it).

"C.Ret" --

I'm not sure exactly what the extensive formulation you presented is illustrating, but I still believe that j^j would be calculated using the procedure I showed earlier, repeated below for convenience:

  1. j^j
  2. eln(jj)
  3. ej*ln j
  4. ej*(ln 1 + j*pi/2)
  5. ej*(0 + j*pi/2)
  6. e(j*j*pi/2)
  7. e(-pi/2)
  8. 0.207879576351

The results of natural logarithm and multiplication for complex numbers in steps 4 and 7 would be carried out in rectangular coordinates, with a purely-real final result based on the product of the non-zero imaginary-valued components, as the other three three terms of the multiplication are exactly zero.

Therefore, the extra accuracy of an extended-precision internal value of pi would allow for an improved result. The final result (step 8) to calculate the exponential in complex mode introduces no error, as the angle is zero, and cos(0) and sin(0) are calculated exactly.

-- KS


Edited: 11 Nov 2008, 2:18 p.m.

#38

I said it was surprising, mostly as a comment on how this is beautiful. This was also subconsciously intended as a bit of a social comment on how it is that many people do not expect mathematics to be so beautiful, or simple. I suppose "elegant" is the word I was looking for.

About pi. In various referene books, the expression for logarithm, and a several of the complex hyperbolic functions that rely on the logarithm all contain a hard-coded pi constant. This bothered me, greatly, so I edited it out. For example:


7: (a + i b)^(c + i d) = alpha * cos(beta) + i * alpha * sin(beta)

8: alpha = (a*a + b*b)^(c/2)*e^(d*(arctan(a/b) - 2*arctan(signum(b))))

9: beta = ln(a*a + b*b)*d/2 - c*(arctan(a/b) - 2*arctan(signum(b)))

The original expression for (a + i b)^(c + i d) contained this bit of code, in a few places:

signnum(b) * pi / 2

I shortened the overall expression by breaking it into 8 and 9. Then, I set about eliminating the had-coded pi constant by replacing the little code snippet with the following:

2*arctan(signum(b))

In radians this amounts to the same thing, and it evades using a constant for pi without making use of the atan2 function that might not be available on all scientific calculators.

I still have not been able to figure out a way to persuade the HP-50g to display the internal equation that it uses for complex powers. I made the ClassPad and the Voyage 200 display their versions. They were identical, and surprisingly both of those machines used a hard-coded pi constant. I suppose their method of evalution is symbolic, and in some way this allows heuristics to compensate for numeric errors that might have crept in.

Bill


#39

Yes !

Quote:
In various reference books, the expression for logarithm, and a several of the complex hyperbolic functions that rely on the logarithm all contain a hard-coded pi constant. This bothered me, greatly, so I edited it out.
This bothered me too.

Your set of equations is much better, since the calculation it carry out is now independent of the trigonometry one may use in his specific application; degree, grad, rad or whatever angle units such as specific bytes per rotation one may get from a position sensor or one may address to a step-motors command line.

As soon as your calculator use the same angular unit for its computation in all the three functions arc tan, sin and cos.

 7: (a + i b)^(c + i d) = alpha * cos(beta) + i * alpha * sin(beta)
8: alpha = (a*a + b*b)^(c/2)*e^(d*(arctan(a/b) - 2*arctan(signum(b))))
9: beta = ln(a*a + b*b)*d/2 - c*(arctan(a/b) - 2*arctan(signum(b)))

Using the notation of my previous post, I may write:


7: (a,b)(c,d) = rc.e-d.t.[cos(c.t + d.ln r) + j sin(c.t + d.ln r)]

8: alpha = rc.e-d.t
9: beta = c.t + d.ln r

where
r = (a.a +b.b)1/2 = abs(x)
t = arctan(a/b) - 2.arctan(signum(b)) = arg(x)

#40

Quote:
it’s pretty cool. For example, you can enter and calculate stuff like (1+i)^(1+i) much faster than on a HP15c.

This is interesting. The uWatch is only running at 250KHz (125K instructions per second at best) during processing, and Hugh's code is double precision floating point in C using the (quite ordinary) Microchip C compiler not optimised for speed, running on the 16bit PIC architecture.

Anyone know how many MIPS and clock rate the HP15c runs at?

I know it's comparing apples and oranges, but it would be interesting to know.

BTW, it's possible to dynamically change the clock rate on the uWatch from 32KHz to 8MHz in software. So a particularly slow routine could easily change the clock rate when it starts and drop it back when it's done.

My original uWatch code actually ran at 32KHz, but I upped it to 250KHz as there wasn't much difference in the power consumption.

Dave.


#41

My quess is that the 15c HW is much slower (which would also explain the amazing battery life).

one of my few criticisms of the 15c is that it is a slow machine, even manual operations seem to drag.

.. or maybe it's my awesome coding :-)


#42

"Clock speed of 15C is about 220kHz and on the HP-41 is about 340kHz (60% faster)"

(Reference: www.finseth.com/hpdata/hp15c.php)

Edited: 7 Nov 2008, 2:48 p.m.


#43

Single-word instructions on the Nut processor take 56 clock cycles, so the Nut running at 220 kHz can execute around 3928 instructions per second. However, each instruction can add or subtract anywhere between one and 14 digits of a word, so for instance the entire addition or subtraction of the mantissa of a floating point number takes one instruction (not counting aligning the operands, normalizing the results, and dealing with the exponents).

The PIC microcontroller in the uWatch executes up to 125,000 instructions per second, almost 32 times as many as the Nut in the 15C, but a single PIC instruction can't do as much work as a single Nut instruction. On the other hand, many Nut instructions do NOT do nearly as much work as the addition of an entire mantissa. The PIC will definitely win for general-purpose computing.

The HP calculator processor architectures from the Classic through Saturn were very heavily optimized for use in calculators. Due to the advances in technology since those were designed, it no longer makes sense to custom-design a processor architecture for a calculator.

#44

That slow speed is one of the strengths of the 15c. (And the 11c). Were they any faster, you would never have the chance to enjoy seeing the machine "running."


#45

Quote:
That slow speed is one of the strengths of the 15c. (And the 11c). Were they any faster, you would never have the chance to enjoy seeing the machine "running."

Hi, Bill --

Maybe that's a reference to the following ironic passage in page 182 of the HP-15C manual: "Press f SOLVE 0 and sit back while your HP-15C exhibits one of its powerful capabilities. The display flashes running while SOLVE is operating."

If it had more power, the user wouldn't have to "sit back" and wait...

Seriously, its processor (shared with the HP-41) doesn't allow too much more speed. I've gotten unstable performance with a 3.3x acceleration of the HP-15C. Hardware that accelerates the HP-41 includes a switch to restore normal speed if necessary.

-- KS

#46

Quote:
My quess is that the 15c HW is much slower (which would also explain the amazing battery life).

The "running" speed of the 15C is almost entirely unrelated to battery life in terms of how much computation one gets from a set of batteries. In fact, battery life might be better if it ran faster.

For CMOS ICs, there is a certain amount of quiescent or "leakage" current that is independent of clock rate. This is the power that the calculator consumes all the time, and it is extremely low.

When the calculator is in "light sleep" (sometimes known as "drowsy mode"), the display is enabled and running on its own oscillator. That oscillator runs at a low rate because it wouldn't give any benefit to run fast, but would only use more power.

When the calculator is actually thinking, the Nut main oscillator is enabled. The power consumption in this mode is much higher. To a first approximation, increasing the clock frequency does not affect battery life, because if you run it twice as fast, it draws twice as much current, but it gets the answer and goes back to sleep in half the time. Due to secondary effects, in some cases running at a higher clock rate actually can reduce overall energy consumption.

The reasons the Voyager series calculators were designed to run so slow probably include:

  • The CMOS technology used was optimized for low quiescent power consumption, not for high clock rates
  • There had to be enough margin on the timing performance to run on the full specification range of battery voltage and ambient temperature
  • The calculator is actually in running mode while you hold a key pressed (for debouncing), so there would be more energy lost to debouncing. This could have been eliminated by different design of the keyboard scanner.
  • If it ran faster, and the user accidentally put it into an infinite loop, it would drain the battery faster without getting useful work done
  • Making it faster probably wouldn't have sold more units -- the average calculator buyer doesn't care that much about the speed (within reason)

#47

Quote:


The "running" speed of the 15C is almost entirely unrelated to battery life in terms of how much computation one gets from a set of batteries. In fact, battery life might be better if it ran faster.

For CMOS ICs, there is a certain amount of quiescent or "leakage" current that is independent of clock rate. This is the power that the calculator consumes all the time, and it is extremely low.

When the calculator is in "light sleep" (sometimes known as "drowsy mode"), the display is enabled and running on its own oscillator. That oscillator runs at a low rate because it wouldn't give any benefit to run fast, but would only use more power.

When the calculator is actually thinking, the Nut main oscillator is enabled. The power consumption in this mode is much higher. To a first approximation, increasing the clock frequency does not affect battery life, because if you run it twice as fast, it draws twice as much current, but it gets the answer and goes back to sleep in half the time.


The new 20B is flawed in this respect. It runs at a crazy fast speed and wastes a fair bit of power in the batteries internal resistance (which is higher than what HP claim).

I do hope HP don't make the same mistake on future calcs.

Details available in a post I made quite some time back (my forum search skills aren't up to the task at the moment)

Dave.


#48

Yes, battery series resistance is one of the reasons this doesn't scale up arbitrarily. For a typical ASIC or microcontroller in a calculator it probably isn't much of an issue when deciding between 200 KHz vs. 2 MHz, but it is not too surprising that the effect may become fairly pronounced at 30 MHz.


#49

Quote:
Yes, battery series resistance is one of the reasons this doesn't scale up arbitrarily. For a typical ASIC or microcontroller in a calculator it probably isn't much of an issue when deciding between 200 KHz vs. 2 MHz, but it is not too surprising that the effect may become fairly pronounced at 30 MHz.

For those interested, here is my original post on the subject:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv018.cgi?read=137911

Dave.

#50

As promised the v1.4.0 firmware is out. I've fixed all the known bugs and complex number support is feature complete. Even ALG mode works!!

you can get it (including the source code) from sourceforge.

http://sourceforge.net/projects/calcwatch

or the hex only at

http://www.voidware.com/tmp/uWatch.hex

Good Luck, and bug reports welcome!


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime: complex numbers in CAS. Alberto Candel 1 1,949 12-06-2013, 02:36 PM
Last Post: parisse
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 3,716 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  Complex Number Entry on Prime Jeff O. 19 5,328 11-16-2013, 12:34 PM
Last Post: Jeff O.
  HP Prime complex results Javier Goizueta 0 1,018 10-06-2013, 12:59 PM
Last Post: Javier Goizueta
  HP Prime Solving Nonlinear System of Equations for Complex Results Helge Gabert 11 4,393 09-30-2013, 03:44 AM
Last Post: From Hong Kong
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 3,566 09-08-2013, 10:40 PM
Last Post: CompSystems
  Elliptic integrals of 1st and 2nd kind calculated by complex agm Gjermund Skailand 3 1,542 06-29-2013, 03:39 PM
Last Post: Gjermund Skailand
  HP-11C and complex numbers Antlab 5 2,260 06-28-2013, 08:59 AM
Last Post: Antlab
  71B Complex User Defined Functions in Calc Mode? Michael Burr 0 965 03-18-2013, 09:38 PM
Last Post: Michael Burr
  HP 34S complex # problem Richard Berler 2 1,246 02-17-2013, 11:01 PM
Last Post: Richard Berler

Forum Jump: