http://stackoverflow.com/questions/19783030/in-julia-why-is-printf-a-macro-instead-of-a-function
On Tuesday, September 22, 2015 at 4:20:41 PM UTC+2, Tom Breloff wrote: > > Chill guys. > > Anyways... I started to tackle this problem, but didn't get any (much > needed) comments on whether I was on the right track. Here's some sample > preliminary usage of what I was working on. Please let me know if you > think it's worth continuing, and what you'd ideally like to see in a > formatter. > > https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl > > On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera <dcar...@gmail.com > <javascript:>> wrote: > >> Coding sprintf() is beyond my skill, I tried. My contributions to Julia >> have to lie elsewhere (recently I've been putting a lot of time making >> mockups of a Julia IDE, and helping a new user port his Matlab code). I >> think it is rude to say "if you don't like it, fix it yourself"; especially >> after you wrote a post claiming that the non-implementation of sprintf() >> was an intentional omission because developers weren't sure how to do it >> right. I showed, correctly, that that argument is nonsense; so you spinned >> around and changed it to "if you don't like it, fix it yourself". That >> answer is only a way to reject valid complaints, and it feels like a thinly >> veiled "fuck you". Imagine if that's how people responded in bug reports. >> This is not the type of answer that Julia developers normally give, and it >> is not the type of answer that I expect in Julia; especially after giving a >> very different answer to the same question. I do try to contribute to >> Julia, and it is rude and unreasonable to hold me personally responsible >> for fixing everything that does not work in Julia. A healthy community >> needs room for receiving legitimate complaints. >> >> Daniel. >> >> On 22 September 2015 at 15:49, Tomas Lycken <tomas....@gmail.com >> <javascript:>> wrote: >> >>> > If C can have one, why can't Julia? >>> >>> *The hard truth, and nothing but it:* If Julia is missing a feature, or >>> has one that works in a way that's not the way you want, it's because >>> no-one has wanted what you want enough to actually implement it. >>> >>> That's it. There's no "it can't be done" - Julia is Turing complete, so >>> "everything" can be done. There's no "it's not allowed" - no-one is >>> stopping you from writing your own package, with your own implementation >>> that does what you want the way you want it done, putting it in the package >>> repository and seeing it take off. Chances are that if you write something >>> that it turns out many others want as well, it will be included in the >>> default package distribution in the future (or even in base Julia). Or it >>> might not take off, but at least be there for your own enjoyment. >>> >>> But the entire language, with all tooling, packages, etc - everything >>> that is Julia - is very much a community-built product. Everything that is >>> there, is there because someone at some point said *hey, this is so >>> important to me that I'm going to put it at the very top of my priority >>> list*. Creating a sprintf function that fulfills your needs might not >>> have made it there for anyone yet. If it's that important to you, maybe >>> that's your next contribution? >>> >>> // T >>> >>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote: >>>> >>>> I might be wrong, but to me Formatting.jl looks next to useless. The >>>> "sprintf" functions it provides only accept one parameter. The main >>>> function provided is `sprintf1()`, but even the very clumsy >>>> `generate_formatter()` function fails at the most basic tasks: >>>> >>>> julia> fmtrfunc = generate_formatter( "%10.3f %6d %3d" ) >>>> ERROR: Only one AND undecorated format string is allowed >>>> in generate_formatter at >>>> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23 >>>> >>>> >>>> I really don't understand why sprintf() is such a big deal. If C can >>>> have one, why can't Julia? I understand the argument that you might want >>>> to >>>> rewrite the implementation later. Fine. Just call the function >>>> "__temp_sprintf()" and put it in a package called >>>> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to >>>> print formatted strings without a ton of needless hassle. >>>> >>>> >>>> >>>> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote: >>>>> >>>>> By the way, you might also note that the Formatting.jl package is >>>>> written and maintained by people who are all active contributors to the >>>>> main language repo, and very active members of the community. Even if >>>>> it's >>>>> "external" in terms of how you install it, it's by no means external "in >>>>> spirit". >>>>> >>>>> // T >>>>> >>>>> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken >>>>> wrote: >>>>>> >>>>>> Julia is a young language. >>>>>> >>>>>> This comes with a lot of benefits - for example, it's possible to do >>>>>> things *right* from the start. We're currently in a phase where there is >>>>>> a >>>>>> multitude of possible solutions to every problem that arises, and we >>>>>> honestly don't know which solution proves to be the best one. Testing >>>>>> various solutions out in packages, outside of the base distribution, >>>>>> where >>>>>> they can compete for popularity, and keep building on top of each-other >>>>>> until we reach something which we believe not only is adequate, but >>>>>> *really* hits the sweet spot. In other words: sure, formatting numeric >>>>>> output is fundamental, but it's a problem with a large solution space, >>>>>> and >>>>>> we don't want to lock in on one path yet. >>>>>> >>>>>> But Julia's young age also means that there are lots of problems that >>>>>> aren't really solved yet, or that have solutions proposed but not >>>>>> implemented, etc. For the future, there are plans to include some >>>>>> packages >>>>>> (which ones have not been decided, or AFAIK really even discussed) in a >>>>>> sort-of "base distribution", so they will be installed upon installation >>>>>> of >>>>>> Julia, and available with a single `using` statement. But the >>>>>> infrastructure for this is not in place yet, and even if it were, there >>>>>> would still be lots of reasons not to make a final decision on which >>>>>> packages make the cut until we approach a 1.0 release of the language. >>>>>> >>>>>> So yeah, it might seem silly to have to install a package just to get >>>>>> fine-grained control of numeric output formatting, but, at least for >>>>>> now, >>>>>> that's part of what one could call Julia's "Package Deal" ;) >>>>>> >>>>>> // T >>>>>> >>>>>> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti >>>>>> wrote: >>>>>>> >>>>>>> Thanks, that seems to work. >>>>>>> Still it amazes me how Julia, being a language made for numerical >>>>>>> calculations, does not natively support a simple mechanism to >>>>>>> print/write >>>>>>> large bunches of numbers. I've been in the numerical world for 20+ >>>>>>> years and I know printing lots of numbers is something you get on a >>>>>>> daily >>>>>>> basis. I know now the formatting package can help on that (thanks >>>>>>> :), what I do not like is the idea of having to install every time a >>>>>>> new >>>>>>> package >>>>>>> to get added functionality. I understand there are things that have >>>>>>> to go to external packages because of its limited or specialized use, >>>>>>> but >>>>>>> come on... printing number os definitely not one of those. >>>>>>> Just my 2cents :) >>>>>>> >>>>>>> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly >>>>>>> wrote: >>>>>>>> >>>>>>>> https://github.com/JuliaLang/Formatting.jl might help. >>>>>>>> >>>>>>>> — Mike >>>>>>>> >>>>>>>> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote: >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I could use some help here, because I can't believe I'm not able >>>>>>>>> to easily print formatted numbers under Julia in a easy way. What I >>>>>>>>> try to >>>>>>>>> do is to write a function that, given a vector, prints all its >>>>>>>>> components >>>>>>>>> with a user-defined format. I was trying something of the form >>>>>>>>> >>>>>>>>> function Print_Vec(aux_VEC,form_VEC) >>>>>>>>> form_VEC :: ASCIIString >>>>>>>>> str_VEC = "%16.8f" >>>>>>>>> for elem_VEC in aux_VEC >>>>>>>>> str_VEC += @sprintf(form_VEC,elem_VEC) >>>>>>>>> end >>>>>>>>> return str_VEC >>>>>>>>> end >>>>>>>>> >>>>>>>>> However, that doesn't work because it looks like the first >>>>>>>>> argument in @sprintf must be a explicit string, and not a variable. >>>>>>>>> Is there anything I can do with that? >>>>>>>>> >>>>>>>>> Thanks a lot for your help. >>>>>>>>> >>>>>>>> >> >