Would it make sense to say that if a container is strongly typed (i.e. declared as type x) it is type x and if it is not then it is not? Why can't you have it both ways?
On Tue, Apr 25, 2017 at 6:48 AM, Lagi Pittas via use-livecode < use-livecode@lists.runrev.com> wrote: > Hi > > I don't know why you want to adapt/enhance the number format as that could > break already working code that uses the nuances of numberformat already. > > Why not add an instruction NumberFormatXL and create the an Excel version > like Curry says. You won't have to jump through hoops to make sure it > doesn't break anything, you can fix what's wrong(?) and you can add stuff > in there without affecting old code, plus and with Curry's experience with > spreadlib you probably have a lot of the problems to solve sorted. > > Now my usual caveat "Everything is easy for the man who doesn't have to do > it himself" - but I haven't seen anything that Mark and his team can't do - > usually the problems stem from trying no to break older stuff. > > I think in this case adding a new command would make it easier all round. > While you're at it why not put a callback/ or in wordpress parlance an > "AddAction" option so you can add to the formatting on the fly? > > Regards Lagi > > On 25 April 2017 at 09:38, Mark Waddingham via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > On 2017-04-25 09:01, Curry Kenworthy via use-livecode wrote: > > > >> To handle arrays better without requiring more lines of code, how > >> about making numberFormat itself an array with at least two parts? > >> Similar to the way the clipboardData has parts. > >> > >> Using it without a key works exactly like before, by setting both parts, > >> ie: > >> > >> -- (assume i=binary 5 and starting format=default) > >> > >> set numberformat to "0.0" > >> put "#" & i into a[i] --> a["5.0"] = "#5.0" > >> > >> If you want just the regular strings formatted and not any array keys, > >> or vice versa, use the appropriate part: > >> > >> set numberformat["text"] to "0.0" > >> put "#" & i into a[i] --> a["5"] = "#5.0" > >> > >> (or) > >> > >> set numberformat["keys"] to "0.0" > >> put "#" & i into a[i] --> a["5.0"] = "#5" > >> > > > > This is certainly an idea - however, I wonder if it isn't quite > addressing > > the crux of the issue. > > > > Arrays in LiveCode serve two purposes - both lists (if integer keyed, > > dense, starting from 1) and dictionaries (all other types). The > distinction > > is made purely on the string structure of the keys (for all intents and > > purposes) and what keys are present. Indeed for a LiveCode array to be > > treated as a list the keys *must* be very strictly formatted as integers > - > > there must be no fractional part (i.e. "1.0" is *not* considered the same > > key as "1"). > > > > For dictionaries, then having the numberFormat affect your numbers isn't > > really an issue - as the keys are strings, they have to be strings, there > > is no option. > > > > For lists, however, what is really happening is that they are being > > indexed by integers. So, could it be that the problem in LiveCode > > is that it doesn't distinguish between integers and non-integers? > > > > This actually alludes to another problem I've been struggling with > > recently (and, indeed, partly why this numberFormat problem is so > > interesting). > > > > At the moment LiveCode's arithmetic uses 64-bit doubles universally. This > > gives a relatively consistent arithmetic, but it has a significant limit: > > you cannot represent 64-bit integers accurately - only up to 53-bit. > > Indeed, > > the current semantics basically mean that you can do integer computations > > up > > to 53-bits and then things 'gracefully' degrade in precision. 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). > > > > One solution here is to have (internally at least) two distinct numeric > > types - integers and (inexact) reals - with the common-sense rules: > > > > integer int_op integer -> integer (+, -, *, div, mod are int_ops) > > integer op real -> real (+, -, *, /, div, mod are ops) > > real op integer -> real > > real op real -> real > > > > The question, now, is that how would we distinguish between a string > > we want to auto-convert to an integer, and a string we want to > > auto-convert to a real? > > > > One option here is to make it so that integers are always of the form > > > > [1-9][0-9]+ > > > > With a string being considered a real if it is any other valid numeric > > string: > > > > "1" is an integer > > "1.", "1e10", "1.03", "1.0" are all reals. > > > > 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" > > > > This would certainly solve the sequence-style-array 'ambiguity' and would > > perhaps make sorting out numeric literals not being touched by > numberFormat > > a little more sane: > > > > set the numberFormat to "0.00" > > put "This is an integer: " & 1 > > => This is an integer: 1 > > put "This is a real: " & 1. > > => This is a real: 1.0 > > > > The problem here is that I have no idea if that distinction is too subtle > > (for LiveCode, at least). It is certainly something you get used to > pretty > > quickly in pretty much any other language - most (if not all!) have a > > strict distinction between integer and real. > > > > To put the potentially subtlety in context; it only arise in: > > > > - numeric literals > > > > - strings/text/files taken as inputs > > > > In the former case, if you actually wanted a real, then you'd > > just have to add a '.' to the literal (there's an advantage here is that > > it completely expresses your intent as to the type of number). In the > > latter case, then if you are processing string inputs: > > > > - For integer do: > > put tStringFromOutside + 0 -> integer if tStringFromOutside is integer > > - For real do: > > put tStringFromOutside + 0.0 -> real > > > > The advantages of this approach are: > > > > 1) The implementation of integers is free to be whatever it needs to > > be. > > > > 2) It explicitly means you can indicate your numeric intent (integer > > operations and real operations have very different semantics) > > in your scripts. > > > > 3) It potentially opens the door to a much less 'surprising' > numberFormat > > with regards indexing arrays. > > > > 4) It potentially opens the door to a much less 'surprising' > numberFormat > > with regards numeric literals in scripts > > > > The disadvantages of this approach are: > > > > 1) The distinction between integer and real could be considered > > quite subtle: "1" vs "1.". > > > > 2) It is not backwards-compatible. > > > > 3) You have to think a little more about transforming your input > strings > > (although, only insofar as using + 0.0 rather than + 0 to force a > > toNumber conversion). > > > > In regards to (1), then in reality there is a *huge* distinction between > > these two things due to the semantics of the arithmetic operations on > > integers vs doubles, so perhaps LiveCode should make you choose > > *explicitly*. > > > > In regards to (2), then it is not backwards compatible but the current > > semantics > > would be subsumed by the new ones since all we are doing (in effect) is > > saying that 'don't represent a subset of numbers (the integers) we > > currently represent > > as doubles, but use actual integers instead'. i.e. The new semantics can > > get back the old behavior by simply converting integer-like strings to > > doubles as they do now. i.e. This new behavior is a binary flag which > > affects > > *only* num->string and string->num. > > > > In regards to (3), this happens now - quite frequently people ask 'why is > > this code dealing with numbers and strings not working quite right' and > the > > answer is generally - 'oh you need to put a + 0 in there somewhere to > force > > a numeric conversion'. > > > > Doing a simple job keeps it simple, and it does that job well. > >> However, it would be possible to have both the classic simplicity and > >> more power, by adding more optional symbols and rules. > >> > > > > That is very true - however, this thread has made me question what job > > does numberFormat *actually* do and in LiveCode it is just a formatting > > property - in comparison to HyperCard it has 0 effect on arithmetic. > > > > -- (assume i=binary 5555) > >> > >> set numberformat to "$#,##0.00" > >> put "Cost:" && i into x --> x = "Cost: $5,555.00" > >> > > > > Therefore, why not (as you suggest) make it a much better formatter? > > > > There are so many precedents for number formatting out there (as Richard > > points out) there is plenty to choose from. Ideally, we'd allow both > > explicit formatting *and* formatting based on locale. > > > > Certainly something to think about :) > > > > Warmest Regards, > > > > Mark. > > > > > > > > -- > > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > > LiveCode: Everyone can create apps > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." _______________________________________________ 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
