format library

[Oliver Seitz]

Hi all :-)

It's been nine days and nine years since the original print library was finally replaced by my version. I remember, I've said then, that I would also do the format library soon. I feel like it's about time now...

So, usually when I start thinking about improvement, I'm focused on mimicking the current behavior as close as possible. Yet... This is what it currently does:

format_sdword(output,12345678, 6,0) ->     5678
format_sdword(output,12345678, 7,0) -> �45678
format_sdword(output,12345678, 7,1) -> �4567.8
format_sdword(output,12345678, 8,0) -> C345678
format_sdword(output,12345678, 8,1) -> C34567.8
format_sdword(output,12345678, 8,2) -> C3456.78
format_sdword(output,12345678, 9,0) -> 12345678
format_sdword(output,12345678, 9,1) -> 1234567.8
format_sdword(output,12345678, 9,2) -> 123456.78
format_sdword(output,12345678,10,0) ->  12345678
format_sdword(output,12345678,10,1) ->  1234567.8
format_sdword(output,12345678,10,2) ->  123456.78
format_sdword(output,12345678,11,0) ->   12345678
format_sdword(output,12345678,11,1) ->   1234567.8
format_sdword(output,12345678,11,2) ->   123456.78
format_sdword(output,12345678,12,0) ->   12345678
format_sdword(output,12345678,12,1) ->   1234567.8
format_sdword(output,12345678,12,2) ->   123456.78
format_sdword(output,12345678,13,0) ->   12345678
format_sdword(output,12345678,13,1) ->   1234567.8
format_sdword(output,12345678,13,2) ->   123456.78

The third parameter, said to give the field length to be used, is quite limited:

1) The actual length differs, depending on the presence of a decimal point
2) Length greater than 11 is treated as 11
3) Too short a field leads to corruption of the number, always reserving places for sign and decimal point

3) probably can't be of any use - here's the question if the number should be truncated or replaced by error signs to show that something's wrong.

For 1) and 2), there's a possibility that existing programs rely on this behavior. But, as those are 'undocumented "features" ', I feel like they can be replaced by more useful things. Like, fields can be as long as 255 characters, and the number is truly right-aligned, if it has decimals or not.

If the number of decimals is greater than the field lengt-1, it is treated as zero. Here's another option to fill: what should be done if both numbers are nearly-equal, equal or the decimals number greater than the field length? Left-aligned, ignoring the field length?

Any preferences anyone?

Greets,
Kiste

[vsurducan]

Hi Oliver,

Can we check your improvements first for the resources used?  The experience of the last 20 years on jal shows that biggest improvements can not be used anymore on small pics...

The length of the number (in my way of understanding) depends on the output device type. On some is useless to have too many numbers. On a LCD display I do not see any requiring a 9 digit  (except perhaps displaying  a frequency) . On the other hand, on a serial console it might be useful for something...

thx,

Vasile

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/2110995783.3397177.1608638352475%40mail.yahoo.com.

[Rob CJ]

Hi Kiste,

I recently added print_float() to your print library 🙂. The format was based on what Kyle already described in the funcs.jal library. 

Some thoughts from my side. 

I wonder why you should pass the formatting of the sdword like you suggested. Why not indicating that a thousand separator is required or not and if the type of separation is '.' (Europe style) or ',' (American style). You could pass this format as one parameter, e.g.:

0 = no thousand separator

1 = thousand separator using '.'

2 = thousand separator using ','

So 12345678 could be written as:

12345678 (no thoudsand separation)

or

12.345.678 (thousand separation using '.')

or

12,345,678 (thousand separation using ',')

Kind regards,

Rob

---

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: dinsdag 22 december 2020 12:59
Aan: Jallib <jal...@googlegroups.com>
Onderwerp: [jallib] format library

 

[Rob CJ]

Hi Vasile,

What do you mean with "The experience of the last 20 years on jal shows that biggest improvements can not be used anymore on small pics..."

If improvements cannot be used then that it  may be caused by an increase in what you want to do with the smaller PIC's but not by the improvements made by JAL itself, at least that is my opinion. I often use smaller PICs and even the recently updated large array library can be used on a 12F617 if for example you want to create an array of e.g. 90 bytes while it only has 128 bytes on board.  Even better, the newest large array used for this example uses even 1 byte less than the previous large array version!

Maybe there are more opportunities for lowering code and data space but then it would help if you could give an example of what you want to achieve what is no longer possible.

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: dinsdag 22 december 2020 18:40
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] format library

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qv_pVn2XgeJ5cLMSv%2BJY%3Dm-Tn9BvyKfF3%3DfWDRr9FA16Q%40mail.gmail.com.

[Oliver Seitz]

Hi Vasile,

of course! In some way, you can check it right now: Compare the format library, which still uses divisions, to the print library (integer routines). My intension is not primarily to add bells and whistles, but to save resources. You can compile a program using the print library for the 10f200 chip if you limit the decimal conversion to 1 byte. 

When I did my own print library, I mainly wanted it to be more flexible. I was impressed by the possibility of using byte*256 sized numbers, and wanted to convert those to decimal. When I was finished however, we discussed both libraries. My new library could output bigger numbers, worked remarkably faster, and used less both code and data space. Therefore, as there was not a single advantage on the old library, it was decided to replace it.

I did in fact measure the instruction cycles both libraries needed to convert every single number that can be stored in a dword. The old library was indeed faster - when converting "0". For all of the other 4294967294 numbers, my library was faster ;-)

And Rob, as usual I had some extras in mind, you guessed some of them :-) 

I was, however, thinking about constants with defaults that one could define, or use variables, if during runtime different output styles are needed.
About like this:

FORMAT_THOUSANDS=","   -- or "'", or " ", or 0 if none wanted
FORMAT_DECIMAL="."
FORMAT_PLUS_SIGN=0    -- or " " to always reserve space for the sign, or "+" to always display a sign
FORMAT_LEADER="0"  -- char with wich a right-aligned number is padded, usually "0" or " "


In general, I really do want format to work the way it does now, displaying a decimal separator wherever I want it. I like to use fixed-point math. Right now, my thermometer has to transmit the measurements in millicelsius. I really would prefer having a decimal point (or comma). There is a special procedure in format.jal which is there for outputting certain digits out of a number. That's helpful for my thermometer, which can do the math internally in millicelsius but can easily be written to a display with only one digit after the point. Again, without using divisions. I hate divisions, they're using so much resources. ;-)

Greets,
Kiste


Am Dienstag, 22. Dezember 2020, 18:40:22 MEZ hat vsurducan <vsur...@gmail.com> Folgendes geschrieben:

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qv_pVn2XgeJ5cLMSv%2BJY%3Dm-Tn9BvyKfF3%3DfWDRr9FA16Q%40mail.gmail.com.

[vsurducan]

Hi Rob, it wasn't any criticism, please do not understand it wrong. The PIC evolution to bigger memory, powerful peripherals (including CLC, NCO, EUSART via pin relocation, etc) is encouraging the extension of actual jal libraries. In small PICs (as PIC12 you've pointed) I'm trying to use onlysome  favourite routines from those libraries, there is no problem for me. However, I've noticed that an 8K microcontroller get 98% of memory full very fast these days...I have no problem in achieving anything I want. :) Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/AM0PR07MB6241B8C8D44F220A3D41384FE6DF0%40AM0PR07MB6241.eurprd07.prod.outlook.com.

[vsurducan]

Ok, great!

For divisions may I suggest division/multiplication with a constant? That allows you to calibrate the full scale of the ADC or a termometer to your needed value with your imposed error and code length. Higher error meaning lower code lenght, lower error creates higher code lenght.

The old routine (constdivmul) was written by a russian named Golovnichenko, a great piece of software adapted separately by Kyle and Stef Mientky (if I recall well).

Thank you for your work, I have appreciated and learned new things from these libraries!

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1676376410.3617961.1608674508106%40mail.yahoo.com.