Specifying log with arbitrary base

[goyalyashpal]

• with reference to the documentation for supported attributes for scale at https://docs.juliaplots.org/latest/generated/supported/#Scales
• the scales of log with common base : ln , log10 , log2 are listed in there (the default gr backend doesnt support base 2, e as can be seen in the attached image)
• if the approach was allowing general base for log scales, then that would allow for much for flexibility while filling in the current void of capabilities

e.g. from python : matplotlib.pyplot :

plt.semilogy( y, base = 2 )

Originally posted by @yashpalgoyal1304 in #74 (comment)

[mkborregaard]

The implementation reason for this is that the scale argument to Plots may be many different things, not just a log scale.
More to the point, though, what would be the use case for this? Log scale of all integer bases are all the same transformation in terms of relative point positions, so it's just a question what to put on the tick marks.

"the current void of capabilities" is maybe a bit dramatic :-D

[goyalyashpal]

scale argument to Plots may be many different things, not just a log scale

i know, i have even already attached the screenshot of it. but there has to be some way to specify the base in case of log, or say power in case of extension of sqrt (if that ever comes on the plan lol)

it's just a question what to put on the tick marks

tick marks and grid - yeah, so, how can i do that?

"the current void of capabilities" is maybe a bit dramatic :-D

yeah, i agree 😅 , but it is kinda essential for analysis - like say, u are dealing with something where the output which come to say powers of 7 is important. so, keeping track of that (i.e. both the tick marks and grid) becomes essential

[t-bltg]

but it is kinda essential for analysis - like say, u are dealing with something where the output which come to say powers of 7 is important. so, keeping track of that

If you known your maths, you should be able to transform your data before plotting.
It would be difficult to support other / arbitrary scales for all backends, without increasing code complexity, and for little gain.

the scales of log with common base : ln , log10 , log2 are listed in there (the default gr backend doesnt support base 2, e as can be seen in the attached image

As you pointed out scaling is (most of the time) a feature of a specific backend (lower level than Plots.jl), so this mean we probably can't do anything here in the intermediate / high level Plots layer. If it is missing in gr, I'd say it should be requested in gr, not Plots.

[goyalyashpal]

If you known your maths, you should be able to transform your data before plotting.

that's not a good suggestion at all... going by that, even the log scaling can be done before plotting, but the option to plot on log scale/log graph exist and that's for a reason... but anyways, thanks for the input.

[t-bltg]

Yes, this is to say that log scaling is a convenience provided by Plots, not a necessity. Sorry, maybe the wording was too harsh, but I wanted to point out that nothing prevented you from transforming your data before plotting, achieving the end result.

[goyalyashpal]

just for the records, the problem with that approach is that log scaling doesnt work directly/inline with 2D arrays (i.e. when an array has multiple "series" to be plotted) whereas with scaling it works direct:

# Doesn't work on whole list, works only per index
plot( log.( list[ i ] ) )

plot( list, scale = :log )

[goyalyashpal]

how about `log( base = x )` **for Fun only:** & similarly, maybe for future: `pow( val = x , inverse = true )` 😆😆

[goyalyashpal]

aah, this is painful - what happened 5 days ago, this is third instance of some old email resent "5 days ago"

please help me in this misterious auto resending of emails