Make numberFormat even better

[Curry Kenworthy]

Mark:

 > If we made this distinction, then it would be viable to
 > make it so that numberFormat *only* affects reals:

 > put 1 + 0 into tInteger
 > put 1. + 0 into tReal
 > set the numberFormat to "0.00"
 > put tInteger , tReal
 > => "1,1.00"

I would expect big problems doing that generally! But it may hint at 
another workable approach.

Doing this for all number to text conversions would be chaotic, because 
one man's integer is another man's real, and another person would like 
their integers formatted too. I may have "5" and intend that to be $5.00 
or 005. I would expect the new problems and code breakage to be much 
more extensive than the ones this is intended to solve.

 > Arrays in LiveCode serve two purposes - both lists
 > (if integer keyed, dense, starting from 1) and dictionaries
 > (all other types).

But doing the above ONLY for numbers that are going into array keys 
would be less chaotic, more targeted to the problem. It is intuitive to 
be able to put a formatted string into an array without worrying about 
the key changing on you.

Then is it necessary to differentiate real vs integer, both for the 
user's number and the array structure? Or just do it for all array keys? 
One guy may have a loop incrementing by .1 and expect it to work, 
another guy may have a mix of integer and text keys. They don't qualify 
as an LC list array, but considering the formatting a separate issue, 
should it just work for them too? To me it seems more intuitive to treat 
all those numbers the same for array key formatting (or nonformatting) 
purposes. I'm not worrying about how the array keys are stored internally.

Either way could be fine with me if it seems consistent, limited to 
array keys, and a persistent way to turn it off which could also be the 
backward compatibility solution, default on for new version stacks and 
off for old ones?

 > The problem is that I'm not sure it is feasible to extend
 > the allowed size of integers (having them arbitrary precision
 > would be really neat!) whilst preserving this graceful
 > degradation to double (at least not in a performant way).

I would consider that a completely separate issue from the formatting 
(and as above, I think it would be chaotic and break a lot of things to 
conflate them in general. Plus second-guessing the user's intended type 
(or nontype) could be frustrating. I firmly believe non-typed is a plus 
for LC.

But as a behind-the-scenes math thing, yes, very useful! Having numbers 
shift types automatically to retain best precision, without necessarily 
worrying about what type they are, could be amazing. It would probably 
still run into problems though, such as two big numbers .1 apart (one an 
integer) ending up miles apart. So it's another issue to consider on its 
own merits.

Back to formatting, this gives us at least two viable possibilities for 
the numberFormat array key issue? Not bad!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/