I don't think this would be allowed on any standardized test. ;)

They even wrote an OS for it... I think we should convince TI to produce it.

That has absolutely nothing to do with my comment.

i agree, even though it wont be allowed on high school tests, it would be good for college, and it's just flat out calculicious with its features

Due to the fact that this prototype was manufactured in 2002, the chances of TI producing it now are slim. perhaps TI believed it to have an insignificant (i.e. not significant *enough*) profit margin and chose to have it remain as a prototype.

Slight spelling error in the first word in the second sentence.

Technically, it doesn't have a qwerty keyboard

It has a stylus though.

Hmmm, You have a point there...and that is what most places say for the rules...

As Lewk pointed out, it has a stylus; since they don't allow PDA like devices, I doubt that they would allow a calculator lacking a physical qwerty keyboard while still retaining that data input function from a onscreen virtual one.

But does it have a qwerty OSK?

I do not know the answer, maybe I missed it in the documentation...anyone know for sure?

Yes, it does - there's a picture that shows one.

Wow, you could make some AWESOME games on that if it could take ASM or a similar language!

Hmm... a computer that doesn't use ASM...

What is wrong with that :D?

Now why would a computer need ASM? :P

What if the CPU ran BASIC (or some other high-level language) directly? :)

CPUs run machine code, or binary. You can thus always program in assembly which is directly related to machine code.

The only problem is getting it to run. This was the case with the ti-85 who's operating system didn't have any apparent way of running programs written in assembly (though a method was eventually devised. All of ti's new calculators come with "asm support" though.

If the CPU ran tokenized BASIC, then the machine code would be BASIC. That would in turn mean that ASM would then be untokenized BASIC. It certainly can be done (& I think it has been done before, though the name of the project escapes me at the moment), but it is not the most efficient design for a processor.

ASM is basically enumeration for machine code. Thus, this machine code tells the processor what to do. For example, put the integer 4 in the first register. The only way that this would be possible would be if:

1. BASIC compiled to machine code in this implementation.
2. There was a translator that translated BASIC into instructions.

In the first case, it would use machine code. In the second case, it would still use machine code (in some form) internally, perhaps in an optimized manner. This would not be visible to the user, and the user would think that the processor directly ran tokenized BASIC. It would be much more efficient (that is, if one would wish to have hardware-based BASIC) to have two separate units, one for machine code execution and another feeding into the first one that would translate the tokenized BASIC into machine code. Perhaps there would be an insignificant loss of speed when running BASIC, but this architecture would also allow for the running of assembly (i.e. machine code) as well, which would be much faster than even tokenized BASIC.

Furthermore, in my opinion, a hardware-based approach to BASIC would make the processor inflexible.

Of course I agree that it would be a very bad idea, I think the point was that it would be possible.

My point was that this would not directly execute the tokenized BASIC. In some way or another, machine code would be used in any case.

Your "second unit" is what would usually be called the virtual machine, feeding instructions (in the sense that it is running on) the "first unit" (= the CPU). You more or less described how Java works; your concept of "tokenized BASIC" (at least, as I understand it) is pretty close to Java's byte code.

My point was that hopefully they'd put a language more powerful than BASIC, but just as easy to use (and easy to understand). The fact that it looks like they were planning on including a touchscreen.... WOW!

It would make for some interesting games...

Perhapes capable of running a C++ compiler/programs too?

Probably not.

1. Have fun compiling projects on such a limited device.
2. Who would want to develop anything in C++? :P
Really though, C++ produces bloated machine code, and is not very suitable to the kind of low-level programming that one does for a device like this.

Actually, I have a better idea. Give it a touchscreen, gobs of memory, and a really really powerful (but easy to use) programming language. For those who want to pay extra, make the screen color. Release it.

... then sit back and watch the $$$ roll in, TI!

like the Palm TX?

http://www.circuitcity.com
/ssm/Palm-TX-Handheld
-1047NA/sem/rpsm/oid
/134802/catOid/-12964
/rpem/ccd/productDetail.do

Yeah, ok, I GUESS so, but this time it would be by TI

Brand loyalty- You'll never want to leave!

It should be noted that the "want to" part of the previous post has been heavily scratched out, leaving

Brand loyalty- you'll never leave!

I would like a calculator that uses something like Haskell as its interface language (except that Haskell's numeric data types are a bit limited...it would have to be redesigned with mathematics in mind). I often accidentally type something Haskell-ish on the calculator only to remember that it has no pattern matching.

I mean, how hard is it to make a^2+b^2+c^2[->]f([a,b,c]) be valid syntax? We should be able to pattern match over things like lists & matrices.

*plug* I ma making a program for the 68k calculators called Mathematica (working title) that will have many features, perhaps even including the facilitation of redefinition of syntax...

Ahem. Now that that is out of the way, I would like to say that that would be an interesting idea, in my opinion. However, I do not like the Haskell syntax. For some reason, I only like the syntax of ~XML-based languages and C-based languages (e.g. HTML, PHP, C, C++, etc). It seems that other languages' syntax is less efficient for some reason.

-- Fibonacci numbers (recursive version) in Haskell:
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

It seems efficient enough for mathematics. Perhaps I should stop complaining & try to implement it, but I am not particularly fond of writing parsers in C.

C certainly has a very compact syntax for traditional programming, & XML is relatively easy to parse due to its regularity, but I was going for something that would at least seem like its primary purpose was doing math. :)

Hmm. It does seem like a good language for mathematics. Perhaps I will implement a variant of this in Mathematica. (I would call it MathsML, as opposed to the common XML-like language MathML.)

However, this may not exactly be compatible with Mathematica's syntax...

We shall see.

Technically, CPUs execute machine language, not ASM. ASM has to be assembled into machine language for execution.

Techically, they execute machine code. It is not really much of a language. That is, unless you would call tokenized BASIC a language. It's more of a code. BASIC is the language. The language is assembly, the code is machine. Well, something like that.

You can think of machine code as being tokenized assembly in a way...

Meh. Whatever. *yawn*

Some of us are deranged enough to program in machine language. Tokenized assembly is not quite correct, since you lose labels (unless your disassembler has AI...).