<linext>
i kind of want to dig into a GLB file and see how it compares with other formats
<linext>
hmmm... it opens in Windows 10 3D viewer
LordOfBikes has quit [Ping timeout: 268 seconds]
<peepsalot>
do we ever want to output negative zero in echo,ast dump,csg dump,etc?
<InPhase>
I don't think so.
<InPhase>
This value has no relevance to 3D modeling.
<peepsalot>
ok, with current behavior it sometimes ends up in multmatrix. but it is stripped from eg echos
<peepsalot>
so my changes will remove it from .csg values
LordOfBikes has joined #openscad
<InPhase>
I don't think it is harmful in multmatrix, as it would impact only certain questions of caching if two "identical" things were calculated in different ways, which would be a weird thing to expect to work in floats anyway. But it would be cleaner without it.
<InPhase>
Well, before and after are both wrong if the goal is really "to shortest"
<InPhase>
ECHO: 160000 This for example is unchanged. 1.6e5 is 1 less character, and an equivalent value.
<InPhase>
"0.000016" also could be "1.6e-5" for 2 fewer characters.
<InPhase>
Also unchanged there.
<peepsalot>
right, so i would have to raise the -6 lower end for that
<InPhase>
Nope.
<InPhase>
Because then it would fail on the ones that have more digits. These are just inadequate test cases by themselves.
<InPhase>
You also need 0.00001234567890123456
<InPhase>
Okay, that one I think is still shorter as an exponential.
<peepsalot>
that specific test case is actually kind of made obsolete by this change. that was for testing our own functions of trimming trailing zeros which supplemented double-conversion's ToPrecision
<peepsalot>
but it still serves as a reassonable example of some of the output differences
<InPhase>
You could reason out the full logic of this, but really the simplest solution that guarantees the right answer is to generate both and take the shortest. :)
<InPhase>
If shortest is REALLY the goal, then it always depends on the digits produced.
<InPhase>
Or at least for positive exponent values.
<peepsalot>
i think "user-friendliness" is the reason for these exponents existing
<InPhase>
For negative exponents it might be strictly a threshold question.
<InPhase>
I endorse user friendliness as a valued goal for number representation over shortest representation. But in this case, rename the function. :)
<peepsalot>
so it doesn't have to be 100% optimal shortest in my opinion.
califax has quit [Ping timeout: 258 seconds]
<InPhase>
Functions should do what it says on the tin. But this one could just be to our definition of best representation, and that's totally fair.
califax has joined #openscad
<InPhase>
DoubleToStr would be a fair enough name.
<InPhase>
Beyond a million it gets hard to visually parse.
<InPhase>
Or well, at 10 million.
<InPhase>
I'm pretty good at numbers, but my 0 parsing starts to get wonky and slowed down as soon as there are 8 total digits. So 6 is a fair threshold for user friendliness I think.
<InPhase>
I can handle the same 6 placeholder digits on values under 1, because to me it's a visual parse processing speed thing. But it might be the case that other people are more uncomfortable with the very small numbers.
<peepsalot>
here is what -6 does currently: ECHO: ["1", "0.1", "0.01", "0.001", "0.0001", "0.00001", "0.000001", "1e-7", "1e-8"]
<InPhase>
So if I were tuning to me, I'd probably use the same threshold for negatives.
<peepsalot>
i think it could stand to go to -4 personally
<InPhase>
But I accept that others might like that a little tilted more toward negative exponents.
<InPhase>
I do like that 0.000001 limit myself. But maybe we need a slightly larger sample size of people.
<InPhase>
I can handle either, so I don't have strong feelings on it. :)
<InPhase>
I stipulate also that 0.000001 is pretty character inefficient.
<peepsalot>
current behavior acts more or less like -5
<peepsalot>
at least for this trivial example of 1 sigfig
<InPhase>
e-4 is the size turnaround where exponents are shorter.
<InPhase>
I believe it is consistent for negative exponents as long as there are at least 2 non-zero digits.
<JordanBrown[m]>
We need printf. I got it about 98% working with libfmt, but was defeated by trying to make OpenSCAD’s doubles work as the width and precision values.
<peepsalot>
InPhase: yeah i agree. i've removed it in the latest push, and set limits to -5,+6 for the minimal amount of change from existing behavior
<peepsalot>
with that, I think I'm done fiddling
<peepsalot>
or at least until further feedback
<InPhase>
A fair enough set of choices. The only feedback I'd give is that ToShortest is still named misleadingly, as it doesn't even try to do that.
<peepsalot>
well, tell that to google :P
ur5us has quit [Ping timeout: 250 seconds]
<InPhase>
That name is from google code?!
<InPhase>
I see it is... I missed that part of the explanation.
<InPhase>
That's... unfortunate.
<JordanBrown[m]>
InPhase I don’t remember the details, but it wasn’t that kind of problem. It was a problem with getting the data types right.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<JordanBrown[m]>
I was trying to feed an array of Value to a generic printf formatted. It was flexible enough to let that work for the data values, but not for the width and precision parameters. Or at least not with my limited knowledge of C++.
<peepsalot>
JordanBrown[m]: i just replied to your email from a couple days ago. but in case you haven't been following, the PR i have been working on is related to the cache precision issue mentioned there
<peepsalot>
had to look them up, can never remember those function names/signatures
<JordanBrown[m]>
Yep.
<JordanBrown[m]>
But yes less applicable.
<JordanBrown[m]>
I need to go back to trying to sleep. I’m out of gas but haven’t been able to get to sleep.
<peepsalot>
doh, looks like different platforms differ on last significant digit or so
fling has joined #openscad
<peepsalot>
iirc our python test scripts had some number-fudging code during comparison to compensate for issues like that, and I think I disabled it when I switched to double-conversion. might need to add that back in
ur5us has joined #openscad
<InPhase>
peepsalot: On platform differences, fesetround maybe?
<InPhase>
peepsalot: I'm not sure if they are actually different, but it's conceivable.
<peepsalot>
CGAL requires some specific rounding setting itself
<peepsalot>
or, i thought it did. we set "-frounding-math" for GNU compiler, but don't see anything for other platforms
<J1A84>
but when you cut the 3 wire i would assume the led driver is also cut away .. never heard that the led itself has an current limiter .. maybe they used higher resistances within the leds
<teepee>
sure, they run at 5V with the data line, so the power control is on the chip
<J1A84>
the chip has 3× pwm but no limiter
<teepee>
there has to be something, otherwise a single one would burn out on 5V and there's no issues running them like that
<J1A84>
btw make sure to have a 470Ω resistor in the dataline .. else a contact issue can fry all chips
<teepee>
I mean the PWM is in the chip itself, you can push in set of colors and then just keep them running in that color without more data clocked in
<J1A84>
yo i have a led here that i hook on the rainbow controller and remove the data line when it hits the color i want .. Ü
<J1A84>
maybe if using a small coil for the data line - a wireless color setting kids toy can be build
<teepee>
yeah, with all the hot glue I'll probably take the risk
<teepee>
I'll probably do a better version with clip-in design if I have more time, maybe even a PCB instead of that perf board thingy
<teepee>
the one I'm using as night light still uses the esp8266 controller
<J1A84>
i run the all an ATTiny85 .. no need for wireless controller
<teepee>
I'll give you 5 attiny13 then :P
fling has quit [Remote host closed the connection]
<teepee>
driving a 5 pointed star with 20 leds charlieplexed each, I still love that thing, will be in the window in 2 month again :D
fling has joined #openscad
<J1A84>
with 5× μcontroller ? a shift register would be easier
<teepee>
boring :)
<J1A84>
oh 5 pins is enough for 20
<teepee>
now where is that video?
<teepee>
I have no idea which yt channel that is in
aiyion has quit [Ping timeout: 258 seconds]
<J1A84>
isn't the attiny13 bit slow
aiyion has joined #openscad
<J1A84>
oh also 20Mhz .. just less memory
<teepee>
yes, and reliably glitches at 4,5V into software that was uploaded before ;-)