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/
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
