Wolfram|Alpha time travel
-
Scenario: I'm encoding a 3½ hour video of an undisclosed but easily guessable subject matter. I want to know how much longer it will take, but my encoder only gives me:
- the total number of frames encoded
- the number of frames encoded in the last second
- various quality settings of the video
- the current size of the output file
- the current timestamp of the output file
- the current bitrate
- the number of frames duplicated or dropped
From this, I devise a simple formula:
Answers Wolfram|Alpha gives:
- 2 hours 56 minutes 31.74 seconds
- -2038 hours
- -7.335×106 seconds
- -122253 minutes
- -84 days 21 hours 33 minutes 12.2 seconds
- -84.9 days
- -12.13 weeks
- -0.2324 average Gregorian years
- ≈ -0.23 × orbital period of Earth (≈ 1 Julian year )
- ≈ -0.38 × orbital period of Venus (≈ 0.62 Julian years )
- ≈ -0.97 × orbital period of Mercury (≈ 0.24 Julian years )
- ≈ -0.044 × half-life of cobalt-60 ( 1.6635×108 s )
- ≈ -0.089 × half-life of sodium-22 ( 8.2108×107 s )
That's not Discoursistency™, that's actually a single positive answer followed by several negative answers. I'm going to assume the different answer is an anomaly.
This isn't a problem with mismatched units, as you can verify by removing hz from 50hz. Apparently my video has already finished encoding and I have to go back in time to find it.
-
3½ hour video of an undisclosed but easily guessable subject matter
Gay bestiality porn?
This isn't a problem with mismatched units, as you can verify by removing hz from 50hz.
It chokes on the multiple time units separated by spaces part, if you remove the x minutes and x seconds you get a (I assume) correct answer, if you add minutes again it chokes. I don't really know Wolfram, maybe it just doesn't accept this?
-
You can put + after hours and minutes and it works, but adding a unitless number to time2 and then dividing by time-1 shouldn't give me a wildly incorrect answer in time1. It should either give me an error or a technically correct answer in time3.
-
but adding a unitless number to time2 and then dividing by time-1 shouldn't give me a wildly incorrect answer in time1. It should either give me an error or a technically correct answer in time3.
Not to get all pedantic on you but ... Oh who am I kidding? You really have your units all B*****med up. Here's you original equation, units only:
(s)Hz - {no unit}
HzSince Hz is basically s-1, this can be simplified to:
(s)s-1 - {no unit}
s-1Which reduces to:
{no unit} - {no unit}
s-1So your finally result should be in terms of time1, as you put it. Where did you get all this crap about time2 and time3?
Edit: I see how you can get an intermediate step which contains time2 by bringing the bottom Hz up top, but that doesn't fit with your previous post, so I chose to ignore that route. In case someone else chooses to call me on this, here it is:
((s)s-1 - {no unit})s
(s2)s-1-s
-
There are two possible interpretations of X hours Y minutes Z seconds:
- (xyz×3600×60) seconds3
- (x×3600 + y×60 + z) seconds
Wolfram|Alpha chose "neither".
-
There are two possible interpretations of X hours Y minutes Z seconds:
(xyz×3600×60) seconds3
(x×3600 + y×60 + z) seconds
Wolfram|Alpha chose "neither".
Well, clearly, there are more than two possible interpretations, neh?
-
the problem is the unitless 97971. put it in frames and then put frames per second instead of Hz.
both adding as
(((3 hours + 22 minutes + 7.49 seconds)(50 frames per second)) - 97971 frames) / (48 frames per second)
or
(((3 hours 22 minutes 7.49 seconds)
(50 frames per second)) - 97971 frames) / (48 frames per second)
work fine if you do it right.
(I am buttuming that you mean frames per second when you put Hz)
-
TRWTF may be using a tool like Wolfram Alpha for something that a simple calculator can handle. Alpha is clearly too complicated for its own good.