Oddly I'm having the inverse problem to many similar posts; I'm trying to use JodaTime (on Android) to give me a dd:hh:mm:ss type output and failing miserably. Code is;
public String GetEventTimeString(boolean withMS, int eventTime)
{
Period p = new Period(eventTime, PeriodType.yearMonthDayTime());
if (withMS)
return _formatter_withms.print(p);
else return _formatter_withoutms.print(p);
}
When I use the debugger to halt after p is set, I see that p itself has the hours value set to 568 and the days value is zero, so I've not posted the code that creates the formatters. eventTime is an int representing elapsed time in ms and has a value of 2045489151 in this case.
In case there's some oddity with the size of the number and the fact it's an int instead of a long, I tried making a new Period(1500000L, PeriodType.yearMonthDayTime()) and got a period of 0 days, 25 hours, 0 minutes and seconds.
Exploring the structure of the iType member of the period, I see an array iTypes containing elements "years", "months" etc. I also see an array iIndices which appears to map types to elements in some other array. Most indices make sense, but the index corresponding to "Days" is -1. So it seems PeriodType.yearMonthDayTime() isn't doing what I think the docs say it should.
If I try PeriodType.yearWeekDayTime I get the same result. If I try PeriodType.yearWeekDay then the three fields are zero with my 25 hour test value. So it's not just the one PeriodType that's misbehaving.
Wondering about the coincidence of getting exactly 25 hours from my fairly arbitrary (picked a number and kept adding zeroes) 1500000ms, I tried 1510000 and got 25h 10m 0s. But neither of those actually makes any sense when you work the conversion manually!
This is on Android, up to date Android Studio 1.3.2, not sure how to tell what version JodaTime I'm using but it's within the last few months and this seems a bit too glaringly obvious to be an obscure bug- more a combination of misunderstanding and digging too deep on my part I think.
Does anyone have any thoughts on what's going on?
Well, Joda-Time says about the normalization of a millisecond-based period:
Creates a period from the given millisecond duration. Only precise
fields in the period type will be used. Imprecise fields will not be
populated.
Here the question arises: Is the day unit a precise field in context of Joda-Time? No because a day can have 23 or 25 hours when it comes to switching daylight-saving time on/off in many countries (in reality there are even more possibilities like 23.5 hours etc). So the constructor you call does not fill the day-unit-field.
How can you get the desired normalization effect? Just do this recommended approach (no normalization in constructing the period):
long eventTime = 2045489151;
Period p = new Period(eventTime, PeriodType.millis());
System.out.println(p); // PT2045489.151S (no normalization)
System.out.println(p.normalizedStandard(PeriodType.dayTime()));
// P23DT16H11M29.151S
System.out.println(p.normalizedStandard(PeriodType.yearMonthDayTime()));
// P23DT16H11M29.151S ( the same result as one line before, not the best period type)
It is for debate IMHO that the Period-constructor, you used does a partial normalization. In my opinion either a full normalization using the given period type or no normalization at all (preferred by me - just leaving the milliseconds as millis, but then the second constructor argument is simply silly) would have been a wiser design decision. Interestingly (and confusing, too), the constructor without explicit period type argument does a partial normalization, too. To avoid premature incomplete normalization in constructor, you have to explicitly specify the period type as PeriodType.millis(). Sorry for your confusion.
Related
I'm actually using Math.sin() in my android app to calculate a sinus of a given angle (using Math.toRadians(angle_in_degrees)). For exemple when I want to get the Math.cos(90) which is 0, the result is 6.123233... E-17. Thanks you.
For floating point numbers, the system can often only approximate their values. For instance, the system would return something like 0.333333 for the expression (1.0 / 3). The number of 3s after the decimal point will be different depending on whether you're a floats or doubles, but it will still be limited to some finite length.
If you're just displaying the value, then you can limit the number of digits using something like String.format("%0.2f", value) or by rounding it using one of the rounding functions such as Math.round().
The tricky part comes when you need to compare the value to something. You can't just use if (value == some_constant) or even if (value == some_variable). At minimum, you usually have to use something like if (Math.abs(value - some_constant) < 0.001). The actual value of the '0.001' depends on the needs of your particular application and is customarily defined as a named constant.
For more complicated needs, you can implement the algorithm in the Floating-Point Guide.
You're getting back an approximation from Math.cos(Math.toRadians(90)) which is
6.123233... E-17 == 0.00000000000000006123233... which is basically 0
The following link should help clear things up as far as the precision of doubles/floats in programming.
http://www.java67.com/2015/09/float-and-double-value-comparison-in-java-use-relational.html
I want to know what is the appropriate process of converting Amplitude to dB. I am using double as below
db = (20 * Math.log10(mediaRecorder.getMaximimAmplitude));
But there are suggestions to use double as below
db = (20 * Math.log10(x2 / REFERENCE));
I dont know what reference is to use in which scenerio
The decibel is a much misused unit. It is defined as the 10 log (P1/P2) where P1 is the measured power, and P2 is the reference power. That is, it is always relative to some reference power. A common reference power is one milliwatt, and this is the definition of dBm. 0dBm is one milliwatt; +30dbm is one watt. Don't be misled by the oft-quoted "0dBm = one milliwatt in 600 ohms". This is an artifact of when voltage measuring devices were used to display dBm. Because they were voltage measuring rather than power measuring, an impedance at which they read correctly needed to be specified, and it was nearly always 600 ohms.
Over the years dB usage has been stretched to cover situations where having a logarithmic unit is really useful. For instance the voltage gain of an amplifier may be quoted in dB, using the formula 20log(Vout/Vin). In this situation, the input and output impedances (and hence powers) are often vastly different, so the usage is technically wrong. In practice it is a convenient unit to work with, and has been given some legitimacy by labeling it dBv.
The first formula you are using will return dB referenced to 1 volt in whatever impedance your circuit exhibits. This is fine, but it won't be dBm. Often this does not matter, as you just need to graph gain in dB against an arbitrary reference.If you need it to be dBm just find the circuit impedance and use Ohms law to work out what voltage represents one milliwatt in that impedance.
The second formula is a bit strange. What is x2? I would expect the formula to be 20log(Vmeasured/Vreference).
I am beginner and trying to write some calculations with App Inventor 2.
I am trying to write a code to calculate Net present value.
The formula of NPV = - investment + CF/(1+i)power up by years of investment, which means if years of investment are > 1 the second part of formula will repeat until it reached the number of years.
I successfully code the formula for one year that works correct, but have problem with the "repeating" the second part powered by number of years.
I tried to declare years as variable to use it as powering number but think something is wrong with it.
In my opinion I need to split the powering number somewhere to memory and then increase it by 1 until the required number. However have no clue how to do it.
Can anyone help?
Screenshot of the blocks
Following the calculation from the NPB Calculator,
this is converted into blocks the following
Note: for a better clarity and to avoid such long calculation blocks as in your screenshot, I used External Inputs instead of Inline Inputs, which is the default. You can switch that from the context menu after doing a right mouse click onto one of the calculation blocks.
EDIT: screenshot updated for changing cashflows using a list.See also
How to work with Lists by Saj and
How to work with Lists and Lists of lists (pdf) by appinventor.org
As a part of a larger aplication I am currently working on a decibel meters that takes the average sound level of a 10 second timespan.
To achieve this I made a CountDownTimer of 10 000 miliseconds that ticks every 100 miliseconds.
In each onTick event I update the textfield that shows the time left, and I also update the realtime decibel value.
My issue however is converting the maximum amplitude to decibels. I found the "power_db = 20 * log10(amp / amp_ref);" formula here on StackOverflow and I understand how it works, but I seem to always end up with a negative decibel value.
I understand that this is because of a wrong amp_ref value, but I am absolutely stumped on which one I should use. I found alot of different values on the web and none seem to do the trick.
Does anyone have any idea which reference amplitude I should use to get the correct decibel reading on my meter? The phone I am testing this on is a Google Nexus 5. For now it would be good enough if it only was a really accurate value on this phone if thats of any help.
The code I have in my onTick event is the following (I removed the formula for now since it seemed to be wrong anyways):
public void onTick(long ms) {
meetBtn.setText(String.valueOf((ms/1000)+1));
amplitude = mRecorder.getMaxAmplitude();
decibelView.setText(String.valueOf(amplitude));
}
If anyone has any tips or needs more information, please let me know!
Thanks in advance! :)
Negative decibels are fine, because it's a relative measure anyway. In fact it's a common practice to take the maximum possible amplitude as a reference point and as a result have decibels go from 0 down to negative space. Pro systems usually indicate positive decibels as an overload when clipping and distortions of sound may occur.
So for example if your amplitude range is 0 to 1 (an accepted float-PCM standard), then your amp_ref would be 1 and your decibel values will go from some negative value that depends on the bitness resolution of your source (e.g. -186dB for 32 bit, or -90dB for 16-bit source), up to 0dB. This is normal!
Edit: actually, your float-PCM amplitude range is -1 to 1, but decibel calculation "drops" the minus sign and gives the same result for both negative and positive amplitudes.
I am wondering how would I be able to run a SQLite order by in this manner
select * from contacts order by jarowinkler(contacts.name,'john smith');
I know Android has a bottleneck with user defined functions, do I have an alternative?
Step #1: Do the query minus the ORDER BY portion
Step #2: Create a CursorWrapper that wraps your Cursor, calculates the Jaro-Winkler distance for each position, sorts the positions, then uses the sorted positions when overriding all methods that require a position (e.g., moveToPosition(), moveToNext()).
Pre calculate string lengths and add them into separate column. Then sort entired table by that that length. Add indexes (if you can). Then add extra filters for example you don't want to compare "Srivastava Brahmaputra" to "John Smith". The length are out of wack by way too much so exclude these kind of comparison by length as a percentage of the total length. So if your word is 10 characters compare it only to words with 10+-2 or 10+-3 characters.
This way you will significantly reduce the number of times this algorithm needs to run.
Typically in the vocalbulary of 100 000 entries such filters reduce the number of comparisons to about 300. Unless you are doing a full blown record linkage and then I would wonder why use Android for that. You would still need to apply probabilistic methods for that and calculate scores and this is not a job for Android (at least not for now).
Also in MS SQL Server Jaro Winkler string distance wrapped into CLR function perform much better, since SQL Server doesn't supprt arays natively and much of the processing is around arrays. So implementation in T-SQL add too much overhead, but SQL-CLR works extremely fast.