numberFormat affecting array keys???

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
Mark Waddingham:
 > I think this is perhaps more evidence that 'numberFormat'
 > should probably be deprecated - or at least marked as
 > 'present for HyperCard compatibility only and shouldn't
 > be used in new code'.

I emphatically disagree.

There's nothing wrong with numberFormat as a binary to text option. On
the contrary, it's a splendid way to present the formatting to users.
The array key example is an outlier case to watch out for, but it's also
easy to use an alternate formatting option or careful coding for those
rare cases.

The numberFormat is very easy to read and clean, similar to formatting
systems used by Excel and others. (Naturally SpreadLib uses it too.)
People understand the representation intuitively, and it's also
extremely popular.

It provides a consistent shortcut compared to using a function several
times, for clean code with one statement to edit, so it is compatible
with KISS philosophy.

I prefer numberFormat for most tasks and would detest having it
deprecated. Obviously the show must go on when someone concatenates text
with a number, so a default behavior would have to be in place for that
regardless (unless LC would throw an error), but we would lose the
customizable aspect. LiveCode will be disfigured if we hack off all the
pleasant parts.

It will also be less "English-like" than before if we remove the wrong
parts. I've been working on materials for my new fluency method for
teaching LiveCode's syntax, based on proven language learning methods
and enhanced with my own additional techniques geared to CS and LC.

This is such a readable sentence to teach and use:

set the numberformat to "0.00"

Although I don't have time to be as vocal an advocate as some others
here on LC trends and directions, there's so much to be said on the
subject of LC's English-like language, how to optimize learning and
coding around it, and what the result offers compared to other computing
languages. (But I'll say most of that in my upcoming book rather than
here on the list.)

I sure don't intend to teach the best parts of LC as deprecated or
denigrated, so I hope the language stays intact without self-mutilation. :)

Best wishes,

Curry K.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
I tend to agree.  There is nothing about "format" that is intuitive to the
non-initiated.

On Fri, Apr 21, 2017 at 8:51 PM, Curry Kenworthy via use-livecode <
[hidden email]> wrote:

> Mark Waddingham:
> > I think this is perhaps more evidence that 'numberFormat'
> > should probably be deprecated - or at least marked as
> > 'present for HyperCard compatibility only and shouldn't
> > be used in new code'.
>
> I emphatically disagree.
>
> There's nothing wrong with numberFormat as a binary to text option. On the
> contrary, it's a splendid way to present the formatting to users. The array
> key example is an outlier case to watch out for, but it's also easy to use
> an alternate formatting option or careful coding for those rare cases.
>
> The numberFormat is very easy to read and clean, similar to formatting
> systems used by Excel and others. (Naturally SpreadLib uses it too.) People
> understand the representation intuitively, and it's also extremely popular.
>
> It provides a consistent shortcut compared to using a function several
> times, for clean code with one statement to edit, so it is compatible with
> KISS philosophy.
>
> I prefer numberFormat for most tasks and would detest having it
> deprecated. Obviously the show must go on when someone concatenates text
> with a number, so a default behavior would have to be in place for that
> regardless (unless LC would throw an error), but we would lose the
> customizable aspect. LiveCode will be disfigured if we hack off all the
> pleasant parts.
>
> It will also be less "English-like" than before if we remove the wrong
> parts. I've been working on materials for my new fluency method for
> teaching LiveCode's syntax, based on proven language learning methods and
> enhanced with my own additional techniques geared to CS and LC.
>
> This is such a readable sentence to teach and use:
>
> set the numberformat to "0.00"
>
> Although I don't have time to be as vocal an advocate as some others here
> on LC trends and directions, there's so much to be said on the subject of
> LC's English-like language, how to optimize learning and coding around it,
> and what the result offers compared to other computing languages. (But I'll
> say most of that in my upcoming book rather than here on the list.)
>
> I sure don't intend to teach the best parts of LC as deprecated or
> denigrated, so I hope the language stays intact without self-mutilation. :)
>
> Best wishes,
>
> Curry K.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
A couple years ago I had a look at format. I gave up after I got the headache. I tried again today. Same results. I cannot even begin to fathom the printf() C rules! I read and read and read, try examples etc. but NOTHING can get me to the point where I can make "1.1" into "01.10" never mind "10.2.1.6" into "010.002.001.006".

My workaround fixes my issue, and Jacque's works also, provided you put the numberFormat into a separate function so that you do not have to continually keep resetting the numberformat everytime it might affect *ANY* numeric value as text.

Bob S


> On Apr 21, 2017, at 18:23 , Mike Kerner via use-livecode <[hidden email]> wrote:
>
> I tend to agree.  There is nothing about "format" that is intuitive to the
> non-initiated.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
Bob Sneidar wrote:


 >> On Apr 21, 2017, at 18:23 , Mike Kerner wrote:
 >>
 >> I tend to agree.  There is nothing about "format" that is intuitive
 >> to the non-initiated.
 >
 > A couple years ago I had a look at format. I gave up after I got the
 > headache. I tried again today. Same results. I cannot even begin to
 > fathom the printf() C rules! I read and read and read, try examples
 > etc. but NOTHING can get me to the point where I can make "1.1" into
 > "01.10" never mind "10.2.1.6" into "010.002.001.006".
 >
 > My workaround fixes my issue, and Jacque's works also, provided you
 > put the numberFormat into a separate function so that you do not have
 > to continually keep resetting the numberformat everytime it might
 > affect *ANY* numeric value as text.

There are good benefits to having both numberFormat and the format
function. I don't suppose Mark was serious about deprecating the former,
just making a point about the strength of the latter.

The numberFormat property is something all of us ol' timers are
accustomed to, and in many cases it's a good fit for what we need.  So
that, plus decades of legacy code, give us good reasons to keep it around.


But if we step back and review the cognitive implications of using it,
we find a few things worth considering:


NumberFormat requires contextual awareness
------------------------------------------
First and foremost, by itself it doesn't actually do anything, in terms
of things we can see.

When we set the numberFormat, no object nor any variable value changes.
The property's utility only becomes evident in conjunction with
subsequent statements.

So comparing the numberFormat property to the format function by using
single statements isn't apples-to-apples, as numberFormat will always
require at least two statements for it to become in any way evident.

Additionally, as a property of the LC system it's not bound to anything,
an abstraction, and one that changes again without our intervention the
moment the current handler exits.

And then of course there's the reason this thread exists:  because the
numberFormat property only affects things that happen after it's set,
the interaction between the property and those subsequent statements
isn't always clear.

If it were we wouldn't be having this discussion. :)  And because it's
unclear, we've seen variants of this discussion every few months, even
among people who first learned numberFormat many years ago.

Never underestimate the compounding impact on cognitive load of
multi-statement sequence dependency.


NumberFormat requires data type awareness
-----------------------------------------
xTalks are traditionally typeless, with the respective engines
(HyperCard, SuperCard, OMO, Gain Momentum, Toolbook, LiveCode, etc.)
converting between strings and numbers automatically for us, behind the
scenes.   This typelessness allows us to think in terms of what we see
with our human eyes, without having to also conceptualize the
representation of numeric values as they pass through CPU gates.  We do
things with what we see in front of us, and it all just works.

Except with the numberFormat property.

Here we have one of the few times in which using an xTalk requires
having at least some awareness that CPUs use different data types for
arithmetic operations than they do for strings.

In some cases, getting what we want from the numberFormat property
requires us to add additional steps in our code in order to coerce the
value we want to be affected.  Sometimes we add a zero to coerce a
string to a number, other times we pad or concatenate to coerce a number
to a string.  Consider the many examples throughout this thread.

Type coercion in an xTalk?  Egads!  Yet here we are. :)

At a minimum, the numberFormat property requires at least two statements
to be of any value at all: first setting the property, and then doing
something that will cause it to be applied to a value.

But because we sometimes have to explicitly coerce the value, now and
then we need at least *three* statements to get the result we're looking
for with numberFormat.  And when that third step is needed, it's because
we have to momentarily think like a computer.

With GUI objects as part of the core language, xTalks usually afford us
the opportunity to code in a way that expresses the user experience.  We
get to think like users, with the engine handling the implementation
details to accommodate the more mundane and arcane needs of the computer.

NumberFormat introduces a moment in which we need to be aware that we're
expressing our user interface in a machine too stupid to count past 1.
:)  We don't otherwise need to be aware of binary representations often,
if at all.

Of course some of the options in the format function are also dependent
on understanding data types.  But not all of them, and if you do need to
use those that requiring understanding types you still gain the benefit
of having everything in the conversion happening within a single
statement, as opposed to the multi-statement requirements for using the
numberFormat property.


NumberFormat has limited options
--------------------------------
With just two options ("#" for zero-padding where needed, and "0" for
required zero-padding), the scope of the numberFormat property is limited.

By itself that's a point in its favor, since there's not much to learn
about using it (beyond the things noted above).

But it also means that sooner or later you're likely to need to use the
format function anyway, as soon as you want padding for text, or
scientific notation, or any of the other options it provides.



TL;DR
-----
When numberFormat can do the job and you want to use it, use it.  For
certain tasks it may be somewhat simpler than the format function.

But when we consider the full cognitive requirements for using
numberFormat, esp. its dependency on multi-statement context, I think it
would be difficult to come up with a cognitive-load metric which could
demonstrate that it's actually easier to learn than the subset of
options needed to get the same result with the format function.

Just because we learned it years ago doesn't mean it's necessarily
easier to learn for anyone else starting out today.

Please remember that the reason we didn't learn the format function back
then it because it didn't exist in any xTalk in those days. :)

Moreover, since the format function covers far more ground, once you
learn the options needed to get simple numeric formatting results you're
already well oriented for learning any other options you might need as
you go later one.



PS: All of these recurring discussions around formatting data reinforce
the value of adding a display formatting property to the field object.

There are still use-cases for both numberFormat and format, but there
are so many precedents in other tools for defining display format in the
object used for display that I think when that's what's needed it would
be the simplest to learn.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
This, yes please.
--There are still use-cases for both numberFormat and format, but there are
so many precedents in other tools for defining display format --in the
object used for display that I think when that's what's needed it would be
the simplest to learn.

On Sat, Apr 22, 2017 at 11:21 AM, Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Bob Sneidar wrote:
>
>
> >> On Apr 21, 2017, at 18:23 , Mike Kerner wrote:
> >>
> >> I tend to agree.  There is nothing about "format" that is intuitive
> >> to the non-initiated.
> >
> > A couple years ago I had a look at format. I gave up after I got the
> > headache. I tried again today. Same results. I cannot even begin to
> > fathom the printf() C rules! I read and read and read, try examples
> > etc. but NOTHING can get me to the point where I can make "1.1" into
> > "01.10" never mind "10.2.1.6" into "010.002.001.006".
> >
> > My workaround fixes my issue, and Jacque's works also, provided you
> > put the numberFormat into a separate function so that you do not have
> > to continually keep resetting the numberformat everytime it might
> > affect *ANY* numeric value as text.
>
> There are good benefits to having both numberFormat and the format
> function. I don't suppose Mark was serious about deprecating the former,
> just making a point about the strength of the latter.
>
> The numberFormat property is something all of us ol' timers are accustomed
> to, and in many cases it's a good fit for what we need.  So that, plus
> decades of legacy code, give us good reasons to keep it around.
>
>
> But if we step back and review the cognitive implications of using it, we
> find a few things worth considering:
>
>
> NumberFormat requires contextual awareness
> ------------------------------------------
> First and foremost, by itself it doesn't actually do anything, in terms of
> things we can see.
>
> When we set the numberFormat, no object nor any variable value changes.
> The property's utility only becomes evident in conjunction with subsequent
> statements.
>
> So comparing the numberFormat property to the format function by using
> single statements isn't apples-to-apples, as numberFormat will always
> require at least two statements for it to become in any way evident.
>
> Additionally, as a property of the LC system it's not bound to anything,
> an abstraction, and one that changes again without our intervention the
> moment the current handler exits.
>
> And then of course there's the reason this thread exists:  because the
> numberFormat property only affects things that happen after it's set, the
> interaction between the property and those subsequent statements isn't
> always clear.
>
> If it were we wouldn't be having this discussion. :)  And because it's
> unclear, we've seen variants of this discussion every few months, even
> among people who first learned numberFormat many years ago.
>
> Never underestimate the compounding impact on cognitive load of
> multi-statement sequence dependency.
>
>
> NumberFormat requires data type awareness
> -----------------------------------------
> xTalks are traditionally typeless, with the respective engines (HyperCard,
> SuperCard, OMO, Gain Momentum, Toolbook, LiveCode, etc.) converting between
> strings and numbers automatically for us, behind the scenes.   This
> typelessness allows us to think in terms of what we see with our human
> eyes, without having to also conceptualize the representation of numeric
> values as they pass through CPU gates.  We do things with what we see in
> front of us, and it all just works.
>
> Except with the numberFormat property.
>
> Here we have one of the few times in which using an xTalk requires having
> at least some awareness that CPUs use different data types for arithmetic
> operations than they do for strings.
>
> In some cases, getting what we want from the numberFormat property
> requires us to add additional steps in our code in order to coerce the
> value we want to be affected.  Sometimes we add a zero to coerce a string
> to a number, other times we pad or concatenate to coerce a number to a
> string.  Consider the many examples throughout this thread.
>
> Type coercion in an xTalk?  Egads!  Yet here we are. :)
>
> At a minimum, the numberFormat property requires at least two statements
> to be of any value at all: first setting the property, and then doing
> something that will cause it to be applied to a value.
>
> But because we sometimes have to explicitly coerce the value, now and then
> we need at least *three* statements to get the result we're looking for
> with numberFormat.  And when that third step is needed, it's because we
> have to momentarily think like a computer.
>
> With GUI objects as part of the core language, xTalks usually afford us
> the opportunity to code in a way that expresses the user experience.  We
> get to think like users, with the engine handling the implementation
> details to accommodate the more mundane and arcane needs of the computer.
>
> NumberFormat introduces a moment in which we need to be aware that we're
> expressing our user interface in a machine too stupid to count past 1. :)
> We don't otherwise need to be aware of binary representations often, if at
> all.
>
> Of course some of the options in the format function are also dependent on
> understanding data types.  But not all of them, and if you do need to use
> those that requiring understanding types you still gain the benefit of
> having everything in the conversion happening within a single statement, as
> opposed to the multi-statement requirements for using the numberFormat
> property.
>
>
> NumberFormat has limited options
> --------------------------------
> With just two options ("#" for zero-padding where needed, and "0" for
> required zero-padding), the scope of the numberFormat property is limited.
>
> By itself that's a point in its favor, since there's not much to learn
> about using it (beyond the things noted above).
>
> But it also means that sooner or later you're likely to need to use the
> format function anyway, as soon as you want padding for text, or scientific
> notation, or any of the other options it provides.
>
>
>
> TL;DR
> -----
> When numberFormat can do the job and you want to use it, use it.  For
> certain tasks it may be somewhat simpler than the format function.
>
> But when we consider the full cognitive requirements for using
> numberFormat, esp. its dependency on multi-statement context, I think it
> would be difficult to come up with a cognitive-load metric which could
> demonstrate that it's actually easier to learn than the subset of options
> needed to get the same result with the format function.
>
> Just because we learned it years ago doesn't mean it's necessarily easier
> to learn for anyone else starting out today.
>
> Please remember that the reason we didn't learn the format function back
> then it because it didn't exist in any xTalk in those days. :)
>
> Moreover, since the format function covers far more ground, once you learn
> the options needed to get simple numeric formatting results you're already
> well oriented for learning any other options you might need as you go later
> one.
>
>
>
> PS: All of these recurring discussions around formatting data reinforce
> the value of adding a display formatting property to the field object.
>
> There are still use-cases for both numberFormat and format, but there are
> so many precedents in other tools for defining display format in the object
> used for display that I think when that's what's needed it would be the
> simplest to learn.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Richard:
 > But when we consider the full cognitive requirements for
 > using numberFormat, esp. its dependency on multi-statement
 > context, I think it would be difficult to come up with a
 > cognitive-load metric which could demonstrate that it's
 > actually easier to learn than the subset of options needed
 > to get the same result with the format function.

 > Just because we learned it years ago doesn't mean it's
 > necessarily easier to learn for anyone else starting out today.

I don't believe for a moment that numberFormat style would lose in a
straight competition to format style for people with zero related
experience to either. I predict the learning time would be a fraction;
there's just not much to learn when the symbols look so much like the
desired result. I'm trying to be fair and think of how hard that can be,
but not having much luck. I want "8.9" and I type "0.0" - it's so easy.
The hashes are just one additional step, and might not be needed the
first time.

Nor do I think numberFormat is mostly useful for legacy code and old
timers, or that more intuitive implies an inferior method. Anything but!
That's why it's not unique in the world; very natural method of
representing formatting options, and it will always be around in many
products. You've proposed some intricate rules for evaluating the two
formatting options, but your system and your calls lean in your
preferred direction. That's fine. But with my rules, numberFormat
usually dominates.

BTW, the human mind is naturally designed for some contextual awareness.
Concatenations often happen more than one at a time, and it's set for
those transactions, much the way we would say it in a conversation.

Talking about a subject with a person, if there's some context we need
to keep in mind for the whole conversation, we can say that once at the
beginning, not keep repeating it along with each point. As if I kept
saying "with LiveCode, with LiveCode" when we all know that's the
context of our discussions here! (Our discussions here with LiveCode,
that is.) You already understand that fact. (I mean, the fact that it's
LiveCode.) Of course I can replicate that memory with some extra code,
but then the use of format has become more verbose, hasn't it? With
numberFormat it's already done and infinitely tested, KISS and robust.
So I just can't see that as a problem. It seems quite natural to the way
we think, so might as well call it a plus.

Whether I'm wearing pants or just nice boxers (more often the latter
around the house, as a wheelchair guy) must be considered in social
transactions. I believe this mental stream of thought at the conscious
level looks more like "set currentClothing to "boxers";answer door for a
package;prepare to go out" than a series of function calls providing my
clothing as a parameter. Then again, maybe that stream is different for
different people. If so, take your pick with my blessing. I'm in boxers
now typing this and giving my blessing; might as well have some fun,
right? :)

The data type awareness is nothing to fret about either. I don't think
it really requires awareness until they reach a certain point. If they
are unaware, a conversion is going to happen anyway, by default when no
format is set. So it's something very natural to learn about when it's
brought to our attention by our own actions, and when we have a desire
for a different result. And when that time comes, dang is it easy to
learn! That was quick.

You need even more awareness to use format. And awareness is good, but
we can't have it both ways. If format awareness is good, numberFormat
awareness can't be bad. And vice versa. I refuse to see the argument
framed as an old timer/legacy thing when intuitive systems will dominate
the future. I can really appreciate the reasons why some people like
format, and more power to them, it's a very good system. But I demand
just as much technical respect for the numberFormat, so I won't hesitate
to reframe the discussion.

Trends and fads change the landscape, and hype drives sales and
adoption, but those come and go. My criteria are objective and fairly
constant, and the numberFormat performs very well for my philosophy.
Intuitive, useful, readable, usually less code, simple, fast to
implement, easy to proofread. Even if LC were mutilated by removing or
denigrating it (I hope not) other products, especially those geared
toward numbers, would continue to use similar representations to reap
the natural benefits of modern and intuitive formatting.

With both, we can both be happy I'm sure! Always enjoy talking with you.

Best wishes,

Curry Kenworthy

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
Curry Kenworthy wrote:

 > Richard:
 >  > But when we consider the full cognitive requirements for
 >  > using numberFormat, esp. its dependency on multi-statement
 >  > context, I think it would be difficult to come up with a
 >  > cognitive-load metric which could demonstrate that it's
 >  > actually easier to learn than the subset of options needed
 >  > to get the same result with the format function.
 >
 >  > Just because we learned it years ago doesn't mean it's
 >  > necessarily easier to learn for anyone else starting out today.
 >
 > I don't believe for a moment that numberFormat style would lose in a
 > straight competition to format style for people with zero related
 > experience to either.

I must admit I have neither the methodological background nor the
resources to conduct such a study myself, hence my reliance here on mere
heuristics.

The link I included in my other post about cognitive load may be
interesting, though in a more general sense.  Of course that researcher
wasn't comparing two different ways to format numbers in LC, but there
may be aspects of his research which could guide a more detailed
assessment here if needed.

That's a big "if", though, because I agree that in both cases cog. load
is small enough that the distance between both forms is almost certainly
shorter than this thread. :)

I just observe that we talk about numberFormat here a few times a year,
even among people who've been using it for decades.

But I can't recall the last time we saw questions here about the format
function.  More often, as with Paul's post, when format is mentioned
here it's as a solution.


 > I want "8.9" and I type "0.0" - it's so easy.

Sure, but by itself it doesn't do anything observable.

With format(), you put something in and get something else out in one
statement.

With numberFormat, you first change an abstraction in the engine, then
do something to a value elsewhere, and if you remembered to do it in the
right order, and within a single handler, you'll get what you were
looking for.

That is, unless you've forgotten that you'd set the numberFormat to some
value further up in the handler for some other reason than the place you
happen to be typing in now some 50 lines later, where you're seeing
values that aren't what you had expected because you'd overlooked that
the numberFormat setting you'd done for one thing 50 lines up is still
affecting everything afterward until you reset it. (Who among us has
never had that happen to them?)   :)


 > Nor do I think numberFormat is mostly useful for legacy code and old
 > timers, or that more intuitive implies an inferior method. Anything
 > but!

Wholeheartedly agree, which is why I wrote:

    When numberFormat can do the job and you want to use it, use it.
    For certain tasks it may be somewhat simpler than the format
    function.


 > With both, we can both be happy I'm sure! Always enjoy talking with
 > you.

Amen to that, Brother Kenworthy.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
Richard:

 > With format(), you put something in and get something
 > else out in one statement.

 > With numberFormat, you first change an abstraction in
 > the engine, then do something to a value elsewhere,
 > and if you remembered to do it in the right order,
 > and within a single handler, you'll get what you were
 > looking for.

Ha ha, and that's precisely what I love about it, in addition to the
intuitive representation and the great syntax!

In other words, the property acts a lot like a setting. Plenty of those
in LiveCode. That's also intuitive, efficient the way I use them, and
something that relates well to human experience, very easy to teach and
learn. That's a strength in my book.

I forgot to add before that numberFormat seems to have the advantage on
data type awareness. When you don't know about it, it works anyway,
using the default when you concatenate. When you desire a different
result and gain awareness, you can set it, and your concatenation code
stays the same.

With format, you must have awareness from the start. Otherwise you're
just concatenating stuff, and then the default has to cover for you. We
could call that a tie, but I look at two other points. The default
superficially looks like the way numberFormat works (the syntax is just
concatenating with no functions) and LiveCode must have that built in
anyway, unless it throws an error. Then you must change your
concatenation code to include the function.

Bottom line is the "0.0" representation is just too intuitive to beat.
Cognitive load theory or not, mark my words, that representation is
going to blow away the competition in learning. That's obvious by being
so much closer in form to the desired result. The closer things are,
generally the less work required to bridge them. You can give it fancy
names, but the underlying math will hold true regardless.

Using the property like a setting is an added plus, appealing and
intuitive for many (I'd venture to guess most) people. Some others may
prefer format. For them, it's there to use and no one is advocating that
it be removed or deprecated. And even if a new property were added to
control field display, it would probably act a lot like numberFormat.

But even that wouldn't replace the need for numberFormat itself. I think
there are so many better priorities for LiveCode's "surgeons" than
attacking the healthy tissue. There are still LC 8/9 bugs and so on that
need attention, and having to intervene on behalf of this feature takes
away a lot time from submitting those bug reports and maybe doing some
promotions and such. This is one of the good parts of LiveCode! I hope
people don't get dazzled by trends or self-destructive. I've seen that
happen before. Good feature, realize the value of what you have and hang
on to it.

Best wishes,

"Uber-Mega-Doctor" Curry Kenworthy
(Richmond, my check is in the mail! Don't be stingy with the gold lettering)

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
On 2017-04-22 02:51, Curry Kenworthy via use-livecode wrote:
> Mark Waddingham:
>> I think this is perhaps more evidence that 'numberFormat'
>> should probably be deprecated - or at least marked as
>> 'present for HyperCard compatibility only and shouldn't
>> be used in new code'.
>
> I emphatically disagree.

Don't worry - I don't entirely agree with my suggestion either :)

I must confess I was being overly pejorative in order to provoke a
conversation - something I have a tendency to do from time to time in
order to help get a greater understanding of things.

> There's nothing wrong with numberFormat as a binary to text option. On
> the contrary, it's a splendid way to present the formatting to users.
> The array key example is an outlier case to watch out for, but it's
> also easy to use an alternate formatting option or careful coding for
> those rare cases.

I'd disagree that anything involving the use of arrays could be
considered
a 'rare case' or an 'outlier case'; so it is irksome that a feature
(numberFormat) which is meant to make working with the display of
numbers
'easier' is somewhat incompatible with it.

I'd mind less if numberFormat was actually had wide utility - but, in
reality,
for all but the simplest of cases (wanting US/UK style numbers, with
preceding or following '0's) it isn't very useful.

To be fair, that is fine - the problems which keep recurring could
probably be mostly dealt with by much better documentation of
numberFormat.
i.e. Clear explanation about how it affects computations, and when to
use it
and when not to

That, however, does still leave me 'wanting' though. As you point out
the
*idea* is so ergonomic that it *seems* like it should be much more
powerful,
but it is not, and if you want to use it easily with other parts of the
language, you are probably best not to use it at all.

I can guarantee that nothing is going to happen to numberFormat (beyond
perhaps improving its documentation) any time soon - if ever. Indeed,
it wouldn't ever disappear just evolved (assuming we can figure out how
to make it a) more powerful and (b) play more nicely with LiveCode's
more
modern features!).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
That's too bad.  I was hoping that I could trade deprecating
numberFormat for giving equal rights to the last item in a list.

Say it with me now:  EQUAL RIGHTS FOR ALL ITEMS!  EVEN THE LAST ONES!

On Mon, Apr 24, 2017 at 10:06 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2017-04-22 02:51, Curry Kenworthy via use-livecode wrote:
>
>> Mark Waddingham:
>>
>>> I think this is perhaps more evidence that 'numberFormat'
>>> should probably be deprecated - or at least marked as
>>> 'present for HyperCard compatibility only and shouldn't
>>> be used in new code'.
>>>
>>
>> I emphatically disagree.
>>
>
> Don't worry - I don't entirely agree with my suggestion either :)
>
> I must confess I was being overly pejorative in order to provoke a
> conversation - something I have a tendency to do from time to time in
> order to help get a greater understanding of things.
>
> There's nothing wrong with numberFormat as a binary to text option. On
>> the contrary, it's a splendid way to present the formatting to users.
>> The array key example is an outlier case to watch out for, but it's
>> also easy to use an alternate formatting option or careful coding for
>> those rare cases.
>>
>
> I'd disagree that anything involving the use of arrays could be considered
> a 'rare case' or an 'outlier case'; so it is irksome that a feature
> (numberFormat) which is meant to make working with the display of numbers
> 'easier' is somewhat incompatible with it.
>
> I'd mind less if numberFormat was actually had wide utility - but, in
> reality,
> for all but the simplest of cases (wanting US/UK style numbers, with
> preceding or following '0's) it isn't very useful.
>
> To be fair, that is fine - the problems which keep recurring could
> probably be mostly dealt with by much better documentation of numberFormat.
> i.e. Clear explanation about how it affects computations, and when to use
> it
> and when not to
>
> That, however, does still leave me 'wanting' though. As you point out the
> *idea* is so ergonomic that it *seems* like it should be much more
> powerful,
> but it is not, and if you want to use it easily with other parts of the
> language, you are probably best not to use it at all.
>
> I can guarantee that nothing is going to happen to numberFormat (beyond
> perhaps improving its documentation) any time soon - if ever. Indeed,
> it wouldn't ever disappear just evolved (assuming we can figure out how
> to make it a) more powerful and (b) play more nicely with LiveCode's more
> modern features!).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
On 2017-04-24 16:10, Mike Kerner via use-livecode wrote:
> That's too bad.  I was hoping that I could trade deprecating
> numberFormat for giving equal rights to the last item in a list.

If you mean:

   the number of items in "a,b," should be 3 (and not 2)

and

   the number of items in "a,b,c" should be 3

Then, err, no.

Sorry.

To paraphrase Scotty from Star Trek - "I can't change the laws of
logic",
and nor can you ;)

If you want to use string lists which may contain an empty element
then just make sure you always have a trailing delimiter.

Of course, if you don't mean the above, then you might want to
elaborate :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
To remind the readers, this is a database thing - null column values cause
issues with LC when the null value is on the tail.
All it would take is removing that one little line in the item code - that
line that makes items less computationally efficient than they could be.

On Mon, Apr 24, 2017 at 10:32 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2017-04-24 16:10, Mike Kerner via use-livecode wrote:
>
>> That's too bad.  I was hoping that I could trade deprecating
>> numberFormat for giving equal rights to the last item in a list.
>>
>
> If you mean:
>
>   the number of items in "a,b," should be 3 (and not 2)
>
> and
>
>   the number of items in "a,b,c" should be 3
>
> Then, err, no.
>
> Sorry.
>
> To paraphrase Scotty from Star Trek - "I can't change the laws of logic",
> and nor can you ;)
>
> If you want to use string lists which may contain an empty element
> then just make sure you always have a trailing delimiter.
>
> Of course, if you don't mean the above, then you might want to
> elaborate :)
>
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
On 2017-04-24 16:58, Mike Kerner via use-livecode wrote:
> To remind the readers, this is a database thing - null column values
> cause
> issues with LC when the null value is on the tail.
> All it would take is removing that one little line in the item code -
> that
> line that makes items less computationally efficient than they could
> be.

That's an anomaly in revDB because revDB doesn't follow the 'trailing
delimiter
is optional unless you want a list containing empty elements':

    http://quality.livecode.com/show_bug.cgi?id=14874

That one can be fixed either in queries (by making sure the last column
you
select can't be NULL - or the empty string); or in code calling it by
appending
a comma if the line ends in comma.

The engine also has a couple of anomalies with regard string-list
processing:

    http://quality.livecode.com/show_bug.cgi?id=14875
    http://quality.livecode.com/show_bug.cgi?id=14876

Unfortunately, fixing any three of those without some sort of
compatibility
mechanism would break large amounts of existing code which is written to
code with the issue.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Well as I said, the workaround is to have a function (say formatNumber) with 2 arguments, value and format string. Because the numberFormat is getting set only for that function, you can call formatNumber() and never have to worry about resetting numberformat again. And it's not more difficult to write the line of code either. In fact less so.

Bob S


> On Apr 22, 2017, at 15:42 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> With numberFormat, you first change an abstraction in the engine, then do something to a value elsewhere, and if you remembered to do it in the right order, and within a single handler, you'll get what you were looking for.
>
> That is, unless you've forgotten that you'd set the numberFormat to some value further up in the handler for some other reason than the place you happen to be typing in now some 50 lines later, where you're seeing values that aren't what you had expected because you'd overlooked that the numberFormat setting you'd done for one thing 50 lines up is still affecting everything afterward until you reset it. (Who among us has never had that happen to them?)   :)


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
I get that it would break existing code that relies on the behavior.  I'm
just offering to make that trade as the self-appointed spokesperson for
equal rights for all items.

On Mon, Apr 24, 2017 at 11:06 AM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Well as I said, the workaround is to have a function (say formatNumber)
> with 2 arguments, value and format string. Because the numberFormat is
> getting set only for that function, you can call formatNumber() and never
> have to worry about resetting numberformat again. And it's not more
> difficult to write the line of code either. In fact less so.
>
> Bob S
>
>
> > On Apr 22, 2017, at 15:42 , Richard Gaskin via use-livecode <
> [hidden email]> wrote:
> >
> > With numberFormat, you first change an abstraction in the engine, then
> do something to a value elsewhere, and if you remembered to do it in the
> right order, and within a single handler, you'll get what you were looking
> for.
> >
> > That is, unless you've forgotten that you'd set the numberFormat to some
> value further up in the handler for some other reason than the place you
> happen to be typing in now some 50 lines later, where you're seeing values
> that aren't what you had expected because you'd overlooked that the
> numberFormat setting you'd done for one thing 50 lines up is still
> affecting everything afterward until you reset it. (Who among us has never
> had that happen to them?)   :)
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Don't amputate numberFormat (was: affecting array keys???)

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Mark Waddingham:

 > I can guarantee that nothing is going to happen to numberFormat
 > (beyond perhaps improving its documentation) any time soon -
 > if ever. Indeed, it wouldn't ever disappear just evolved (assuming
 > we can figure out how to make it a) more powerful and (b) play
 > more nicely with LiveCode's more modern features!).

Mark, thanks for the reassurance, that is great to hear!

I agree it would be even better if it did more. I would be thrilled if
numberFormat can be upgraded in ways that are backward compatible.

Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Make numberFormat even better

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode

We've talked about this topic so much that now it almost seems a waste
to let it go without trying to make some progress. :)

Mark:

 > I'd disagree that anything involving the use of arrays could
 > be considered a 'rare case' or an 'outlier case'

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"

Pros: Array keys can be set independently of their contents or any other
text, but only one "set" statement required for most situations. Fully
backward compatible. Basic syntax is just as before, easy to learn and
sufficing for many (most?) tasks.

Cons: A bit more complex and less English-like when using the special
parts. It's a bit unusual to need to differentiate array keys from all
other text.

Also: You'll notice it can be confusing if you think i=5 binary and
expect a change, but it was actually already text. If we have to add +0
&"" stuff it's less intuitive. But that's a separate issue to consider,
outside this particular point.

Mark:

 > I'd mind less if numberFormat was actually had wide utility -
 > but, in reality, for all but the simplest of cases (wanting
 > US/UK style numbers, with preceding or following '0's) it isn't
 > very useful.

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.

-- (assume i=binary 5555)

set numberformat to "$#,##0.00"
put "Cost:" && i into x --> x = "Cost: $5,555.00"

BTW, I've worked with Excel number format a bit. Supporting it would be
an impressive product compatibility and even benefit some of my own
projects. However, that might be overkill for LC team and the user. (It
has 4 parts, to start with, and a learning curve of its own for advanced
features.)

A simpler route (based on ideas and techniques while doing SpreadLib and
other projects) would be to retain any text prefix and suffix outside
the # and 0 number portion of the representation, and also look for
commas and periods within the number. Bonus: allow smart period/comma
positions and a few other tricks. Maybe including a parenthesis anywhere
before the number portion = negatives in parentheses.

-- (assume i=binary 5555)

set numberformat to "#.##0,00 EUR"
put "Cost:" && i into x --> x = "Cost: 5.555,00 EUR"

-- (assume i=binary 5)

set numberformat to "$ (0.##)"
put "Cost:" && i into x --> x = "Cost: $ 5"
put "Cost:" && -i into x --> x = "Cost: $ (5)"

That should be backward compatible, except if existing code was reading
the numberformat to analyze it for decisions or settings. Should be able
to figure out a way around that.

(If I've proposed something that has been proposed before, sorry!)

Richard:

 > there are so many precedents in other tools for defining
 > display format in the object used for display that I think
 > when that's what's needed it would be the simplest to learn.

That's true, very nice to have that option too!

Best wishes,

Curry Kenworthy

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Make numberFormat even better

Bob Sneidar via use-livecode
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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Make numberFormat even better

Bob Sneidar via use-livecode
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 <
[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Make numberFormat even better

Bob Sneidar via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> > LiveCode: Everyone can create apps
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123