Great job Martin! (Or would "Mooi werk Martin!" be more appropriate?) I like the idea of integrating Graph3 and DiffEqu in a single app.
Nice to see there are still great applications being developed (hate to admit it, but things where a little quiet lately). I'd love to try this one out, but ehm, where did I put that GraphLink...? :p

(BTW, if any of the DS people are reading this: the Graph3 page on ds.com hasn't been updated yet.)

Thanks, Rob. (Dutch is also fine, "Bedankt, Rob.") There was enough space left in graph3 and diffequ mode also extends the graphing modes, so it seemed appropriate to add diffequ support instead of making a new app.

In case anyone is interested, I've also finished basicbuilder 3.0 The reason I mention this, is my other Summer of Code proposal was to extend and opensource basicbuilder. I haven't extended it much but now it's opensource I hope others can help me with that. You can find the source code at the above link. I haven't been able to upload it to ticalc.org yet, because it keeps giving me the error "Failed to parse uploaded file!" (Maybe someone at ticalc.org can help me out with this.)

In case anyone finds a bug or any other problem with graph3 or basicbuilder, please contact me and I'll try to fix it.

Good job indeed, but it would have been better to release this as a stand-alone application... That is, unless there was "extra room" in the Graph3 application, in which case this would make sense.

Graph3 still takes up one page (16384 bytes) on the calc. It didn't get any larger, it just got more functionality. So I just used the "extra room" left in graph3 to add diffequ support

hey you guys can talk dutch???!
Wel I also check this:
hallo toffe vrienden

Well, Im not quite sure what Differental Equasion graphing is exactly. x.x But it looks cool and good job.

D( Differentiate is used in calculus... Pain to graph by hand, so it is cool that the 83-84 series is being updated to be used in higher level college courses, since the average person can't afford a 89, 92, or V200.
Great idea, but it has to join my other two good graphing apps...
1:) Inequality Graphing
2:) Conics Graphing
And both of these hog up to 32,626KB of Archive, Now if those can be combined with DiffEq, then more space could be cleared...
Whew, that was one long-winded sentence...

The 89Ti costs as much as the 84+SE...

Really cool guys! I really enjoy my 89 and Voyage, but my teacher doesn't let me use them, so now I can have some more of the functionality!

... now only if I could find a program that emulates the "solve(" and "expand(" functions....

As a matter of fact, I am working on a program as a side project to Mathematica for the TI-83/4+/SE series calculators entitled "Symbolica". It is designed to do just that. However, it will mostly be working with polynomials (at least for now). Factoring, solving, expanding, input parsing, etc.

Awesome guys, this only proves one thing: there is NOTHING you can't do with a z80, some ram, rom... etc. Keep the good job.

Congratulations to Martin and Kirk. People like you are the ones that make this community so great.

How is this possible if the TI-89 is faster in processing speed?
anyways, I don't know exactly why but it feels like an insult to the TI-89 :)
>.<
:(

There are a couple of reasons. Perhaps the most immediate is the lower screen resolution compared to the 89. There is also the issue of general overhead required to run the operating system as the 89's is much more complex. Finally, it is quite possible the algorithm used on the 84 is more efficient than that used on the 89 because the algorithm used on the 84 was tabored specifically for that task.

I'm sure the m68k takes no offense. ;)

Zarel would also like to point out that while your reasons do account for some of it, it shouldn't cause that big of a difference. The main reason it's far, far faster on the 83 series calculators is simply because it doesn't have a CAS. All it has to do is arithmetic. The 89 series calculators, on the other hand, do have a CAS, and do much more complex manipulations of expressions than simplification. Although it means the calculator is more powerful (&#8730;(8) = 2&#8730;(2) ), it also means it's a lot slower in evaluating simple expressions (Although it might also be because the CAS itself is inefficient).

[C'mon, please display Unicode correctly...]

That's what I was trying to get at with the os part while trying to not get complicated.

Blaming AMS's CAS for its lack of graphing ability is incorrect. A correct statement would be to say that AMS's C graphing routines are slower than these assembly ones. AMS would not affect a graphing utility programmed in C or assembly in any way (with the exception of interrupt handlers which can even be disabled). So I'm sure that with the 68ks' higher clock speed and larger/more registers/other resources, a faster graphing utility could certainly be programmed.

oh, ok that makes more sense now ty

You'd still want to use AMS's infrastructure to evaluate the functions though, unless you want to code your own expression parser and evaluator (which is likely to work only on a limited set of functions compared to what AMS supports). You are then constrained by the time needed by NG_approxESI.

Sorry if this is a dupe.
Thats true, any graph-app for the ti89 should be based on NG_approxESI.

However Zarel's post suggests that numerical evaluation in NG_approxESI is slowed down by the CAS. I can't see any CAS leftover within NG_approxESI being responsible for a noticeable slowdown in basic floating point math. E.G. the only CAS slowdown from evaluating '2.3 + 3.2' should checking for floating point tags and jumping to the correct code for the overloaded '+' operator that handles two float types.

The exception to this is matrix math. NG_approxESI uses CAS formulas in approximate mode. But I doubt that formulas with matrices where used when benchmarking this 83 program to the 89.

But then again Zarel might be right about the CAS leftovers. I hope that the ti89 has a more advanced NG_appoxESI for graphing that does faster substitution than pulling tricks with 'f(x)|x=?' or VAT searches.

And does the CAS have optimizations for doing math that combines INTEGER tagged types with FLOAT types? E.G. To graph y(x)=2*x, does the CAS repeatedly convert the integer 2 to a floating point 2.0? Or is multiplication overloaded with special optimizations for multiplying a float by an integer? Or is there a first pass that creates a new version of the formula: y(x)=2.0*x ?

Also it might not be the ti89s floating point performance but the window API.

Is it?
They always make newer stuff.
I cant help it.

Congratulations, I'm glad this project has come to fruition. I've followed Martin's progress very closely on Detached Solutions' private Summer of Code message board and was also able to give him a few hints. The only sad thing is that it's probably going to lose the POTY vote to some crappy game...

Well it's certainly got my vote.

While I largely share your sentiments regarding games having a rather annoying tendency to beat "real" programs (the kind the calculators where intended for) in the POTY vote, I don't think it's fair to use the phrase "some crappy game"; even if the nominated math programs (I'm not yet promising I'll vote for DiffEq, the year is still long, and I'd love to be surprised by an even cooler app) are beaten by a game (my vote will try to prevent it for one), then I'm sure it'll at least be a very good game (otherwise it wouldn't be feature (and therefore nominated) in the first place).