Re: Make numberFormat even better AND Cognitive Load

[Bob Sneidar via use-livecode]

Yup. I do that a lot. Where I have an issue is dividing up a block of time into 
multiple segments, where the minutes may not divide evenly between all the 
segments. So I produced this:

function timeTable pStartTime, pStartLunch, pEndLunch, pEndTime, pItemCount
   set the itemDelimiter to ":"
   
   -- convert all times to minutes
   put item 2 of pStartTime + (item 1 of pStartTime *60) into tStartTimeMinutes
   put item 2 of pStartLunch + (item 1 of pStartLunch *60) into 
tStartLunchMinutes
   put item 2 of pEndLunch + (item 1 of pEndLunch *60) into tEndLunchMinutes
   put item 2 of pEndTime + (item 1 of pEndTime *60) into tEndTimeMinutes
   put tEndLunchMinutes - tStartLunchMinutes into tLunchMinutes
   put tEndTimeMinutes - tStartTimeMinutes - tLunchMinutes into tTotalMinutes
   
   -- calculate the minutes per item with remainder
   put tTotalMinutes div pItemCount into tItemMinutes
   put tTotalMinutes mod pItemCount into tModMinutes
   
   -- if there was no lunch times provided, make some up
   if pStartLunch is empty then
  put tStartTimeMinutes + tItemMinutes into tStartLunchMinutes
  put tStartLunchMinutes into tEndLunchMinutes
   end if
   
   repeat with counter = 1 to pItemCount
  put tStartTimeMinutes into aTimeTable [counter] [1]
  put tStartTimeMinutes + tItemMinutes into tNextTimeMinutes
  
  -- distribute spare minutes
  if tModMinutes >0 then
 add 1 to tNextTimeMinutes
 subtract 1 from tModMinutes
  end if
  
  if tLunchMinutes > 0 then
 if tNextTimeMinutes >= tStartLunchMinutes then
put tStartLunchMinutes into aTimeTable [counter] [2]
put tEndLunchMinutes into aTimeTable [counter] [3]
add tLunchMinutes to tNextTimeMinutes
put 0 into tLunchMinutes
 else
put 0 into aTimeTable [counter] [2]
put 0 into aTimeTable [counter] [3]
 end if
  else
 put 0 into aTimeTable [counter] [2]
 put 0 into aTimeTable [counter] [3]
  end if
  
  put tNextTimeMinutes into aTimeTable [counter] [4]
  
  -- calculate total minutes for this record
  put (aTimeTable [counter] [4] - aTimeTable [counter] [1]) - \
(aTimeTable [counter] [3] - aTimeTable [counter] [2]) \
into aTimeTable [counter] [5]
  put tNextTimeMinutes into tStartTimeMinutes
   end repeat
   
   -- convert minutes back to seconds
   put the keys of aTimeTable into tTableKeys
   sort lines of tTableKeys numeric ascending
   
   repeat for each line tKey in tTableKeys
  put aTimeTable [tKey] into aTimeRecord
  put the keys of aTimeRecord into aRecordKeys
  repeat for each line tRecordKey in aRecordKeys
 put aTimeRecord [tRecordKey] into tTime
 if tTime = 0 then
put empty into aTimeTable [tKey] [tRecordKey]
 else
put tTime div 60 & ":" & tTime mod 60 into tTime
put formatTime(tTime, "sql time") into tTime
put char 1 to 5 of tTime into aTimeTable [tKey] [tRecordKey]
 end if
  end repeat
   end repeat
   
   return aTimeTable
end timeTable

function formatTime theTime, theFormat
   /*
   accepts any valid time and returns the form of the time specified in the 
second parameter.
   The valid formats are:
   sql time: hh:mm:ss (Note: combining sql date from the formatDate() function 
with the
   sql time will produce a valid SQL date time type). 
   short time: LC short time format
   abbreviated time: LC abbr time format (same as short time)
   long time: LC long time format
   seconds: the number of seconds since the prior midnight
   military: the military time 00:00 - 23:59
   */
   if theTime is empty then return empty
   
   set the numberformat to "00"
   switch theFormat
  case "sql time"
 convert theTime to dateitems
 put (item 4 of theTime +0) & ":" & \
   (item 5 of theTime +0) & ":" & \
   (item 6 of theTime +0) into theTime
 break
  case "short time"
 convert theTime to short time
 break
  case "abbreviated time"
 convert theTime to abbreviated time
 break
  case "long time"
 convert theTime to long time
 break
  case "seconds"
 convert theTime to seconds
 break
  case "military"
 set the itemdelimiter to ":"
 
 if theTime contains "PM" then
add 12 to item 1 of theTime
 end if
 
 put word 1 of item 2 of theTime into item 2 of theTime
 break
   end switch
   
   return theTime
end formatTime


> On Apr 27, 2017, at 13:27 , Mike Kerner via use-livecode 
>  wrote:
> 
> On the topic of keeping LC stupid-simple, here's of one of those ways that
> LC makes ugly math fun:
> #
> 
> put the short date into theDate
> convert theDate to dateItems
> put 0 into item 3 of theDate
> convert theDate to short 

Re: Make numberFormat even better AND Cognitive Load

[Mike Kerner via use-livecode]

On the topic of keeping LC stupid-simple, here's of one of those ways that
LC makes ugly math fun:
#

put the short date into theDate
convert theDate to dateItems
put 0 into item 3 of theDate
convert theDate to short date
put theDate

#

On Wed, Apr 26, 2017 at 12:45 PM, Mike Kerner 
wrote:

> I think 3 is something we should scratch off the list, since we have more
> important fish for you to fry.
>
> On Wed, Apr 26, 2017 at 11:42 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> On 2017-04-26 16:00, prothero--- via use-livecode wrote:
>>
>>> Ok, I'll shut up about this for now. Sorry to unfocus the thread.
>>>
>>
>> To be fair, I managed to conflate three issues:
>>
>>   1) Improving numberFormat
>>
>>   2) How we could get arbitrary precision integers whilst retaining
>> doubles for reals
>>
>>   3) How to make numberFormat and array keys play nice together
>>
>> They are all distinct issues really, although the numberFormat is
>> involved in all three (at least in some way) :)
>>
>> 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
>>
>
>
>
> --
> 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."
>



-- 
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

Re: Make numberFormat even better AND Cognitive Load

[Mike Kerner via use-livecode]

I think 3 is something we should scratch off the list, since we have more
important fish for you to fry.

On Wed, Apr 26, 2017 at 11:42 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-04-26 16:00, prothero--- via use-livecode wrote:
>
>> Ok, I'll shut up about this for now. Sorry to unfocus the thread.
>>
>
> To be fair, I managed to conflate three issues:
>
>   1) Improving numberFormat
>
>   2) How we could get arbitrary precision integers whilst retaining
> doubles for reals
>
>   3) How to make numberFormat and array keys play nice together
>
> They are all distinct issues really, although the numberFormat is involved
> in all three (at least in some way) :)
>
> 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
>



-- 
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

Re: Make numberFormat even better AND Cognitive Load

[Mark Waddingham via use-livecode]

On 2017-04-26 16:00, prothero--- via use-livecode wrote:

Ok, I'll shut up about this for now. Sorry to unfocus the thread.


To be fair, I managed to conflate three issues:

  1) Improving numberFormat

  2) How we could get arbitrary precision integers whilst retaining 
doubles for reals


  3) How to make numberFormat and array keys play nice together

They are all distinct issues really, although the numberFormat is 
involved in all three (at least in some way) :)


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

Re: Make numberFormat even better AND Cognitive Load

[prothero--- via use-livecode]

Folks,
This thread addresses two issues with numbers. The main issue being discussed 
is the display of numbers. This is very important and the main point of 
diddling with numberformat. I like the idea of making a behavior we can all use 
to format numbers in a variety of ways.

The other one is the internal representation of numbers in the engine. 
Currently, it seems there are either strings or numbers and the engine converts 
between the two, depending on rules that it carries internally. It's partially 
my bad that this issue got incorporated into this thread. But where I saw the 
problem was in the discussion of array keys and how the engine treated a[1] 
different from a[01]. It's really the way arrays work and that the keys are 
really text, not numbers (at least, that's what I understand from the 
discussion). I use arrays a lot and love them for this. They become a bit 
inconvenient when all I want is a numerically indexed array without gaps. But 
it's only a minor issue for me. When it comes to integers, I only need to 
decide whether to round or trunc a value. 

When speed issues arise, the most transparent way of dealing with this would be 
to declare an integer type variable, and the engine would then treat all 
instances of that variable as an integer. We already declare variables as local 
or global, and I see no conflict with the xTalk language philosophy in adding 
that property to a variable.

Ok, I'll shut up about this for now. Sorry to unfocus the thread.

Best,
Bill P

William Prothero
http://es.earthednet.org

> On Apr 26, 2017, at 2:31 AM, Curry Kenworthy via use-livecode 
>  wrote:
> 
> 
> Roland:
> 
>> I vote for the LC-NATIVE "Excel style" number format
>> (enhanced numberFormat in LC, not a new one, no
>> depreciation, but just different ways to achieve the same)
> 
> Excel number format is powerful and popular, that's for sure.
> 
> Richard:
> 
>> The Excel spec is a guide, but not an implementation.
>> Making that work robustly, flexibly, and sensibly within
>> LiveCode is a considerable design project.
> 
> SpreadLib supports a portion of the Excel number and date formatting, a good 
> start on that effort and with some lessons learned. Excel does have its 
> quirks like everything else.
> 
> Over time I've also chosen my own favorite "Curry Lite" formatting features, 
> with the convenience of a single code for both positive and negative. I tried 
> some tests with that style, and here are the results:
> 
> http://curryk.com/ck-num-format.png
> 
> 
> 
> I can choose where to put a negative sign or parentheses, and include 
> arbitrary text. Maybe I can break that out into a separate formatting 
> library. Still want to try some of the crazier things that Excel can do. :)
> 
> Best wishes,
> 
> Curry Kenworthy
> 
> ___
> 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

Re: Make numberFormat even better AND Cognitive Load

[prothero--- via use-livecode]

Curry,
This is great and best of all is the table of examples. This, in the 
dictionary, would have made my thrashing around with format, to get what In 
wanted a lot easier.
Bill

William Prothero
http://es.earthednet.org

> On Apr 26, 2017, at 2:31 AM, Curry Kenworthy via use-livecode 
>  wrote:
> 
> 
> Roland:
> 
>> I vote for the LC-NATIVE "Excel style" number format
>> (enhanced numberFormat in LC, not a new one, no
>> depreciation, but just different ways to achieve the same)
> 
> Excel number format is powerful and popular, that's for sure.
> 
> Richard:
> 
>> The Excel spec is a guide, but not an implementation.
>> Making that work robustly, flexibly, and sensibly within
>> LiveCode is a considerable design project.
> 
> SpreadLib supports a portion of the Excel number and date formatting, a good 
> start on that effort and with some lessons learned. Excel does have its 
> quirks like everything else.
> 
> Over time I've also chosen my own favorite "Curry Lite" formatting features, 
> with the convenience of a single code for both positive and negative. I tried 
> some tests with that style, and here are the results:
> 
> http://curryk.com/ck-num-format.png
> 
> 
> 
> I can choose where to put a negative sign or parentheses, and include 
> arbitrary text. Maybe I can break that out into a separate formatting 
> library. Still want to try some of the crazier things that Excel can do. :)
> 
> Best wishes,
> 
> Curry Kenworthy
> 
> ___
> 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

Re: Make numberFormat even better AND Cognitive Load

[Curry Kenworthy via use-livecode]

Roland:


I vote for the LC-NATIVE "Excel style" number format
(enhanced numberFormat in LC, not a new one, no
depreciation, but just different ways to achieve the same)


Excel number format is powerful and popular, that's for sure.

Richard:


The Excel spec is a guide, but not an implementation.
Making that work robustly, flexibly, and sensibly within
LiveCode is a considerable design project.


SpreadLib supports a portion of the Excel number and date formatting, a 
good start on that effort and with some lessons learned. Excel does have 
its quirks like everything else.


Over time I've also chosen my own favorite "Curry Lite" formatting 
features, with the convenience of a single code for both positive and 
negative. I tried some tests with that style, and here are the results:


http://curryk.com/ck-num-format.png



I can choose where to put a negative sign or parentheses, and include 
arbitrary text. Maybe I can break that out into a separate formatting 
library. Still want to try some of the crazier things that Excel can do. :)


Best wishes,

Curry Kenworthy

___
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

Re: Make numberFormat even better AND Cognitive Load

[Richard Gaskin via use-livecode]

Roland Huettmann wrote:

>  AGAIN -- having read all - I vote for the LC-NATIVE "Excel style"
> number format (enhanced numberFormat in LC, not a new one, no
> depreciation, but just different ways to achieve the same) and the
> ability of fields (text controls) to express at least the same
> styling properties that fields (cells) in Excel support, or text
> boxes in the web browser without having to write my own functions.
> I would like to have it "built-in". It is a wish. LiveCode should
> grow so that the team developing it will consist of 100 core
> developers. It is a wish. Maybe someone else can help developing.
> We can fund it. Whatever. It is a wish. And I do not want to stop
> wishing just because there is "no time left" for the core developer
> team to care for such minor (???) details. They need more support and
> more funding in such case.

I like that.  A lot.

There are many ways to support a project.  Cash is great (they do have a 
donation button), but so is code.


When we think about code contributions, they already have a team far 
larger than 100s.  It's in the thousands.  It's us.


One of the hardest aspects of this problem is the design.  The Excel 
spec is a guide, but not an implementation.  Making that work robustly, 
flexibly, and sensibly within LiveCode is a considerable design project.


And it's a design project that we can do.

We can start today.

Design doesn't require expertise in C++.  The best qualification for 
designing a solution is a clear understanding of the need.


We want this.  Can have have this.

Having begins with designing, and we can design in script.

And once the implementation's design is well honed, we may find we just 
saved the engine team a boatload of design work.


And along the way we have a functional scripted solution we get to use now.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Make numberFormat even better AND Cognitive Load

[Roland Huettmann via use-livecode]

With reference to the past suggestions, and the last one from Richard
Gaskin:

"Even if the core team were in a position to drop other priorities to add
formatting to fields, they couldn't do it any faster than a scripter who
has the advantage of doing it in LiveCode itself."

I have been thinking about the underlying reasons why we are discussing. I
agree with Richard that a lot of what we have in mind can be done simply
using LiveCode script and behaviors for fields. But are we not doing this
already most of the time?

===
 AGAIN -- having read all - I vote for the LC-NATIVE "Excel style" number
format (enhanced numberFormat in LC, not a new one, no depreciation, but
just different ways to achieve the same) and the ability of fields (text
controls) to express at least the same styling properties that fields
(cells) in Excel support, or text boxes in the web browser without having
to write my own functions. I would like to have it "built-in". It is a
wish. LiveCode should grow so that the team developing it will consist of
100 core developers. It is a wish. Maybe someone else can help developing.
We can fund it. Whatever. It is a wish. And I do not want to stop wishing
just because there is "no time left" for the core developer team to care
for such minor (???) details. They need more support and more funding in
such case. Would they not deserve it? And are there not billions of dollars
around, often enough just wasted for what? ))). Why should not a clever
large company see LiveCode as a way to enhance their public awareness and
sponsor it?
===

Expanding the "numberformat" going beyond...

I favor great visual style and I would love when people start using
LiveCode as a development platform even for the web, as a design system, as
a way to translate to HTML/CSS, Javascript and PHP using ONE base, as a
workshop for great content management systems -- and a lot has been done in
this way during the last three years.

And I am also asking myself, why am I spending time over and over writing
lines of code that are just repeating themselves for me and others, more or
less. And my own library is just my own. I use it. I could share it, but it
is not part of the community really. (And I feel too shy to share it unless
it was reviewed and tested a hundred times.)

So basically, we are not so much discussing about ourselves -- at least not
when there is some experience gained developing with LiveCode -- we are
discussing about the LANGUAGE as we believe it deserves to be spreading out
into the world to 100x or 1000x more developers or people wishing to at
least using such jewel for their fun at home, for in-house development,
just to solve some problems that otherwise would require a professional and
very costly setup.

We know that we can already solve lots of such questions about formats
(number formats, date formats, colors, forms, visual appearance in general)
just reverting to scripting. For example, to just have a bottom border
underlined, I can of course just use a line object and have it set where I
want it to be. But is this really how it should be in today's world? I
would rather like to focus on even more abstract levels and not having to
care too much about the daily standard routines.

I am thinking of the ATTRACTION TO THE LANGUAGE especially for NEWBIES,
young people, retired people, who have not much or no experience at all
with computer languages. There is a huge market.

So, I am stretching out beyond numberFormat -- more into Cognitive Load --
another nice discussion we are having.

Why should not retired people have fun developing on a computer? Would not
LiveCode be the only and truly ideal way to learn and enjoy results
immediately? It can be a business by itself. There are growing numbers of
them, millions and millions of retired people who even have all the time to
not allowing their brains to rust. It is "just" a question of proper
worldwide marketing.

Or think of Africa with hundreds of millions of young people who have not
much chance to even touch any computer, even if almost every of their
elderly brothers and sisters owns a cheap Android phone to be proud of.
There are hundreds of millions of young people eager to get involved. And
some of them could even make a living using it. And there are funds with
hundreds of millions just for such young people.

I want the language to shine bright, really be able to compete, and even
when acknowledging that it is probably impossible to win much ground
against Javascript or PHP or Python. The base for such other languages is
too big. The support such languages enjoy from largest companies can not be
argued against.

But still, I feel, that I would love to see LiveCode gaining ground, be the
first choice at least for beginners. (And I say this because I have fun
using it.)

Who will start with the expanded "numberformat" to be shipped with newer
versions? )

Roland

P.S. I hope this contribution message is not too much missing the point --