Re: floating point output formating
@Araq I probably mistook the general spirit of your answer for an answer to this particular thing. Sorry then. Well, I'm puzzled about this particular case (searching for float formating) too, as... well, I've already said this --- if you're looking for a single specific function (which is, luckily, not some fancy operator), it's quite easy to find it. It would be less obvious if it was about some techniques, I'd say. So... I can't give you my answer, as I find index very useful. Also: ohhh, please, don't say you're nice because you're not censoring people... again. ^^" You're much cooler when you don't use that argument. Well, I guess this thread is a huge off-top, that's right here. ^^"
Re: floating point output formating
> It seems Araq doesn't really like my way of thinking. I can also see how Araq > reacted to pointing out formatFloat's odd behaviour for 0 (which was quite > odd to me, too). I, for instance, didn't notice it myself as I don't really > use Nim for numerical calculations (I use Fortran). And I think good docs > should be treated as kind of test and things should be fixed if these tests > prove what they test is unobvious or even worse, erroneous. I actually agree the behaviour for 0 is odd and never said otherwise. All I did was offering my help and I tried to find the root cause for why jzakiya spent 3 hours unsuccessfully looking for `formatFloat` when his/her very own **title** contained the word `format`. As a thank-you I never got any real answers (I still haven't btw) and I have to read pamphlets about my "attitude" and that I should be grateful for his precious feedback that from my perspective he actually actively withholds. There are always at least two sides to look at, from my perspective I'm grateful and humble, I haven't banned him or censored his impertinences. I won't participate in this thread any further.
Re: floating point output formating
@dom96 > Doc writing is boring > > Creating documentation PRs is the easiest thing in the world (but also the > most boring) It depends. I, for instance, quite like it. I care (although "deeply" may be a big word) about my users so even if I have no time, energy or I'd like to move to another project, I like to make good docs so that the project is... well... what I call "mature product". > So, what's your excuse? A few reasons not to do this: * It seems Araq doesn't really like my way of thinking. I can also see how Araq reacted to pointing out formatFloat's odd behaviour for 0 (which was quite odd to me, too). I, for instance, didn't notice it myself as I don't really use Nim for numerical calculations (I use Fortran). And I think good docs should be treated as kind of test and things should be fixed if these tests prove what they test is unobvious or even worse, erroneous. * I once made a pull request to a unofficial Nim package. It wasn't accepted because of... names of testing routines. Of course it's just an example, but if everybody says docs are not-really-so-important, boring and in-general-quite-of-stupid-thing-to-do-so-please-do-it and then it turns out that some real code can be simply ignored because of such a "stupid thing", then I'm not really surprised few people are motivated. * I, for once, am using Nim for just a few things. I could write some docs about using macros but I didn't even knew about formatFloat because... I've never used it. I think the authors of respective pieces of code are the best people to write docs as... they just know what these things do and why they decided them to do so. Also, if the docs are updated simultaneously with the code, they're always up-to-date. Then, some other people can improve the docs and, thanks to that, possibly improve the code too, as the docs help finding out the code's far from perfect. > Nim is a community project. Everybody that works on it, does so out of love > for the project. Telling us to "get on it" is unfair and rather ignorant. Then no surprise users have complains and may eventually switch to another language. Most of people don't like "shut up, I do it in my free time anyway". Or so I guess. @Araq Good to know. I haven't really tried generating comments yet as it's quite new (it wasn't there before I took a break from using Nim). Too bad it doesn't work for submodules. But I like renaming nim doc2 to nim doc. @mratsim > documentation is universally what most devs always put last That's bad news. But I like the idea of Nim Cookbook, that's for linking it.
Re: floating point output formating
>From a formatting point of view, please don't use the `code` syntax for bold, >it's painful to read. I think it's completely misplaced to criticize dom96 for not contributing to documentation, he took two years of his time to write an excellent book, make sure that his examples are useful and also that they still compile (which is not easy given the rate of development). And documentation is universally what most devs always put last, because there is always a new shiny thing, a bug to fix, deadline or just plain taking a breather and enjoy life. I don't think dom was saying that he found documenting too boring but he was explaining why the Nim community didn't contribute as you would like, you even say it yourself, "it's so primitive". Also there is an interesting [Nim cookbook project.](https://forum.nim-lang.org/t/3259). Regarding wikis, if it can be as awesome as [Arch wiki](https://wiki.archlinux.org/), that would be great, now some devs are even saying that [this is where information goes to die](https://dev.to/bytemybits/confluence-is-where-information-goes-to-die-25n). If people tell you "Add your solution to the wiki" after getting help on the forum will you do it? And PRs for doc doesn't even require you to clone Nim repo on your machine, you can just check that the example work on [https://play.nim-lang.org/](https://play.nim-lang.org/), I fail to see how hard it is for a developer. Last thing, I would really like you to stop with the passive-aggressive and entitled tone in your posts. While it's understandable to want something you like to improve and succeed, don't lash out within the Nim community, we all want to make it happen: you don't like docs, fine, build a library, blog, contribute to the cookbook/wiki in the thread I linked, add [Rosetta Stone](https://rosettacode.org/wiki/Category:Nim) examples.
Re: floating point output formating
@jzakiya: You seem like a proponent of constructive, positive criticism so I'll offer my own. In every conversation you have a choice to be cordial, even if you think the other side isn't doing you the same favor. When met with antagonism, perceived or real, you can escalate and attack back or try bridge misunderstandings. You always have the choice to be polite and take the higher road. It may go against instinct, but I think it leads to more peace (both internally and in the community).
Re: floating point output formating
@dom96 if you want people to voluntarily, out of their concern for the project, and goodness of their own `heart`, contribute to Nim, first you need to `check your attitude`, and learn how not to chase people away. [https://medium.freecodecamp.org/how-to-attract-new-contributors-to-your-open-source-project-46f8b791d787](https://medium.freecodecamp.org/how-to-attract-new-contributors-to-your-open-source-project-46f8b791d787) [https://www.itworld.com/article/2768358/open-source-tools/how-to-attract-more-people-to-your-open-source-project.html](https://www.itworld.com/article/2768358/open-source-tools/how-to-attract-more-people-to-your-open-source-project.html) Writing better documentation has very little to do with how much money or people a project has. Like I (and all these links I've been providing) said `it's an ATTITUDE`. You took whatever time you took, with whatever resources you had, to create the documentation that exists now. Well, take at least the same time and resources to make them better, and stop making excuses. The most relevant thing you said was you think writing documentation is `boring`, and it shows! Instead of telling me what I should/could do you should do it yourself. `It ain't my project and I have no responsibility to make it better`. The fact that I (and others) take time to inform you all about errors and deficiencies in your project (and you've made it clear this isn't an `our` project) should be seen as a `gift`. You know, you can do what @bluenote has done and try to write some better, correct, and useful documentation. It's amazing how much you can accomplish if you just improved one function/page/module of documentation each day/week/month. And if you really, really, really want people to contribute to documentation don't require people to jump through the hoop of writing/submitting `pull requests`. I personally hate making pr's just for documentation, it so primitive. Instead, create a `wiki` (there's this little project called `wikipedia` you know), so people who are writers, or willing to write, can actually do documentation in a way that's more conducive to writing documentation versus code versioning. I know, I know, this would take too much `time and effort` to implement, and it's much easier taking `time and effort` to peruse the forums and tell people you won't take `time and effort` to create better documentation because its `too boring`.
Re: floating point output formating
> Would it be difficult to enamble doc tool to handle expanded macros? I love > generating docs in Rust's macros so I thought it would be really nice when > you have repetitive routines as I could use a macro and the user still have > nice docs for each routine independently. `nim doc2` does expand macros. (Soon to be renamed into `nim doc`.)
Re: floating point output formating
> BTW, could anyone direct me to how index is built/generated ? I hope it is > not manual work. I have something in mind I wish to explore. `koch docs` builds the documentation. The index is eventually generated by a command like nim buildIndex -o:html/theindex.html destPath Where `destPath` contains the `.idx` files.
Re: floating point output formating
@jzakiya I have read a lot in this post, but due to my own lack of time I decided to skip most of it (so apologies if somebody mentioned this already). Why doesn't Nim have better docs? Some reasons: * Nim doesn't have full-time employees working on it (this is also why telling us "you should get on it" doesn't achieve anything) * Nim isn't v1 yet, so creating docs is difficult (because things change constantly) * Doc writing is boring Nim is a community project. Everybody that works on it, does so out of love for the project. Telling us to "get on it" is unfair and rather ignorant. To help illustrate my point better: you mentioned Nim by Example and Rust by Example. Both are community driven projects. Check out the people that helped create these projects: * [https://github.com/rust-lang/rust-by-example/graphs/contributors](https://github.com/rust-lang/rust-by-example/graphs/contributors) * [https://github.com/flaviut/nim-by-example/graphs/contributors](https://github.com/flaviut/nim-by-example/graphs/contributors) If you want to help improve them then make a PR. Creating documentation PRs is the easiest thing in the world (but also the most boring, which is why people rarely do it). So, what's your excuse? In the time that you've written these posts you could have gone in and fixed the problems instead of talking about them. If you don't know where to find things, then ask, I'll happily guide you.
Re: floating point output formating
Well, it certainly helps a lot when you find some code which uses some cool routines you know nothing about. It helped me with pegs that way if I recall. Although I must admit that I've already assumed it was something similar to regexes as ~= was used and Perl also uses it.
Re: floating point output formating
"the index" is good to have but it is helpful **only** if you already know what you're searching for. Otherwise if you dont have any clue about what you are searching, **how** certain things are done in Nim, It is only a huge pile of unorganized identifiers. BTW, could anyone direct me to how index is built/generated ? I hope it is not manual work. I have something in mind I wish to explore.
Re: floating point output formating
Wow, I see most of you guys don't like the index & library list as much as I do. They're not bad, in my opinion. @bluenote Dependency avoidance... Well... It wouldn't be a real problem if dependencies were solved automagically (see: Rust). ^^" Btw. that's a hell of a nasty line you quoted! Adding spaces in a for loop? It's horrible! You actually convinced me to look for a Rust string interpolation lib. Or create a procedural macro for that, if it doesn't exist yet. @mikra I had some problems with Slice and Range too, actually. ^^" More so with why static didn't work as expected (it's much better now though) despite working in the examples. Simple examples, I'd add. About the easiest build system --- try Rust. It's even easier. And Scala has a build system quite similar to Nim. Hell, even Fortran has it's build system (FoBoS), which is roughly as advanced as Nim's one so I guess it's not that huge an advantage, actually. It's just... modern. Actually, as much as I hate Java, I need to admit it's a good example of nice docs. Glad you brought it up. @all Well, I had a break using Nim. What really puzzled me that recommended project structure actually changed without me noticing it in the docs. I've only noticed when I saw it in some new projects and then looked for it very carefully. This is not the case for, let's say, Rust or Scala --- project hierarchy is a valid part of their respective manuals. @Araq Speaking about documentation... As you've probably noticed by know, I love metaprogramming. Would it be difficult to enamble doc tool to handle expanded macros? I love generating docs in Rust's macros so I thought it would be really nice when you have repetitive routines as I could use a macro and the user still have nice docs for each routine independently. @jzakiya Well... I'd say you're not the first one to make Araq get mad despite doing the right thing (see the blog post mentioning slice views). Just get used to it and do your thing.
Re: floating point output formating
**Araq you need to chill out!** I took the time to document for you unexpected, deficient, and incorrect behavior of your documentation and you are not even `humble` enough to thank me for it. So why should I bother to keep using your `work in progress` language that you can't even take `positive critical feedback` to improve?
Re: floating point output formating
How much more will be revealed once you know about [https://play.nim-lang.org/?gist=3e9b43b91d956366d8e5ff1a13e1efc6](https://play.nim-lang.org/?gist=3e9b43b91d956366d8e5ff1a13e1efc6) Btw thanks for never answering my questions.
Re: floating point output formating
Upon thinking about it, I think the case for `echo num.formatFloat(ffDecimial,
0)` is incorrect, and should be changed to be consistent with the intent of the
function.
The `0` option should produce a value (currently it would be `rounded`) with no
digits displayed.
`echo (10.456).formatFloat(ffDecimal, 0) -> 10`
`echo (10.556).formatFloat(ffDecimal, 0) -> 11`
Also, its current behavior is redundant, as it mimics the behavior of `echo
num.formatFloat()`. Thus, currently there is no way to use this function to
display no ('0') digits, which is inconsistent (and undocumented) with what a
user would expect of its behavior.
import strutils
let num = 10.5678
echo num.formatFloat()
echo num.formatFloat(ffDecimal, 0)
These revelations about how this one little function actually works, have all
been illuminated because of the effort we've engaged in to document it. How
much more will be revealed about all the other parts of the language once you
begin creating `full case tested` documentation?
Re: floating point output formating
@bluenote, also for `formatFloat`, it should also explain that it seems to using `rounding` of the digits its displays and not truncation. If a user wants to just truncate the displayed digits what function does that, or can this one perform that too. It may be an option to include into this function (and other ones where relevant). let num = 5.1273456 echo num.formatFloat(ffDecimal,1) echo num.formatFloat(ffDecimal,2) echo num.formatFloat(ffDecimal,3) echo num.formatFloat(ffDecimal,4) echo num.formatFloat(ffDecimal,5) echo num.formatFloat(ffDecimal,6) echo num.formatFloat(ffDecimal,7) echo num.formatFloat(ffDecimal,8) This is why you have to have thorough test structures in order to provide `good and accurate human usable` documentation. What you have there now, though technically accurate, doesn't tell the whole story of how the function behaves, and what then should a user do if they want to do `decimal truncation`. It should be explicitly stated it performs `rounding` of the digits before displaying. Is there a function that performs truncation? One significant added benefit of writing thorough tested documentation is, after you do it, you will `really` understand how the language `actually` works, and not just how you thought it did.
Re: floating point output formating
@bluenote I could kiss you! Now just do that for at least everything in that module and that will be a significant start, and benefit to all of us users.
Re: floating point output formating
@jzakiya: Do you think that is helpful: [https://github.com/nim-lang/Nim/pull/6704](https://github.com/nim-lang/Nim/pull/6704)
Re: floating point output formating
Hey guys, stop being defensive. If I didn't think Nim is a worthy project, and has great potential, I would have never bothered to take the time to tell you how to improve your project, and it would be in your interest to take comments as mine as `positive critical feedback`. As further `positive critical feedback` please read/study/learn from these sources (there are many, many more with simple internet searches). [https://opensource.com/business/15/5/write-better-docs](https://opensource.com/business/15/5/write-better-docs) [http://www.writethedocs.org/guide/writing/beginners-guide-to-docs](http://www.writethedocs.org/guide/writing/beginners-guide-to-docs)/ [http://blog.screensteps.com/10-examples-of-great-end-user-documentation](http://blog.screensteps.com/10-examples-of-great-end-user-documentation) [https://www.techrepublic.com/blog/10-things/10-things-you-can-do-to-create-better-documentation](https://www.techrepublic.com/blog/10-things/10-things-you-can-do-to-create-better-documentation)/ You can really demonstrate that you understand what I would like you to do if when I go back and look at the docs for `formatFloat`, and everything else on that page, there are use examples for each entry.
Re: floating point output formating
@jzakiya, you are right that Nim documentation could be improved. Especially theindex could be made more visible, like a link "Looking for a proc? Try theindex" on the website or the manual. If it exists it's probably not visible enough. Then, Nim has 2 core devs, and no one full-time on it. At one point you have to juggle between delivering features (and getting to the elusive 1.0), solving bugs, doing blog posts/PRs, doing documentation. Maybe getting more features or the 1.0 will bring more people to produce more documentation, or maybe documentation would bring more people who would help bring more features, it's probably both, but there are more people that can add to the doc (see the cookbook project) than people that can debug/add features. Last thing, when you're breating something day in, day out, you forget what it's like to begin. I think people just out of the beginner phase know best about what they struggled with when they started.
Re: floating point output formating
Jzakiya, you are absolutely right when you say > the only limits of what you can provide in documentation are self imposed and I also agree that, in general, there is a lot of space to improve nim documentation since there are lots of parts that are undocumented in practice (or at least assume the reader already knows the subject), nimscript is just an example. I may guess this is just the result of the fact the there is no company with eight-digits revenues backing nim development, it's far easier to find someone who codes for fun than someone who writes documentation when is not paid for it. That said, when I pointed you to the doc of formatFloat proc you posted a this two liner program let num = 10.123456789 echo( formatFloat(num) ) to which the compiler yells > in.nim(3, 7) Error: undeclared identifier: 'formatFloat' which has nothing to do with the usage of the formatFloat proc, it is instead a problem with nim module system which is part of the very basics of the language, which is documented (I will not push myself to say "well-documented", but still it is documented) in nim's [manual](https://nim-lang.org/docs/manual.html), a document I strongly advise you to carefully read. You say you're used to Ruby, which also has a module system, I can't believe that a message like 'undeclared identifier' didn't get you to think that you missed a dependency. I don't know anything of Rust, if I wanted to start using it I would first read the documentation or at least some tutorial about the language, I would not write System.out.printf << 'hello world' and then rush to the forum asking why it does not compile
Re: floating point output formating
Hi all, my humble 2ct to the docu topic: it took me also 1hr to find out what a Slice is and how it`s constructed and especially whats the difference between Slice and range (I think range is compiler built in). One example would be very nice. @jzakiya you can also use printf native in Nim (I personally hate that because I did mostly embedded and nobody likes that there . that a string is implemented as a sequence told me g**gle. The coolest thing I recently discovered is that you can do a manual allocMem and let the gc do the dealloc (burried within this forum by an example of mratsim) The docu is good (especially the FFI and Compiler User Guide); but the information is sometimes really scattered (some examples are in the manual, some inside the module (stdlib), some reside within the tutorial). At least I found me browsing the sourcecode. The bugtracker in Git is also very good (if you need special information how something exotic was solved) But for someone who comes from a interpreted language it´s hard and I agree it´s a little bit time consuming. At least for everything (if you use the C/Cpp backend) the cpp reference is your friend ( [http://en.cppreference.com/w](http://en.cppreference.com/w)/ ). I know it´s very difficult to write good documentation especially for a language which has the power of nim (the best and easiest to use build system I ever worked with) no hazzle with cmake, make (magic folder naming rules; somethimes the build has more (crappy) complexity than the project itself), gcc and so on). There are so much topics to cover and nobody knows everything. It's also very hard to keep the docu up to date. The docu from java was very good (especially pre 1.0) and there is/was least one example for everything. Especially for a nim-noob like me (as a absolutely noob you have sometimes a unobstructed view) it would be nice to get into by helping with the documentation. But for me (and I think others, too) it´s not very clear how to contribute (a howto would be very nice). Some docu (I think the manual) is inside the doc folder (rst, but how do you run the generator?), there is also a example folder and the other stuff is within the sourcecode generated with nim doc... so really scattered (and at the beginning very confusing). And I sometimes found me also within the situation that I skipped over something important within the documentation :->
Re: floating point output formating
@Udiknedormin I strongly think it should be part of the language. Developers fear dependencies[*], so people will continue to use workarounds instead of using string interpolation via an external dependency. Also, the Nim core itself could benefit from it in some places ([random example](https://github.com/nim-lang/Nim/blob/87a46765eee6601ccc53b2c38d1c8f3a9b045124/lib/system/nimscript.nim#L285) or every line with more ~5+ concatenating `&` and the notorious opening and closing `"`). Sometimes I don't embed helpful information in my exception strings, because typing out the manual concatenation is tedious (and I don't want to add a dependence for just 1 line of code), whereas in e.g. Scala I would, because it is so easy (`f"Error: blah blah because x = $x and y = $y while running in mode '$mode'"` if I counted correctly that would take 6 `&` and 8 `"` in Nim). It's a general pattern that in languages where string interpolation is included, developers tend to produce higher quality output strings on average compared to languages where there is a larger barrier for achieving the same. [*] I'm an author of one of the string interpolation libs out there, but I've never dared to use it in my other libraries because of dependency avoidance
Re: floating point output formating
I will just quote myself again: > At this point you need to be able to read Nim's type signatures. More > examples for this proc would be nice indeed (!!!) but I don't see how they > would have helped you in finding the proc in the first place. There were some hidden questions for you, you might want to answer them instead of writing pretty offensive pamphlets about my attitude. * Did you know about `theindex`? If so, how come it didn't help? Overwhelming? If not, how can we make you aware of it? * OR: Did you find `formatFloat` and ignored it because it was missing examples? "Just write a better nim-by-example" is not as helpful as advice because it's pretty vague.
Re: floating point output formating
Actually, `the only limits of what you can provide in documentation are self imposed`. `Writing documentation is an attitude!` Either you care about doing it (to benefit/help users) or you don't. Nim has to compete against lots of other languages, and like cars, smartphones, etc, having the better/best technology doesn't mean you will have the biggest following. People will ultimately use first the things that are accessible, easy to use, and cheap (why do Americans eat so much bad fastfood - because its cheap, the stores are everywhere, and they stay open late when people are hungry). Your own 2017 Survey specifically lists lack of documentation as one of the biggest deficiencies of this project, but I don't see an active effort to make it better. [https://nim-lang.org/blog/2017/10/01/community-survey-results-2017.html](https://nim-lang.org/blog/2017/10/01/community-survey-results-2017.html) Let's compare Nim against Rust, two languages promoting themselves as `system` programming languages. Rust is by far a much harder to learn/use language than Nim, but it knows that, and has created very good documentation (and forum) to help people get their heads `(and hearts)` around it. Both Nim and Rust have a document called `[Nim|Rust] by Example`, but tell me which is more helpful/useful to potential users. Let's compare their presentation of `arrays` in each document. Nim: [https://nim-by-example.github.io/arrays](https://nim-by-example.github.io/arrays)/ Rust: [https://rustbyexample.com/primitives/array.html](https://rustbyexample.com/primitives/array.html) As `a potential user` I get a much clearer understanding of how to create, access, and print arrays from Rust's docs, with examples for each use case given. Now let's take a look at Ruby's: [https://www.ruby-lang.org/en/documentation](https://www.ruby-lang.org/en/documentation)/ Granted, Ruby has been around a lot longer than Nim, and has loads of books, videos, and conferences, but it all starts with an `attitude` of the Ruby community, which is probably `The Most Friendly` language community in the world. You can find just about anything you want on this page about how to use Ruby, and this is by design. They didn't limit what they could do. And here's what I mean by `attitude` for this specific instance of trying to find out about outputting floating points. I took about three hours, searching the docs and internet, trying to find out how to print out floats to a given precision, and gave up after being frustrated (fed up). Only then did I resort to asking help in the forums. It was first answered by only providing a link to a cryptic (my impression of it) function, which had no examples of how to use it. I had to ask, again, how to use it, and was finally given a specific example of how. And then when I point out none of those functions on that page (and elsewhere) have specific use case examples, instead of saying, "you're right, we'll get on it", you give excuses (there are limits to what we can do). If I were you all, I'd start immediately upgrading your docs, first by formatting the categories from the point of view of helping potential users (Input/Outputting Data, How to use Files, etc) with clear/concise/helpful use case examples. You can start by copying `best practices` used in other projects docs. Would this take a lot of work and effort -- `Hell Yes!`. But you all need to really understand, you are not only in a battle to win peoples minds, to get them to understand your language, you're also competing to win (and keep) their `hearts`, so they `want` to use your language. People can criticize Ruby all they want, but people who use Ruby, and go to its conferences, do so because they `love it`, even when they move on to other languages (like Elixir). Actually, this specific discussion should have its own thread, so others can chime in, and not be buried at the end of this thread. But please take `to heart` this old saying: `You only have one chance to make a first impression.`
Re: floating point output formating
> The Docs really need to get better by showing clear examples like this for > just about everything. It took way too long for me to search and not even > find this, and had to resort to asking how to do this here. When I go to [https://nim-lang.org/docs/theindex.html](https://nim-lang.org/docs/theindex.html) and search for "format" there are too many hits but eventually I arrive at "formatFloat". When I search for "formatFloat" I find what is suggested here, if I search for "floatformat" I get a hit to FloatFormatMode pointing me to strutils which contains "formatFloat". The docs say proc formatFloat(f: float; format: FloatFormatMode = ffDefault; precision: range[0 .. 32] = 16; decimalSep = '.'): string At this point you need to be able to read Nim's type signatures. More examples for this proc would be nice indeed but I don't see how they would have helped you in finding the proc in the first place. > just about everything We have `theindex.html` that contains links to just about everything. It didn't seem to have helped you. As I keep saying, there are limits to what we can do about the fact that people do not read text on the screen. I just did the same for Python: Starting at [https://docs.python.org/3](https://docs.python.org/3)/ I go to [https://docs.python.org/3/genindex.html](https://docs.python.org/3/genindex.html) then to [https://docs.python.org/3/genindex-F.html](https://docs.python.org/3/genindex-F.html) then to [https://docs.python.org/3/library/functions.html#format](https://docs.python.org/3/library/functions.html#format) and I arrive [https://docs.python.org/3/library/string.html#formatspec](https://docs.python.org/3/library/string.html#formatspec) which keeps me puzzled.
Re: floating point output formating
@bluenote
Correct me if I'm wrong but wasn't string interpolation ("borrowed" from Swift)
already done long time ago? Can't it stay library-provided? It's not like every
language has it in the core.
Re: floating point output formating
RFC: if strutils has `toBin()`, `toHex()`, `toOctal()`, `intToStr()` and from system.nim, the `$` operator is described as `The stringify operator for an integer argument. Returns x converted to a decimal string. $ is Nim's general way of spelling toString.` why not add a helper proc to strutils as proc toString(f: SomeReal, prec: int = 8): string = result = f.formatFloat(ffDecimal, prec)
Re: floating point output formating
Thanks a whole lot! The Docs really need to get better by showing clear examples like this for just about everything. It took way too long for me to search and not even find this, and had to resort to asking how to do this here. I also agree the semantics for doing this has to become a lot shorter/simpler/clearer. I don't mean to go off, but outputting is such a standard thing to do in any language it should be readily available in the Docs to show users how to deal with the various cases. Thanks again.
Re: floating point output formating
import strutils let num = 10.123456789 echo num.formatFloat(ffDecimal, 4)
Re: floating point output formating
let num = 10.123456789 echo( formatFloat(num) ) Could I get a little help here to make this work.
Re: floating point output formating
And hopefully we will soon have string interpolation in Nim ([PR](https://github.com/nim-lang/Nim/pull/6507)). Then it would be something like this (or similar, language is still in discussion): echo "$x%.4f"
Re: floating point output formating
read [here](https://nim-lang.org/docs/strutils.html#formatFloat,float,FloatFormatMode,range\[\],Char)
floating point output formating
I compute a floating point number `x`. How do I use `echo|write.stdout` to output it with just 4 decimal digits showing?
