Backlight: definitely. Navigation: Arrow keys. Yes, they are old, but they work. A suggestion though is to make the keypresses a little less noisier. Battery type: AA batteries - they're all over the place, and are the least expensive. Rechargeable via USB if the AA batteries are chargeable.
I recall seeing that... the beagleboard! (xM version, that is!) Good luck! This is very likely to become the "OTARM" (you can name it differently of course) - we had the exact same ideas in mind, just not much progress.
To correct, tar is NOT a compression method. It's just a nice format to combine directories and files into one file, and then a compression (like BZIP, GZIP, etc.) is applied onto that file. To explain visually:
blk = data block entry for file/folder/link More info about tar and compression (bzip2) can be found here: http://en.wikipedia.org/wiki/Bzip2 http://en.wikipedia.org/wiki/Tar_%28file_format%29
So finally summer is here, and my school work has substantically decreased to nil! (Not that I have nothing else to do... like signing up for internships, studying for SAT, etc. )
OTZ80 will resume at full speed, assuming I (and others) can dedicate some time to working on it. This surprisingly comes at a time where recently we've discovered that TI have made a new boot code to block OS downgrades. (And believe me, you probably don't want to use their odd, horrific little 2.55MP ) OTARM, as you might know, will probably be shelved... for now. This is due to the fact that there's an Ubercalc being made with the same exact goals as OTARM, and so we're likely to adopt UberCalc as OTARM's replacement. We also have some great OS (Linux distro) makers and some expert Linux users/devs at hand, so we will definitely be able to handle writing software/OS for it.
We are in a desperate need for HW experts! I'm hoping Ubercalc (the user, not the calculator) may be able to prototype an eZ80 calc for us! (If he's available at all, of course.)
Finally - there's some change in opinion about what CPU, what screen, etc. to use, so we may have a poll restart to regather opinion on it.
Here's to hoping we get enough progress this year to get a prototype out!
Current feature list: CPU: eZ80 50 MHZ, underclockable to 20 MHZ Screen size: 192x128 (7 other people voted for 240x160, revote possible based on supply and opinion change) Battery indication: On screen (part of OS) Navigation: regular arrow keys ASCII input: Alpha-lock Backlit screen: Yes... 14 vs. 9 people on this topic, may need a revote to confirm. I/O: 3.5 mm link cable and mini USB OTG Power:Will definitely need a revote - this was the closest one ever, with no real winner. The top two were: AA battery (rechargeable if possible), and "#1 and 2" = internal rechargeable battery + AA battery (rechargeable if possible)
Omitted features: Wifi (too much power munching, internet connection should be external) SD card support (no use)
I don't know if this has been suggested yet, but can the Axioms get custom token support? I don't think people (nor I) would enjoy writing down which token corresponds to which command... It should be definable in the compiled file (obviously), and... accessible via a special menu. (Omnicalc esque, where a button is pressed twice to access the menu OR some other method)
Also, can subroutines get custom token support too? (Basically, preparse the library file, and then make an accessible menu to access the new tokens)
.LIBRARY [special identifier to indicate this program is a library]
.Fade.FadeIn may even make a "Axe Class" possible! But don't worry about that for now - this is just for organization. #Token(Fade.FadeIn) Lbl FIN code here...
Hehe, I was actually creating this a while ago, but lost time due to much busyness IRL.
A couple of suggestions... 1) The command list page should later be revised to have the monospaced font, but not be placed in a dashed line box. It should also link to the command's own page, where further explanation, examples, and information can be found about it. 2) Oh, and here's the old wiki that failed... and the Axe command template that was being made. You should install the Infobox template for this to work. This also uses "hidey boxes" as well, which may require a thing or two (maybe not) to work. http://withg.us.to/axewiki/index.php?title=AxeCommandTemplate
EDIT: You should also poke Runer112 as well... he has a good idea of what he wants to put in.
I would ignore this. Yes, if you're really really lucky, you may come upon quite a few bitcoins, but... what else? You have an extremely low chance of getting anything.
MD Bonus Match 5: Match 5 Odds = 1:575,757 Killed by lightning: 1:1,603,250 Dying from venomous bite/sting: 1:1,159,364 Difficulty in getting a bitcoin: ~1:1,000,000
As you can see, they are VERY close to each other. You're playing the lottery here. Just because it's digital doesn't mean the odds aren't against you.
(This analogy/comparison is probably wrong... but who cares? )
What I would do is learn a programming language that a popular platform uses (if you don't know it already), and put it to use! Android Market is a great place to start! Create your own app, make it awesome, and sell it! What I'm going to attempt this summer is to make a Facebook app. They have this new credit system (which is 100% guaranteed, otherwise major app publishers wouldn't be using it) that players and users can use to buy things. If I had a game that needed upgrades, people will buy such upgrades. 1 FB credit = $0.07. Sure, it's little, but if you do a good job, you're going to get quite a bit.
Basically, my point is that there's no such thing as a free lunch. Even in the virtual world.
Oops, sorry, didn't get to get those PMs out! The valley curve of my busyness is over, and work amount is sharply increasing as I head towards the end of the year! This is really going to end up becoming a summer project, in which my summer doesn't start until June 22nd. Blame my school system for their weird dates...
Here are those PMs! (Shown with permission, of course!)
Spoiler For CAS Theory PMs:
Qwerty started by informing me about another technique:
Just wanted to point out a few things I think you missed in your CAS topic, on the off chance you don't know about them. The standard (and easiest) way to parse mathematical expressions is actually to work in Reverse polish notation. A lot of CASes convert to RPN before evaluation, so here's a simple algorithm for it (basically the Shunting-yard algorithm).
Recognize that it's essential for a CAS to have an X^n operation. Rather than expanding the expression using pascal's triangle (which would be incredibly tedious/slow for a 9001th degree equation), you can use x^n for numerical evaluation since the expression is constant for each value of the variables. Plug the values in and watch it go. For symbolic operations, you can just apply the normal power laws.
From this messy RPN equation, we can actually get something incredibly useful for a CAS, namely a beautiful syntax tree:
Ans | * / \ + * / \ / \ * 5 + ^ / \ / \ / \ 2 X X 4 5 + / \ 6 * / \ X 5 Now we have a simple way to evaluate the expression in terms of a few elementary operations. You just need to traverse the tree and evaluate the values at each node. The answer then comes right out. It also allows you to do certain optimizations to the expression, such as evaluating constant values such as 2*3 in the equation (2*3)+X, which would show up as a node with constant arguments. A little pruning of the syntax tree and you get a nice simplified expression.
Wow.... I honestly did not know that! Now I know why programming classes LOVE to talk about trees... The basis of my CAS theory is basically asking a computer to do the same thing we do when solving a problem. (I would be actually pleasantly surprised for the FPM!) Of course, humans may not be as
Somehow, someway, the RPN notation makes things a lot faster (and of course, much more efficient then nCr, in which I found out that the calc slows and stops at 36 (ERR:OVR), and my laptop, although "modern", takes quite a while to compute that. (451.583050966 seconds => 7.53 minutes!)
I think I get your idea/theorem... and then again, maybe not! The tree somewhat deviates from the RPN converted equations you posted, and I'm not too sure how I would handle such input.
Either way, the theorem you mentioned is interesting indeed, and I could use all the help I can get!
Thanks! Albert
P.S - do you mind if I post your PM in the topic? It might be somewhat useful for people to know.
About the tree deviating slightly, well that's because I'm not very good at RPN
Basically, what RPN does is convert the expression into a series of individual operations on the operands in the order they're supposed to occur. What the tree does is group them in such a way that every operations is linked to its operands. The operations are the nodes and the operands are the leaves. You start from the bottom (or top down, they both work) with all of the given constants and variables listed. Then, you connect all of the operands with their operations. Those operations produce new operands which are then operated on by some of the leftover initial operands and so on until you end up with one final operand that is your answer. That's also essentially how you generate trees in code. If you want to start from the top, you just assume an answer, then find the operations that produce that answer, the operands for those operations, and then the operations that produce those operands, etc...
On a side note, Dynamic trees are useful, but they're a serious PITA to organize in memory. I've had nightmares about the internal representations
One of the concepts I've been working on for Axe GUI Library is this other side of it. I wanted to try something new - offering GUI functions that integrate seemlessly inside the program. Or, if the developer happened to want more control, give them access to some drawing functions, and let the developer handle all the other code. This portion of Axe GUI Library is geared to game developers, but also to any developers wanting a GUI without the full blown GUI. (Mouseless is one aspect.)
That said, no worries - I'm still interested in the regular, window/mouse based Axe GUI Library! I'm just adding another side of it to cater to other developers as well.
So what do I have for today? I have the "advanced drawing routine" done and implemented for... MENUS! This routine provides the drawing, all you need to do is provide the input! I've attached BOTH the source and the compiled Axe binary for your convenience. I strongly suggest opening the source 8Xp inside a PC source editor of some kind. It's very, very, long. The routine of interest is MNU (line "Lbl MNU" all the way to "Return", as well as routines that are used in routine MNU). Don't get the code? Thank Runer112 for that extreme optimization that made this routine possible! (The original one was very, very slow)
prgmAGMENUD is the binary, which is a significant menu demo program. prgmAGMENUDS is the source of that program.
This routine can possibly be implemented into actual menus in the regular GUI! (Not sure if actual menubars->menus would work on a calc, but click-button-to-show-menu would work.) Of course, this routine needs more work, esp. to support no animation.
Enjoy!
EDIT: Unfortunately, I have no suitable calculator emulator that could record a GIF of the demo program in action. Could someone please record one for me? You just need to run all around using [2nd]/[Enter], the arrow keys, and [Clear]. Thanks!
EDIT 2: Darl181 posted a nice screenie below this post. Thanks Darl181!
Ah ok. I was worried about downtimes à la Dragon-Fire (our former IRC location), which averaged around 3 months.
Oh no, no worries about that! There are still two servers that are part of OmniNET besides mine and Netham's. As soon as I feel good about rebooting (that is, my users know about it and are ready), I will do a quick reboot which shouldn't last too long
Depends. If Cooliojazz (who manages the IRC server) is up at the moment, downtime should be minimal - at most 5-10 minutes, 30 if my VPS is being slow. If he's not on, I might end up starting it myself, which may take time.
I'm hoping to time the reboot so that he's on when I do it, and most (if not all) of the people on my server are in their chans and can start up their bots quickly.
I am planning to reboot my server sometime soon since 633 MB of my memory is "used"... or should I say, robbed by the kernel and not giving it back? MC isn't even running, and there's only 130 MB of RAM left... but yeah, withg.us.to is going down too soon.
Any people on the server should stay in their chans until your bots are back up, and anything hosted on withg.us.to's IRC server (irp.irc.omnimaga.org) should be switched temporarily.
INCOMPLETE. I'm still writing this, but since aeTIos bugged me to post this ASAP, here it is. Will update tonight or tomorrow depending on if I have time or not.
So, I was lying in bed one day thinking random thoughts, and suddenly I have this idea in my head: CAS for the calc! Actually, it wasn't that - it was CAS theory, which led to me thinking that this could be implemented as a calc app or program with Axe.
So - the theory. Basically, the core of this is simply arrays and strings. Numbers of course are in it, but only for non-variable calculations and integer calculations.
With that, let's get started!
Variable multiplication Say, the user inputs this into the CAS:
AwesomeCAS v1.0 > (2x+5)(x+4)(5x+6)^5 How can we solve that? First, we need to make our lives easier and apply existing laws/theorem to solving certain parts of the equation. One thing comes to mind - Pascal's triangle! A brief explanation of this theorem - Pascal's triangle is a very simple concept. You start with 1, and then 1, 1. You keep adding 1s to the side to make a triangle while adding the above numbers to place below inbetween them. Sound confusing? Here's an example:
1 1 1 1 2 1 1 3 3 1 1 4 6 4 1 1 5 10 10 5 1 So you (kinda) get it. But why does this have anything to do with CASes? Take a look at this equation: (x+y)^3 No one really knows what that is, right? Multiply it out, and you get: x^3+3(x^2)y+3x(y^2)+y^3 The coeficients are 1, 3, 3, and 1. Hold on! Did we see that before??
1 2 1 1 3 3 1We did indeed! Basically, you can the (n-1)th row's numbers for the coefficients! (And you simply start at the highest degree of the first variable - x^3 - and add Ys to it at the same time decreasing the X power until you get y^3!)
BUT... no one wants to loop through this insanity to get the triangle. What if someone typed in (x+y)^9000? That's where combinations come in [more details here] quick and dirty info: Enter "3 nCr 0" into your calc, going from 0 to 3. See the pattern?
So for this, we need to find such easy problems. Going back to the problem:
> (2x+5)(x+4)(5x+6)^5We treat this as a STRING. I first verify to see if all the parenthesises are closed or not. Then, I look for ^[number]. If the number is enclosed in (), I evaluate the () and then use that. Using the above method, I find that the base equation is:
3125 x^5+18750 x^4+45000 x^3+54000 x^2+32400 x+7776 But wait! How is this calculated in the first place?? Well, the above base equation is split into an array. Python style:
equArray = [ [1, ["x", 5]], equPlus, [5, ["x",4], ["y",1]], equPlus, [10,["x",3],["y",2]], equPlus, [10,["x",2],["y",3]], equPlus, [5,["x",1],["y",4]], equPlus, [1,["y",5]]] equEquateX = ["x",[5, ["x", 1]]] equEquateY = ["y", [6]]...where equPlus is a special constant/type defined in program to signify a + sign, equArray is the array that contains our base equation, and equEquateX/Y contain the substitution we want to do.
So now let's plug the variables in! (The below python code does not necessarily work, and is very crudely designed, but it does explain what I'm thinking. In the future, the code will be much more flexible and have more possibilities than this.)
for equPart in equArray: # This loops grabs every item of equArray into equPart buffInt = 1 # Initialize a "blank" integer for us to use. This will serve as a standing point to create the final coefficient... for this part, anyway. :P for varEquPart in equArray: # This loop grabs every item of the equPart into varEquPart if type(varEquPart) == int: buffInt = buffInt * varEquPart # Multiple the coefficient into the final one else: # This should be an elemental array for actVarEquPart in varEquPart: # You see why I don't exactly like turning this idea into code, eh? :P if type(actVarEquPart) == str: if actVarEquPart == equEquateX[1]: # Substitute X in! for varEquPartInSubstitution in equEquateX if type(varEquPart) == int: buffInt = buffInt * varEquPart # Multiple the coefficient into the final one else: # This should be an elemental array The above code is incomplete; my brain is hurting from writing this code. Any help possible is appreciated! Optimizing, prettifying, organizing, coding - you name it! Depending on my schedule, I may come back tonight or tomorrow to work on this code snipplet. I quickly outlined my ideas below with no concept code.
Floating Point Math - Addition WIP code posted below - this is in Python. Hopefully it's self explanatory (with assistance from the theory posted below!)
#!/usr/bin/env python # Experimental floating point implementation # Written by Albert H
# Variables DEBUG = 1
n1 = raw_input("> Enter 1st floating point number: ") n2 = raw_input("> Enter 2nd floating point number: ") op = raw_input("> Enter operation (+, -, *, or /) to perform: ")
# Now for the REAL guts of this program! # We use absolutely NO floating point operations here at all. NONE. # If you enable the DEBUG var above, you get to see every part of the # process. No single number used is a floating point number at all. if op == '+': # Easiest one of the bunch. Align the decimal point! pointpos1 = n1.index(".") pointpos2 = n2.index(".") if pointpos1 < pointpos2: # If pointpos1 has a lower index than pointpos2... that means # we have n1 being 3.14 and n2 being 12.4. for n in range(0, pointpos2-pointpos1): n1 = " " + str(n1) if DEBUG == 1: print ">> DEBUG: n1 string is: "+str(n1) print ">> DEBUG: n2 string is: "+str(n2) # Number crunching time! lenOfNum1 = len(n1) lenOfNum2 = len(n2) # TODO: Fix bug with entering same number/dec place == crash # TODO: Fix 0.9+12.9 =12.18 due to lack of carryover correction result = "" tempResult = "" for nIndex in range(0, max(lenOfNum1, lenOfNum2)): if nIndex <= (lenOfNum1 - 1): if nIndex <= (lenOfNum2 - 1): if n1[nIndex] != ' ': if n2[nIndex] != ' ': # TODO: add checking for misalign of decimal points if n1[nIndex] != '.': if DEBUG == 1: print ">> DEBUG: Both n1 and n2 digits are present! Adding integers: "+n1[nIndex]+" + "+n2[nIndex] tempResult = int(n1[nIndex]) + int(n2[nIndex]) result = result + str(tempResult) else: if DEBUG == 1: print ">> DEBUG: Decimal point detected! Appending decimal point to result." result = result + "." else: if DEBUG == 1: print ">> DEBUG: n2[nIndex] is a space, so adding n1's digit to result. Digit: "+str(n1[nIndex]) result = result + str(n1[nIndex]) else: if n2[nIndex] != ' ': if DEBUG == 1: print ">> DEBUG: n1[nIndex] is a space, so adding n2's digit to result. Digit: "+str(n2[nIndex]) result = result + str(n2[nIndex]) else: print "ERROR: Something went wrong in preprocessing!" print "Guru meditation: n1[nIndex] and n2[nIndex] are both spaces! n1='"+n1+"', n2='"+n2+"', nIndex="+str(nIndex) exit(1) else: if DEBUG == 1: print ">> DEBUG: n2[nIndex] does not exist, so adding n1's digit to result. Digit: "+str(n1[nIndex]) result = result + str(n1[nIndex]) else: if nIndex <= (lenOfNum2 - 1): print ">> DEBUG: n1[nIndex] does not exist, so adding n2's digit to result. Digit: "+str(n2[nIndex]) result = result + str(n2[nIndex]) else: print "ERROR: Something went wrong in preprocessing!" print "Guru meditation: nIndex is out of range! n1='"+n1+"', n2='"+n2+"', nIndex="+str(nIndex) print "> Result: "+result
Floating Point Math - Multiplication This method can also be applied to other operations as well. Z80 calcs don't have floating point math. It's all software. How can we do it without using TI's stuff? Probably not the best way to do it, but... HANDLE IT AS A STRING! Take for instance: 0.51 X 0.003 Quickly outlining the method: 1) Find number of decimal places, figure it which one is longer or if they are both the same 2) Perform hand-done multiplication on computer... aka: a) Cut string into numbers b) Multiply based on place c) Shift around as needed, like what you usually do when you switch places d) Add things, AGAIN e) Organize numbers into string f) Figure out where to put decimal point, and put it there g) Simplification as needed ("0.50000 => 0.5") h) Done! Variable Manipulation Basically, aiming for the famous TI-89 (or TI-Nspire CAS) command: solve(2x+6+x^1029=5, x) Something like the first idea, but with a lot more complexity. Array element shifting to the extreme! Again, treat variables like a string. Keep track of where they are in the equation, and perform operations to the equation array to isolate them and solve it.
Show him the Chrome videos, especially with the potato gun. Show him that IE is very very buggy. Show him that IE has sooo many security flaws, and that if he doesn't stop using it he WILL get a virus.
If you need something to prove your point, the classic example: http://www.crashie.com/ Run it a thousand times as needed to do so...
Show Posts
(xM version, that is!)
