-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to specify fixed width floats in specific tagged-literals for output purposes #83
Comments
I think there are three separate issues wrapped up in here.
There are two ugly workarounds for your immediate needs:
We delegate to Clojure here and - unfortunately - Clojure's print-method for numbers (modified above) does not provide a parameter for controlling this. I'd be open to providing an option for this, but I'm hesitant because duplicating an underlying print method for a primitive decouples us from future changes. For instance, when
No. An intentional design feature of the EDN conversion is that it is formatting-agnostic. In theory, a custom type could be used to pass through formatting hints, but I haven't seen a good reason to do so yet.
Maybe? I'd have to think about the implications of that. My gut reaction is to say no unless additional use cases are understood.
That's the less hacky workaround: Simply copy/paste this part of the implementation and modify as necessary. It's small enough to be a low maintenance burden. -- In summary, let me know if one of the workarounds works for you. If number formatting control is important, we can survey/lobby other printers and Clojure itself in case it makes sense to add a clojure.core/number-precision or similar. |
Oh, the Thanks for pointing out the print-method override approach, but I think I want scoped control over the precision of output and not a global change. It's a useful override if the floating point values are coordinates in a vector, but less useful if they represent something else. That said, I guess it's also possible to override the display of all floating point numbers using a custom Thanks for all the help, I'm trying to think how this could be better documented, but this discussion might be sufficient for now. I'll play around with the symbol and custom |
I've been working with debugging larger datastructures containing many instances of the shape and vector objects from https://github.com/thi-ng/geom. I've found fipp to be very useful for ensuring the debug output is readable, so thank you.
However, I've also found it useful to simplify the output by doing tricks like:
So that instead of verbose output like
It's simplified to
However,
.toFixed
is converting the output element type to string too early, so the visitor pass detects it as a string and instead it prints like:I've succeeded in getting output without the string by rounding each of the x,y coordinate values to two decimal places, keeping them a number, but that occasionally expands back to the max width for each coordinate due to floating point representation errors.
So my question is, is there a way to control formatting by passing through a fixed float, or is this simply behavior that is out of the scope of this library?
Is there a way to pass through formatting instructions during the EDN conversion prior to visiting each element? Or is this attempting to do the transformation in the wrong place, and instead should look into something akin to fipp.clojure to adjust formatting in the output. However based on
fipp/src/fipp/edn.cljc
Lines 55 to 58 in a4cb207
It looks like the pretty symbols override only works for
'(symbol a b c)
forms, but there does not appear to be equivalent functionality for overriding tagged-literals infipp/src/fipp/edn.cljc
Lines 71 to 76 in a4cb207
:symbols
, such as:tagged-literals
that supported overriding the printer visitor for each tagged literal? Should I look into writing my ownEdnPrinter
with this functionality?Happy to work on a PR if there is a recommended approach or even just to document this behavior, but am uncertain which way is intended. Thanks again for creating such a useful pretty printer interface.
The text was updated successfully, but these errors were encountered: