At some point, you'll probably distribute the startup script alongside the rest of the program (under a slightly different name, so that people don't overwrite their own too easily), won't you ?

The catalog uses an even better system, where you can press a number from 0 to 9 or a letter key from A to L (from XoT to the -> key) to select a menu item. Menu items start counting at 1, 0 selects the 10th item, XoT (A) selects the 11th item, and -> selects the 22nd item.
So if you want to quickly insert, for example, the rationalize function, you press F1 (catalog) then 9 and finally cos (E).
You can then memorize (or build a cheat sheet ) the key sequences of the functions you use the most.

As for special chars, these are not supported by the console system nor Eigenmath itself. I have made sure all the math-related symbols Eigenmath can accept as operators have been made available either using the keyboard or through the catalog. If you can't find one, ask here.


I don't intend to distribute another file along with the g3a for internet download, as that would mean zipping them which (unfortunately) seems to add yet another step of complexity for many users when installing add-ins. This way it's a matter of copying to the right folder.

When transferring the add-in to other people with calc-to-calc links, I intend to send both files at once, but that's just me.

Also, I ask you to not host Beta versions of the add-in on other sites. It breaks my download counter and makes it harder to update versions (something very important specially in the case of betas)

Over time, I too have helped various users who were incompetent at using computers and calculators, so I understand what you mean... but I still think it would be much better to distribute at least the binary, the sample startup script, and a README, in a ZIP file
(why not the source code, as well - upstream Eigenmath is OSS, otherwise this port wouldn't have been possible)

Experience shows that distribution of pure binary files without a README is pretty infrequent in the calculator community (even for Nspire documents, whose tabs can contain e.g. README information). Additionally, not distributing the startup script would cause many users to miss on that feature (and the possibility of such a feature, since most of them don't read the README), which is a shame.

EDIT:

I never upload third-party software to TI-Planet, or other sites
I manage less than 10 files on TI-Planet.

I agree that hosting downloads without asking is a no-no; I've spoken to TI-Planet about that before. On the other hand, I agree with Lionel that distributing as a zip containing the binar(y|ies), a README, and if applicable, source, is what users are accustomed to. I hope that you'll eventually upload the final version to the major archives, including Cemetech, though; I think this is a tool that every Prizm math user (ie, students and teachers) need on their calculator, even if they don't use it that often. It shows that the Prizm is indeed capable of running a full-featured CAS, even if Casio didn't bother to make a CAS version or include a CAS.

A number of TI-Planet archives do point to the upstream site, starting with TI's software (when it's still available) and Kerm's software

I would have less problems with people hosting files on their sites and uploading to every major archive, if the add-ins had the ability to self-update themselves when run or, at least, warn when a new update is available. Unfortunately this is not possible thanks to Casio's breath-taking innovative networking technology called AirGap(tm).

I made the mistake of distributing early Utilities binaries to many people, both over the internet and in-person, and now there are dozens of people still stuck with really early versions that are unstable and miss 80% of the current features, and I have no easy way to contact them or convince them to update.
At the time I didn't know Utilities would have so many changes till its current version so I didn't think it would be a problem to distribute these versions as they are "almost 1.0". 1.0 will get out really soon (once I get the nice ZIP file and readme you want done), seven or eight months and many beta releases after I thought I was reaching 1.0.
I don't want to repeat the same mistakes with my new projects.

Once, a colleague got a Prizm, and he tried to install Raptor... by copying the ZIP, as well as the contents of the ZIP, into the calculator's storage memory. This included source code, bmp icons, readme... it also made his calculator super slow because of the big amount of files in the root folder. Not to mention the wasted space. Best of all, after all that he managed to put the g3a in the wrong folder. I wasn't too surprised.
(we had no computer near us at the time and Utilities couldn't still move files and folders around, and I didn't have my link cable, so I told him what to do when he got home... I think he never got it right and just gave up).

The reason why source code for my add-ins stays on GitHub (for this one, not yet...) and distribution occurs in files as simple as possible is to make the life of the common user easier. By "common user" I mean someone who just got a graphic calculator for school and maybe didn't even know it could run third-party software.
I'm trying to reach the people who don't usually go on calculator software archives. The archive files with readmes and source code are very nice for people who know what they are for, and I too appreciate when I get such a complete download. But most people aren't used to downloading software like that, for many people even downloading and running setup files of Windows software is hard (for me too, but for different reasons )
That's why app stores are such a success, they "just work" when it comes to installing, updating and uninstalling software. It's also much easier for developers to track the amount of downloads and get feedback. The problem is that there's no way to make an app store that runs in-calc and "just works".

For experienced users willing to mess with the source code, by pulling from GitHub they can be sure they are using the latest one. They can also get the code for previous versions by looking in the commit history, for example in case they want to make sure the binary they have came from that code.

I've seen more cases in the style of that one of my colleague that wanted to play Raptor (and he is more or less computer-savvy).
Some people never connected their Prizm to a computer, but I'm sure they would benefit from Utilities, Eigenmath or any other add-in as much as everyone else. Some of these people think of non-official add-ins and games as something obscure - and if we don't enlighten them, it's most certainly really going to turn into an obscure thing.

It's unfair to reserve the greatness of add-ins to people who can read READMEs in English and extract things into the right places. I'm working towards having my software accessible to "every Prizm math user" - independently of the fact they RTFM, or are tech-savvy. They just need to be able to understand a bit of English and use Google.
I believe it's better to have an user who doesn't use a software to its full potential because I didn't distribute a readme, than to have an user who couldn't even install it because I distributed a readme, but it wasn't read or understood. People who are interested in a readme can still get it, it just doesn't come with the binary.

Sometimes, when people run into problems they just don't care to ask for help, or think it isn't worth the effort, and miss all the greatness. Other times, I must admit, I have no patience or time to help when I'm asked. So I'm not just making things easier for these users, I'm also making things easier for me.

I definitely plan on making complete ZIP files for people who want them and for submitting to traditional archives (since users who download from there expect ZIP files and readmes). Creating ZIP files and submitting to archives will only occur every major release, because updating the file on every archive is a pain - and I'll almost certainly miss some of them. It also makes tracking the number of downloads a pain.

At the same time, I intend to have pure binary downloads without readme, and have the add-ins walk the user through their features when they are run on the calculator (see Utilities' first-run wizard - it's basically a readme many people still don't read/understand, but at least I'm sure it was shown to their eyes). I've seen software for computers and smartphones follow this approach and I believe it's easier for an user to learn about a feature when the "right time" comes, instead of having a monolithic readme (that 90% of the users won't read) detailing every aspect.

For Beta versions, it's much easier for me to have the "readme" in an online form, and just have a simple binary download. For the non-savvy users, my experience tells me it's also easier to have it like that when it comes to stable releases.

Today I took the time for checking the fx9860 port of Eigenmath by Diameter. The factoring bug happens there too. The bug does not happen on x86-64 platforms or ARM in little endian mode (Nintendo DS - the port for it doesn't have the bug).

I believe it has something to do with CPU endianness, since of the platforms Eigenmath runs on, all are little endian except the Casio calculators, which use a SH CPU in big endian mode.
It is probably not a compiler optimization trick, because Taumath (the fx9860 port) was compiled with the Hitachi compiler, and my port was compiled with GCC. The two ports are based on the same source code but other than that don't have much to do with each another except for some memory settings I copied (and then also tweaked).

Unfortunately I lack the knowledge to fix the factoring functions... maybe my last option is to bother G. Weigt again, but I'm not sure he's very interested in fixing a bug he can't reproduce on "traditional" systems.

EDIT:
Beta 3 is out. Get to know the changes:
I found console output to be painstakingly slow, so I decided to investigate. Turns out diameter's code, which I adapted to the Prizm and PrintMiniFix, was really inefficient. By changing some lines I managed to cause a dramatic increase in console speed. Eigenmath is really fast now
Other new things include the ability to stop input execution by holding AC/on, like on the Casio system. To Eigenmath, this has the same effect as pressing Esc on the GUI version of it (hence the message that's displayed).
The "clear" command now not only clears the variables but also the console output.
The factoring bug still isn't fixed, though...

Download is at the same URL (both long and short to avoid issues with browser redirect cache): http://tny.im/prEigenDL

And here's a new startup script with the xor function:

Code:

wow, looks good, i hope you can get that factoring bug worked out

On TI-Planet, Bisam is rightfully pointing that for npr and ncr, factorials and divisions of these large numbers are costly.
Maybe you could suggest the addition of more efficient builtins for those to George Weigt, or make them yourself ?

I can barely get him to help me with the bugs (which I understand because he probably has more things to do than help people with unofficial ports), let alone add new features. I agree factorials and divisions are costly, and since the npr and ncr implementations are based on them... but the truth is, on every computer system (even with just integer math) these operations are costly, so it's no big surprise they are slow/fail with memory allocation errors on Eigenmath.
If you check the factorial function on the Casio system, you'll see that 100! will already fail with a "math error", while this Eigenmath port will happily calculate 1000!. So it is already a big improvement over the original capabilities. Despite being sometimes slow, Eigenmath can also deal with scientific notation with exponents well above 99 and below -99, unlike the original math engine.

I can't understand the Eigenmath code well enough to fix the existing bugs and make small changes, let alone add new commands myself...

Meanwhile, George Weigt replied to the email I sent him about the endianness thing, and he says the problem doesn't occur on a PowerPC Mac which is big endian, like the SH4 of the Prizm. He tells me to disable the compiler optimizations... I'll try that, but I'm sure the resulting binary will be huge.

EDIT: compiling with -O0 or no -O option at all gives strange linker errors... this is annoying.
EDIT2: seems to be related to this problem: http://forums.codeblocks.org/index.php/topic,15436.0.html
In my case, I believe it's the "library from Casio" that's causing the problem (it wasn't compiled with GCC, I only converted it). Unfortunately, I have no other option but use it for setjmp/longjmp.
EDIT3: other kind of linker errors, this time related to libm, happen when I compile with -Ofast. I tried compiling with -O1, -O2 and -O3, and while these all compiled and resulted in a much increased binary size, the bug wasn't fixed either.
Can the problem be related to the Casio implementation of some function in their library? That would explain why it also happens on the fx9860G. At the same time, I'm trying to make sure libm is used in place of the Casio library when it comes to math functions... and this libm is not used on the fx9860G for sure.

EDIT4 (unrelated): Just found out an outdated version of this add-in (Beta 1!) is at Planete-Casio, with their own hosting and download counter! I swear the next add-in I build will not be licensed under the GPL or I won't release any kind of "consumer preview" versions. It's really annoying.

EDIT5: I managed to fix the factoring bug
It was just a matter of un-commenting some debug printf lines, which I thought that weren't important (hence why I commented them). But even without these printf lines running except when some static var was set, they seemed to be important, because after I un-commented them, factoring works fine. I'm not sure what was the problem, eventually it was really a compiler glitch. What matters is that it works now

I've noticed that French sites seem to have different ethics than English sites in re-hosting files without asking (no, not just TI-Planet). My theory is that it's a cultural divide that we mutually don't quite get.

Congratulations! That must have been quite a relief when you finally tracked it down. Out of curiosity, can you post the lines of code in question? I'd like to see what about them was the problem.

I just took the // out of some lines, and magically it started working... I really don't know what lines were (I did a find&replace). It is now the same as the original file. Maybe I had commented something I shouldn't...

Fair enough; thanks for the clarification. The important thing is that it works now!

cool, so glad you got that factoring bug fixed, I thought maybe it would kill the project.

The people asking for command history and cursor editing are going to love the next beta.

I'm looking forward to it.

Beta 4 is out! Changelog:
- Input history (20 entries maximum, use the up and down keys);
- Input with movable cursor (use the left and right keys);
- Ability to run arbitrary scripts, select with a file browser (press F2 on the main screen);
- The hourglass on the top right now spins (let's hope this doesn't cause instability);
- The factoring bug is fixed! factor(x^2+1) now correctly returns x^2+1 (since that can't be further factored).

Download the new version at the same address: http://tny.im/prEigenDL

EDIT: with a new strtod and a little change to a line of code, I managed to make Eigenmath support display and parsing for as much as 10 significant digits on floating point numbers, putting it on-par with Casio's system. Stay tuned for the next version.

Wow, this is really awesome. Do you plan on using the same small font for the input method in the end-product, or using the casio default font?

EDIT:
could you make eigenmath have an eact strip?

I plan on using the small font for input.


It's an interesting suggestion and I am definitely taking it into account.

Beta 5 is out!
New features:
- Floats are displayed with a higher number of significant digits now (10, like on the remaining parts of the OS).
- Fixed loss of precision on float input (and that's why there's now a giant copyright text in the version/about screen... if you have been reading the IRC conversations, you'll know the details).
- About screen now accessible with Shift+Menu, to free F6 for use (read on)
- Users can now assign the execution of custom functions to unused keys, for example through the startup script (or any other script, or even just by running commands directly).
These unused keys include F3, F4 and F6, as well as any keys the text input routine doesn't know how to handle. You can also set custom labels for the mentioned function keys. Here's a new startup script that illustrates the use of the feature, by assigning the "clear" command to the F3 key, and other functions to some other keys:

Code:

prizmUIhandleKeys - this symbol is checked to see if custom key handling should be enabled.
prizmUIkeyHandler(k,s) - this function is executed if custom key handling is enabled, every time a unknown key is pressed. k gets the number of the key as returned by the GetKey syscall and s gets the key modifier status (shift, alpha, alpha-lock, etc.). Values in decimal.
prizmUIfkey3label, prizmUIfkey4label and prizmUIfkey6label - labels for the user-defined function keys. Values in decimal. You can get the values in hexadecimal, for all the available labels, with INSIGHT. Here are a few of them (in hex too): http://prizm.cemetech.net/index.php/FKey_Bitmaps
You can get the value for a certain key by modifying the startup script so that line 26 is not commented (remove the --) and line 27 is commented (add -- at the beginning). The value for the key, along with the current modifier value, will then be printed when you press an unknown key.

Download at the same address: http://tny.im/prEigenDL

can we make scripts interactively?

In the manual it says:



Can you make it possible to do that in the PRIZM port?