The #If and #End would be super easy to code, but what would be good symbols for those to replace?

I had two ideas for this:

• The first and most obvious solution would just be to make 3 unrelated tokens the tokens for #If, #Else, and #End. The tokens under VARS → Table... could be useful for this, as it's a menu containing exactly 3 unused tokens. #ElseIf would probably just be a combination of #Else and the normal If. This method would have the advantage of looking nicer with Axe-tokenized code, but they would look pretty confusing without Axe token replacements like in SourceCoder.
  
  
• My other idea would be to replace IS<( with #If and just use the normal Else and End. This would have the advantage of looking just about as good in something like SourceCoder and being easier to type on both platforms. However, the lack of hash marks preceding Else, ElseIf and End might be undesirable.

The #If and #End would be super easy to code, but what would be good symbols for those to replace?

How about Pmt_Bgn and Pmt_End (in the Finance menu)? I can't see them being used anywhere else.

Also, octothorpe?  Haven't heard that used.

Lol I don't think that's the one usually used, especially in coding.

The convention I use when reading code aloud is:

Code: [Select]

# - Hash
! - Bang
* - Splat
/ - Whack

I love those terms Oddly appropriate too.

Quote from: Quigibo on August 03, 2011, 01:55:47 pm

Also, octothorpe?  Haven't heard that used.

Lol I don't think that's the one usually used, especially in coding.

No, it's just called "hash".  Someone was trying too hard to sound smart when they used that one .  In fact, calling it anything other than "hash" or "crunch" usually makes other programmers look at you funny.

Also, here's my two cents on the new XXX.XXX decimal notation, with a discussion leading up to why I would prefer an XX.XX notation instead: http://ourl.ca/916578

But if it was made to help TI-BASIC programmers translate easier, they would wonder why numbers like 255.998 and 255.999 are equal.  And then they have to lear about how floating point notatio. In Axe works with binary terms anyways.  Rather pointless?..

And when you type 7/10 in Java/C, it DOES equal 0.7f/d, not something like 0.66f/d.  You know as well as I do that's not a good comparison; the two forms of floating point notations work entirely differently, using different techniques (and in most languages, the amount of numbers that can be stored is already specified in digits, not in 256 base-units).  I.E: you know that 0.00000000001f and 0.00000000000002f are equal due to the digit length and the fact they'll either be treated as generic infitesmals or simply zero (possibly even throw a warning!); in axe, you don't know if two consecutive small numbers are equal, or even what they really represent.  5.001 is equal to 5.002 which is equal to 5.003, but why are they not equal to 5.004 then?  It's not sane.  It's pointless to have large precision for the hell of it when the user doesn't know what things will truncate to.  I still stick by the XX.XX argument.  The programmer should expect that high precision floating point numbers will retin their value; if there is rounding involved in the thousands place, and things are stored in 8.8 notation for high precision work, something is wrong with the implementation.

It's fairly common knowledge that you shouldn't use equal/not-equal comparison for floating-point numbers, and this applies to fixed-point as well.

That's after operations like comparing a calculus function that simulates a sine function to a built in sine function, that could get things off by a few millionths per calculation.  Not by thousandths.  And, the main point is not returned values from operations being slightly off, it's that the programmer doesn't know the storing limit directly of thousandths FP numbers.  That's a large problem.  If there's an option for sot ring things to 3 decimal points, there should be assurance that everything in those 3 digit points will be completely represented, and anything past that won't do much.  XX.XX rules because you know everything will be represented fairly.  With XXX.XXX, that sixth X is really questionable because no one has an idea how it will be represented.

It's 7.22 because it can get an 8th, though you know that eighth has no usable purpose.  With Axe, if the XXX.XXX must stay, make sure to warn people that the sixth X is crap and never ever to use it.

And of course .7 doesn't equal .7 in binary.  But it doesn't equal .701 either.  You can't do it.. all that matters is the representation and that there is a given standard on how many digits you should go to.  Since Axe is a language used mostly by inexperienced programmers that haven't touched face with computer languages like C++ or Java, the third should be eliminated since the BASIC coders, who wont know anything about represented digits and how they work, will get confused (and the reason it was put in there was to make a nice transition for them?  Yeah, right, that wont confuse them whatsoever).  I'm not an idiot, I know how FP IEEE754 numbers work, and I know how many digits can be stored.  But if this is being added to cut confusingness for lower-experience Axers, then it's 1000% pointless and 50% stupid.  It's not even a good idea for advanced programmers, since it still doesn't represent numbers well enough for high-precision applications, so what's good about it again?  Those extra .41 digits could be used for something much more useful than storing another .41th of a digit, they could be used for flags and other commodities.

C and c++ (with decent compilers) usually have some sort of compilation option to check for over-extended FP numbers and warn at compile-time about them, so, yes they can.

It's 7.22 because it can get an 8th, though you know that eighth has no usable purpose.  With Axe, if the XXX.XXX must stay, make sure to warn people that the sixth X is crap and never ever to use it.

The 3rd decimal digit of Axe fixed point numbers has a purpose. Try representing 1/256, a very useful number for transformations, without it. Or try representing 1/3. Whereas 0.33 would equal 84/256, 0.333 would equal 85/256, the latter of which is 4x more precise. I, and I believe many others, would not want to forfeit this additional precision. Saying that the 3rd decimal digit doesn't matter is like telling someone to ignore the units digit of a 3-digit integer.

If you limited numbers to 99.XX, people will think 99.99 is the maximum number possible, although it's really 255.997. If you thought they'd be confused when 0.138 equals 0.139 (I'm simply obliging your suggestion here; not once in my programming experience have I seen someone check for exact equality to a number with more than one decimal place), think about the confusion caused when they learn that, in a system that presents itself as a mod 100 system, 50+50 doesn't overflow. And I know you might suggest having BCD math routines for this purpose, but there are multiple problems with this. To list the ones that come to mind:

• Bloated code in regard to both size and speed.
• Cannot optionally interpret the highest bit as a sign bit to easily use signed and unsigned numbers interchangeably.
• Most importantly, Axe doesn't have types (and it shouldn't, it's much more flexible and optimizable without them), so there's no way for Axe to know if you're operating on a BCD number. Every single operation Axe has would need to have a second token representation for the BCD operation. Weigh the following: which would be more confusing? 0.138 equaling 0.139? Or + not equaling +?

EDIT: As a note, I just want to mention that I'm not dragging this out for the sake of trying to prove anybody wrong. I just think it's simplest to leave fixed point numbers the way they are.