Hi,I would like to learn how to pad the ragged right edge of a column offloating point data with visible zeros, appearing after the decimalpoint.At the moment, q auto-magically leaves out any trailing zerosoccurring after the decimal point.For instance, in a column of results, I have:90.3290.1490.790.0390.49090.98NB: q also seems to omit the decimal point where both trailing zerosare present. i.e., 90What I would like to see on the console screen is:90.3290.1490.7090.0390.4090.0090.98I am able to trim the floating part of the number to any amount ofnumerals after the decimal point. In the case above I functionallytrimmed the data to 2 numerals after the decimal point. I just can’twork out how to zero-pad the white-space of floating point data.Additionally, if at all possible, I would also like to know how toright-justify a column of floating point data.For instance, in a column of floating point results I have:1000.12999.54997.431001.031004.261002.07998.41I would prefer to display it using the last digit as the alignmentmeasure, see below:NB: This may not display properly since I had to use two white-spacesto line up these right hand values inside the forum input message-box.1000.12 999.54 997.431001.031004.261002.07 998.41Thanks, for your eternal patience.Q.
I think .Q.fmt does what you want:
q).Q.fmt[6;2] each 90.32 90.14 90.7 90.03 90.4 90 90.98
" 90.32"
" 90.14"
" 90.70"
" 90.03"
" 90.40"
" 90.00"
" 90.98"
q)
Hi Simon,Thank-you for your kind assistance.I was kind of hoping for a formatting option that might return a listof float, ie., type num 9h...Unfortunately, the suggested .Q.fmt format returns a list of elementsof char; ie., type num 10hWhen I assign the process to a variable t, and query the type ofvariable t, it returns 0h, a general list.t:(.Q.fmt[6;2] each 90.32 90.14 90.7 90.03 90.4 90 90.98)type t0hWhen I query the type of the member elements of t, it returns 10htype t[0]10htype t[1]10h… etc.. being type 10h I can’t perform subsequent arithmeticoperations on char elements.When I select an element of t and do a cast to float, it returns alist of the decimal ascii numerical values for each char in thestring.t[5]" 90.00"float$t[5]32 57 48 46 48 48fIt seems it may not be possible to simply format and return a list of`float, at least with current built-in functions.Regards,Q.
Hi Tim,Yes, it does return a list of floats, but the .Q.fmt formatting islost.When I go:q)“F”$.Q.fmt[6;2] each 9090f … it returns the original q float format…The same thing happens when I apply eval parse to Simon’s stringresult.For instance:q)t:(.Q.fmt[6;2] each 90 90.1 90.7)q)t" 90.00"" 90.10"" 90.70"q)eval parse t[0]90fIt may not be possible to zero-pad float data using existing built-infunctions in the current q implementation.Regards,Q.
Ah sorry, I understand you now. You can probably force the rendering function to do something about it if you really wanted, but I don’t think this serves much purpose other than to make it *look* uniform. Remember:
q)(90.0=90.00)&90.0=90f
1b
Hello>> Yes, it does return a list of floats, but the .Q.fmt formatting is>> lost.But surely you want to work with floats as a compact and efficientinternal representation of your data, and deal with stinky stringsonly when presenting results to (or getting inputs from) a human orplain-text communication (XML etc).Cheers
Hi Tim,Making it look uniform is exactly what I want to do. :)Do you know if it is possible to view the rendering function? i.e., Isit in q.k…Regards,Q.
Just type .Q.fmt at the prompt and you will see the K code it is madeof.or did you mean something else?-- O.L.
And yes it is defined in q.k, currently at line 71-- O.L.
Hi Olivier,You are most likely right… that the use of the term renderingfunction was a reference to .Q.fmtI have mistaken the term as referring to some function which controlsthe way float values are natively rendered in q. i.e., droppingtrailing zeros and dropping the decimal point for a round-number floatvalue.Where there are 7 places of float precision, I would have liked tosee:0.0000001and0.1000000as being uniformly consistent.When I program a recurring increment to a Time field by exactly oneminute, every subsequent result does include the zero-padding, whichis entirely consistent.For instance,12:00:00.00012:01:00.00012:02:00.00012:03:00.00012:04:00.000Kind Regards,Q.
> Making it look uniform is exactly what I want to do. :)>> Do you know if it is possible to view the rendering function? i.e., Is> it in q.k…“show” is the rendering function for most things, and it is defined inq.k. it’s fairly hard going though, as it quickly gets into a hugemess of k setting up string forms for tables and dicts and things.now, part of that chain is -3!, which as a C binding is uneditable,but there’s nothing in principle preventing you from, for instance,intervening in a late stage of .Q.s, trapping all the f’s (and e’s)and using .Q.fmt to pad them out to the current /P. it’s just trickyto get exactly right. :)also be aware it’s not going to affect “string” or 0:, only show andthe default console display. (and possibly the web display, dependingon where you make your changes–i think the .h rendering pipelineeventually goes through .Q.S.)
G’day Aaron,Thanks for your detailed explanation.I had a good look at ‘show’ and .Q.s on the q.exe command line. I cansee the -3! as the last term of .Q.s … It is not a problem, that itwon’t affect ‘string’ or 0:… I only want to apply the effect to thefloat data on the console screen.I was thinking I might leave it for the moment and tackle it as anadvanced exercise down the track and cross my fingers, in themeantime, that it might appear as built-in function, sometime in thefuture..I was also thinking that part of the cause of the ragged right edgefor my float data output to the console screen, might also lie in myrounding function, which chops the \P output back to 2 decimal placesand then applies the rounding effect. Given that my program generatesa simulated time-series from a set of user inputs, it should notaffect the output too much if I just did a bare chop of the float at2 decimal points and leave out the rounding process. The probabilityof having a whole number or even a single decimal point result,emitted as raw output for 7 places of float precision, looks to bequite low, especially when I examine the data coming out of theprogram, i.e., before the rounding function gets applied.Hello Margherita Pizza,Do you have a sister named Supreme? Coz, I think I might have eaten…er sorry …met her at dinner a few times. Very nice girl, especiallywhen she leaves those anchovies at home. :)I fully understand what you are saying, … I ought to only worryabout formatting for human readable files.I guess I am just being overly pedantic, by insisting on consistencyfor float data. Nevertheless, I don't like the idea of disappearingdecimal points.In terms of compactness or efficiency, I am not sure that wholenumbers, or very short numbers in float data enhance the speed orefficiency of the program. After all, what is the chance of gettingone of those numbers, or a series of them, as raw output from 7 placesof precision… However, it is more than likely that I simplymisunderstood your point.The main reason I want consistent, two decimal-point float data -after rounding, is for presentation purposes. If I show someone how Iam progressing with this language.... I want it to look nice. It makesme feel more professional, ....by taking care with the details. Ithink may have misled people, when I said earlier in this thread thatI want to do calculations on the 'float data. I really just want tomake it look consistent and be able to align the float data in theconsole window by applying ‘right justification’. So that, when I showpeople the data moving through the program, it looks like I care…and I do care, but at the moment the output doesn’t look like it.Kind Regards,Q.